Jorge Luis

Pérez Medina

Dominique Rieu

Sophie Dupuy-Chessa

A Service-Oriented Approach for Model Management

Keywords: Model, service, model management, MDE, modeling tools, operational service, organizational service

In the Software Engineering (SE) domain, the Model Driven Engineering (MDE) 1 paradigm focuses on using models as main software artifacts to provide a full description of software systems and on automating model manipulation with tools. Model management concerns a set of features allowing representing, creating, storing and manipulating models. Nowadays, the needs of models designers in terms of management process and products are diverse. Modeling tools are not complete because there is no consensus about models needs and uses. To remedy the heterogeneity and the functional limitations of models management tools, we propose a service-oriented approach for model management for the creation of modeling environments adapted to the needs of designers. The considered needs are related in two abstract levels: the operational and the organizational level.

Introduction

Software development is a collaborative process where teams of developers work together to design solutions and produce quality code [START_REF] Booch | Collaborative Development Environments[END_REF]. In order to cover the variety of software viewpoints (business, human-computer interaction, security…), multiple modeling languages are used by model designers in a software project. In particular, UML covers many concerns for modeling software systems; however, there exists domain-specific concerns, such as the Human Computer Interaction (HCI) domain [START_REF] Paterno | ConcurTask Tree: a diagrammatic notation for specifying taskmodels[END_REF], that model designers cannot express using UML. Due to the needs to describe the system through different viewpoints, software development projects involve actors with different types of skills that play different roles (e.g. designers, ergonomists,…). Project managers need to create environments that support a useful coordination of activities and tasks between actors, and actors need to create models to resolve assigned activities. To assist them in their work, the model-based approaches aim at helping designers in understanding user needs and in designing solutions in an effective way. Consequently, realizing a model-based software project requires an environment that could assist designers to collaboratively manage models and to coordinate all Software Engineering (SE) activities involving differents models.

Nowadays Computer-Aided Software Engineering (CASE) tools and Model-Driven Engineering (MDE) tools are used to describe a set of concepts and technologies around model management. Tools can manipulate different models and perform different actions on models. They are limited in features and often reduced in the use of some meta-models and models. They do not permit the coordinated and cooperative models management required by different specialists, that work together in a context of collaborative design [START_REF] Godet-Bar | Interactional Objects : HCI concerns in the analysis phase of the Symphony method[END_REF]. In conclusion, models management tools are not complete because there is no consensus on the needs and the uses of models.

At the same time, using models permits a new form of interoperability in terms of model-based tool integration. It focuses on the integration through metamodeling tools [START_REF] Kapsammer | Model-Based Tool Integration -State of the Art and Future Perspectives[END_REF]. Several works have treated the problem of model-based tool integration [START_REF] Wicks | Tool Integration within Software Engineering Environments: An Annotated Bibliography[END_REF]. However, none of them answer the questions of the choice of modeling tools according to the needs of actors and design processes. The question that we try to resolve is how to build a model management environment that solve technical needs of companies in conformity with theirs organizational needs.

want propose a modeling environment that allows model designers to build a modeling environment that suits her needs, whatever role she plays in a design process. To find a solution to problem, we propose to adapt the services based approach [START_REF] Bieber | Introduction to Service-Oriented Programming[END_REF]. Our approach considers the models management as services for creating environments adapted to the needs of different stakeholders, whose goals are: a) Documenting services to facilitate their research and their use; b) Integrating model management tools as services in an open platform to add, edit and delete services; c) Defining language modeling development process to describe the roles and needs of each actor that participates in a software development process in terms of models management.

In this paper, we propose two types of services: "operational" services and "organizational" services. This paper is organized as follows. Section 2 presents the needs of model designers and the features offered by models management tools. Section 3 presents the concepts of service in an overview of our approach based on two modeling levels. Models of the operational layer and the organizational layer are presented. Finally a conclusion and some perspectives are presented in section 4.

Features offered by models management tools

Model designers need to manipulate models along the software project lifecycle. At the organizational level, the system design consists in guiding modeling activities using human resources. Consequently, project managers need to create environments that support a useful collaboration of activities and tasks among actors. This means that it is necessary to define the roles that are played by model designers and the activities realized. It is also necessary to define all the modeling languages used by the stakeholders of a project. Considering these concerns, the Business Process Management (BPM) deals with the design, the automation, and the optimization of business processes [START_REF] Wil Van Der | Business Process Management: A survey[END_REF]. In our work, we focused on identifying those functional activities that produce or use models. Our aim is to offer modeling environments based on the reuse of modeling activities. A development process consists in collaborative activities (e.g. cooperation or coordination) among designers. In a cooperation, designers must work together to produce a common product: specialists different headings in a common form are for instance realizing a cooperation activity. Coordination occurs when tasks are decomposed into common activities. A common planning is set up, actors are dispatched on these activities a proper goal is assigned to each actor or activity. Drawing semantic relationships between models is a typical coordination activity example.The issue is to take into account any existing development method, ith its organizational specificities. Finally, an efficient modeling management cannot be realized without automated support. Consequently model designers need some software engineering activities to be automated.

In order to automate model management activities, many models management tools are available. With regard to our approach, the features offered by model management tools can be considered at two modeling levels. At the operational level, the model management functionalities offered by tools are model management, model transformation, etc. At the organizational level, the functionalities offered by tools consist in guiding modeling activities using human resources.

Two levels of service

Service-Oriented Computing (SOC) uses services as the constructs to support the development of rapid, low-cost and easy composition of distributed applications. A service is a set of self-contained software modules and auto-descriptive applications than can be described, published, discovered, composed, and negotiated on demand by a customer Services perform functions that can be anything from simple request to sophisticated business processes requiring multiple layers of services consumers and providers [START_REF] Papozoglou | Service-Oriented Computing: A Research Roadmap[END_REF]. Services are offered by service providers. In our context, a service provider is the entity that offers any editor which realizes treatments on models and tools for models management. The clients are users with needs in model management. They represent any Model Designers. They must able to find the description(s) of the modeling services adapted to their needs. Our approach based on services does not limit itself in considering each model management tool as a "service". It relies on two modeling levels (see Figure 1) where providers, clients and services are different. The first level corresponds to the operational layer. This layer offers services for model designers, to facilitate the creation of their modeling environment. The client is a model designer who wants to manage models in an individual collaborative way (with other designers). So, she needs to define her modeling environment adapted to her favorite functions and use context. The organizational layer permits to model the design process of a system in of modeling activity. This layer offers a support based on services for project group. Therefore, in this layer, roles and activities are expressed in terms of simplified development processes. The organizational layer reuses, in a coordinated way, the operational services defined in the first level. The customers is, in this case, project managers who need to define and manage roles and activities for their process.

The operational layer

The operational layer describes the static structure supporting the research and the coupling of services that are required by model management. An operational service (Fig. 2) corresponds to an executable application composed of other model management services. A model management service consists in a tool offered by a provider. An operational service is associated with various types of features: a) different types of collaboration; b) some factors of software quality; and c) the contexts of utilization model designer. An operational service is associated to various types of services which are represented by a composition of elementary services. An elementary service defines how a model designer can make operations on models, the supported languages to store the information and the possible operations of service. To take into account the reuse of modeling, a type of service supports the use of one or several models. Modeling operational services is not new. We extend the classical aspects (e.g. collaboration, context of usage) in response to the needs identified by [START_REF] Godet-Bar | Interactional Objects : HCI concerns in the analysis phase of the Symphony method[END_REF]. This study lead us to propose an original operational model service characterized by: 1) aspects related to collaborative design; 2) and the user's context.

To support the needs of creating collaborative environments, an operational service is connected to several collaboration forms. A collaboration form is defined according to three axes: location, space and time. Location represents either if the task is centralized or distributed. Space is the area where tasks are performed. Finally, time is the collaboration moment (synchronous or asynchronous).

To guarantee the quality in the use of a model management tool, we introduced the notion of quality factor. It consists in composition of several criterias that assure the software quality. The evaluation can be expressed as a function or a degree of excellence. Related to the notions of users profile and context of use of an operational service, Fig. 2 considers that an operational service can be executed in different contexts of use by specialists who have diverse levels of expertness. The context of use is a structured information space that includes the hardware-software platform required by the service. It is related to a variety of interaction modalities, multimodality referring to a composition of multiple modalities simultaneously.

