Céline Coutrix
email: celine.coutrix@imag.fr

Laurence Nigay
email: laurence.nigay@imag.fr

An Integrating Framework for Mixed Systems

Keywords: Mixed Systems, Mixed Object, Interaction Model, Characterization Space, Taxonomy

Technological advances in hardware manufacturing led to an extended range of possibilities for designing physical-digital objects involved in a mixed system. Mixed systems can take various forms and include augmented reality, augmented virtuality, and tangible systems. In this very dynamic context, it is difficult to compare existing mixed systems and to systematically explore the design space. Addressing this design problem, this chapter presents a unified point of view on mixed systems by focusing on mixed objects involved in interaction, i.e. hybrid physical-digital objects straddling physical and digital worlds. Our integrating framework is made of two complementary facets of a mixed object: we define intrinsic characteristics of an object as well as extrinsic characteristics of an object by considering its role in the interaction. Such characteristics of an object are useful for comparing existing mixed systems at a fine-grain level. The taxonomic power of these characteristics is discussed in the context of existing mixed systems from the literature. Their generative power is illustrated by considering a system, Roam, which we designed and developed.

Introduction

The growing interest for mixed interactive systems is due to the dual need of users to both benefit from computers and stay in contact with the physical world. Mixed systems can take various forms and include augmented reality, augmented virtuality, and tangible systems. Although mixed systems are becoming more prevalent, we still do not have a clear understanding of this interaction paradigm. In particular, we lack capitalization of our experience, comprehension of problems when explaining the choice of a design to other designers. In addition, we are not able to explore the design space in a systematic way, and as a result quite often find a better solution after the development is finished. Even though several conceptual results exist for understanding and designing such systems, they do not address the entire design and remain local, and are not related to each other. As a consequence, it is difficult to compare existing mixed reality systems and explore new designs.

Rather than present yet another taxonomy that would not improve the clarity of this domain, we capitalize on existing research in our framework:

• We encapsulate related works in order to provide a coherent, integrating and unifying framework. • We identify overlaps between existing studies, so that we can contribute to a better comprehension of the domain. • We refine existing taxonomies as well as identify new characteristics and uncover areas to be explored in the design space.

The basis of our integrating framework is that we take the viewpoint of the objects involved in interaction with mixed systems, namely mixed objects, i.e. hybrid physical-digital objects straddling physical and digital worlds. Our framework is therefore made of characteristics of mixed objects. The characteristics are useful for analysis and comparison of existing systems as well as for design: indeed the characteristics allow generation of ideas and choice of design alternatives. Since these characteristics are also used for design, we organized them according to two points of view of a mixed object that make sense for design: intrinsic and extrinsic characteristics. These two sets of characteristics enable designers to study the reusability of their design for different application contexts. Indeed intrinsic characteristics of a mixed object are not modified from one context to another, whereas extrinsic characteristics are modified.

In this chapter, we first recall our definition of a mixed object [START_REF] Coutrix | Mixed Reality: A Model of Mixed Interaction[END_REF][9] and then present the corresponding intrinsic characterization space of a mixed object while demonstrating its taxonomic power. We then focus on interaction with mixed objects [START_REF] Coutrix | Mixed Reality: A Model of Mixed Interaction[END_REF]: we present the resulting extrinsic characterization space of a mixed object and study its taxonomic power. The taxonomic power of our intrinsic and extrinsic characteristic framework is studied in the light of several existing mixed systems that we present in the following section. Finally, in the last section, we show how our characteristic framework is useful for the design, in the context of a new mixed system that we designed and developed.

Illustrative Examples

For demonstrating the taxonomic power of our framework, we rely on existing mixed systems. We purposely chose mixed systems that seemed similar at first glance. Indeed, the selected mixed systems support interaction with objects on a horizontal surface. These systems are from the literature (i.e., not designed using our framework) and are therefore unbiased examples for evaluating the taxonomic power of our framework.

NavRNA [START_REF] Bailly | NAVRNA : Viusalization -Exploration -Edition of RNA[END_REF] is a system for interacting with RNA molecules. As shown in Fig. 1 (left), biologists are gathered around a table equipped with a camera and a projector. The camera captures the positions of the blue tokens that the users hold and move in order to explore (i.e. move, turn, resize) the 2D view of RNA. Phicon [START_REF] Ullmer | The metaDESK: Models and Prototypes for Tangible User Interfaces[END_REF] stands for Physical Icons. In the Tangible Geospace [START_REF] Ullmer | The metaDESK: Models and Prototypes for Tangible User Interfaces[END_REF] (Fig. 1, center), the phicon is a tool shaped as the MIT Great Dome. Users hold and move it on the table, where a map of the campus is projected. In this way, the location of the Phicon on the table always corresponds to the location of the Dome on the map.

The reacTable [START_REF] Jordà | The reacTable: Exploring the Synergy between Live Music Performance and Tabletop Tangible Interfaces[END_REF] (Fig. 1, right) is used as a music synthesizer, where mixed cubes and tokens represent the synthesizer modules. Users can directly touch the surface with several fingers in order to interact. They can also hold and move, change the relative distance, orientation and relation of the objects on the table in order to control the synthesizer. When studying reactTable, we only consider the interaction with the objects. The table is augmented by a camera, which tracks the nature, location and orientation of the objects and by a projector for displaying animation corresponding to the state of the objects onto the surface. The music bottles (Fig. 2, left) are objects that are part of a music player system. Each bottle contains a musical part. When a music bottle [START_REF] Ishii | Bottles as a Minimal Interface to Access Digital Information[END_REF] is put on the table and opened, the corresponding music part is played. In addition, rear projected light corresponding to pitch and volume is displayed underneath the bottle on the table. The Digital Desk [START_REF] Wellner | Interacting with paper on the DigitalDesk[END_REF] is one of the first mixed systems and was partially developed. We consider the seminal drawing scenario (Fig. 2, center and right). The user draws a house with a regular pen on a regular sheet of paper on a table equipped with a camera and a projector. In Fig. 2 (center), the user starts drawing tiles on the roof, and then decides to use a "fill" paper button by pointing it towards the roof. She then presses the paper button, which is sensed by the camera. Then the roof is filled with tiles displayed by the projector. The resulting drawing is mixed, with physical parts, made by a pen, and a projected digital part. In Fig. 2 (right), the user erases projected tiles with a regular eraser thanks to the camera. The Actuated Workbench [START_REF] Pangaro | The Actuated Workbench: Computer-Controlled Actuation in Tabletop Tangible Interfaces[END_REF] is a table that embeds magnets. On this table, the user or the system can manipulate pucks. The manipulation of a puck can be indirect by using a trackball (Fig. 3, left) or direct by holding the puck (Fig. 3, center). PICO [START_REF] Patten | Mechanical Constraints as Computational Constraints in Tabletop Tangible Interfaces[END_REF] stands for "Physical Intervention in Computational Optimization". The system [START_REF] Patten | Mechanical Constraints as Computational Constraints in Tabletop Tangible Interfaces[END_REF] is similar to the actuated workbench, with a table embedding magnets and augmented by a camera and a projector above. The system computes the ideal positions of the pucks on the table and the magnets automatically move them towards these positions (Fig. 4). Furthermore the user can add physical constraints: For example in Fig. 3 (right), the puck cannot access the entire surface of the table.

Integrating Framework for Describing and Classifying Mixed Systems

Focusing on mixed objects involved a mixed system, our integrating framework is made of intrinsic and extrinsic characteristics of a mixed object. We first present the modeling of a mixed object and the induced intrinsic characteristic framework. We then put the mixed objects into interaction context and we expose the modeling of interaction with mixed objects. From this modeling of mixed interaction, we finally describe the extrinsic characteristic framework.

Modeling of a Mixed Object

Mixed objects are hybrid objects with a physical part, like a physical object, in addition to a digital part like a digital object. For describing mixed objects, we consider its physical and digital parts as well as the link between them. On the one hand, the user interacts with the physical part, because users belong to the physical world. On the other hand, the system can interact with the digital part of the object. Physical/digital properties are properties like shape, color, weight, etc. for physical properties and a digital image, a boolean value, etc. for digital properties. We describe the link between these properties with linking modalities and draw the definition of a linking modality from that of an interaction modality [START_REF] Vernier | A Framework for the Combination and Characterization of Output Modalities[END_REF]: Given that d is a physical device that acquires or delivers information, and l is an interaction language that defines a set of well-formed expressions that convey meaning, an interaction modality is a pair (d,l), such as (camera, computer vision). The two levels of abstraction (device, language) constitute the basis of the definition of a linking modality. But in contrast to high-level interaction modalities used by the user to interact with mixed environments, the low-level modalities that define the link between physical and digital properties of an object are called linking modalities. Fig. 5 shows the two types of linking modalities (i.e., input/output linking modalities) in the example of the music bottle. An input linking modality allows the system to compute the presence and placement of the bottle on the table. The musical part is made perceivable by the user, through two combined output linking modalities. For the composition of the linking modalities we reuse the CARE (Complementarity, Assignment, Redundancy and Equivalence [START_REF] Vernier | A Framework for the Combination and Characterization of Output Modalities[END_REF]) properties: in the music bottle example, the composition of the two different output linking modalities corresponds to a case of a partial redundancy.