The organizational layer

Our organizational model service is inspired by several works. Ralyté et al. [START_REF] Ralyté | An Approach for Method Reengineering[END_REF] propose a method engineering process model approach, which permits to represent any method as an assembly of the reusable method fragments. In our work, we use the notion of service to support the construction of modeling process environment by assembling method fragments of design processes adapted to the functional activities of model designers. Fig. 3 presents the organizational model service. An organizational service consists in a composition of development method fragments of that can be reused by model designers. A method fragment is represented by an organizational elementary service that is defined in terms of model manipulation. An organizational service is carried out by one or more roles. A model designer who plays a role can define and reuse several organizational services. At this level, the "collaboration" term is used for coordination and cooperation tasks between designers. Another aspect considered by our organizational model is the fact that the operational services are the mechanisms that realize the organizational services. It means that organizational elementary services must use operational service to support the management of modeling activities.

Conclusion and perspectives

This article presents the principles of our service-oriented models management approach. It relies on two modeling levels where providers, clients and services are different. The first level corresponds to the operational layer. An operational service considers aspects such as: the type of services, modeling resources, collaboration forms, context of use and user profiles. At the second level, the organizational model permits the reuse of operational services in a coordinated way, but also the creation and the management of model process fragments. This organizational model will allow project managers to model design processes. Afterward, we consider necessary to specify an intentional layer. This layer will in modeling the goals that can be proposed to represent the intention of a specialist, a group of specialists, a unity of work or any organization involved in the development process. Therefore, this intentional level will permit to justify the existence of fragments of design processes, actors and roles. Then, we must develop a modeling process language in order to unify the concepts of intentional and organizational levels (expressed in terms of models management) with operational services. This modeling language must take into account coordinated and cooperative model management required by several specialists. Finally, we must consider the use of a platform for the implementation of our three levels of services. The existing service-oriented tool such as DoCoSOC [START_REF] Yu | Development Tool for Service-Oriented Applications in Smart Homes[END_REF] will be important references in this area.

Fig. 1 .

 1 Fig. 1. Two levels of service.

Fig. 2 .

 2 Fig. 2. Operational model service.

Fig. 3 .

 3 Fig. 3. Organizational model service.

Official Site of Model Driven Engineering, http://www.actionidm.org/.

Acknowledgments. are grateful to the Foundation "Gran Mariscal de Ayacucho" and the university "UCLA-Venezuela" for their financial support.


S Dupuy-Chessa

G Godet-Bar

J.-L Pérez-Medina

D Rieu

D Juras

A Software Engineering Method for the Design of Mixed Reality Systems

Keywords: Mixed Reality, interaction design, model, functional core, process

The domain of Mixed Reality systems is currently making decisive advances on a daily basis. However, the knowledge and know-how of HCI scientists and interaction engineers, used in the design of such systems, is not well understood. This paper addresses this issue by proposing a software engineering method that couples a process for designing Mixed Reality interaction with a process for developing the functional core. Our development method features a Y-shaped development cycle that separates the description of functional requirements and their analysis from the study of technical requirements of the application. These sub-processes produce Business Objects and Interactional Objects, which are connected to produce a complete Mixed Reality system. The whole process is presented via a case study, with a particular emphasis on the design of the interactive solution.

Introduction

Mixed Reality systems, which include tangible user interfaces, augmented reality and augmented virtuality seek to smoothly merge physical and digital worlds to improve usability. Many prototypes in various domains [START_REF] Wellner | Interacting with paper on DigitalDesk[END_REF][2][3] [START_REF] Ullmer | mediaBlocks: Physical Containers, Transports, and Controls for Online Media[END_REF] have been developed to demonstrate the technical feasibility and the interest of such interaction techniques. But developing mixed systems often remains based on the realization of ad hoc solutions, which do not facilitate the reusability of the systems and do not capitalize on previous solutions. It is now required to focus on design approaches rather than adopting technology-driven approaches only.

A design approach is based on the study of users' requirements in order to propose a suitable solution. It needs approaches, like models or processes, to reason about solutions, compare them and choose the most appropriate one according to users' needs and good practice. However, good practice for Mixed Reality systems is still being identified. Existing knowledge and know-how must be exploited in order to be integrated into industrial practice. At the present time, software designers and developers tend to build graphical user interfaces, which are easy to develop, but which are not always adapted to the interaction situation. Therefore exploiting and spreading design knowledge and know-how about Mixed Reality systems design can be a way to facilitate the acceptance of Mixed Reality systems in industry.

The first step to make use of design knowledge is to integrate it into models. Given the particularities of the Mixed Reality systems domain, current design approaches in Human Computer Interaction (HCI) are no longer sufficient. Several proposals (for instance, by Dubois et al. [START_REF] Dubois | ASUR++: a Design Notation for Mobile Mixed Systems[END_REF] and by Coutrix and Nigay [START_REF] Coutrix | Mixed reality: A model of mixed interaction[END_REF]) have been made for guiding the design of Mixed Reality systems. They provide a rationale for how to combine physical and digital worlds. They are used in addition to traditional usersystem task description in order to identify physical and digital objects involved in interaction techniques and the boundaries between real and virtual worlds.

A second step in helping designers is proposing design processes. The lack of maturity of the mixed systems domain suggests processes based on experimentations, as presented by Kulas et al. [START_REF] Kulas | Towards a Development Methodology for Augmented Reality Users Interfaces[END_REF], rather than models. Nevertheless the use of models and their associated processes, which has been described by Nigay et al. [START_REF] Nigay | Mobile and Collaborative Augmented Reality: A Scenario Based Design Approach[END_REF] or by Gauffre et al. [START_REF] Gauffre | Domain Specific Methods and Tools for the Design of Advanced Interactive Techniques, 3rd Workshop on Model Driven Development of Advanced User Interfaces at MoDELS'07[END_REF], facilitates the link with classical software engineering (SE) practices and the integration of new interaction techniques into applications.

Our goal is to propose a design method based on models integrating both an SE method for the development of the functional core and HCI practices for designing the interaction. Compatibility between design methods for interactive systems and for the functional core is a recurring problem that has already been subject to specific studies by Tarby and Barthet [START_REF] Tarby | Analyse et modélisation des tâches dans la conception des systèmes d'information : la méthode Diane+[END_REF] and Lim and Long [START_REF] Lim | The MUSE method for usability engineering[END_REF]. In particular, Gulliksen and Göransson [START_REF] Gulliksen | Usability design: Integrating user-centred systems design in the systems development process[END_REF] and Sousa and Furtado [START_REF] Sousa | From usability tasks to usable user interfaces[END_REF] propose extending the Rational Unified Process with the design of interaction, in a user-centred approach. Constantine et al. [START_REF] Constantine | Usage-centered design and software engineering: Models for integration[END_REF] also describe a process unifying the design of interaction and that of the functional core but in a usage-centred approach. These studies illustrate an interest in considering both the interaction and functional aspects while designing a system. Nevertheless, none of these studies addresses Mixed Reality-specific aspects, such as the integration of interaction devices like Head-Mounted Displays, positioning systems, etc. Moreover, they offer a weak formalization of the proposed processes, which renders their application difficult for designers.

The second section introduces software engineering principles that are used as a foundation for the design of Mixed Reality systems and the Symphony Y-cycle software method [START_REF] Hassine | Symphony: a conceptual model based on business components[END_REF] that we will use as a medium for integrating those principles. We then describe how a Y-shaped development cycle can be applied to the design of Mixed Reality systems by using specific models and processes. The functional aspects, which aim at designing a functional and interactive solution without considering the technical aspects, are described in Section 3. Then Section 4 describes the technical analysis that aims at choosing the most appropriate devices, software architectures and platforms for supporting the Mixed Reality system under development. In Section 5, the junction of both concerns poses the challenge of merging technical choices with the models elaborated in the functional analysis. Finally, we conclude by considering lessons learnt from the use of the method. We also give details of evaluations of the method, both carried out and envisaged.

Extending a SE Method for Mixed Reality Systems

Extending Symphony for the Design of Mixed Reality Systems

Our approach is mainly based on the practices of the Rational Unified Process [START_REF] Jacobson | The Unified Software Development Process[END_REF]. We apply three of them to the design of Mixed Reality systems:

-The process is iterative. Given today's sophisticated software systems, it is not possible to define the entire problem, design the entire solution, build the software and then test the product at the end. An iterative approach is required for allowing an increasing understanding of the problem through successive refinements, and for incrementally growing an effective solution over multiple iterations. Thus, we envisage building Mixed Reality systems incrementally and iteratively. Additionally, sub-processes are identified for allowing shorter iterations when the activities focus on crucial elements of the system, such as the design of the interaction.

-The Symphony process is driven by use cases and scenarios to manage requirements. We choose a compatible approach based on scenarios [START_REF] Kulas | Towards a Development Methodology for Augmented Reality Users Interfaces[END_REF] to complement the process with design steps specific to the design of Mixed Reality systems (for instance, the choice of interaction devices or the design of interaction techniques). These scenarios are used as a pivot model for all specialists.

-The process uses graphical models of the software to capture the structure and behaviour of components. Graphical models such as UML diagrams help to communicate different aspects of the software, enable a developer to see how the elements of the system fit together, maintain consistency between a design and its implementation and promote unambiguous communication among developers. For the design of Mixed Reality systems, we complement classical HCI models like task trees [START_REF] Paterno | ConcurTaskTrees: An Engineered Notation for Task Models[END_REF] with specific models such as ASUR [START_REF] Dubois | ASUR++: a Design Notation for Mobile Mixed Systems[END_REF]. Additionally, the original Symphony method was centered on the early use of reusable and reused components. It provides a systematic approach for defining a solution using new and existing components. When the solution is precise enough to be described by computerized objects, we propose to structure the interaction space with interactional objects [START_REF] Godet-Bar | Interactional Objects : HCI concerns in the analysis phase of the Symphony method[END_REF], which are user interface-oriented components. In parallel, the business is designed into components called Business Objects.

During the process, models and scenarios are continuously refined. SE and HCIoriented activities are realized either in cooperation or in parallel, by design actors specialized either in SE and/or HCI. All actors collaborate in order to ensure consistency of adopted design options. However Mixed Reality system design is not yet a fully mastered task. The design process needs to be flexible enough to evolve over time. Therefore, our Symphony method extended for Mixed Reality systems contains black box activities which correspond to not fully mastered practices: a black box only describes the activity's principles and its purpose without describing a specific process. In such a case, we let the designer use her usual practices to achieve the goal. For instance, "preparing user experiments" is a black box activity, which describes the desired goal without making explicit the way in which it is achieved.

The method also proposes extension mechanisms, in particular, alternatives. Indeed, we can imagine alternatives corresponding to different practices. For instance, different solutions can be envisioned to realize the activity « analyzing users' tasks». They are specified as alternative paths in our process.

Additionally, Symphony is based on a Y-shaped development cycle (Fig. 1). It is organized into three design branches, similar to 2TUP [START_REF] Roques | UML2 en action, de l'analyse des besoins à la conception J2EE, collection Architecte Logiciel[END_REF]. For each iteration, the whole development cycle is applied for each functional unit of the system under development [START_REF] Hassine | Symphony: a conceptual model based on business components[END_REF]:

-The functional (left) branch corresponds to the traditional task of domain and user requirements modeling, independently from technical aspects. Considering the design of a Mixed Reality system, this branch is based on an extension of the process defined by [START_REF] Nigay | Mobile and Collaborative Augmented Reality: A Scenario Based Design Approach[END_REF]. It includes interaction scenarios, task analysis, interaction modality choices and mock-ups. This branch ends by structuring the domains with Interactional and Business objects required to implement the Mixed Reality system.

-The technical (right) branch allows developers to design both the technical and software architectures. It also combines all the constraints and technical choices with relation to security, load balancing, etc. In this paper, we limit the technical choices to those related to Mixed Reality systems support, that is, the choice of devices and the choice of the global architecture.

-The central branch integrates the technical and functional branches into the design model, which merges the analysis model with the applicative architecture and details of traceable components. It shows how the interaction components are structured and distributed on the various devices and how they are linked with the functional concepts.

In the rest of the paper, the extended Symphony method and its design principles will be detailed in a case study, which concerns the creation of an inventory of premise fixtures.

Case Study

Describing the state of a whole premise can be a long and difficult task. In particular, real-estate agents need to qualify damage in terms of its nature, location and extent when tenants move in as well as when they move out. Typically, this evaluation is carried out on paper or using basic digital forms. Additionally, an agent may have to evaluate changes in a premises based on someone else's previous notes, which may be incomplete or imprecise.

Identifying responsibilities for particular damage is yet another chore, which regularly leads to contentious issues between landlords, tenants and real-estate agencies.

In order to address these issues, one solution may be to consider improving the computerization of the process of making an inventory of premise fixtures. In particular, providing better ways to characterize damage and to improve the integration of the process into the real-estate agency's information system, as well as its usability, all of which could add considerable value to this activity.

In the following sections, we detail the application of our method to this case study.

The Functional Branch

Introduction

This section presents the development activities of the extended Symphony method's functional branch, from the preliminary study to the requirements analysis. In particular, the focus of our concern is on the collaborations that HCI specialists may have with SE experts. Therefore, we provide an excerpt of our development process centered on these aspects, in Fig. 2. Please note that, for the sake of conciseness, both the SE and HCI processes have been greatly simplified. For instance, we present collaborations between domains (i.e., a group of actors sharing the same concerns), not between the particular actors; in fact, several collaborations occur between the functional roles of each domain during the application's development cycle.

The activities that appear across the swimlanes correspond to cooperations: the development actors must work together to produce a common product. For instance, the "Description of weaving model between Business Objects and Interactional Objects" involves having both the HCI and SE experts identifying which Interactional Objects correspond to projections of Business Objects and laying this down in a specific model.

Coordination activities are not represented as such in the central swimlane because the experts do not need to produce a common product. On the contrary, they must compare products from their respective domains in order to validate their design choices. In our example, the coordination between the "Structuring of business concepts into Business Objects" and "Structuring of interaction concepts into Interactional Objects" implies that the SE and HCI experts identify whether they may need to modify their model in order to facilitate the ulterior weaving of the two models. The details of these activities, as well as the possible business evolutions they may trigger, have been covered in [START_REF] Godet-Bar | When interaction choices trigger business evolution[END_REF].

Initiating the Development

Before starting a full development iteration, a preliminary study of the business is realized. Its aim is to obtain a functional decomposition of the business as practiced by the client, in order to identify business processes and their participants. A business process is defined as a collection of activities taken in response to a specific input or event, which produces a value-added output for the process' client. For instance, our inventory of fixtures case study corresponds to a fragment of a larger real-estate management business, in which several business processes can be identified: "management of tenants", "management of landholders" and "management of inventories of fixtures". An essential issue of this phase is therefore to identify the stakeholders' value, for each process.

This study is described using high-level scenarios in natural language shared by all development specialists (including usability and HCI specialists), so as to provide a unified vision of the business, through the description of its constitutive processes.

In this phase, the usability specialist collaborates with the business expert for capturing prescriptions based on the current implementation of the business processes, as well as for defining a reference frame of the application's users, using the participants identified by the business specialist during the writing of the scenarios.

Conceptual Specifications of Requirements

In the original description of the Symphony method, this phase essentially comprises the detailing of the subsystems that constitute the different Business Processes and of the actors that intervene at this level, in terms of sequence diagrams and scenarios.

In our extension of the method for HCI, we associate the usability specialist with the description of the Business Processes' scenarios. In collaboration with the HCI specialist, and based on the scenarios and usability prescriptions (from the preliminary study), the usability expert determines the types of interaction that may be envisaged for the application, such as Mixed Reality, post-WIMP or classical interfaces according to the context and needs. In collaboration with the other actors from the method and stakeholders, an estimation of the added value, cost and risks of development associated with the interaction choice is realized, for each subsystem of the future application. Considering our example, the "Realization of an inventory of fixtures" subsystem is a good candidate for a Mixed Reality interaction for a variety of reasons including:

-The case study typically features a situation where the user cannot use a desktop workstation efficiently while realizing the activity, -Textual descriptions of damage are both imprecise and tedious to use, especially for describing the evolution of damage over time and space, -Several manual activities are required for thoroughly describing the damage, e.g. taking measures, photographs etc., -The data gathered during the inventory of fixtures cannot be directly entered into the Information System (except if the user operates a wireless handheld device), -Standard handheld device such as PDAs would only allow the use of textual, formfilling approaches, with the aforementioned limitations.