Mixed Object: Intrinsic Characterization

Based on the modeling of a mixed object, our intrinsic characteristic framework applies to a mixed object without considering its context of use in a particular interactive mixed system. We consider related studies and show how our characterization scheme unifies such approaches. Existing characteristics including affordance [START_REF] Norman | Affordance, Conventions and Design[END_REF], expected and sensed actions [START_REF] Benford | Expected, Sensed, and Desired: A Framework for Designing Sensing-Based Interaction[END_REF], characteristics of devices [START_REF] Buxton | Lexical and pragmatic considerations of input strcutures[END_REF] [START_REF] Mackinlay | A Semantic Analysis of the Design Space of Input Devices[END_REF] and languages [START_REF] Bernsen | Taxonomy of HCI Systems: State of the Art[END_REF] [24], bounce-back physical properties [START_REF] Dix | Modeling Devices for Natural Interaction[END_REF], and some aspects of composition of physical properties [START_REF] Fishkin | A taxonomy for and analysis of tangible interfaces[END_REF][11]) fit in our modeling of a mixed object. More interestingly, this modeling leads us to identify new characteristics, such as generated physical properties, acquired and materialized digital properties, bounceback digital properties and some aspects of composition of physical properties. This clearly states our contribution: we provide a unifying framework that organizes various existing characteristics into a single unifying framework and we further identify new characteristics.

Based on our modeling of a mixed object, we present our integrating framework by starting with the characteristics of the linking modalities. We then consider the characteristics that apply to the physical and digital properties.

Characteristics of the Linking Modalities (Devices and Languages)

As our approach capitalizes on existing studies, we reuse the results from multimodal interaction studies for characterizing the two levels of abstraction of a linking modality. Taxonomies of devices [START_REF] Buxton | Lexical and pragmatic considerations of input strcutures[END_REF][17] are applied to characterize input and output linking devices. Frameworks described in [START_REF] Bernsen | Taxonomy of HCI Systems: State of the Art[END_REF][24] can also be applied for the linking languages: a language can be static or dynamic, linguistic or not, analogue or not (similarity with the real world or not), arbitrary or not (need to be learned or not), deformed or not (like "how r u?" as opposed to "how are you?"), local or global (only a subset of the information is conveyed or all the information). Our framework also allows study of the relationship between devices and languages [START_REF] Dubois | A Design-Oriented Information-Flow Refinment of the ASUR Interaction Model[END_REF]. For example, is the precision of the device lost through the language? Finally, we also capitalize on research on multimodality to characterize composition of modalities with the CARE properties (Complementarity, Assignation, Redundancy, Equivalence) [START_REF] Vernier | A Framework for the Combination and Characterization of Output Modalities[END_REF]. For example we can immediately make the difference between the eraser in the Digital Desk (Fig. 2, right) and the music bottle (Fig. 2, left): the latter has a multimodal output link, whereas the first one does not.

Focusing on the relationships between input and output linking modalities of a mixed object, our model generalizes the temporal relationships identified in [START_REF] Fitzmaurice | Bricks: Laying the foundations for Graspable User Interfaces[END_REF]. Indeed we refine the temporal coupling characterization from tightly/loosely coupled [START_REF] Fitzmaurice | Bricks: Laying the foundations for Graspable User Interfaces[END_REF] to five possibilities: linking modalities can be asynchronous, in sequence, concomitant, coincident, or in parallel [START_REF] Vernier | A Framework for the Combination and Characterization of Output Modalities[END_REF]. Moreover spatial coupling of input and output linking modalities has been studied as Continuity in [11], Embodiment in [START_REF] Fishkin | A taxonomy for and analysis of tangible interfaces[END_REF], or as Physical & Virtual Layers in [START_REF] Fitzmaurice | Bricks: Laying the foundations for Graspable User Interfaces[END_REF]. As for temporal relationships, we extend these existing frameworks by considering five spatial relationships [START_REF] Vernier | A Framework for the Combination and Characterization of Output Modalities[END_REF]: the input and output space of a mixed object can be either separate, adjacent, intersecting, overlaid, or collocated.

Characteristics of the Physical Properties

We use four intrinsic characteristics for physical properties, namely affordance of, bounce-back, sensed/generated, and aspects of composition of physical properties.

Affordance and Expected Changes

Affordance [START_REF] Norman | Affordance, Conventions and Design[END_REF] is defined as the aspect of an object that suggests how the object should be used. A flat object can be translated on a table. Expected/non-expected actions [START_REF] Benford | Expected, Sensed, and Desired: A Framework for Designing Sensing-Based Interaction[END_REF] are also those we expect the user to do with an interface. Considering the physical properties, these characteristics allow us to identify a simple difference between the examples of Section 2: if we consider the symmetry of rotation of the objects, we have on the one hand objects like the tokens in NavRNA, the pucks in the actuated workbench and PICO, that are invariant when rotated. On the other hand we find the Dome Phicon, the cubes of the reacTable, the music bottles, and the objects used in the Digital Desk that are not symmetrical. Based on this absence of symmetry, we expect the user to rotate the objects of the second category more often.

Bounce-back physical properties

A bounce-back button, introduced in [START_REF] Dix | Modeling Devices for Natural Interaction[END_REF], is a button that rebounds, like a spring or a rubber band, and goes back to its initial position. Some objects have this physical property, like a simple light switch. Within our model, a physical property can be bounce-back, like the physical location in PICO: Even if the user puts it in a particular position, it tries to go back to its ideal position.

Sensed/Generated physical properties

Sensed actions [START_REF] Benford | Expected, Sensed, and Desired: A Framework for Designing Sensing-Based Interaction[END_REF] are those that can be captured by the system. Sensed actions and sensed physical properties are related: a sensor does not sense an action but some physical properties from which the system can identify actions. In our framework, sensed physical properties are properties that are captured by any input linking modality. We draw on our capitalization of sensed actions into our description of mixed objects in order to also characterize generated physical properties (those that are made physical by any output linking modality). We characterize physical properties with two orthogonal sensed/generated axes as schematized in Fig. 6. The sensed/generated characteristics of physical properties correspond to the "Input&Output" axis described in [START_REF] Fitzmaurice | Bricks: Laying the foundations for Graspable User Interfaces[END_REF] ("what properties can be sensed and displayed back to the user (or system)?"). If we consider the physical location of the mixed objects presented in Section 2, we obtain the classification presented in Table 1. All these objects share this physical property: they all have a physical location. For almost all these objects, their location is sensed, but it is also generated for two types of objects: those in PICO and Actuated Workbench. Studying the location of the objects in lights of our framework leads us to three main classes of mixed systems. Towards a more detailed classification, we consider another physical property: the color. In examples like NavRNA or reacTable, the color is sensed by the camera and is used by the language of the input linking modality to compute the location of the object. In the case of the reacTable the modality tracks markers, so their color cannot be changed at all, or can be changed in a very limited way. Similarly for NavRNA, the color cannot be changed. In examples like the Music Bottles, PICO and Actuated Workbench, the color is not sensed: the system senses the infrared light emitted by the objects for the later, and an electromagnetic resonator tag is used for the Music Bottles. Contrastingly, color is generated for these three systems. Finally for the case of the Tangible Geospace, the color is neither generated nor sensed -infrared is used instead. Note that we do not consider the Digital Desk example for this physical property since this part of the system was not developed. By considering the color property, we then obtained three classes of systems as shown in Table 2.

Aspects of the composition of physical properties

Based on the spatial and temporal composition of linking modalities, we can characterize at the physical level the coupling between sensed and generated physical properties. More interestingly, we can also consider the spatial and temporal compositions of those sensed/generated physical properties with the non-sensed/nongenerated physical properties. This relation has five possibilities: properties can be asynchronous, in sequence, concomitant, coincident, or in parallel (temporal aspects) or either separate, adjacent, intersecting, overlaid, or collocated (spatial aspects) [START_REF] Vernier | A Framework for the Combination and Characterization of Output Modalities[END_REF]. For example the generated display of the reacTable cube is adjacent to the nongenerated part of the object (Fig. 1, right), whereas in the actuated workbench in computer vision mode (Fig. 3, center), the generated display is collocated with the non-generated part of the object.