Organizational and Interaction-oriented Specification of Requirements

Once the Business Processes are identified and specified, the Organizational and Interaction-oriented Specification of Requirements must determine the "who does what and when" of the future system. Concerning the business domain, the SE specialist essentially identifies Use Cases from the previous descriptions of Business Processes, and from there refines business concepts into functional components called Business Objects.

We have extended this phase to include the specifications of the interaction, based on the choices on the style of interaction made during the previous phase.

Three essential aspects are focused on in this phase: firstly, the constitution of the "Interaction Record" product, which integrates the synthesis of all the choices made in terms of HCI; secondly, the realization of prototypes, based on "frozen" versions of the Interaction Record; thirdly, the elaboration of usability tests, which use the Interaction Record and the prototypes as a basis.

The design of these three aspects is contained as a sub-process within a highly iterative loop, which allows testing multiple interactive solutions, and therefore identifying usability and technological issues before the actual integration of the solution into the development cycle.

The construction of the Interaction Record is initiated by creating a projection of the users' tasks in the application under development: the HCI specialist describes "Abstract Projected Scenarios" [START_REF] Nigay | Mobile and Collaborative Augmented Reality: A Scenario Based Design Approach[END_REF], based on usability prescriptions proposed by the usability expert. However, at this point the description remains anchored in a business-oriented vision of the user task, as we can see in Table 1.

From this basis, the HCI specialist moves her focus to three essential and interdependent aspects of the future interaction: the description of interaction artefacts, of interaction techniques and of the device classes for supporting the interaction. This latter activity is optional, given that it is only necessary when designing Mixed Reality interfaces. Additionally, this activity is undertaken in collaboration with the usability expert.

We expect the following types of results from these activities: -A textual description of the interaction artefacts, including lists of attributes for each of these artefacts. A list of physical objects that will be tracked and used by the future system may also be provided (even though at this point we do not need to detail the tracking technology involved), -Dynamic diagrams may be used for describing the interaction techniques. Both physical action-level user task models (e.g. ConcurTaskTrees [START_REF] Paterno | ConcurTaskTrees: An Engineered Notation for Task Models[END_REF]) and more software-oriented models (e.g. UML statecharts [START_REF] Jacobson | The Unified Software Development Process[END_REF]) may be used. For instance, the following interaction technique for displaying a menu and selecting an option may be described using a task model: the expert makes a 1-second pressure on the Tactile input; a menu appears on the Augmented Vision display with a default highlight on the first option; the Expert then makes up or down dragging gestures to move the highlight; the Expert releases the pressure to confirm the selection, -Static diagrams for describing device and data-flow organization for augmented reality interactions, such as ASUR [START_REF] Dubois | ASUR++: a Design Notation for Mobile Mixed Systems[END_REF], complement the description of artefacts and interaction techniques. Fig. 3 presents an example of such a diagram for the "Create a damage report" task. The user, identified as the Expert, is wearing an Augmented Vision Display ("==" relation), which provides information ( relation symbolizes physical or numerical data transfer) about the Marker and Vocal Note virtual objects. Additionally, the Mobile Display device, which is linked to the Tactile input ("==" relation), provides information about the Marker, Vocal Note and Situational Mesh (i.e., the 3D model of the premises) virtual objects. The Marker is a numerical representation ("-->" relation) of physical damage in the physical world. The Expert can interact with the Marker and Situational Mesh objects using Tactile Input. She can interact with the Vocal Note using a Vocal Command input. The Expert's position in the premises is deduced from the Positioning system, which sends information to the virtual objects for updating the virtual scene as the Expert moves. The damage is observed and recorded in the Inventory of Fixtures (…) The Expert enters a room. Her position is indicated on the premises plan. The past inventory of fixtures does not indicate any damage or wear-out (damage) that needs to be checked in this room. She walks around the room and notices a dark spot on one of the walls. She creates a new damage report, describes the observed damage, its position on the premise's plan and takes a recording (photograph or video) of the damage and its context(…).

The descriptions of artefacts, interaction techniques and classes of devices are then integrated into "Concrete Projected Scenarios" [START_REF] Nigay | Mobile and Collaborative Augmented Reality: A Scenario Based Design Approach[END_REF], which put into play all the concepts elaborated previously, as an evolution of the Abstract Projected Scenarios. An extract of Concrete Projected Scenario is presented in Table 2.

Finally, high-level user task models are deduced from the Concrete Projected Scenarios, both in order to facilitate the the evaluation process and to validate the constructed models.

Following each iteration of the Interaction Record's development, we recommend the construction of paper and software prototypes (Flash or Powerpoint simulations, HCI tryouts…) putting into play the products of Interaction-oriented Specifications. Beyond the advantage of exploring design solutions, the prototypes allow the usability expert to set up usability evaluations for validating the specifications. Fig. 4 presents an early prototype for the Augmented Inventory of Fixtures application, with both the Expert wearing an augmented vision device and the data displayed.

From these different products of the interface's design process, the usability expert compiles recommendations and rules for the future user interface, such as its graphic chart, cultural and physical constraints, etc. Based on the prototypes, the Interaction Record and the Concrete Projected Scenarios, the usability expert may start elaborating validation tests for all the products of the Interaction-oriented Specification. We use "Black box activities" for describing these steps, as described in Section 2. Finally, once the Interaction-oriented Requirements are validated, the HCI expert proceeds with the elicitation of the Interactional Objects, deduced from the interaction concepts identified previously. The criteria for this selection are based on the concepts' granularity and density (i.e., if a concept is anecdotally used or is described by only a few attributes, then it may not be a pertinent choice for an Interactional Object).

As was mentioned in Fig. 2, a cooperation activity between HCI and SE experts aims at mapping these Interactional Objects to the Business Object they represent through a "represent" relationship. For instance, the "Marker" Interactional Object is linked to the "Damage" object, through a "represent" relationship (see Fig. 5).

In the following section, we detail how the Symphony Objects that have been identified previously are refined and detailed.

Analysis

This phase describes how the Symphony Objects are structured, in terms of services and attributes, and how they behave. The latter aspect is detailed a dynamic analysis of the system, while the former is elaborated in a static analysis. Following these analyses, details of the communication between the business and interaction spaces, indicated by the "represent" relationship, are described.

Concerning the business space, the dynamic analysis consists of refining the Use Cases identified during the previous phase into scenarios and UML sequence diagrams, for identifying business services. These services are themselves refined during the static analysis into the Symphony tripartite structure (i.e. methods and attributes are identified, see Fig. 6). The left-most part describes the services proposed by the object, the central part describes the implementation of the services, and the right-most part (not used in this example) describes the collaborations the object needs to set up in order to function. A "use" dependency relationship, allows Symphony Objects to be organised (e.g., the "Inventory of fixtures" depends on the "Damage" concept during its lifecycle).

Concerning the interaction space, the dynamic analysis is similar to that of the space, but based on the high-level user task models elaborated at the end of the Specification of Organizational and Interaction-oriented Requirements phase. They are complemented by UML statechart diagrams for describing the objects' lifecycles. For instance, the "Marker" Interactional Object can be described using a simple two-state statechart diagram: it may be "Locked" and immovable, or and moveable. Similar to the business space, the static analysis refines these studies into tripartite components. We propose the same, model-oriented representation of Business Objects and Interactional Objects (i.e., "Symphony Objects") [START_REF] Godet-Bar | Interactional Objects : HCI concerns in the analysis phase of the Symphony method[END_REF], in order to facilitate their integration into MDE tools, as well as their implementation.

At this point, both the business and interaction spaces have been described in parallel, from an abstract (i.e., from technological concerns) point of view. Now HCI and SE specialists need to detail the dynamic semantics of the "represent" It is first necessary to identify the services from the interaction space that may have an on the business space. For instance, creating a "Marker" object in the interaction space implies creating the corresponding "Damage" object in the business space. Second, the translation from one conceptual space to the next needs be described. In our example, it is necessary to convert the pixel coordinates of the "Marker" into the architectural measures of the premises plan.

These translations from one conceptual space to another are managed by "Translation" objects. There is one instance of such object for each instance of connection between Interactional Objects and Business Objects. In the Analysis phase, the Translation objects are described using sequence diagrams for each case of Interactional-Business Object communication. Fig. 7 illustrates the consequence of the "create Marker" interaction event in terms of its translation into the business space. Note that the reference to the Marker object (i.e. the "source" instance) is assumed to be registered into the Translation object. Details of this mechanism are presented in Section 5.