Characteristics of the Digital Properties

We use two intrinsic characteristics for digital properties, namely acquired/materialized and bounce-back digital properties.

Acquired/Materialized digital properties

By considering the digital properties symmetrically to the sensed/generated physical properties, we characterize digital properties with two orthogonal acquired/materialized axes as schematized in Fig. 6. A digital property can be acquired and/or materialized by any input/output linking modality. This set of characteristics is independent of the types of linking modalities.

We consider the example of the digital property corresponding to the location. For most of our examples, this property is a pair of coordinates (x, y). The music bottle is the only object that does not need such a precise location. The system only needs to know the area (one of the three defined parts of the table). If we consider in Table 3 the Actuated workbench in mouse mode (Fig. 3, left), in this case the digital location is not acquired: it is updated indirectly through a tool, and therefore the object has no input linking modality acquiring this digital location. The other examples in Table 3 show that the digital location of the mixed object is acquired. Yet, for example like the Actuated Workbench in computer vision mode, the reacTable and PICO, the digital location is materialized through a projection on the table. In contrast to the others, the system does not provide observability of the state of the object: the acquired digital location is not materialized. Through this example, we are then able to more finely classify the examples of Section 2: for example the difference between the NavRNA and reacTable tokens is based on the affordance of the physical properties and whether the digital location is materialized or not.

Bounce-back digital properties

We generalize the bounce-back characteristic to the case of digital properties. Digital properties can also behave like a spring and when modified, go back to their initial value after a specified time. For example, we previously explained that the physical location of the mixed objects in PICO was a bounce-back physical property. This can be explained by the fact that the physical position of the pucks is generated from the digital location. The digital location corresponds to the stability value and is therefore a bounce-back digital property. This implies that the corresponding generated physical property is also characterized as a bounce-back physical property.

As a conclusion, Table 4 summaries the intrinsic characteristics of a mixed object. By characterizing a mixed object, we have shown that our framework generalizes and refines several existing frameworks and identifies overlaps between them. We therefore showed that our description of a mixed object provides a unifying framework for capitalizing existing studies. We also showed that it enables us to identify new characteristics. We demonstrated that these new characteristics of a mixed object are useful elements to finely classify existing systems.

Modeling Mixed Interaction: Putting Mixed Objects Into Interaction Context

A mixed interaction involves a mixed object. An object is either a tool used by the user to perform her/his task or the object that is the focus of the task. To model mixed interaction, we enrich the instrumental interaction model [START_REF] Beaudoin-Lafon | Designing Interaction, not Interfaces[END_REF] with the notion of interaction modality (d, l) [START_REF] Vernier | A Framework for the Combination and Characterization of Output Modalities[END_REF]. We study the two types of mixed objects, namely mixed tool and mixed task object, involved in the interaction in light of a definition of an interaction modality [START_REF] Vernier | A Framework for the Combination and Characterization of Output Modalities[END_REF] as the coupling of a physical device d with an interaction language

• A mixed tool is a device of a given modality. In Fig. 7 (in gray) the mixed tool is a device d coupled with an interaction language l that will translate the action into an elementary task. • A mixed task object is manipulated by the user by means of an interaction modality. For example, in Fig. 7 we consider the example of the Digital Desk of Fig. 2

(left).

The user is handling and moving the eraser -the mixed tool. This action on the physical properties of the object is sensed by the input linking modality (camera, computer vision) in order to update the digital properties <location> and <recognized movements>. The changes of the digital properties of the mixed tool are interpreted by the interaction language into an elementary task: (x,y) location is translated into "erase drawing located at (x, y) on the table". This elementary task is applied to the task object and the digital properties of the mixed drawing are consequently modified. The mixed drawing shows its internal digital changes by updating display through its output linking modality -the feedback.

Mixed object: Extrinsic Characterization

Extrinsic characterization concerns the aspects of a mixed object specific to its use in a particular application. We first consider the object as a whole in the interaction and show how we can characterize its role. We then focus on the part of a mixed object that serves as an interface to its outside environment: the physical and digital properties. As for the intrinsic characterization framework, we show how related studies fit in our description of a mixed interaction. We capitalize on existing characteristics (roles [START_REF] Dubois | A Design-Oriented Information-Flow Refinment of the ASUR Interaction Model[END_REF][3], metaphors [START_REF] Fishkin | A taxonomy for and analysis of tangible interfaces[END_REF], physical constraints [START_REF] Shaer | The TAC Paradigm: Specifying Tangible User Interfaces[END_REF][23], desired actions for an application [START_REF] Benford | Expected, Sensed, and Desired: A Framework for Designing Sensing-Based Interaction[END_REF]) in our characterization framework. Moreover, our description leads us to identify new characteristics, such as a new dimension for metaphors, output physical ports and input digital ports.

Characteristics of the Roles

As identified in the ASUR (Adapter, System, User, Real object) design notation for mixed systems [START_REF] Dubois | A Design-Oriented Information-Flow Refinment of the ASUR Interaction Model[END_REF] and in the instrumental interaction model [START_REF] Beaudoin-Lafon | Designing Interaction, not Interfaces[END_REF], an object can play two roles in interaction: it is either a tool used by the user to perform her/his task or the object that is the focus of the task (i.e., task object). In our examples of Section 2, this enables us to distinguish two categories of objects. On the one hand, the tokens in NavRNA and the Dome Phicon are tools. On the other hand the music bottle is the object of the task.

Characteristics of the Physical Properties

We use three extrinsic characteristics for physical properties, namely noun metaphor of, ports of and aspects of composition of the physical properties of mixed objects.

Noun Metaphor

In [START_REF] Fishkin | A taxonomy for and analysis of tangible interfaces[END_REF], the noun metaphor is defined as "an <X> in the system is like an <X> in the real world". To assess the noun metaphor based on the modeling of mixed interaction, we study how the physical properties reflect the task performed with the mixed object. For example in Fig. 7 (dotted dark gray), the physical properties of the eraser reflect the task: erasing. The Dome Phicon belongs to the same category, as opposed to the tokens of NavRNA, the cubes of the reacTable and the pucks of PICO.

Instead of considering only the metaphor with the "real" natural world, we consider a continuum from this real-world metaphor to digital practice based metaphors, putting thus on equal footing physical digital worlds. For example, in the Digital Desk [START_REF] Wellner | Interacting with paper on the DigitalDesk[END_REF], the user interacts with a mixed tool made of paper that looks like a digital button in GUI.

Moreover, we also consider the command and its parameters as two different metaphors. For example for the case of the Dome Phicon, the physical properties reflect the parameter of the task "move the location of the dome of the map to (x,y)". In contrast the digital properties of the eraser reflect the command itself.

Ports

Physical input ports are related to the affordance of the object. Affordance [START_REF] Norman | Affordance, Conventions and Design[END_REF] is defined by the physical properties that the user can act on. Some of these actions might be impossible because of external constraints, as defined in [START_REF] Shaer | The TAC Paradigm: Specifying Tangible User Interfaces[END_REF][23] [START_REF] Patten | Mechanical Constraints as Computational Constraints in Tabletop Tangible Interfaces[END_REF]: the corresponding physical ports are closed (i.e., not fully open). As explained in [START_REF] Patten | Mechanical Constraints as Computational Constraints in Tabletop Tangible Interfaces[END_REF]:

• On the one hand, some physical input ports can be closed in order to guarantee data that can be processed by the input linking modality. This can be done to overcome some technological limitations: For example in most of our examples, the position of an object on a table is constrained so that it does not get out of range of the camera. • On the other hand the user can close some physical input ports explicitly in the interaction process, as in [START_REF] Patten | Mechanical Constraints as Computational Constraints in Tabletop Tangible Interfaces[END_REF] when the user puts an object filled with sand on a mixed puck in order to prevent it from moving.

extend this characterization of physical ports by also considering the output physical ports. Output ports define properties exported by a mixed object. For example, if we consider the generated physical property corresponding to the display projected onto the table of the systems of Section 2, the output ports can be partially closed according to the kinds of projection (from the top, from behind). Indeed with a projection from the top, as in the Digital Desk, the actuated workbench and PICO, the users' hands or head may hide some parts of the projection. In contrast, with a rearprojection, as for the reacTable and the music bottle, output ports are always open.

Aspects of the composition of mixed objects