Main points discussed

The extension of the Symphony method for the development of Augmented Reality systems capitalizes on the features we discussed in Section 2.1. Similarly to what is achieved in terms of the business description, we have proposed the following principles for the development of the interaction space: 1. Early description of interaction components (i.e., "Interactional Objects"), during the specification of requirements, 2. Structuring of interaction components based on the same tripartite structure as the business components (i.e., "Business Objects"), 3. Parallel and collaborative description of the business and interaction specifications and analysis, 4. Late connection between the business and interaction spaces, using Translation objects.

As we can see, principles 1 and 2 reproduce what was initially proposed for the business space. However, principles 3 and 4 aim at allowing HCI experts and Fig. 7. Translation semantics corresponding to the "createMarker" event usability experts to design ambitious interfaces early enough in the development cycle for permitting their integration into the final system. Additionally, the design of the user interface involves regular prototyping and evaluation activities, contained in a highly iterative sub-process, as recommended by ISO 13407 for UCD Design).

As a consequence of the application of these principles, the end of the development of the functional branch provides developers with two exhaustively detailed sets of products structuring the business and interaction spaces, as well as the necessary elements for realizing the junction between these spaces (i.e. the Translation classes).

Additionally, we have integrated regular collaborations between the HCI specialist and the usability expert during all the phases of the functional branch. The usability specialist herself involves future users in the design process (for instance through the observation of the business practices and the usability tests). These practices greatly increase the overall usability and efficiency of the future system. In this respect, we follow once again the indications of ISO 13407 for UCD.

The Technical Branch

The technical branch of the original Symphony method allows developers to design the applicative and technical architectures. Their goal is the analysis of all the constraints and technical choices related to security, pervasiveness, and load balancing, for example. We saw previously that in order to design Mixed Reality systems, our method considers the choice of techniques of interaction, interaction artefacts and classes of devices. Consequently, this has led us to propose extensions for the technical branch.

The applicative architecture corresponds to the organization of technical and functional components amongst applicative tiers, as well as the description of the software architectures used for supporting the execution of Business and Interactional Objects detailed during the Analysis phase. Additionally, patterns and design rules are identified and defined for the applicative architecture. The technical architecture corresponds to the hardware and technology (e.g., frameworks) solutions that will allow the application to be run. Finally, note that both phases are realized concurrently with the functional requirements.

Description of the Applicative Architecture

The goal of this phase is to identify and describe the rationale concerning the selection of the software architecture, which must allow the integration of the technical and functional components. First, the distribution of components amongst applicative layers is described, before a software architecture for efficiently supporting the interaction is superimposed on the applicative layers.

Description of applicative layers. The original Symphony method recommends a placing the components in a five-tier architecture, for classic systems. The tiers are built following the Layer pattern [START_REF] Buschmann | Pattern-Oriented Software Architecture -A System of Patterns[END_REF], which enables designing, developing and testing each tier independently from the others. The extension of the method preserves this decomposition of the Information System, and describes the distribution of Business Objects and Interactional Objects amongst the five layers. This applicative choice facilitates the maintenance, reuse and evolution of future software.

Description of the software architecture. The original Symphony method recommends the MVC pattern for the design of the Presentation layer, which isolating the business concerns of the application from the interface's control and view concerns. However, this solution needs to be complemented for taking into account the distribution of Interactional Objects, as well as the technical constraints imposed by Mixed Reality systems, such as multimedia rendering loops. Fig. 8 illustrates how we envisage this dispatch of components amongst the applicative tiers, using an adapted MVC software architecture:

-The Interactional Objects correspond to the abstract, logical part of the MVC's "View", while the "OpenGL Client" corresponds to the technical implementation of the Interactional Objects; the "Controller" is an adaptation of the View to the user input (e.g., pressing a given button triggers a notification, which allows matching this event with a given action), -

The Business Objects correspond to the "Model" part of the MVC pattern, -

The Translation objects correspond to facets of MVC's "Controller" in the sense that they manage the bridge between the "Model" and "View" aspects.

Description of the technical architecture

This section describes the technical analysis for choosing the most adequate devices and platforms for supporting Mixed Reality systems.

Choice of interaction devices. Once the need to develop a Mixed System (in this case, an Augmented Reality System) is identified (see Section 3.3), it is necessary to choose the most satisfactory interaction devices. This selection must be made on the basis of characteristics of the generic devices identified during the Specification of Organizational and Interaction-oriented Requirements (see Section 3.4).

Our method for facilitating the selection of devices is based on the QOC notation [START_REF] Buschmann | Pattern-Oriented Software Architecture -A System of Patterns[END_REF]. It enables designers to classify and to justify the design decisions. In the context of the inventory of fixtures, the study of the interaction has determined the need for an augmented vision display, a tactile input and mobile display, a positioning system (i.e. orientation and localization) and a vocal command device (see Fig. 3). For the sake of conciseness we will only present in Fig. 9Erreur ! Source du renvoi introuvable. the selection of the augmented vision display.

Based on the QOC diagram, the usability expert has determined that the most adequate device for the inventory of fixtures is an HMD device: it allows user mobility, guarantees low energy consumption, and offers an acceptable image quality, low weight and a wide space of visualization.

Description of the interaction's devices. This activity consists of detailing the technical specifications of each interaction device chosen during the previous activity. For instance, Table 3 shows the technical specifications of the HMD device.

Main points discussed

In this section we have presented a methodological guide adapted to HCI concerns that aims at selecting the most adequate device, software architectures and platforms to support the design of Mixed Reality systems, based on the use of principles underlying recognized software architectures. We use the QOC notation, which 5 The Junction of the Functional and Technical Branches

Design

Two essential aspects need to be addressed at this point in the development cycle: the blending of the functional analysis with the technical choices (i.e., the organization of the functional and non-functional software components), and the deployment of these components on the technical infrastructure.

For the sake of conciseness, the latter point is not extensively discussed in this paper: the choices made are in fact summarized in Fig. 10. We use a tactile smartphone device for running the application, which is linked to the real-estate agency's database through a wireless message bus. Additionally, the "Vocal Command" and "Positioning System" mentioned in Fig. 3 correspond to the internal microphone and Wi-Fi/accelerometers (used for position triangulation purposes) subdevices of the smartphone. The "Tactile Input" is managed by the "Tactile Display" sub-device. An OpenGL client, which corresponds to a technical presentation component (c.f. Presentation tier in Fig. 8) managed by the Interactional Objects, manages the display of the adequate data for both the HMD and the Tactile Display. Finally, note that the Interactional Objects, Business Objects and Translations are dispatched amongst the Process and Entity tiers.

The OpenGL client runs the main rendering loop of the 3D scene and dispatches user events to the Controller elements, while another thread loop taps into captured Wi-Fi and acceleration data in order to infer the user's location, which is then notified to the main loop. The initial position of the user in the premises is obtained using manual calibration (i.e., the user pinpoints her position in the premises on the smartphone before starting the inventory of fixtures).

We focus now on the design choices made for realizing the connection between Interactional Objects and Business Objects, via the Translation objects.

In the technical branch, we noted that the use of the MVC architectural style corresponds to the requirements for our Augmented Inventory of Fixtures. Consequently, we need to adapt the Analysis models concerning the structure and of the Symphony Objects to this architectural style, while preserving the semantics of the functional services they provide.

As we saw previously, every collaboration between Symphony Objects (represented by "use" relationships in Section 3) occurs through a "Role" class (see the comments concerning Fig. 6).

In order to respect the MVC architectural style, we chose to overload the responsibilities of the "Role" classes with the management of the Interactional Object-Business Object (IO-BO) communications.

Concretely, when an event occurring in an Interactional Object needs to be reflected in the business space, the communications between the interaction space and the business space (identified by "represent" relationships in Section 3) occur through the "Role" classes. Fig. 11 presents an example of such a communication, where the Interactional Object that uses the "Marker" object needs to manage the creation of a new "Marker" object, through the "MarkerRole" Role object: 1. The "MarkerRole" object calls the "MarkerTranslation" object to create a new damage report in the business space, 2. The "MarkerTranslation" object translates the pixel coordinates of the marker into the corresponding position in the premises and calls the "RealizeInventoryOfFixtures" Business Object Process (which holds the applicative logic for creating damages), 3. The "RealizeInventoryOfFixtures" Business Object Process calls the Business Object Entity for creating the damage in the right room of the premises, 4. "MarkerRole" calls the "Marker" Interactional Object for creating a marker at the appropriate location in the 3D model of the premises (i.e., the "Situational Mesh" from Section 3). Thus, all the occurrences of Interactional Object-Business Object (IO-BO) communications are concentrated into "Role" classes. Therefore, the coupling between the interaction and business spaces is limited to clearly identified entities.