As part of the intrinsic characterization framework of a mixed object, we described the spatial and temporal coupling of a mixed object by focusing on the relationships between its physical properties. Symmetrically, at the extrinsic level, we also study the spatial and temporal relationships between properties of different mixed objects. For example we can study the spatial relationships between the physical properties of the mixed drawing and the mixed eraser in the Digital Desk and compare it with the relationships between the physical properties of the NavRNA tokens and the projected RNA molecule, or with the relationships between the Dome Phicon and the map. All pairs of objects are adjacent, in contrast to the reacTable Indeed the cubes and the synthesized sound are spatially overlaid -Where we can perceive the cubes, we can perceive the sound, but the reverse is not always true -.

Characteristics of the Digital Properties

We use two extrinsic characteristics for digital properties, namely verb metaphor of and ports of the digital properties of a mixed object.

Verb Metaphor

In [START_REF] Fishkin | A taxonomy for and analysis of tangible interfaces[END_REF], the verb metaphor is represented by the phrase "<X>-ing the object in the system, is like <X>-ing in the real world". To assess the verb metaphor, we study if the acquired digital properties reflect the task performed with the mixed object. For example in Fig. 7 (dotted light gray), the acquired digital property <recognized movements> of the mixed eraser reflects the task. Note that in this particular example, there is both a noun and a verb metaphor, but we can consider them independently. For example the eraser in the Digital Desk could be used without the verb metaphor, by putting the eraser on the drawing in order to erase the designated area, without moving it like an eraser. The mixed cork of a music bottle belongs to the same category.

Ports

Output digital ports define digital properties exported by a mixed object towards an interaction language. For example in Fig. 7, the mixed eraser exports the location of the eraser (x,y), that is then transformed by the interaction language to obtain the final task. The output digital port corresponds to the notion of "desired actions" in [START_REF] Benford | Expected, Sensed, and Desired: A Framework for Designing Sensing-Based Interaction[END_REF]. We further identify input digital ports. Indeed the application context can modify and/or prevent possible values of a digital property through the interaction language.

The input digital port is then open or closed. For example, the blue tokens in NavRNA and the Dome Phicon in the Tangible Geospace have no input digital port, the cubes in the reacTable do: the system can modify digital properties of some cubes, by adding an extra circular tool on the table that controls one of its digital property. Fig. 8 shows this case with a sinusoidal Low Frequency Oscillator controlling a band pass sound filter.

As a conclusion, by characterizing extrinsically a mixed object based on our modeling of mixed interaction, we have shown that our framework encompasses and extends existing frameworks. Table 5 summaries our extrinsic characteristic framework. Our integrating framework is made of both intrinsic and extrinsic characteristics of a mixed object. Table 4 and 5 respectively list the identified intrinsic and extrinsic characteristics. Based on this integrating framework, we are able to classify the existing mixed systems. To conclude on the taxonomic power of our framework, Table 6 shows how the examples of Section 2 differ from each other based on the identified intrinsic and extrinsic characteristics. In this Table , we see that the framework allow us to find at least one characteristic to make a difference between systems. Finally each system belongs to a single category, even if they were chosen similar at the beginning.

Integrating Framework for Designing Mixed Systems: the Case of Roam

Having presented our framework and studied its taxonomic power, we now focus on the design and illustrate the generative power of our framework. We purposely choose for our design example an application that is of a radically different type than the considered existing mixed systems of the previous section. The considered mixed system that we designed and developed is Roam, a mobile recording system. We designed developed Roam as part of a multidisciplinary project involving a designer and computer scientists. Roam is a mobile mixed system for recording (pictures, sounds). Even if users already use camera for recording images as keepsakes, the intention during the design of Roam is to have a tool that does not distract user's attention from the world. With commonly used recording tools, like camera, people focus on the tool in order to record a souvenir. In contrast Roam is intended to stay in the background of the focus of attention and not to distract the user from the facts of interests.

Puck (vision A green LED allows her to know if the tool is actually recording. of the record is not planned in Roam but can be done using a computer (i.e., after using Roam).

) (3) (1) (1) (10) (1) (1) (6)

Extrinsic Design

This tool is be used in a mobile context. We therefore need to avoid obtrusiveness. Apart from its role, some extrinsic characteristics are yet to be explored. We selected examples from the characteristics of our framework: the noun metaphor and the digital/physical ports. We first present the example of exploring the different types of noun metaphors. A noun metaphor can be to a command such as the eraser of the Digital Desk or to a parameter of the such as the Dome Phicon of the Tangible Geospace. We also identify a continuum from the real-world metaphor to digital practice based metaphors. For the Roam tool, this helped us to generate six ideas, presented in Table 7. We chose the octopus because it fitted better in the hand of the user.

We now consider the input digital ports. Exploring the design space along our characterization framework, we identified the need for an output digital port -isOn. Apart from this required output port, our design space drove our attention to the possibility of having a digital input port in our tool. It inspired us to come up with the idea of a response from the task object (the record) towards this tool: the tool contains a digital property that conveys the success of the record action. If this input digital property is then materialized, this enforces the observability principle [START_REF] Abowd | Structuring the Space of Interactive System Properties[END_REF] as we argued in [START_REF] Coutrix | Mixed Reality: A Model of Mixed Interaction[END_REF]. We chose to have an input digital port, named isOk. We now consider the examples of exploring the physical properties of the tool and its output physical ports. The framework enabled us to explore physical properties that can be output ports. We explored alternatives and found sound and light: beeping (Fig. 10, left) and blinking (Fig. 10, center and right).

For our mobile tool, this also highlights which and how physical properties are going to be perceivable in the context of use. For example the sound of the loudspeakers can be too intrusive according to the environment: the others can hear it. Moreover, depending on how the tool is handled by the user, the physical properties generated by the LEDs can be hidden (Fig. 10,right). Thus we studied the placement of the LED as shown in Fig. 9 (left and center) and 10 (center).

the design space thanks to the dimensions identified with our framework gave rise to the design of alternatives that were not envisioned at first sight. It thus assisted us in exploring the extrinsic design space. We now present the intrinsic design of this tool.

Intrinsic Design

We first consider the example of the bounce-back characteristic for digital properties. We already identified, thanks to extrinsic design, two digital properties: an output port isOn and an input port isOk. From the intrinsic viewpoint on design, we can study if the two properties are bounce-back or not. Given that the output linking language turns the yellow LED on as long as isOn is true, if isOn is bounce-back, then the yellow LED only blinks once. If isOn is not bounce-back, then the yellow LED is on as long as isOn is true. In our design, we chose isOn not to be bounce-back. On the contrary, we chose isOk to be bounce-back: according to the output linking language, if the user wants to be sure the system is recording, she has to have a quick look at the green LED when she bends the tentacle.

We can also consider the composition of the physical properties. Thanks to our framework, we can envision multiple spatial compositions of the physical properties of the tool. They can be collocated and adjacent (Fig. 9, left and center) or separated, manipulated by the two hands (Fig. 9, right).

In this section we showed how the new characteristics we identified thanks to our framework were useful for the design of a tool. The characteristics allow generation of ideas by suggesting different types of alternatives. We chose to only illustrate the new characteristics identified with the framework, but the complete framework was used to design Roam. We studied the reusability of our intrinsic design for a different application context: Indeed the Roam tool can be used for interaction with Google Earth, which is a completely different application. However in this context, intrinsic characteristics of the tool are not modified. For example, the digital property isOn is still not bounce-back. On the contrary, some extrinsic characteristics are modified: Google Earth does not enable the property isOk to be an input digital port. These ideas show the benefits of using the framework for design.

Conclusion

This chapter has introduced a new way of thinking of interaction design of mixed systems in terms of mixed objects. We presented intrinsic and extrinsic characteristics of a mixed object, the object being a tool or a task object. By showing how this characteristic framework enables us to classify existing similar systems, we demonstrated the taxonomic power of our framework. We also illustrate the generative power of our framework by considering the design of a mixed system, Roam. In addition to Roam, the has also been used to design other mixed systems such as ORBIS [START_REF] Coutrix | Balancing Physical and Digital Porperties in Mixed Objects[END_REF], RAZZLE [START_REF] Coutrix | Mixed Reality: A Model of Mixed Interaction[END_REF] or Snap2Play [START_REF] Chin | Snap2Play: A Mixed-Reality Game based on Scene Identification[END_REF]. Moreover we are currently conducting an evaluation of our framework by considering the design of objects for exhibits in museums.