Main points discussed

We saw in this section an overview of how the Symphony method realizes the blending of the functional analysis with the technical choices. After briefly showing how the functional (i.e., Symphony Objects) and technical components may be deployed, we studied how the organization of between Symphony Objects and Translations (see Section 3) may be adapted to the MVC common architectural style.

Let us mention that the design solution that we provided in this section is in no way exclusive. Indeed, we will show in future work how other design solutions may be efficiently implemented, independently of the technical choices, provided that developers respect the structure of the Symphony models from the Analysis phase.

Conclusion and future works

The Symphony method extended for Mixed Reality systems permits a Mixed Reality system design to be considered in its entirety without neglecting either the functional or the interaction part. However, if it is clear that interaction cannot be designed without considering functionality, we have pointed out in [START_REF] Godet-Bar | When interaction choices trigger business evolution[END_REF] that the interaction choices also influence the functional part. Therefore the method needs to include cooperative activities in order to guarantee global design consistency, but also to maximize the benefits obtained from the analysis of each conceptual space.

The method also allows a clear separation of concerns, as well as design traceability for each domain. We focused in this chapter on how these properties are achieved in the interaction space.

The method has been applied to two case studies. Each study was realized by teams of three persons. These teams consisted of average and expert programmers, some of whom are authors of this paper, others being interns in our research team.

The first application we developed concerned the simulation and evaluation of airport security. It had to respect precise requirements from another research team in our laboratory, and most particularly it had to fit into a large test workflow. Even though not strictly speaking a Mixed Reality system, the application nevertheless features a very complex interface (several windows, animated elements). It has met its requirements and is currently being transferred for actual deployment.

The other application (i.e., the Mixed Reality inventory of fixtures) is welladvanced but still under development. At the current stage of development, screenshots are quite similar to the prototype presented in Fig. 4. Additionally, we are currently working on a robust localization system.

Even if these studies are not comparable to industrial designs, they forced us to define more precisely the design process and modify some of its steps. However, we also noted that some developers and testers who intervened during the development or the evaluation of our method had trouble handling the volume of the specifications. Indeed, the amount of documentation produced during the development cycle is currently quite high (over 50 pages of specifications for a project of about 4000 lines of codes, for instance). This volume is generally necessary for allowing the integration of applications into large information systems (such as that of a real-estate agency) and for permitting the maintenance and evolution of the system. Nevertheless, extensive documentation is only necessary when the team is not familiar with either the business domain or the interaction style. In more well-known contexts, large parts of the method may be either skipped or less strictly documented, thus making the development methodology more lightweight.

Finally, a large number of models are constructed during the development cycle of our Mixed Reality systems. Even though most of these models are either refinements of previous models or partially generated, we admit that the members of the development team currently spend too much time using a plethora of modeling tools for single iterations of their models, and not enough time discussing and iterating over these models.

Consequently, one of our long-term perspectives is to propose an open platform for supporting collaborative modeling activities and short iterations over these models. This platform may be based on the model-driven engineering approach (where models would be first class elements). We hope that such support, coupled with our methodological guide, will facilitate the design of mixed reality systems.

Fig. 1 .

 1 Fig. 1. Symphony design phases

Fig. 2 .

 2 Fig. 2. Collaborations between the HCI and SE domains during the functional development

Fig. 3 .

 3 Fig. 3. ASUR model representing the "Create damage" task

Fig. 4 .

 4 Fig. 4. Augmented Inventory of Fixtures prototype

Fig. 5 .

 5 Fig. 5. "represent" relationship between an Interactional Object and a Business Object

Fig. 6 .

 6 Fig. 6. Interactional Object example

1

  QOC: Questions, Options and Criteria, is a semi formal notation proposed by MacLean et al. This notation gives place to a representation as a diagram, which can decomposed into three columns, one for each element of the notation (questions, options, criteria), and links between the elements of these columns.

Fig. 8 .

 8 Fig. 8. Applicative architecture for Mixed Reality systems

Fig. 9 .

 9 Fig. 9. Selection criteria for the vision support device

Fig. 10 .

 10 Fig. 10. Deployment diagram for the functional and technical components of the Augmented Inventory of Fixtures application

Fig. 11 .

 11 Fig. 11. Simplified view of the Interaction Object -Business Object connection at the Design level

Table 1 .

 1 Abstract Projected Scenario for the "Create damage report" task

	Theme(s)	{Localization, Data input}
	Participant(s)	Inventory of Fixtures Expert
	Post condition

Table 2 .

 2 Concrete Projected Scenario for the "Create damage" task The Expert enters a room. Her position is indicated on the Situational Mesh, which is partially displayed on the Mobile tactile display. The past inventory of fixtures does not indicate any damage or wear (Marker object) that needs to be checked in this room. She walks around the room, notices a dark spot on one of the walls. She creates a new Marker and positions, orients and scales it, using the Mobile tactile display. Then she locks the Marker and describes the damage by making a Vocal note with the Vocal input device (…)

	Supporting device(s)	{Mobile tactile display, Augmented vision device, Vocal input
		device, Positioning system}
	Interaction artefact(s)	{Marker, Situational Mesh, Vocal note}
	(…)

Table 3 .

 3 Description of the interactive devices Device Technical specifications HMD Model AddVisor 150. Full color image on 1280x1024 pixels (SXGA), excellent image quality, high brightness and contrast. Superposed image with up to 35 % see-through or fully immersed. Designed for a 46 degree diagonal 100% overlap field of view. Low weight.

Acknowledgments. We are grateful to the Foundation "Gran Mariscal de Ayacucho, the university UCLA-Venezuela" for their financial support.


Eduardo Mucelli

Rezende Oliveira

Aline Carneiro Viana

Routine-based Network Deployment

The careful deployment of hotspots in metropolitan areas allow to maximize WiFi offloading, a viable solution to the recent boost up of mobile data consumption. Our proposed strategy considers routine characteristics present on people's daily trajectories, the space-time interaction between them urban locations, and their transportation modes. Using a reallife metropolitan trace, we show our routine-based strategy guarantees higher offload ratio than the current approach in the literature while using a realistic traffic model.

I. INTRODUCTION

WiFi offloading consists in shifting the traffic off of cellular networks to WiFi networks. Carefully deploying WiFi hotspots can both be cheaper than upgrade the current cellular network structure and can concede significant improvement in the network capacity [START_REF] Lee | Mobile data offloading: how much can wifi deliver?[END_REF]. Nevertheless, one question remains: how WiFi hotspots should be deployed?

This work tackles the WiFi hotspot deployment problem in a metropolitan area by leveraging mobile users' trajectories, scenario interaction and traffic demands. Our objective is to define what are the best places to receive WiFi hotspots in order to maximize the offloaded traffic on an urban scenario. II. RATIONALE People are routinary, they have regular circles of actions. Furthermore, people present three mobility characteristics, tendency to use the shortest-path to reach their destination, confinedly roaming close by their main physical address and repetitively visiting the same places. These observations guide our hotspot deployment proposal. For this, we consider GeoLife dataset [START_REF] Zheng | Geolife: A collaborative social networking service among user, location and trajectory[END_REF] that describes the mobility and transportation modes of 182 people mostly in Beijing during a 4-year span. To better understand specific behaviors inherent from different periods of the day, each day is divided into four periods of 6 hours starting from 00:00.

A trajectory is a set of geolocalized points describing a route traveled by a person using at least one transportation mode. While passing by, people may "interact" with points of interest. In our scenario, points of interest are geolocalized physical venues, e.g., bar, bus station, supermarket, etc. We have collected information from more than 202 thousand real unique points of interest in Beijing from Google Places, Nokia Maps, and Foursquare. We consider that a person interacts with a point of interest if the former is inside the coverage range (50 meters [START_REF] Dimatteo | Cellular traffic offloading through wifi networks[END_REF]) of the latter.