Several characteristics of our framework come from related work. Our contribution lies in the capitalization of these results into a single unifying/integrating framework and in the identification of new characteristics. However a more thorough analysis of mixed systems could lead to extensions of the framework with new intrinsic or extrinsic characteristics of mixed objects and to a better assessment of its limitations.

As on-going work, we are focusing on the design of mixed objects based on our framework. Design relies on both "thinking it through" and "working it through". We are working on putting the conceptual framework in operation for designing by prototyping. A toolkit for building mixed objects explicitly based on the underlying concepts of the framework is under development. The toolkit covers existing development frameworks and toolkits and provides modularity, and extensibility. This toolkit will enable us to quickly develop prototypes that look like and work like the intended designed mixed object, as illustrated with the Roam system.

Fig. 1 .

 1 Fig. 1. NavRNA (left), the MIT Great Dome Phicon in the Tangible Geospace (center), the reacTable (right).

Fig. 2 .

 2 Fig. 2. The music bottles (left), filling a drawing (a roof with tiles) with the Digital Desk (center) and erasing a part of the drawing with the Digital Desk (right).

Fig. 3 .

 3 Fig. 3. The actuated workbench (left and center) and PICO used with constraints (right).

Fig. 4 .

 4 Fig. 4. The PICO system tries to have an equilateral triangle: as the user moves one puck, the system change its position in order to form an equilateral triangle.

Fig. 5 .

 5 Fig. 5. Our description of the music bottle.

Fig. 6 .

 6 Fig. 6. Characterization of the sensed/generated physical and acquired/materialized digital properties of a mixed object.

Fig. 7 .

 7 Fig. 7. Interaction between the user, the mixed tool in (eraser) and the mixed task object (drawing) in the Digital Desk, and assessment of the noun (dotted dark gray) and verb (dotted light gray) metaphors.

Fig. 8 .

 8 Fig. 8. A token of the reacTable with a digital property controlled by another circular tool.

Fig. 9 .

 9 Fig. 9. Roam tool prototypes: close-up of final prototype with bend sensors and green/yellow LEDs (left), in the hand of the user (center). Another prototype of the Roam tool with separated physical properties (right).

Fig. 9 (

 9 Fig. 9 (left and center) shows the pictures of our prototype of the Roam tool for recording sound souvenirs. It fits in the hand of the user in an unobtrusive way. She

Table 7 .

 7 Exploring the design of the Roam tool thanks to the noun metaphor dimensions: the task is "record the sound" in contrast to "record the image". the design of Roam and show how our framework helps in exploring the design space by considering examples during the design process. Since we know the application context of the tool, we first focus on extrinsic design exploration of the Roam tool. We then present examples of intrinsic design exploration.

Fig. 10 .

 10 Fig. 10. Design alternatives for output ports: sound (left), light (LEDs in center and right).Focusing on the output ports: according to the way the tool is handled by the user, the lights may be hidden or not.

Table 1 . Studying the physical location of mixed objects in light of our framework.

 1

	Physical Location Generated	Non Generated
	Sensed	PICO	NAVRNA
		Actuated Workbench (in	Tangible Geospace
		computer vision mode)	reacTable
			Music Bottle
			Digital Desk
	Non Sensed	Actuated Workbench (in
		mouse mode)

Table 2 . Studying the color of mixed objects in light of our framework.

 2

	Color	Generated			Non Generated
	Sensed				NAVRNA
					reacTable
	Non Sensed	Music Bottle			Tangible Geospace
		PICO			Actuated Workbench
		Actuated	Workbench	(in	(in mouse mode)
		computer vision mode)

Table 3 . Studying the digital location in light of our framework.

 3

	Digital Location	Materialized	Non Materialized
	Acquired	Actuated Workbench (in	NAVRNA
		computer vision mode)	Tangible Geospace
		reacTable	Music Bottle
		PICO	Digital Desk
	Non Acquired	Actuated Workbench (in
		mouse mode)

Table 4 . Summary of intrinsic characteristics (our new characteristics are underlined).

 4

	Level	Characteristic	Possible Values
	Physical properties	Affordance, expectations
		Sensed	Yes/No
		Generated	Yes/No
		Bounce-back	Yes/No
		Compositions	Five schemas for the spatial aspects as
			well as for the temporal aspects
	Link	Multimodality	-Direction: in/out,
			-Number: integer,
			-CARE characterization
		Precision of device
		…
		Dynamicity of language	Yes/No
		…
	Digital Properties	Acquired	Yes/No
		Materialized	Yes/No
		Bounce Back	Yes/No

Table 5 . Summary of extrinsic characteristics (our new characteristics are underlined).

 5

	Level	Characteristic Possible Values
	Mixed Object	Role	Tool/Task Object
	Physical properties Noun metaphor Absence / Related to a command / Related to a
			parameter and related to natural to digital world
		Input ports	Open/Closed
		Output ports	Open/Closed
		Compositions	Five schemas for the spatial aspects as well as for the
			temporal aspects
	Digital Properties	Input Ports	Open/Closed
		Output Ports	Open/Closed
		Verb metaphor Absence / Related to command and related to natural
			to digital world

Table 6 . Classification of the existing systems of Section 2. In this table, for clarity purposes, we show only one difference based on a given characteristic between each system, while several characteristics can be applied to distinguish them. Our new characteristics are underlined. Differences are made by characterizing (1) sensed/generated physical location, (2) sensed/generated color, (3) materialized / non materialized digital location, (4) simple/multimodal output link, (5) affordance, (6) adjacent/collocated generated and non generated parts, (7) tool / task object role, (8) command/parameter noun metaphor, (9) digital input port and (10) physical output port (display can be hidden or not).

 6

	NavRNA Phicon PICO bottle drawing eraser reacTable Puck
	(

We would like to thank the authors of the example systems for using their illustrations, Jérôme Drouin, designer, for his participation in the Roam project and George Serghiou for reviewing the paper. The work presented in the article is partly funded by the "Plan Pluri-Formation" on Multimodal Interaction (financed by four Universities in Grenoble), by the French Research Agency under contract CARE (CulturalExperience: Augmented Reality and Emotion)www.careproject.fr and by the European Commission under contract OpenInterface (FP6-35182), www.oi-project.org.


E Ceret

S Dupuy-Chessa

G Godet-Bar

Using Software Metrics in the Evaluation of a Conceptual Component Model

Keywords: Information Systems, Human-Computer Interaction, Design Method, conceptual component, Quality, Metrics I

Every interactive system has a functional part and an interactive part. However the software engineering and the human-computer-interaction communities work separately in terms of methods, models and tools, which induces a work overhead for integrating the results of these efforts, as well as increased inconsistency risks. We endeavour to treat this problem by proposing a design method, which couples the functional kernel and the interaction design. In particular, this method proposes a specific way of structuring the interaction and the business spaces. The structure is based on components called Symphony Objects. In this article, we attempt to evaluate the technical aspect of a Symphony Object model issued from the method by measuring its implementations with software metrics.

INTRODUCTION

The evolution of computer technologies, in terms of communication (wireless networking) and interaction device (visualization headsets, tactile gloves) deeply alter the classical, implicit perception of Human-Computer Interaction (HCI). The users are now expecting adaptable and user-friendly interfaces. However, the methods are not all ready to design the interactional components of such HCI. Symphony is one of those methods, initially very strongly focused on business concerns, and augmented in the very last years for considering rich user interfaces [START_REF] Dupuy-Chessa | A Design process integrating mixed system into information systems, chapter of the book Engineering of Mixed Reality[END_REF].

The augmented version of Symphony was realized following some principles, mainly the use of reusable components early in the design process and a clear separation of concerns between the business and the human-computer interaction aspects. The latter principle has been applied for describing several software architectures, such as the Seeheim model [START_REF] Pfaff | Seeheim Workshop on User Interface Management Systems[END_REF] or MVC [START_REF] Dupuy-Chessa | A Design process integrating mixed system into information systems, chapter of the book Engineering of Mixed Reality[END_REF]. Following this principle, the augmented version of Symphony features a separation of the design of the information system and that of its human-computer interface as early as the specifications phase. Therefore, the method specificies two distinct sub-processes for describing business and interaction conceptual components, which are respectively called Business Objects [START_REF] Hassine | Symphony: a conceptual model based on business components[END_REF] and Interactional Objects [START_REF] Godet-Bar | Interactional objects: Hci concerns in the analysis phase of the symphony method[END_REF]. During the following development phases, these concepts (which we gather around the term "Symphony Objects") are progressively refined into concrete components. Symphony Objects are a major contribution of the augmented Symphony method: they were imagined to provide the designer with simple, consistent, structured and reusable constructs and consequently to encourage the production of good quality software.

But first, we needed to validate this extension of Symphony. Proving the quality of a design method is a hard work, but D.L. Moody [START_REF] Moody | The Method Evaluation Model : a Theorical Model for Validating Information Systems Design Methods[END_REF] has proposed assessing a method by the evaluation of several of its aspects, from effectiveness to actual usage. Augmented Symphony was not ready for an actual use, so we decided to follow the first ones of his recommendations. As our method proposes a new way of structuring business and interaction spaces, we first needed to evaluate it in terms of its technical effectiveness (the extent to which the method improves the quality of the results): we evaluated if the method helps designers to produce good quality Symphony Objects models.

Many aspects of a model can be studied to determine its quality. The most immediate criteria are legibility, expressivity conciseness. In this work, we consider that a model is good if it gives rise to good quality in its implementations. Using this definition, our research question can be formulated as: does a structure in terms of Business and Interactional Objects obtained from the use of the Symphony method give rise to good quality in the resulting software ? We try to answer this question with an experiment that we describe in this article.

Before answering this question, we will study related work about model and software evaluation. We will describe the Symphony method, with its extensions for HCI aspects, and particularly the concept of Symphony Object. Then section IV describes an experiment to evaluate Symphony Objects, based on different implementation solutions. Finally, we analyze the results of this experiment and conclude on the contribution of this approach.

II. RELATED WORK

A. Evaluation of Conceptual Models

Considering the Symphony Object model as a conceptual model, we study related works on the quality of models. There is little agreement among experts to define what makes a "good" model. If we consider the definition of quality given by ISO 9000, Moody [START_REF] Moody | Theoretical and practical issues in evaluating the quality of conceptual models: current state and future directions[END_REF] proposes to define the model quality as "the totality of features and characteristics of a conceptual model that bear on its ability to satisfy stated and implied needs". These needs can be defined with characteristics, which are decomposed into sub-characteristics following the ISO approach. For example, according to Lange & Chaudron [START_REF] Lange | Managing Model Quality in UML-based Software Development[END_REF], the first level of the model quality is the primary use of models, either development or maintenance. The primary uses are decomposed into purposes: for the development primary use, the purposes are communication, analysis, prediction, implementation and code generation. For each purpose, the required characteristics are specified. For instance, communication requires evaluating complexity, selfdescriptiveness, conciseness and aesthetics. On another hand, complexity is defined as the effort required for understanding a model. After selecting some quality characteristics, a set of metrics is identified to measure them. Complexity metrics are the depth of inheritance tree or the number of classes per Use Case and so on.

Another approach is to integrate needs into a quality framework like the semiotic one proposed by Lindland [START_REF] Lindland | Understanding quality in conceptual modeling[END_REF]. In [START_REF] Lindland | Understanding quality in conceptual modeling[END_REF], quality is detailed into syntactic, semantic and pragmatic aspects. The syntactic quality verifies how well a model corresponds to its language constructs without considering the meaning. The semantic quality indicates the link of a model to its domain or to the knowledge of the domain specialists. Finally the pragmatic quality relates to the interpretation by the model audience.

Finally there is a reverse inference approach [START_REF] Moody | Theoretical and practical issues in evaluating the quality of conceptual models: current state and future directions[END_REF] where we work backwards from the quality characteristics of the final system to the characteristics of the model. Even if this approach is referenced in [START_REF] Moody | Theoretical and practical issues in evaluating the quality of conceptual models: current state and future directions[END_REF], we found no existing work using it. We choosed this approach to evaluate Symphony Objects because we hypothesised the existence of a causal relationship between the characteristics of our conceptual model (the Symphony Objects model) and the characteristics of the code made following its recommandations. So, we try to evaluate the Symphony Objects model through the quality of several of its implementations. We then focus on the technical effectiveness as defined in [START_REF] Hassine | Symphony: a conceptual model based on business components[END_REF]. We hope that this will help us in defining some quality properties such as those proposed by the ISO approach. Then these properties can be used to understand the pragmatic quality of a Symphony Objects model.

B. Software quality

Our problem is now refined into the evaluation of implementations resulting from a Symphony Objects model. For evaluating an implementation, we can refer to software quality that has been studied for a long time in the software engineering domain. Software quality has given rise to standards such as the ISO/IEC 9126. The ISO/IEC 9126 software quality standard is one of the most widespread quality standard available in the software engineering community. It fixes six top-level characteristics, which are refined into twenty-seven sub-characteristics, which are in turn decomposed into properties that the software products belonging to the domain of interest should exhibit. For instance, software maintainability is the characteristic that refers to the effort needed to make specific modifications. Its sub-characteristics are stability, analyzability, changeability and testability. Some of these characteristics are measurable with metrics, like the number of lines of comments in a program. In our work, software metrics are used to measure software obtained from a Symphony Object model.

III. THE AUGMENTED SYMPHONY METHOD

A. Presentation

Originally developed by the UMANIS Company, Symphony is a method focused on business components. It has been extended, first to increase components' reusability [3], and then to include the design of rich user interfaces [START_REF] Dupuy-Chessa | A Design process integrating mixed system into information systems, chapter of the book Engineering of Mixed Reality[END_REF].

Symphony is based on the separation of two purposes represented in a Y-lifecycle, as shown on Figure 1. The whole lifecycle is applied for each functional unit of the system under development.

B. Reusable components in Symphony

The left branch of Symphony consists in studying functional and interactional solutions by refining models previously outlined. Software Engineering (SE) and HCIoriented activities are realized in parallel, by design actors specialized either in SE or HCI. Both conclude their analysis with conceptual components.

The original version of Symphony is based on the iterative identification and description of business components. For example, considering a tool for managing team members, two types of objects may be identified (Fig. 2): Business Object Entities (BOE) e.g. a person, and Business Object Processes (BOP), e.g. the applicative rules for adding or removing team members, for managing mentorships etc. Entities represent domain concepts, and processes describe the applicative logic of the system.

Our extension of Symphony is expected to improve the integration of rich user interface design, in order to gain modular, reusable and independent interactional components. It notably analyzes HCI concerns similarly to and in parallel with the more classical business analysis, thus allowing the definition of interactional entities and processes. An Interactional Object Entity (IOE) is an essential concept of the interactional domain, e.g. the graphical representation of a team (using tree-graphs, for instance). The Interaction Object Process (IOP) describes the logic of the interactional domain, e.g. the interaction techniques for adding or removing branches from a tree graph.

Figure 2 presents a part of a Symphony Objects model. Each object features an interface, which defines its contract with the outside world and an implementation of the contract, which includes a master class (for describing the main concern of the object) and part classes (for organizing the minor concerns the object depends on). Dependencies with other Symphony Objects are managed using role classes. These classes notably allow reusing existing Symphony Objects (for instance, the "Person" object) by adapting it to an applicative concern (for instance, the concept of team member, which is a person with an office and a position in the team hierarchy).

C. Technical choices

The right branch of the Symphony method generally recommends structuring software into a classical three-tier architecture, with the topmost tier describing the interaction devices (e.g., digital tables, OpenGL rendering components etc.), the middle tiers integrating the Symphony Process and Entity Objects and the lowest tier defining the database components.

Following common design practices, Symphony recommends the use of design patterns. In particular, all objects are designed with a "Factory", a class that is used to instantiate the objects [START_REF] Gamma | Design Patterns: Elements of Reusable Object-Oriented Software[END_REF]. Factories are not strictly recommended by the method, but using design patterns is generally advisable for obtaining good code quality.

IV. EVALUATING THE CONTRIBUTIONS OF THE SYMPHONY METHOD

A. Research methodology

As we previously mentioned in the introduction, our goal is to evaluate the quality of a Symphony Object model obtained from the use of the augmented Symphony method. In particular, we want to evaluate if our model, that contains business and interactional objects, give rise to good quality software. In the produced software, we concentrate on the components that are systematically obtained from the design and implementation rules associated with Symphony Business and Interactional Objects, because we expect that the properties of those technical Symphony Objects to be induced by the properties of the corresponding analysis-level Symphony Objects model.

Considering the characteristics of the augmented Symphony method (i.e. the reusability of components and a clear separation of concerns between the HCI and the business parts), we would like to obtain the following code properties: Objects and Interactional Objects should be very low, as to say nonexistent.

The technical Business Object Entities and technical

Interactional Object Entities must be reusable at least in terms of a low complexity of their implementation classes and, all instability factors being concentrated into process Objet, they should have a high functional stability. As a matter of fact, they must be independent from the application logic, which is implemented in Process Objects.

B. Experiment 1) Evaluation Process

The previously mentioned properties being identified, we think about a way to evaluate them. As they are related to code quality, we study existing software engineering metrics. [START_REF] Booch | Object-Oriented Analysis and Design with Applications[END_REF] identifies 225 metrics which can be classified into 2 categories:

• Metrics measuring directly programmers' work like the ratio of comments or the size of methods;

• The others evaluating the implementation recommendations of the method like the coupling between components.

We chose to focus on the method dependent metrics that are more relevant to our hypotheses.

Then we built an experiment to evaluate our hypotheses:

1. We chose a case study (controlled variable) which is a software to implement;

2. We designed the conceptual models according to the augmented Symphony method (controlled variable);

3. Several versions of the same software were developed by different programmers with different techniques (independent variables);

4. Then each of them have been evaluated with software metrics (dependent variables).

The details of this experiment are described below.

2) Controlled variables