III. PROPOSAL

This section presents how mobility is mapped into a time dependent graph, routine characteristics measurement, traffic model and hotspot placement strategy.

Graph creation: Our graph G(V, E) represents the interaction between people and points of interest. A vertex v ∈ V is created on the same coordinates of the point of interest if the latter covers at least one person passing by. An edge e ∈ E is created between two vertices if their corresponding points of interest sequentially cover a person during its trajectory. Routine characteristics measurement: The characteristics present on people's routinary mobility are measured on GeoLife dataset using three confirmed intuitions: usage of shortest-paths, confinement and repetitiveness.

On average, 70% of people's trajectories measure, at most, half longer than the respective shortest path. We have used Google Directions API1 to compute the shortest path. To measure the usage of shortest-paths on the graph, we use Stress Centrality. Vertices with high stress are those that lay on most of people's shortest routes and may become well positioned hotspots.

People's mobility is generally confined. In our scenario, 90% of the trajectories have, at most, 10 km maximum displacement regardless of the period of the day. We use Closeness Centrality as a way to measure how close a vertex is to the rest of the network. On a city, those are places planned to be close to most of the people's trajectories, e.g., hospitals and markets.

People tend to repetitively visit the same areas. Beijing map was divided into cells of 50 square meters in a grid shape. Then, we have calculated the number of unique cells (N U C) and total cells (N T C) that each trajectory visited. To quantitatively express the repetitiveness of a trajectory, a metric called Repetitiveness was conceived: N T C-N U C N T C * 100. The result shows that 91% of the performed trajectories present at most 50% of the visited cells repeated. Traffic model: To the best of our knowledge, there is not in the literature a freely available dataset describing both people's mobility and their traffic demands on an urban scenario. Therefore, we have created a realistic synthetic traffic model that takes into consideration traffic parameters and measurements from the literature (cf. Table I) to simulate the content generation and offload as if it was done by people participating on GeoLife while performing their trajectories.

Moreover, the traffic model was designed to couple with specific demands inherent in a scenario that contains people moving using different transportation modes. When a person is covered by a point of interest, and the transportation mode being used is "taxi", "bus", "walk", "train", "subway", "car" or "boat" the traffic generated by our model is normally made available to be offloaded. Correspondingly, when the person gets covered and uses other transportations modes, e.g., "run", "motorcycle" and "bike", no content will be available for offloading. Spots selection: Consider a graph G t (V t , E t ) constructed as described in Section III for a period of time t ∈ T = {1, 2, . . . , u}. Let φ be the number of period of times per day d ∈ D, which between people and urban scenario for the hours contained in t. Therefore, V t ⊆ V is the the set of vertices that covered at least one person during t and E t ⊆ E is the subset of edges that represents the mobility of people during t. Our objective is to maximize data offloading. We advocate that in order to deploy a WiFi network for data offloading on an urban scenario, it is important to take into consideration both traffic and mobility characteristics. For instance, consider two points of interest h i and h j that receive the same amount θ of traffic to be offloaded during a period of time t. If we consider only offloaded traffic, both would be equally selected.

Our intuition is that if we also consider people's mobility it is possible to provide a better network deployment for data offloading envisioning future traffic. Consider offloaded traffic (tr) and mobility characteristics metrics Stress (st), Closeness (cl) and Repetitiveness (re). Consider U i,t,m as the value of the metric m ∈ M = {st, cl, re, tr} on the period t for the vertex i. The traffic on a period t for the vertex i is calculated as the sum of all b bytes of content offloaded from all people covered by i during t, i.e. U i,t,tr = b b i,t . Due to the different magnitudes of the metrics, we have normalized U i,t,m between 0 and 1 by the maximum value of m on the period t.

Let --→ R i,t be a vector of metrics calculated for the vertex i ∈ V t . Due to the mobility, a vertex i may appear on the graph on a certain period t = k, but not appear on a period t = k + 1. Therefore, [R i,t,m = U i,t,m • z i,t ], where z i,t = 1 if i appears on t and z i,t = 0 if i does not appear in t. The result of metrics attributed to the same vertex on different periods is aggregated through a sum, i.e., i,t R i,t,m = T otal m ∀ m ∈ M . Then, our problem is to find the set of vertices that maximizes the metrics with a limited number of hotspots λ, formally:

Maximize i,t R i,t,m Subject to z i,t < λ
Besides, our model can be tunned in order to prioritize either mobility characteristics or traffic: α * ( i,t R i,t,st + i,t R i,t,cl + i,t R i,t,re ) + β * i,t R i,t,tr by choosing weights α and β depending on operators' demands. Considering α → 0 and β → 1 results in a deployment that prioritizes traffic demands. On the other hand, when α → 1 and β → 0 hotspots will likely be placed on more important areas of the city regardless their traffic offload. Initially we consider both traffic and mobility characteristics with the same importance.

IV. PERFOMANCE EVALUATION

We have compared our approach, routine-based, with the current work on the literature that proposes WiFi deployment considering user mobility characteristics, grid-based [START_REF] Bulut | Wifi access point deployment for efficient mobile data offloading[END_REF]. Gridbased uses only the mobility of taxis in San Francisco, which is divided in a grid with one hotspot in the center of each cell.

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Its traffic model generates a data request every 5 seconds.

Figure 1 shows the offloaded traffic by period of the day. Each period of the day has its own number of trajectories which in turn generates a respective amount of traffic. If it is necessary to guarantee an offload ratio per period, different number of hotspots are needed to offload the traffic on each period of the day. Indeed, in order to achieve 80% of offloaded traffic on each period of the day, the routine-based needs, on average, 34% less hotspots than the grid-based approach.

V. CONCLUSIONS AND NEXT STEPS

In this work in progress, we have presented to the best of our knowledge, the first analyses of a metropolitan-wide hotspot deployment which employs a realistic traffic model. We have proposed (1) a graph model to represent the relationship between people and the city infra structure, (2) a realistic synthetic traffic model that considers transportation modes, and (3) a metric to turn points of interest into well positioned hotspots capable of providing data offload based on people's real routines and their traffic demands. Our initial results show that our routine-based deployment can offload more data with less hotspots than the current work in the literature while using a realistic traffic model. As future work, we intend to investigate how good is our deployment configuration for a different period of the dataset. Additionally, we are going to further investigate the monetary trade-off of a deployment in which the cost of the hotspots is not unique and the cost of offloaded traffic is considered. Finally, we envision to study the impact of changes on the mobility and traffic parameters α and β on the deployed configuration.

Fig. 1 .

 1 Fig. 1. Offloaded traffic per # of deployed hotspots by period of the day.

  |T | = |D| * φ. G t represents all the interactions

		TABLE I
	TRAFFIC MODEL PARAMETERS
	Parameter	Value
	File size	Gamma (shape=2, scale=8.5 MB)
	Inter-arrival time (IAT)	Exponential
	Amount per day	94.54 MB
	Transfer rate	3.9 Mbps
	Connection time	1.83 second
	represent the set of days in which we analyze mobility data.
	Therefore,

https://developers.google.com/maps/documentation/directions 978-1-4799-3360-0/14/$31.00 c

IEEE

This work was supported by the EU FP7 ERANET program under grant CHIST-ERA-2012 MACACO.


Xingrong Chu
email: chuxingrong@gmail.com

Lionel Leotoing
email: lionel.leotoing@insa-rennes.fr

Dominique Guines
email: dominique.guines@insa-rennes.fr

Jun Gao

Comparison of constitutive laws on the modeling of thermo-viscoplastic behaviour of an aluminum alloy

Keywords: Hardening law, Aluminum alloy, Flow stress, Temperature, Strain rate

Comparison of constitutive laws on the modeling of thermo-viscoplastic behaviour of an aluminum alloy

Xingrong Chu, Lionel Leotoing, Dominique Guines, Jun

Introduction

Due to environment protection requirements, the innovative lightweight materials, such as aluminum alloys, have been widely adopted in the automotive industry thanks to their low density, comparable strength and stiffness characteristics. The analytical and numerical methods have been proved to be an effective tool to optimize the forming process parameters or to predict the formability of the studied sheet metal. For these innovative lightweight materials, their mechanical behaviours may be considerable different under different forming conditions. Hence, a reliable strain hardening model which can describe the flow stresses of the material over a wide range of temperatures and strain rates is essential in order to get an accurate modeling result.