Our case study is based on the results of a software engineering project, called "EDEMOI" 1 , that deals with civil aviation security. The EDEMOI project originally assessed the conformance of a given security policy with the security standards, by automatically building and running test cases. However, the tests cases and their results were presented as lists of events and system states, which were difficult to understand for security specialists. Therefore, we were asked to design a user-friendly interface for visualizing these tests. The actual implementation features a rich graphical humancomputer interface, developed in Java Swing [START_REF]Java Swing[END_REF] and Apache Project's Batik [START_REF]The Apache XML Graphics Project[END_REF] library for manipulating SVG files. Persistency is handled using XML files. So this application 1 http://www-lsr.imag.fr/EDEMOI/ offers the advantages of having a reasonable size with a complex user interface while its business logic is reasonably complex.

All our implementations are based on the same study of the EDEMOI project following the augmented Symphony method. The analysis document with its UML specifications, in particular its Symphony Objects model, and its technical choices (section 3.3) will not change during the experiment. They are our controlled variables.

3) Independent variables

The independent variables are those that we varied in order to obtain a significant experiment. Our independent variables are: 1) programmer experience; 2) some design choices (i.e. communication choices between Symphony Objects and their organization).

The first independent variable of our experiment is programmer experience. This criterion allows us to check whether good code quality is only due to a programmer's skills or to the method guidelines (i.e., average and inexperienced programmers should be able to produce satisfactory code, especially in terms of structure). Three implementations have been realized with two programmers. The first one was made by a PhD student, who is experienced in object-oriented programming. He used Java aspect-oriented programming to implement EDEMOI. The two other implementations were developed in JavaBeans by an experienced developer, who had a small experience in object-oriented programming. No constraint was given about the programming environment or the time required to produce code as our goal was to evaluate the code and not the way to achieve it.

The second independent variable concerns technical choices (Symphony's right branch). The first implementation uses a software framework whereas the two other implementations follow the MVC pattern [START_REF] Krasner | A description of the model-view-controller user interface paradigm in the smalltalk-80 system[END_REF].

Changing the type of technology allows checking whether a good quality is dependent on a very specific type of technology or is more generic.

The third variable carries on the design step (Symphony central branch). The main question was about the communication mechanism between technical objects. MVC can be implemented by using an Observer design pattern, but a more recent solution, proposed by R. Eckstein [START_REF] Eckstein | Java SE Application Design With MVC[END_REF] proposes a solution based on a propertyChange event, as shown on figure 3. It permits a complete independence between View and Model objects. The role of the Controller is augmented, as it manages the events and their impact on each object. Therefore, it matches well with the processing applied by Process Objects and allows us to obtain a complete independence between the implemented Interactional and Business Entity objects. Finally the last variable is the internal organization of objects. This criterion evaluates the impact of different implementation strategies for the Symphony Objects' "Master" and "Part" classes (i.e., finely grained classes or dense, complex ones) on the overall code quality. As a matter of fact, the code can be cut out in several ways in order to achieve the same goal: a large Master class can manage the whole problem of the object or a smaller Master class can be coupled with several Part classes to which parts of the problem are delegated. In the same way, inside a class, methods can be more or less important.

To summarize, we introduced variations at different levels of the design: 1. Programmer experience;

Communication management between technical

Symphony objects, which gathers our 2 nd and 3 rd independent variables.

Organization of technical Symphony Objects.

For time reasons, we were not able to realize all the possible combinations of those independent variables. However we developed 3 different versions of the EDEMOI project with a specific goal for each one of them (Table .

1):

• A version using an original software framework (whose description is outside of the scope of this paper) that facilitates the implementation of Symphony Objects and of the connections between Business and Interactional Objects.

• The second version can be qualified as standard: it can be developed by any programmer adopting standard design choices.

• The last version could be realized by any programmer trying to make optimal choices. In particular, this version was developed by taking into account the results of software metrics tools run on our code.

4) Dependent variables

The dependent variables are those that allow us to evaluate our hypothesis. In our case, they are the metrics measured on our three implementations. The metrics will give us some quantitative results without having to make any inference. We simply need to define their "good" values according to the literature.

We looked for software metrics that would permit to measure modularity and reusability of our technical components. Classic metrics such as the Lines Of Code / Lines Of Comments ratio can only be used to assess the programmers' coding practice, whereas we need to focus on the metrics related to the structure of the application. We focused on application architecture metrics, particularly those proposed by Chidamber and Kemerer [START_REF] Chidamber | A metrics suite for object oriented design[END_REF] (coupling between objects, object complexity, depth of inheritance tree…). Among all the application metrics, we chose three of them that seem to be the most significant to measure modularity and reusability: coupling, complexity and instability. As these metrics are correlated, we cannot envisage to realize some meta-analysis on their results.

a) Coupling

Coupling indicates the level of interaction between several software components. Afferent (Ca) and Efferent Coupling (Ce) count respectively the number of ingoing and outgoing links between software entities, which are identified by Chidamber and Kemerer [START_REF] Chidamber | A metrics suite for object oriented design[END_REF] as indicators of their modularity and reusability. As a matter of fact, the more a software entity is autonomous, the more it is easy to separate it from its original application; therefore it is reusable. G. Booch [START_REF] Booch | Object-Oriented Analysis and Design with Applications[END_REF] proposed the notion of "category", that is, a set of software classes that are designed to work together and be tightly coupled. Measuring the coupling of the classes within a category would make no real sense, therefore a relevant measure of coupling needs to take into account the software's architecture design. Concerning our implementations, Java packages correspond both to Symphony Objects and to categories. Therefore, we measure the coupling between Java packages.

In many metrics calculation tools, the value of the efferent coupling Ce did not match our expectations. To measure a package coupling, classic tools count the number of its classes that import other classes or packages. So, a package containing only one class that imports 3 classes of other components will be counted as Ce = 1 (i.e. one class with dependencies). This didn't seem to measure actual dependencies between our components : we expected to have Ce=3 in this case. This is the reason why we decided to define another efferent coupling: Ce², which counts the number of effective efferent links between packages, without considering standard language classes (which seldom evolve). This definition of efferent coupling enabled us to refine our perception of dependency, for it was the exact level of risk for a package to be impacted by the modification of one of the external objects it uses.

When considering a whole implementation, each ingoing link is also an outgoing link from the used object, thus the number of ingoing links is equal to the number of outgoing links. This is why we focused only on efferent coupling.

b) Complexity

Cyclomatic and Npath Complexity [START_REF] Nejmeh | Npath : a measure of execution path complexity ans its applications[END_REF] measure the number of paths through a source code. They represent the number of unit tests required to cover the whole code. So, it's a vision on code testability, maintainability and granularity. Those qualities are necessary for guaranteeing the reusability of developed components.

c) Instability

Instability is defined as a ratio between afferent and efferent coupling: Ca / (Ca + Ce). It is usually interpreted as an indicator of the object resilience to change. Within Symphony, an object is expected to be either a service client or a service provider, i.e. that its instability should be close to either 1 or 0. When the component is distant from either mark, it has an unclearly defined role.

V. RESULTS

A. Hypotheses based on metrics measures

Our approach is not based on statistical analysis, we simply want to evaluate if the implementation of Symphony Objects give rise to acceptable results in terms of code quality. So considering the chosen metrics, we need to translate our highlevel hypotheses into expected metrics values (Table 2):

1. We expect a low coupling value between the objects of our implementation. The literature on SE metrics recommends a measure of Ce such that Ce ≤ 4. From our experience, we generally have Ce 2 ≈ 2 * Ce, therefore we expect that Ce 2 ≤ 8,

If coupling exists between two Symphony objects,