Over recent years, several constitutive models have been developed for use in computational mechanics. Based on their intrinsic characters, they are classified into two major groups: physical based models and phenomenological models. The former can be applied to wide forming conditions due to their microstructure theory basis. But the great number of parameters to be identified, the complicated equation formulations and the difficulty of being implemented into finite element (FE) codes limit their applications (e.g. Rusinek-Klepaczko [START_REF] Rusinek | Shear testing of a sheet steel at wide range of strain rates and a constitutive relation with strain-rate and temperature dependence of the flow stress[END_REF]). Although the phenomenological models are based on experimental observations, they are widely used thanks to the simplistic expressions, reduced fitting parameters and the facility to be implemented into FE codes. In the sheet metal forming filed, the phenomenological models generally own a multiplicative expression which comprises the strain, strain rate and temperature functions.

In the literature, several works have been published to model the thermo-viscoplastic behaviour of the aluminum alloys. A modified Bergström model was proposed by van den Boogaard and Bolt [START_REF] Van Den Boogaard | A material model for warm forming of aluminum sheet[END_REF] for describing the flow stresses of AA5754-O under different temperatures (100, 175 and 250°C) and strain rates (0.002, 2 s -1 ). An extended Bergström model was also adopted by Palumbo and Tricarico [3] to predict the formability of AA5754-O. With this extended model, good correlation between numerical and experimental punch load was obtained. Abedrabbo et al. [START_REF] Abedrabbo | Forming of aluminum alloys at elevated temperatures -part 2: Numerical modeling and experimental verification[END_REF] proposed a modified power law to study the flow stresses of AA3003-H111 at different temperatures (25 -260°C) and strain rates (0.001, 0.1, 0.05 and 0.08 s -1 ). This model gives an accurate punch load curves description. The flow stresses of different aluminum alloys (AA6016-T4, AA5182-O) were described by Aretz [START_REF] Aretz | An extension of hill's localized necking model[END_REF] with the different forms of Voce models. Good correlations were obtained compared to experimental data. The responses of AA5182-O under a wide range of temperatures (23 -200°C) and strain rates (10 -4 -1 s -1 ) were studied by Khan and Baig [START_REF] Abedrabbo | Forming of aluminum alloys at elevated temperatures -part 1: Material characterization[END_REF] with a modified KHL model. A good correlation result was obtained.

In this study, based on the uniaxial tensile test results, two simple and different types of hardening models are modified to correlate the true stress-strain responses of an aluminum alloy AA5086 under different temperatures (20, 150 and 200°C) and tensile speeds (1, 10 and 100 mm•s -1 ). And the roles of the different hardening laws on the description of the material flow stresses are compared and discussed.

Proposed hardening models 1. Experimental equipments

With the designed grip system which allows a predetermined run to get the desired test velocity and the tested specimen as shown in Figure 1, the uniaxial tensile tests of AA5086 under temperatures (20, 150 and 200°C) and tensile speeds (1, 10 and 100 mm•s -1 ), corresponding to the strain rates of 0.02, 0.2 and 2 s -1 , were carried out and the flow stresses of AA5086 under the tested conditions were obtained. The experimental results show that the flow stresses of AA5086 are both temperature and strain rate dependent. The material flow stresses increase with the increasing tensile speed and decrease with the increasing forming temperature as presented in Figure 2.

Identification method

Based on the experimental data, taking into the strain rate sensitivity (m) influence with a multiplicative strain rate function, analyzing the evolution of the related parameters with the testing temperature as the similar procedures introduced by Abedrabbo et al. [START_REF] Abedrabbo | Forming of aluminum alloys at elevated temperatures -part 1: Material characterization[END_REF], the final proposed hardening models can be obtained. In this work, the fitting parameters are determined with an optimization method through a gradient-based Matlab minimization function.

Proposed KHL model

It is found from the experimental results that the initial yield stresses of AA5086 are only dependent on temperature but not on strain-rate, which is commonly verified for aluminum alloys. Based on the values determined from experimental stress-strain curves, the yield stresses of AA5086 can be described by Eq.1.

    0 0 0 1 exp 1 T T T K T T T m m                             (1)
Where   0 0 T  is the initial yield stress at ambient temperature, K=0.556 is the fitting parameter, T m = 627°C is the melting temperature. The evolution of the strain hardening and strain rate hardening parameters are analyzed according to the testing temperature. And the proposed KHL model to describe the flow stress of AA5086 is obtained as shown in Eq.2.

 

  T C C p m r m m T n n p n p T T T T D B T 1 0 3 2 1 exp 0 0 0 ln ln 1                                        (2)
Where T r = 20°C the reference temperature, B, n 1 , n 2 , n 3 , m, C 0 , C 1 are fitting material constants. 0  = 1s -1 and D 0 is the maximum strain rate (fixed to 10 6 s -1 ). The comparison of the flow stresses predicted by the KHL model and the experimental flow stresses are shown in Figure 2 and the identification values are presented in Table 1. As illustrated in Figure 2, despite its simplistic formulation, the proposed KHL model gives a good flow stress description under all the tested forming conditions. Due to its monotonic strain hardening character, the predicted flow stresses all give a little high evaluation at high strain level.

Proposed Voce model

A saturation Voce type model is also adopted to correlate the flow stresses of AA5086. The same identified procedure is applied and the final proposed model is obtained as shown in Eq.3. The strain hardening coefficient  

T K K K 2 1  
evolves linear with temperature and the strain rate sensitivity index

) exp( 1 0 T m m m 
evolves experimentally as the one observed in KHL model. The identification results are shown in Table 2. The proposed Voce model also gives a good flow stress description for all tested forming conditions. Due to the intrinsic saturation character, the proposed Voce model gives a better flow stress description at high strain level compared to the KHL model as shown in Figure 3. Good correlation results at high strain levels are obtained.

            T m m p p T K K T K K T 1 0 exp 4 3 2 1 0 exp 1            (3)

Discussion

With the proposed hardening models and the identified parameters, the KHL model and the Voce model both give a good flow stress description within the tested strain range for all the forming conditions. Due to the localized phenomenon, the strain level obtained by the tensile test can only up to about 20%. A clear uncertain exists when the identified hardening model is applied to high strain level. While in the sheet forming field, the deformed strain level usually reaches up to about 50%. So it is interesting to compare the flow stresses at high strain level predicted by the two hardening models. With the identified parameters, the extrapolation of the predicted flow stresses with the strain level up to 50% can be determined. As depicted in Figure 4, the two models both give a good flow stress description within the uniaxial tensile strain range, while great discrepancy is observed at high strain level. This difference can be explained by the different strain hardening characters of the two models. And this difference may play an important role in predicting the formability or in optimizing the process parameters in sheet metal forming field. For KHL model, a clearly monotonic flow stress description is observed and a temperature softening effect corresponding to a lower stain hardening rate is found at 200°C compared to the one at 20°C. Due to the saturation character, the Voce model show a saturation stress state at high strain level.

Conclusion

In this work, two different types of hardening models are proposed to describe the flow stresses of AA5086 under a wide range of temperatures and strain rates. Although with a simplistic formulation, both models give good correlation results within the measured strain range while big discrepancy appears at high strain level. Special attentions should be paid in choosing the hardening law in sheet metal simulation field. Despite its advantage, the uniaxial tensile test is unable to characterize the material behaviour at high strains. An alternative method to determine the high strain level stress-strain curve is essential to identify the hardening law parameters.

Fig. 1 .

 1 Fig.1. Grip system used in the tensile tests

  (a) 1 mm•s -1 (b) 10 mm•s -1 (c) 100 mm•s -1 Fig.2. True stress-strain curves of AA5086 and correlation with KHL model under different temperatures and tensile speeds Table.1. Fitting parameters of the proposed KHL model B

Fig. 3 . 1 Fig. 4 .

 314 Fig.3. Flow stresses correlation results with Voce model under different temperatures and 1mm•s -1

Table 2

 2

		Fitting parameters of the proposed Voce model
	K 1 (MPa) K 2 (MPa/°C)	K 3	K 4 (1/°C)	m 0	m 1 (1/°C)
	201.9	0.2457	13.4023	0.04473 0.0001514 0.02965

Acknowledgement

Thanks for the support provided by Jun Gao. The corresponding author is Jun Gao.