we expect it to be concentrated on the dependency relationships between role classes and the interface class of the collaborating object (see Section 3.2), As a corollary, we expect the instability of our Symphony Objects to be concentrated into the role classes. So instability must be close to 1 for Symphony Objects and close to 0 for other objects.

3. We expect an overall low complexity, in order to guarantee a finer granularity and modularity of classes and components. We base our thresholds on those introduced by Watson and MacCabe [START_REF] Watson | Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric[END_REF] while defining the cyclomatic complexity (CC):

• 1 ≤ CC ≤ 4 -low complexity;

• 4 < CC ≤ 7 -moderate complexity;

• 7 < CC ≤ 10 -high complexity;

• 10 < CC -very high complexity.

B. Coupling

We expect a low coupling between our components i.e. Ce 2 ≤ 8. Moreover if coupling exists between two Symphony objects, we expect it to be concentrated on the dependency relationships between role classes and the interface class of the collaborating object. Table 3 presents the values for coupling. Ce² tot is the total coupling in a project, the total number of links between packages. Efferent coupling is lower than the values set in our hypotheses, for all our implementations. By looking at the code elements that are coupled, we note that they are the collaborative parts of tripartite technical Symphony Objects: the interface parts are used by the other components and the role classes use external components. Interfaces and role classes are easy to adapt as they are abstract classes. We can conclude than hypotheses 1 and 2 are verified.

C. Complexity

We expect an overall low complexity so as to guarantee a small granularity and a high modularity of classes and components. We measured Cyclomatic (CC) and Npath (NC) Complexity.

Our projects have very low CC values (between 1.46 and 1.79). But average values don't to be very significant, as they hide peaks. Looking at maximum values tells us a bit more: we expected to obtain values lower than 10. Our implementations, optimized, standard and with framework, are respectively evaluated to 5, 23 and 11, which are satisfactory results, above all because the project evaluated at 23 is the less optimized one: its value is high, but acceptable considering that it does not exceed of more than an order of magnitude the values set in our hypotheses.

The situation is very similar with Npath complexity: we expected values lower than 50 [START_REF] Scott Janzen | an Empirical Evaluation of the Impact of Test-Driven Development on Software Quality[END_REF]. Our implementations are in the expected range. Our optimized version has the lowest value (1.61), and Standard the highest (50).

But here too the maximum value gives a different vision: all projects, except Optimized have lots of method with high values, reaching up to 182000. Optimized has a maximum of 16, and Standard 13000. This can be explained by the fact that for the first one, we have been watching complexity all over the development cycle, splitting methods as soon as CC or NC was too high. This is not a Symphony specific problem, but the way our objects were designed made it simple to apply: the clear specialization of each object, the well identified role of every component facilitate the restructuring when needed. Those results tend to validate our fourth hypothesis.

D. Instability

Tripartite objects recommended by Symphony have by construction two roles: the contract part is managing the provider role of the object, while the collaboration part corresponds to its client role. This architecture should lead to bad instability values.

But Symphony also recommends splitting objects into entities and processes. Entities represent dense, consistent and relatively independent concepts. On the other hand, processes describe the applicative logic and use the entities they are considering. So, processes are strongly in a client role, while entities are mostly service providers.

For our three implementations, the values of I are particularly eloquent if we consider separately the entity and process objects. In fact, the interactional and business entities feature an instability of I=0 (no incoming link), while the process objects (some of these assuming the role of MVC controllers) have a value close to 1, at least greater than 0.75, meaning few outgoing links. These values match the distribution of applicative and entity roles proposed by the Symphony method, as detailed in Section III.B. By construction, role classes are the only ones of our tripartite objects having an efferent coupling: interfaces, master and part classes have no incoming links. And, if we check it, efferent coupling is actually concentrated into role classes. For example, the optimized version, with its 11 packages, has 17 role classes, representing 95% of all efferent coupling. Those classes are only used within the object in wich they embedded, so none of them can have afferent coupling: cumulated afferent coupling in Optimized, Standard and Framework versions is actually 0 for role classes. Given that instability is defined as Ce / (Ce + Ca), all those classes have an instability of 1. Conversely, interfaces are measured with a null instability, and master and part classes are evaluated at I=0.14. This matches our third hypothesis: 96% of instability is concentrated into role classes. Moreover this analysis confirms the one realized on the coupling. So the validation of the 2 nd hypothesis is strengthened.

E. Discussion

The Symphony Objects were designed to reduce the coupling between business and interaction elements. The experiments we conducted tend to validate the contribution of Symphony on this point. However Symphony does not prevent from overly complex code when developers do not respect basic programming rules and practices. This point was not developed during these experiments because it seemed to be common sense. The point was to show that when respecting "good practices" in development, the Symphony method and its structuring objects give rise to reuse and modular components.

We could also develop the same application without the Symphony method and compare the metrics results with the ones with Symphony. In such case, we think that the results without Symphony would too heavily depend on the quality of the developer who would not be guided by a method.

Anyway evaluation is a very difficult task. At this point of our work, definitive statements would be very bold. We must, in particular, consider the instability results with precaution. As a matter of fact, we discovered during the experience that the EDEMOI project has a structural specificity: all its Entity Objects are directly linked to their Process Object. This specificity is in favour of a low efferent coupling for Entity Objects (they do not use other Entity Objects) and a high efferent coupling for Process Objects (they use the Entity Objects of the conceptual domain).

There are also several points which can influence the validity of our experiment: the size of the case study may be too small; the number of case studies is certainly not representative enough, or the fact that the sample developments were realized by two persons. Therefore, additional evaluation is required for refining our first conclusions.

VI. CONCLUSION

We showed how some code-oriented metrics actually help in evaluating a system model. Our way of experimenting a model is original as it is based on an under used approach, the reverse inference one, which is applied in a usual way i.e. by evaluating software metrics. Moreover it gives an insight in fine on the method that guided the description of this model. In this way, our experiment shows the applicability and the interest of the reverse-inference approach.

Our experiment has shown that a Symphony Object model, which represents business and interactional aspects, can give rise to implementations with modular, reusable and simple components. Thus we can conclude that 1) the augmented Symphony method can give rise to good Symphony Object models; 2) the Symphony Object model can be adequate to represent applications with quality requirements in terms of reusability.

From this first experiment, we can now introduce several variations in a Symphony Objects model in order to identify their impact on the implementation quality. This would give us some insights about the technical quality properties for Symphony Objects models. Those quality properties can be completed by the study of related works on UML model quality and other experimental studies. Now considering that the augmented Symphony method can give rise to technically good solutions, we are currently realizing qualitative experiments in order to evaluate the process in itself. We investigate whether the process integrates efficiently the practices of HCI and software engineering specialists and enables designers to develop rich user interfaces. We hope that these experiments will improve our insights into the interest of the augmented Symphony method and into the process of evaluating development method.

However, even though we try to minor the evaluation bias (for instance by multiplying code variations and programmers), we would need to apply our experimental protocol on a very large number of projects to guarantee our method's quality. This is a very severe limitation, given that the Symphony method would first need to be widely adopted on very different project types in order to be adequately evaluated. Olsen discussed the same limitations concerning usability evaluation [START_REF] Olsen | Evaluating User Interface. Systems Research[END_REF], and suggested that new techniques should be first and foremost be considered in terms of the "important progress" they may provide.

Nevertheless, while the use of software metrics was applied for validating a model from a single development method, we believe that this approach could be generalized for providing an alternative solution for assessing method quality through the quality of the models and the implementations that they enable to produce.

  The functional (left) branch corresponds to the traditional task of domain and user requirements modelling, independently from technical aspects, The technical (right) branch allows developers to design both the technical and applicative architectures. It also federates all the constraints and technical choices with relation to security, pervasiveness, load balancing… The central branch integrates the technical and functional

Figure 1 .

 1 Figure 1. Symphony's development cycle

Figure 2 .

 2 Figure 2. Symphony tripartite objects

Figure 3 .

 3 Figure 3. MVC with propertyChange event

TABLE I .

 I INDEPENDENT VARIABLES OF THE EXPERIMENT.

		Programmer	Communi-	Object
		experience	cation between	Organization
			objects
	Implem. #1 (Framework)	Experienced	Managed by the framework	Minimal sizes
	Implem. #2 (Standard)	Intermediary	MVC with Observer	No care to size
	Implem. #3 (Optimized)	Intermediary	MVC according to Eckstein	Minimal sizes

TABLE III

 III

	.	COUPLING IN OUR IMPLEMENTATIONS
		Ce² tot	Ce² max	Ce² avg
	Optimized	21	5	1.82
	Standard	46	7	3.00
	Framework	13	2	1.00