Pierre Laborde
email: pierre.laborde@fr.thalesgroup.com

Steven Costiou
email: steven.costiou@inria.fr

Éric Le Pors
email: eric.lepors@fr.thalesgroup.com

Alain Plantec
email: alain.plantec@univ-brest.fr

5 years of reuse experience in evolutionary prototyping for the defense industry (preprint)

Keywords: Evolutionary prototyping, Component reuse, Traits, Pharo

At Thales Defense Mission Systems, software products first go through an industrial prototyping phase. We elaborate evolutionary prototypes which implement complete business behavior and fulfill functional requirements. We elaborate and evolve our solutions directly with end-users who act as stake-holders in the products' design. Prototypes also serve as models for the final products development. Because software products in the defense industry are developed over many years, this prototyping phase is crucial. Therefore, reusing software is a high-stakes issue in our activities. Component-oriented development helps us to foster reuse throughout the life cycle of our products. The work presented in this paper stems from 15 years of experience in developing prototypes for the defense industry. We directly reuse component implementations to build new prototypes from existing ones. We reuse component interfaces transparently in multiple prototypes, whatever the underlying implementation solutions. This kind of reuse spans prototypes and final products which are deployed on different execution platforms. We reuse non-component legacy software that we integrate in our component architectures. In this case, we seamlessly augment standard classes with component behavior, while preserving legacy code. In this paper, we present our component programming framework with a focus on component reuse in the context of evolutionary prototyping. We report three scenarios of reuse that we encounter regularly in our prototyping activity.

Introduction

In the defense industry, software systems are designed, developed and evolved over many years. It is therefore important to evaluate and to adjust systems' design ahead of time before starting long and costly development phases.

At Thales Defense Mission Systems (DMS), the Human-Machine Interface (HMI) industrial prototyping activities are an important part of the software production process. HMI industrial prototyping is the building of software prototypes as close as possible to real products from the HMI point of view (graphics and ergonomics). Using prototypes, we evaluate software HMI design and experiment complete use-cases with end-users. This enables early and strong feedback loops between developers and end-users. Using prototypes, we anticipate architectural needs and problems before development of real products begin. The prototyping activity is followed by an industrialization phase, in which we build final products based on prototypes' evaluations and feedback.

Because we build and rebuild prototypes, we need means to reuse code from existing pieces of software. We need to evolve parts of prototypes without changing how these parts interact with the rest of the software. To foster such modular architectures, Thales use component-oriented programming [START_REF] Szyperski | Component-oriented programming[END_REF][START_REF] Lau | Software component models[END_REF]. Componentbased architectures bring the necessary modularity to enable reuse and evolution of prototypes.

In this paper, we present our requirements for reusable software in our industrial context. We describe how component-oriented programming helps us fulfill these requirements (Section 2). We present how we implement components for modular and reusable software architectures with the Molecule componentoriented programming framework (Section 3). This framework is today the main tool that we use for evolutionary prototyping, for which we report and discuss 15 years of reuse experience and the difficulties we face today (Section 4).

Reuse in prototyping for the defense industry

Exploring design ideas through Concept prototyping [START_REF] Bernstein | Foreword: Importance of software prototyping[END_REF][START_REF] Lidwell | Universal Principles of Design[END_REF] is one of the main activities at Thales DMS. Prototypes are developed to help communicate concepts to users, demonstrate the HMI usability and exhibit potential problems. Moreover, prototypes are developed and maintained until they meet users expectations regarding not only the HMI, but also the main business functionalities. Some of our prototypes implement complete business behavior and fulfill functional requirements. Thus, they are also kind of evolutionary prototypes [START_REF] Lidwell | Universal Principles of Design[END_REF]. Thales DMS engineers maintain a lot of them since 15 years.

Maintaining evolutionary prototypes is a very expensive activity and Thales struggled with evolution issues. Building a final product is also an expensive and a tedious task, and engineers must take advantage of the prototyping activity. Furthermore, the prototyping and the final product teams have to fully understand each others' designs. This poses a knowledge sharing issue.

We use component-oriented programming to build and to maintain evolutionary prototypes, and to share knowledge between prototyping and industrialization activities. In this context, this section introduces briefly the component model we use in prototyping, and the overall benefits of component-oriented programming that we observed in our development process.

The Molecule component model

Our component model is close to the light-weight CCM [START_REF]Corba component model specification[END_REF]. We use Molecule, a Thales open-source implementation4 of the light-weight CCM.

A Molecule component implements a contract defined by its Type (Figure 1). A contract consists in a set of services that the component provides, a set of services that the component uses, a set of events that the component may emit, and a set of events that the component is able to consume. The Type implements the services that the component provides and that are callable by other components, and defines the events that the component produces. Other components use its Provided Services interface through their Used Services interface. Other components listen to the component's Produced Events interface through their Consumed Events interface. Components subscribe and unsubscribe to event interfaces to start and stop receiving events. Parameters are specific and are not present in the CCM. We use parameters to control components' state, and only once when initializing components.

Components as reusable modules

At the beginning of a project, we benefit from direct reuse of previous prototypes' components. Through composition of existing components, we reduce the time and efforts to get to the first versions of a new prototype.

Being able to build reusable and homogeneous software architectures was the first motivation for using components. This is particularly true for Graphical User Interfaces (GUI) components that we call Panels. It is well known that GUIs are expensive to implement. Our panels expose a stable public interface and implement a standard contract. We therefore directly reuse our panels in several prototypes (Figure 2). The reused parts include not only the contract but also its implementation provided by the Type. This kind of reuse is now possible because we capitalized a sufficient quantity of components. After a decade, we benefit from a virtuous cycle where a finished prototype is kept in a prototype repository and some of its component set can be reused later for another prototype. This virtuous cycle tends to minimise the number of prototypes that we need to implement from scratch.

In Figure 2, we show our prototyping reuse chain. From previous legacy code, we build standardized and reusable components, defined by their contracts. When a component assembly covers a technical or a business requirement, it becomes a sub-system (e.g., a geographic view with layering, filtering, selection...). Prototypes (re)use and deploy instances of sub-systems and/or of single components. Each time we build a new prototype, we identify new functionalities or reusable bricks and we integrate them back into the repository of existing components or sub-systems for future reuse. Fig. 2: From components to prototypes: a reuse chain.

Components to ease evolution

Change and evolution of software is always an issue. Switching to another technology implies modifying the existing software code to integrate that technology. This kind of change hinders our ability to reuse software to evolve our prototypes. For example, GUI technologies are often changed, because they evolve, they become obsolete or they stop being maintained. A new GUI framework will expose different interfaces and trigger different events. This forces developers to rewrite the same GUI in different technologies over the years [START_REF] Dutriez | Switching of gui framework: the case from spec to spec 2[END_REF][START_REF] Verhaeghe | Gui migration using mde from gwt to angular 6: An industrial case[END_REF].

Without components, this kind of change forces us to change how GUIs interact with legacy or business software. It implies adaptation of such software, which will impact all using projects, or force us to maintain different versions of the adapted code. This is not desirable as, e.g., we have legacy sub-systems in use since a decade by multiple maintained prototypes. Because our prototypes are composed of components, in case of such a change, only a well identified part of the system has to be adapted (Figure 3). We evolve the related components implementation without changing GUI clients nor legacy and business software.

Engineering impact: design traceability and co-working

Thales DMS' design process involves different and specific teams that work together throughout the life cycle of a product. The system engineering team builds Fig. 3: Components to ease evolution, for example: changing GUIs. systems' design models using dedicated methods like Arcadia [START_REF] Voirin | Model-based System and Architecture Engineering with the Arcadia Method[END_REF] and modeling tools like Capella [START_REF] Bonnet | Not (strictly) relying on sysml for mbse: Language, tooling and development perspectives: The arcadia/capella rationale[END_REF]. System engineers model interactions between hardware entities, software entities, users, etc. These models are produced early in the design of a product. The prototyping team develops and evaluate prototypes based on these models. The software engineering team develops final products.

The prototyping team is composed of 5 to 10 engineers. For each product, there are 10 times more system and software engineers working with the prototyping team. The descriptive properties of components models (interfaces, interaction models...) ease communication between different teams working with different technologies (Figure 4). For example, when building a GUI panel, the system team uses components to specify interactions between end-users and the panel. From these specifications, the prototyping team builds a first version of the panel to evaluate these interactions with end-users. Finally, the software engineering team builds a stable and robust version of the panel, connected to the real product's environment.

Using a common vocabulary also favors reuse, as components can be inserted and (re)used in an architecture solely based on their contract, without having to master implementation details. 3 Component-oriented programming with Molecule Since 2005, Thales DMS use Smalltalk for prototyping. The main motivations behind the choice of Smalltalk is the ability to quickly design and program complex prototypes, and the capabilities to lively change a design in the front of customers [START_REF] Ingalls | Back to the future: The story of squeak, a practical smalltalk written in itself[END_REF][START_REF] Rein | Towards exploratory software design environments for the multi-disciplinary team[END_REF]. Thales adopted component-based development to ease software reuse and separation of concerns. Since 2016, we use Pharo [START_REF] Ducasse | Pharo by Example 5[END_REF] with the Molecule component-oriented programming framework. Thales developed Molecule to capitalize on its experience in component-based development. This section briefly describes how we program components with Molecule.

The Molecule framework relies on Traits [START_REF] Schärli | Traits: Composable units of behaviour[END_REF][START_REF] Ducasse | Traits: A mechanism for fine-grained reuse[END_REF][START_REF] Tesone | A new modular implementation for stateful traits[END_REF] to implement component Types. A Trait is an independent set of methods with their implementation and requirements (methods and variables). Classes using a Trait automatically benefit from these methods, and must define that Trait's requirements. A Trait can be composed of multiple other traits. In this case, a class using this composed Trait benefits from all the methods provided by the Traits composition. A Trait provides orthogonal behavior to all classes using that Trait, regardless of their class inheritance hierarchies. In Molecule, we define the elements of a component's contract (services, events, parameters) as a set of Traits (Figure 5). A component Type aggregates theses traits, and is itself defined as a Trait. Molecule provides a dedicated Trait MolComponentImpl, which implements cross-cutting behavior shared by all components (e.g., components' life-cycle management). Implementing a component consists in defining a class that (1) uses the MolComponentImpl Trait to obtain component shared behavior and (2) uses a Type Trait (MolComponentType) implementing the component's business behavior (Figure 6).

The direct benefit of this approach is that it is possible for any existing class to become a component. This existing class is then turned as (or augmented as) a component, and becomes usable in a Molecule component application while remaining fully compatible with non-component applications (Figure 7).

Molecule provides syntactic sugar to directly implement components by inheriting from the MolAbstractComponentImpl class (Figure 6). In that case, we only need to satisfy (2) by using a Type Trait for our component.

The evolution of components is driven by Traits. For example, to provide new services, an augmented class will use additional Traits defining these services. The integration of the Traits implementing the component contract with the original class may require some code adaptation. Typically, when we reuse Fig. 6: Two ways to implement a component. classes from legacy software as components (e.g., a radar class), we have to adapt how the component's Type (i.e., it's business behavior) interacts with the class API (e.g., by converting the radar's accuracy from feet to meters). This code adaptation ensures that the augmented class provides the correct level of information in regards with the requirements of the connected components.

Reuse scenarios and difficulties at Thales DMS

In this section, we describe three reuse scenarios that we regularly and successfully deal with during our prototyping activity. While we learnt how to cope with these reuse scenarios, we still encounter many difficulties that we discuss.

Common reuse scenarios in the prototyping activity

While prototyping, we frequently deal with three reuse scenarios: long-term reuse of legacy code, reuse of non-component frameworks and reuse of component business interfaces. The story of Prototype X 5 is a successful illustration of the application of these scenarios. This prototype is an HMI for touch tables with completely new ergonomics and multi-user functionalities, that we built in 2019. We did not have any functional code implementing touch table ergonomics with multiple users at the same time. However, most of the business and tooling behavior already existed in previous prototypes. Overall, the complete prototype is composed of 674 components and 1704 additional classes, for a total of 47447 methods. We only wrote 22 new components and 35 classes. We reused 603 components and 991 classes from 5 existing sub-systems (Table 1). Reused components represent 89.47% of the prototype's components and reused classes represent 58.16% of the prototype's classes 6 . This use-case is representative of fast-written prototypes we build, with multiple iterations over two years. Long-term reuse of legacy code. This scenario is the most common case of reuse in our prototyping activity. For each new prototype, we systematically need to reuse functionalities from previous prototypes or from legacy code. Before we based all our architectures on reusable components (2005-2013), we used to reuse code by manually performing copy/paste of hundred of classes from prototype to prototype. Since then, component-based architectures help us to reuse legacy code from previous prototypes in new prototypes. For example, 10 years ago, we took an old prototype using an old GUI technology. As this prototype was component-based, we were able to redesign the HMI with another technology without modifying the component architecture. The complete business layer of this old prototype continued to work transparently with the new HMI design (as in Figure 3). Components forming this business layer became particular sub-systems reused in many other prototypes. Today, 10 years later, we continue to reuse and enrich these sub-systems in our new prototypes. Typically, these sub-systems simulate complex hardware and software systems such as radars, sensors, detection and communication equipment, etc.

Another example of frequently reused sub-system is the tactical view 7 . This view is a recurrent requirement throughout our different prototypes. We reuse the same tactical view sub-system from prototype to prototype since 10 years.

Reuse of non-component frameworks in component architectures. In this scenario, we need to reuse non-component code in our component-based architectures. Typically, we rely on open-source frameworks in our prototypes: UI models, graphics engines, visualization engines, etc. These frameworks are object-oriented, so we augment their classes with Molecule to reuse them directly in our component-based prototypes.

We start by inheriting from the framework classes we want to reuse. We then apply the Molecule component Traits to the inherited classes to augment them with component behavior. As illustrated by Figure 7, these classes become usable transparently by both standard applications and our component systems.

For example, we regularly need to reuse graphical, non-component elements from open-source graphics engine. This happens when we want to extend a component sub-system to support another graphics engine. Therefore, we augment classes of graphical elements (views) as components to directly connect them to our component sub-systems. This allows us to add new graphics technologies as display backends with very few adaptations.

Reuse of component business interfaces. In this scenario, we reuse components' business contract to replace component implementations transparently (as in Figure 5). Interactions between components are expressed through component contracts, which are reusable for different components implementations. Components exposing the same contract are seamlessly interchangeable.

For example, we had a prototype for which we needed to migrate the database system to a new database backend. The database access (i.e., database requests) was implemented in a dedicated component. High-level data access (i.e., data requests) was defined in that component Type (i.e., its Type Traits). Other components communicated with the database through the contract defined by the Type, i.e., to request data without knowing about the database access details.

To change the database, we implemented a new component for a new backend and we reused the Type Traits for high-level data access. We were then able to transparently switch the old component by the new one in the prototype.

Discussion

The example of Table 1 is a nice success story of software reuse. We built a new prototype from existing sub-systems, while developing additional code only for new aspects of this prototype. Software reuse brings direct benefits to our prototyping activity, but there are difficulties that we do not overcome yet.

Benefits of reuse for evolutionary prototyping. We apply systematic reuse [START_REF] Lynex | Organisational considerations for software reuse[END_REF] of software to reduce the time and cost of building, maintaining and evolving prototypes. The ability to reuse (parts of) previous prototypes, legacy software and non-component code within component architectures enables fast building of new prototypes. We can build a base prototype for a new project in a few days. From there, we experiment ideas, enrich that base, then evolve and maintain the resulting prototype over years. Some sub-systems (e.g., the tactical view, or a radar simulator) will not change over many years while being systematically reused in many prototypes. These sub-systems became more stable with time, and today we trust that we can reuse them while maintaining software quality. Typically, we encounter less bugs in older and frequently reused components than in more recent components.

Similar benefits of software reuse in industrial contexts are reported in the literature [START_REF] Mohagheghi | Quality, productivity and economic benefits of software reuse: a review of industrial studies[END_REF][START_REF] Barros-Justo | What software reuse benefits have been transferred to the industry? a systematic mapping study[END_REF]. The most reported benefits are increased quality [START_REF] Barros-Justo | What software reuse benefits have been transferred to the industry? a systematic mapping study[END_REF], increased productivity [START_REF] Mohagheghi | Quality, productivity and economic benefits of software reuse: a review of industrial studies[END_REF][START_REF] Barros-Justo | What software reuse benefits have been transferred to the industry? a systematic mapping study[END_REF], reduced development cost and time and a lower defect rate [START_REF] Barros-Justo | What software reuse benefits have been transferred to the industry? a systematic mapping study[END_REF]. While reflecting on 15 years of reuse, we observe these same benefits throughout our different prototypes. Another commonly reported benefit of reuse is a shorter time to market [START_REF] Barros-Justo | What software reuse benefits have been transferred to the industry? a systematic mapping study[END_REF]. In our case, prototypes are not destined to end up in the market. Rather than a shorter time to market per se, we speak of a shorter time to prototype evolution. The purpose of our prototypes is to live and evolve from end-users feedback and evaluation. Fast prototype evolution is therefore a valuable benefit. Over the years, this benefit has been plebicited by our customers and this encouraged us to push it further this way.

Smalltalk to explore reuse opportunities. While building and evolving prototypes, we rely on Smalltalk's live and exploratory nature [START_REF] Ingalls | Back to the future: The story of squeak, a practical smalltalk written in itself[END_REF][START_REF] Rein | Towards exploratory software design environments for the multi-disciplinary team[END_REF] to find and to understand components to reuse. To select which component to reuse, we lively explore and experiment components from our repository. For a given requirement, we study components' interfaces, we start and connect them, observe how they behave, and dynamically explore how they can be reused. We choose which component to reuse from these experiments, and with time we know from this empirical experience which components fit specific (re)use-cases.

This strategy of components selection seems common in practice [START_REF] Land | Reuse with software components-a survey of industrial state of practice[END_REF]. Using Smalltalk provides a live and dynamic perspective, that improves this strategy's output. However after many years, relying on this sole strategy became less effective. We have today too much components and sub-systems: we cannot explore everything lively, and the amount of necessary knowledge to choose the right components is oversized. To overcome this difficulty, we needs to study means to filter meaningful components ahead of time, before live experiments.

Pitfalls of reusing everything. We observe that we tend to reuse everything. The example from Table 1 is a typical illustration of massive reuse, although successful. However, we still lack rigorous means of evaluation to determine if we should reuse a component [START_REF] Land | Reuse with software components-a survey of industrial state of practice[END_REF], if we should implement a new component, and in this latter case if we should make this component reusable. Making components reusable has a cost but in practice some of them are never reused. In this case, the cost of systematic reuse exceeds the cost of ad-hoc development.

While applying massive reuse, we do not allow enough time for documenting our prototypes, their components and their sub-systems. We therefore lack the knowledge to choose which component or sub-system to reuse, nor how to reuse them. Typically, building the prototype from Table 1 requires an extensive knowledge of existing sub-systems, how to integrate them into the new prototype architecture and what is missing to realize the new prototype. Consequently, it is difficult to select components and sub-systems for reuse.

In addition, this expertise is shared among developers but mostly depend on a few experts. This is a problem for transmitting knowledge to new people, and a serious concern in the long term. If the few reuse experts leave, knowledge will be lost and reuse possibilities will be jeopardized as well as all its benefits. Knowledge and retrieval of reusable components in the context of a project, while in our case not directly inhibiting reuse [START_REF] Lynex | Organisational considerations for software reuse[END_REF][START_REF] Bauer | Analysing and supporting software reuse in practice[END_REF], are clearly a weakness and a slowdown in our development process.

Finally, some of our sub-systems implementations are too focused on the realization of business behavior, and mix business and technical concerns. To reuse technical parts of such sub-system, we have to reuse the complete subsystem. In this case, we lack perspective while implementing and architecturing components into sub-systems to avoid this pitfall.

Conclusion

At Thales DMS, we elaborate evolutionary prototypes that we refine until they meet end-users functional and ergonomics requirements. We then evolve and maintain these prototypes for years. Prototypes serve as realistic demonstrators used as the main input when building and evolving final products. This process is expensive, and we heavily reuse software to minimize development costs and to maximize the quality of our prototypes.

To support the reuse of software, we use component-based development. Since 15 years, we develop reusable components using Smalltalk, and we reuse these components in our prototypes. Today, Thales capitalized this experience in Molecule, a component framework built in Pharo Smalltalk, with which we build our new prototypes. We organize our components and sub-systems in a repository. We reuse elements from this repository to build new prototypes, and each time we enrich the repository back with new reusable elements. Building a realistic demonstrator based on these reusable elements is industrially efficient. Our prototyping team builds prototypes with reduced development costs and time, while focusing on functional concepts and ergonomics. Long-time reused elements expose less bugs and are trusted while reused in new prototypes.

We presented our reuse scenarios: long-term reuse of legacy code, reuse of non-component frameworks and reuse of component business interfaces. After 15 years, we can highlight a beneficial rate of component reuse. We also reported our reuse difficulties. We struggle with our too large amount of reusable elements, and the necessary knowledge required to exploit them efficiently. It is more and more difficult to identify reusable elements to build prototypes.

To improve how we select reusable elements, we plan to study how to exploit preliminary systems models to allow for the early identification of reusable elements. We also plan to conduct larger scale empirical studies at Thales to better understand how we applied reuse over the years. This will help us to take a step back and to reflect more on our reuse processes in order to improve our prototyping activity and to standardize our reuse practice in all Thales.

Fig. 1 :

 1 Fig. 1: Public view of a Molecule component.

Fig. 4 :

 4 Fig. 4: Engineering impact: design traceability and co-working;

Fig. 5 :

 5 Fig. 5: Component contract implementation in Molecule.

Fig. 7 :

 7 Fig. 7: We use augmented classes in component and non-component applications.

Table 1 :

 1

	Sub-System (the * means reuse)	Components % Classes %
	Prototype X (new code)	22 3.26	35 2.05
	Survey mission system *	37 5.49	71 4.17
	Mission technical system *	332 49.26	236 13.85
	Command-Control architecture *	26 3.86	34 2.00
	Scenarios and simulation *	53 7.86	127 7.45
	Tactical views and models *	155 23.00	523 30.69
	Prototyping tools & models (framework)	49 7.27	678 39.79
	Total	674 100	1704 100

Component and class reuse in a prototype from 2019: 603 reused components (89.47% of the prototype's components) and 991 reused classes (58.16% of the non-component prototype's classes).

https://github.com/OpenSmock/molecule

For confidentiality reasons, we cannot give the real name of this prototype.

We do not count the prototyping framework's code as reuse.

Geographical business objects display on a map


Pierre Laborde
email: pierre.laborde@fr.thalesgroup.com

Steven Costiou
email: steven.costiou@inria.fr

Alain Plantec
email: alain.plantec@univ-brest.fr

Eric Le Pors
email: eric.lepors@fr.thalesgroup.com

Molecule: live prototyping with component-oriented programming

Keywords: Live Prototyping, Components, LCCM, Traits, Pharo

published or not. The documents may come

Introduction

At Thales Defense Mission Systems, the Human-Machine Interface (HMI) industrial prototyping activities are an important part of the software production process. HMI industrial prototyping is the building of software prototypes as close as possible to real products from the HMI point of view (graphics and ergonomics). Using prototypes, we evaluate software HMI design and experiment complete use-cases provided by end-users. This enables early and strong feedback loops to fulfill users requirements. Using prototypes, we anticipate architectural needs and problems before development of real products begin. The prototyping activity is followed by an industrialization phase, in which we build final products based on prototypes' evaluations and feedback.

The dynamic aspects of prototyping requires the capability to modify code at run time. Evaluations of prototypes take hours and end-users are rarely available for review meetings. During a prototype evaluation bugs may appear, and endusers may request live modifications of the prototype to experiment ideas. In such cases, it is important to efficiently benefit from direct feedback. We cannot stop the program and lose hours of evaluation. We need to modify and to debug our prototypes without restarting everything.

In this paper, we present Molecule, an open-source component-oriented programming framework for the building of modular software architectures. Molecule has been implemented in Pharo [START_REF] Ducasse | Pharo by Example 5[END_REF] to favor changes at run time, during demonstrations in front of our end-users. Molecule features a component model based on the Light-weight CORBA Component Model (CCM) specification [START_REF]Corba component model specification[END_REF]. Molecule is based on Traits [START_REF] Ducasse | Traits: A mechanism for fine-grained reuse[END_REF][START_REF] Schärli | Traits: Composable units of behaviour[END_REF][START_REF] Tesone | A new modular implementation for stateful traits[END_REF] to define component contracts and to define interfaces' behavior. The dynamic aspects of Traits in Pharo allows us to dynamically redefine and change component architectures at run time. We are thus able to experiment changes and ideas with end-users during demonstrations: this is what we call live prototyping.

In this paper, we present the following contributions:

1

• We exhibit the benefits of Pharo in an industrial context where we use live prototyping intensively to elaborate complex systems, • an overview of Molecule, our Trait-based component framework which brings a clear separation of concerns to our prototypes implementation and facilitates updates at run time. The paper is organized as follows. We explain our requirements for live prototyping and how components help for the elaboration of complex prototypes in Section 2. We present an overview of Molecule in Section 3, and illustrate its usage through examples in Section 4. We study related work in Section 5 and conclude the paper in Section 6.

Live prototyping in the defense industry

In the defense industry, we obtain high value feedback from prototypes demonstrations with end-users. During a demonstration, we need to quickly and efficiently capture users' needs to elaborate Graphical User Interface (GUI) prototypes. This work cannot be done remotely. It requires presence, observation and feelings from users in front of their application. However, there are strong constraints from our end-users' availability:

• We might only see end-users during a few days once a year for a prototype demonstration, • during demonstrations, users always have requests and ideas they want to experiment, • we need to take advantage of the users' presence to experiment those ideas and benefit from live feedback loops. Therefore, a strong requirement of our prototyping activity is the ability to change pieces of software at run time to adapt prototypes according to the end-users's feedback. Thus, a prototype implementation is expected to evolve often and quickly during a demonstration. As we learn during our meetings with end-users, the architecture as well as the implementation of the software change many times.

Figure 1. Live prototyping with Components

The importance of live prototyping

Imagine a moving train (Figure 1) and imagine that workers are changing the rails path without stopping the train. In practice, this is what we expect during workshops and evaluations: the running prototype is halted on the fly, its code is updated in front of our end-users and then restarted without stopping the running demonstration. This is particularly important when we need to choose one solution among several design candidates. In that case, we evaluate alternatives by changing the prototype code on-the-fly.

Live code modification gives us the ability to understand constraints in a given context, and to experiment code alternative without losing this context. Indeed, a demonstration scenario may last hours, and users perform lots of actions and configurations. If we have to restart demonstrations each time we change the software, we lose the execution context, the scenarios' data and the measured metrics. Complex user interactions inputs are hard to reproduce, e.g., mouse events sequences or touch finger gestures. We cannot guarantee that users will do the same actions again and that they will reproduce the same execution context. In addition, end-users' availability is limited and we cannot afford to replay hourslong scenarios to experiment variations.

When live prototyping with end-users, we dynamically change the running software to experiment new solutions without restarting the entire evaluation scenario and losing measured metrics. To users, these changes are done transparently: they do not lose their configurations, their data nor the state of the running scenario.

Enabling live prototyping: an industrial context

Since 15 years, the Thales Defense Mission Systems prototyping team uses Smalltalk for prototyping. The motivation behind the choice of Smalltalk is its dynamic capabilities which enable live changes of a design in the front of customers. From 2005 to 2016, the VisualWorks1 system was used. Since 2016, we integrate also Pharo [START_REF] Ducasse | Pharo by Example 5[END_REF] as a programming environment solution.

However, these technical capabilities for live programming are not enough in our context. Let us come back to the illustration of Figure 1. Developers are changing preassembled rails. They do not have to build them on the fly with wood and steel. They dynamically switch one code portion implementing a particular functional solution by another in few editing steps. Similarly, we need to clearly separate the code portions that are updated on the fly from the legacy code that must stay unchanged [START_REF] Panunzio | A component-based process with separation of concerns for the development of embedded real-time software systems[END_REF].

Our final products are component-based architectures, and we need prototypes and final products to share similar architecture principles. This guarantees equivalent levels of services, and precise evaluations of development costs of final products. Therefore, we also decided to base the prototyping step on component-oriented development to bring consistency in the whole product life-cycle from the prototyping to the final product. In this context, we developed

Molecule overview

Molecule is a Light-weight implementation of the Corba Component Model (LCCM) [START_REF]Corba component model specification[END_REF]. It allows for the specification of components as in the Corba standard: provided and used services, produced and consumed events. However, Molecule components are only specified and instantiated locally. They are not exchanged nor shared through a standard object bus. The rest of this section briefly presents what is a Molecule component and how it is dynamically managed.

Molecule, a component framework

Similarly to the LCCM, a component's business contract is exposed through its component Type (Figure 2). The Type specifies what a component has to offer to others components (namely, provided services and produced events) and what that component requires from others components (namely, used services and consumed events). Thus, the main role of the Type is to implement the services that the component provides and that are callable by other components. Other components use this interface through their Used Services interface. Produced Events represent the receivable events interface of the component. Other components listen to this interface through their Consumed Events interface. They subscribe and unsubscribe to their event interface to start and stop receiving notifications. Parameters are used to control the component's state. Parameters can only be used once at the component's initialization. The light-weight CCM model does not define Parameters, but instead it allows direct access to public attributes. We introduced the Provided Parameters as an interface to explicitly define how the state of a component can be initialized. Other components use this interface through their Used Parameters interface.

A Molecule component definition is based on Traits [START_REF] Ducasse | Traits: A mechanism for fine-grained reuse[END_REF][START_REF] Schärli | Traits: Composable units of behaviour[END_REF][START_REF] Tesone | A new modular implementation for stateful traits[END_REF]. The Type, as well as the services, the events and the parameters parts are all defined as Traits. A Molecule component is an instance of a standard class which uses Molecule traits.

Live update of components

When a Type is modified, a mechanism automatically updates the component classes implementing this Type. A Molecule Type is defined by a set of related Traits. A Molecule component is made of a class which uses a Type Trait. A Type can be modified either by modifying the Trait aggregation or the Traits themselves.

For example, adding a particular method in a service Trait implies updating the related methods in the class that is using the component Type. In that case, some methods have to be implemented by hand to plug in the services, and then to turn the component into a fully usable one at run time. Recall that during a demonstration, switching from one component to another must be doable as fast as possible to benefit from a live demonstration flow. Upon the modification of a Type, an additional mechanism automatically implements changes into component classes using this Type (Figure 3). Adding or removing Traits (services, events or parameters) in a Type is automatically detected and all classes using the updated Type are themselves updated accordingly. This mechanism is implemented using the Pragma [START_REF] Ducasse | Pragmas: Literal Messages as Powerful Method Annotations[END_REF] infrastructure of Pharo.

Run-time management of components

All components are managed by the ComponentManager object. It maintains the list of component instances currently alive in the system. It is currently handled as a singleton. The ComponentManager class implements an API to instantiate and to remove each component, to associate them, to connect events, etc. This API is used to manage each component life cycle programmatically.

The component states

The activity of a component depends on contextual constraints such as the availability of a resource, the physical state of hardware elements, etc. To manage consumed resources accordingly, the life-cycle of a component has four possible states: Initialized, Activated, Passivated and Removed (Figure 5). After its initialization, a component can switch from an Activated state to a Passivated state and conversely. When the life-cycle of a component is over, then it switches to the Removed state.

Let us details each state of a component life-cycle. When a component is switched to the Initialized state, it is configured through its provided parameters. If a component depends on another component through its interfaces (used services, consumed events or used parameters), these components are associated during this state.

The Activated state is the nominal state of a component. When a component is switched to this state, it subscribes to each consumed events that are produced by the components that have been associated with it during the Initialized state. After this subscription step, the component is able to receive and react accordingly to any of its consumed events.

When a component is paused, it switches to the Passivated state. Then, the component unsubscribes to its subscribed events and all its required resources are set in waiting mode. As an example, a hardware can be set in its sleeping mode, it can also be asked to free its Graphics Processing Unit memory. The idea behind this state is to avoid consuming resources if not needed, and to be able to switch back as quickly as possible to the Activated state.

The terminal state of a component is the Removed state. When a component switches to this state, all of it resources are released. The ComponentManager removes that component from its list of alive components.

Let us illustrate the use of these states with the example of a GUI window handled as a component. First, the window is instantiated by the component. Then the component state switches to Initialized. When the window is displayed on the desktop, the component's state switches to Activated. When the window is reduced and its icon is stored into a task-bar, then the component switches to the Passivated state. As the window is only reduced, it can be re-opened very quickly. Finally, when the user closes the window. The component is first switched to the Passivated, then to the Removed state.

Molecule by example

In this section, we give an overview of Molecule through two examples. As depicted in Figure 6, in the first example, we program a component application that connects to a Global Positioning System (GPS) hardware and displays the GPS data on a view map. In the second example, we reuse an existing non-component class in our Molecule application. To do so, we augment this class with component behavior.

The GPS map and data provider example

In this example, we create two Molecule components with their Types. We show how we define the components events and services and how these components interact with each other (Figure 7).

We create a first component, its job is to manage and provide datas from a GPS hardware (as the current geographic position). Listing 1 shows an example of component implementation. To develop a new component from scratch, developers subclass the MolAbstractComponentImpl abstract class. In fact, MolAbstractComponentImpl is a syntactic sugar directly using the default Molecule trait which injects We define the GPSData Type as a Trait which itself uses the Molecule base Type MolComponentType (Listing 2). This base Type provides the skeleton methods providedCompo-nentServices and producedComponentEvents. Developers have to complete these methods by hand to declare the provided services and the produced events. The method providedComponentServices (or produced-ComponentEvents for events) return the array of Traits that implement the specific provided services (or produced events for events). Specific services and events are implemented in their own trait, namely, GPSDataServices and GPSDataEvents (Listing 3). In these traits, we add methods that the GPSData component Type has to implement. We create a second component to display a GPS position on a map. The map displays a circle around the position whose radius represents the accuracy of the GPS. The second component needs to be connected with an existing GPS data provider component. In Listing 4, we add a new component class GPSMapImpl (lines 1-2) with a new GPSMap Type (line 3). The Type GPSMap requires to consume services of the GPSDataServices interface (lines 4-6) and to use events of the GPSDataEvents interface (lines 7-9). Note that these interfaces are already defined and used by our first component GPSDataImpl. A component is expected to implement a particular method for each state introduced in Section 3.4. These methods are called when the component is switched to the corresponding state. In our example, regarding the Activated state, the corresponding method is componentActivate. This method is completed by hand with the subscription code shown in Listing 6 to enable events reception management.

In this example, the subscriber does not specify which instance of the event provider is required. In that case, the GPSMapImpl component subscribes to the first available event provider. When GPSMapImpl is activated, it subscribes to the GPSDataEvents event provider. After the subscription, a GPSMapImpl is able to receive the position change events to update its view accordingly.

Reusing existing code as Molecule components

Imagine that we want to reuse an open-source library that implements the driver for the GPS hardware that we use. We want to reuse a class from this existing implementation in our application to add the capability to use this GPS hardware. This class is not a Molecule component, and does not share the same class hierarchy as Molecule components. Therefore this class does not answer the Molecule component's interface, and cannot be reused directly as a component. To manually plug this class into a Molecule component, we have to write glue code for the component to use the API of this class. This requires an additional effort to write nonfunctional code, which introduces noise in the application code. This makes such architecture less to understandable and to maintainable.

With Molecule, we reuse any existing class by augmenting that class with component behavior (Figure 8). This class becomes seamlessly usable as a component in a Molecule architecture.

Imagine that we want to reuse a class GPSHardware. This class is originally used as described in (Listing 8). Developers must instantiate this class, then interact with its instances to use the GPS hardware. After augmenting the GPSHardware class with component behavior, we make sure the class implements the component contract in accordance with the GPSData Type. By default, these methods are automatically generated by Molecule. In this example (Listing 9) as we reuse an existing class, we adapt the generated interface to fit our needs:

• We implement a call to the behavior provided by the class, • we implement in addition a conversion from the feet to meters unit.

Because of the interface enforced to every Molecule component, we are able to directly reuse and specialize an existing class. We only write domain code to reuse existing behavior into the component architecture and avoid writing non-functional code. Swapping components does not require to restart the whole application, and can be performed at run time. Between the removal and replacement of a component, it is possible that other components continue to access the services of the removed component (e.g., in multi-threaded applications). In that case, Molecule automatically returns a default instance that corresponds to a non-existing provider. Components implementations must handle this default instance when they require a service from another component.

Related Work

Molecule provides the same well-known architectural and reuse benefits of software components systems [START_REF] Lau | Software component models[END_REF][START_REF] Szyperski | Component technology-what, where, and how?[END_REF][START_REF] Szyperski | Component-oriented programming[END_REF][START_REF] Szyperski | Component software: beyond object-oriented programming[END_REF]. To focus on the live aspect of prototyping, we study related work on run-time software modification.

Run-time adaptation in component systems has been well studied. For instance, and non-exhaustively, there is work on dynamic component modification [START_REF] Fabresse | Unanticipated connection of components based on their state changes notifications[END_REF][START_REF] Piechnick | Using rolebased composition to support unanticipated, dynamic adaptationsmart application grids[END_REF][START_REF] Vandewoude | Supporting run-time evolution in seescoa[END_REF], with safety [START_REF] Vandewoude | Dynamically updating component-oriented systems[END_REF] and consistency [START_REF] Ivey | Robusta: une approche pour la construction d'applications dynamiques[END_REF] concerns. These systems generally only provide run-time modification of component-related entities such as components, component ports or interconnections. However, while designing and demonstrating prototypes we also require to modify code outside components, e.g., to fix bugs in third party libraries.

Smalltalk-based component models implementations [START_REF] Bouraqadi | Clic: a component model symbiotic with smalltalk[END_REF][START_REF] Fabresse | Unanticipated connection of components based on their state changes notifications[END_REF][START_REF] Spacek | A component-based metalevel architecture and prototypical implementation of a reflective component-based programming and modeling language[END_REF] enable run-time modification of both component and non-component code thanks to Smalltalk's reflective properties. Such implementations provide the same dynamic, unanticipated run-time modification capabilities as the Molecule Pharo implementation.

As far as we know, Molecule is the only implementation of LCCM relying on Traits.

Conclusion

Developing industrial prototypes as close as possible to final products is tedious. At Thales Defense Mission Systems, we 7 build such prototypes before a final version is implemented by another team. Our prototypes are evaluated not only through their HMI but also through complete functional use cases. In order to fulfill the requirements and the actual endusers expectations, we evaluate prototypes with end-users and adapt them lively according to their feedback. Thus, we use Pharo to implement our prototypes because of its dynamic capabilities. Because our final product are component oriented, we use this paradigm for the implementation of our Pharo prototypes. Regarding the life-cycle of a product, the direct benefit is the traceability between the prototypes components and the final products components. Moreover, the implementation and the lively adaptation of our prototypes is also facilitated by the component orientation. In this paper we presented Molecule, a light-weight CORBA Component Model implementation based on Traits that we have developed in this context. We presented an overview of Molecule and illustrated its usage through a simple example.

More and more, our prototypes involve multiple users on collaborative tasks on interconnected workstations. We will upgrade the capacity of Molecule to build distributed component architectures. In the future, we want to use Molecule in distributed architectures but keeping all its live prototyping capabilities. This is challenging as this implies consistent modifications of remote and distributed run-time architectures.

  prototyping with component-oriented programming IWST20, September 29th and 30th, 2020, Novi Sad, Serbia Molecule, our component-oriented programming framework for Pharo. The rest of this Paper describes Molecule.

Figure 2 .

 2 Figure 2. Public view of a Molecule component.

Figure 3 .

 3 Figure 3. Components automatic modifications using Traits.

Figure 4 .

 4 Figure 4. The ComponentManager manage all components.

Figure 5 .

 5 Figure 5. Molecule components life-cycle.

Figure 6 . 1 MolAbstractComponentImplListing 1 .

 611 Figure 6. Examples with a GPS application.

1Listing 2 .

 2 Trait named: #GPSData uses: MolComponentType. Declaring the GPSData Type with one provided services interface and one produced events interface.

1 2 GPSDataEvents>>currentPositionChanged: aGeoPosition 3 " 5 6 "Listing 3 .

 23563 Trait named: #GPSDataEvents. Notify the current geographic position of the GPS receiver when changed"4Trait named: #GPSDataServices.GPSDataServices>>getAccuracyRadiusInMeters Get and return the accuracy of the GPS depending quality of signal and quantity of connected satellites" Defining the GPSData Type content.

1Listing 4 . 4 "Listing 5 .

 445 MolAbstractComponentImpl subclass: #GPSMapImpl2 uses: GPSMap. 3 Trait named: #GPSMap uses: MolComponentType. Creating GPSMapImpl component class that uses GPSMap Type with one used services interface and one consumed events interface. As explained in Section 3.2, some methods are automatically generated to plug the services in the component class. Declaring the uses of GPSDataServices automatically generates the corresponding accessor getGPSDataServices which allows the GPSMapImpl component to call the services methods. Declaring the consumption of GPSDataEvents automatically generates a skeleton implementation of the interface in the component class GPSMapImpl (Listing 5). Developers have to complete generated methods with their application codeDisplay a circle on the ma |p view at the current position" 5 self updatePositionCircleOnMap: aGeoPosition radius: radius. Consumed event generated method.

5

 5

1 2 self

 12 GPSMapImpl>>componentActivate getGPSDataEventsSubscriber subscribe: self Listing 6. Subscription of GPSMapImpl receives to GPSDataEvents.As shown in Listing 7, components instances are created and activated by the ComponentManager which has the responsibility to connect them each other lazily.

Listing 7 .

 7 Instanciating and activated components.

1 driver

 1

3 1

 1 accuracy := driver accuracy. Listing 8. A GPSHardware class providing the accuracy of the GPS.To use the GPSHardware class as a GPSData Type component, we augment that class with Molecule component behavior and with the GPSData Type (Listing 9). First, we add the Molecule component interface MolComponentImpl to the GPSHardware class. Any class that implements this interface is usable as a Molecule component. Then, we affect the GPSData Type component to the GPSHardware class.The MolComponentImpl interface and GPSData Type are implemented as Traits. Therefore the GPSHardware class is augmented just by declaring the use of these Traits (line 2). Traits automatically brings the code for implementing interfaces.Object subclass GPSHardware

2 uses: {MolComponentImpl + GPSData} Listing 9 .

 29 Augmenting the GPSHardware class with Molecule component behavior and set its Type.

1 2 " 3 ↑self accuracy feetToMeters Listing 10 .

 12310 GPSHardware>>getAccuracyRadiusInMeters GPSHardware use imperial units, need to convert into meters" Reusing and extending the GPSHardware implementation in the Molecule component interface.Finally, we instantiate this class as a Molecule component and we swap the previous implementation GPSDataImpl with our new implementation GPSHardware (Listing 11). We remove the current component from the application (lines 2-3) and replace it with the new component (lines 5-6).

Figure 7 . 1 "" 2 3 removeComponent: GPSDataImpl. 4 " 5 6 instanciateComponent: GPSHardware. Listing 11 .

 712345611 Figure 7. The GPS map and data provider example

Figure 8 .

 8 Figure 8. Reusing existing code as Molecule components.

http://www.cincomsmalltalk.com/main/products/visualworks/ -accessed July,

27th, 2020

Acknowledgments

We thanks Thales Defense Mission Systems for their continuous support and for believing in the powers of live prototyping, and the Thales technical board who authorized us to publish our work in the open source world. We thanks also Nolwenn Fournier and Camille Delloye for their participation to the elaboration of Molecule.


Mohammad Karam

Aren Joe Bizdikian

Nour Khalil

Ziad Bakouny

Ibrahim Obeid

Joe Ghanimeh

Chris Labaki

Georges Mjaess

Aya Karam

Wafa Skalli

Khalil Kharrat

Ismat Ghanem

Ayman Assi
email: ayman.assi@usj.edu.lb

Alterations of 3D acetabular and lower limb parameters in adolescent idiopathic scoliosis

Keywords: Adolescent idiopathic scoliosis, Acetabulum, Lower limbs, 3D reconstructions, Spine

Purpose To evaluate the 3D deformity of the acetabula and lower limbs in subjects with adolescent idiopathic scoliosis (AIS) and their relationship with spino-pelvic alignment. Methods Two hundred and seventy-four subjects with AIS (frontal Cobb: 33.5° ± 18° [10°-110°]) and 84 controls were enrolled. All subjects underwent full-body biplanar X-rays with subsequent 3D reconstructions. Classic spino-pelvic and lower limb parameters were collected as well as acetabular parameters: acetabular orientation in the 3 planes (tilt, anteversion and abduction), center-edge angle (CEA) and anterior and posterior sector angles. Subjects with AIS were represented by both lower limb sides and classified by elevated (ES) or lowered (LS), depending on the frontal pelvic obliquity. Parameters were then compared between groups. Determinants of acetabular and lower limb alterations were investigated among spino-pelvic parameters. Results Acetabular abduction was higher on the ES in AIS (59.2° ± 6°) when compared to both LS (55.6° ± 6°) and controls (57.5° ± 3.9°, p < 0.001). CEA and acetabular anteversion were higher on the LS in AIS (32° ± 6.1°, 20.5° ± 5.7°) when compared to both ES (28.7° ± 5.1°, 19.8° ± 5.1°) and controls (29.8° ± 4.8°, 19.1° ± 4°, respectively, p < 0.001). Anterior sector angle was lower on both ES and LS in AIS when compared to controls. CEA, acetabular abduction and acetabular anteversion were found to be mostly determined (adjusted R 2 : 0.08-0.32) by pelvic tilt and less by frontal pelvic obliquity, frontal Cobb and T1T12. Conclusions Subjects with AIS had a more abducted acetabulum at the lowered side, more anteverted acetabulum and a lack of anterior coverage of both acetabula. These alterations were strongly related to pelvic tilt.

Introduction

The 3D deformity of the spine in adolescent idiopathic scoliosis (AIS) causes alterations in posture, spino-pelvic sagittal alignment [START_REF] Alzakri | Global sagittal alignment and proximal junctional kyphosis in adolescent idiopathic scoliosis[END_REF] and pelvic orientation [START_REF] Pasha | Three-dimensional spinopelvic relative alignment in adolescent idiopathic scoliosis[END_REF]. The pelvic vertebra, as described by Dubousset [START_REF] Dubousset | CD instrumentation in pelvic tilt[END_REF], is often an integral part of the scoliotic curvature, and any spino-pelvic deformity could cause its tilting in the frontal and sagittal planes, and its rotation in the axial plane.

Previous studies on subjects with AIS found acetabular and lower limbs alterations, such as decreased femoral torsion [START_REF] Burwell | Ultrasound femoral anteversion (FAV) and tibial torsion (TT) after school screening for adolescent idiopathic scoliosis (AIS)[END_REF], a greater neck-shaft angle [START_REF] Saji | Increased femoral neckshaft angles in adolescent idiopathic scoliosis[END_REF], differences in femur lengths, total lower limbs lengths and tibial torsions between sides of subjects with AIS [START_REF] Márkus | The effect of coronal decompensation on the biomechanical parameters in lower limbs in adolescent idiopathic scoliosis[END_REF]; these findings were attributed to spino-pelvic alterations. However, these studies remain scarce, and a comprehensive analysis of the relationship between the spino-pelvic deformity in AIS and acetabular and lower limb morphological alterations is lacking, especially since these alterations were shown to be related to the development of pathologies of the hip such as osteoarthritis [START_REF] Lazennec | Hip-spine relations and sagittal balance clinical consequences[END_REF].

Thus, the aim of this study was to investigate changes in the morphology of the acetabulum and lower limbs between subjects with AIS and controls, and to elucidate the relationship between the 3D deformities of the spine and the acetabula.

Methods

Subjects and imaging

This is an IRB approved retrospective descriptive study (CEHDF742) on non-operated subjects with AIS who had consulted our center for imaging. Demographics (age, weight and height) were collected for each subject. All subjects underwent full-body biplanar radiographs (EOS Imaging ® , Paris, France). Subjects were asked to stand in a modified free-standing position [START_REF] Chaibi | Fast 3D reconstruction of the lower limb using a parametric model and statistical inferences and clinical measurements calculation from biplanar X-rays[END_REF], and acquisitions were performed by a qualified technician.

Inclusion criteria were: age between 10 and 18 years old, diagnosed with AIS, with a frontal Cobb angle ≥ 10°. The exclusion criterion was the presence of structural lower limb discrepancy > 1 cm (measured from the center of the femoral head to the middle distal tibial end). A control group of asymptomatic subjects, recruited for a previous study, with no musculoskeletal or neurological disorders, were included.

Neither group reported any pain or pathologies related to the hips or lower limbs.

The spine and lower limbs of each subject were reconstructed in 3D by well-trained operators using SterEOS ® (version 1.6.4.7977, EOS imaging, Paris), as well as the pelvises and the acetabula using a specific software (Arts et Métiers ParisTech, Paris, France).

Collected parameters

Different 3D spino-pelvic, acetabular and lower limb parameters were collected from the 3D reconstructions (Fig. 1) [9]. The spino-pelvic parameters included: frontal Cobb angle, type of curvature according to Lenke [START_REF] Lenke | Adolescent idiopathic scoliosis: a new classification to determine extent of spinal arthrodesis[END_REF], apical vertebral rotation (AVR), T1T12 kyphosis, L1S1 lordosis, pelvic incidence (PI), pelvic tilt (PT), lateral pelvic obliquity (LPA) (distance between iliac crests calculated in the frontal plane) and pelvic axial rotation (PAR) (in the horizontal plane). Spino-pelvic parameters were calculated in the 3D patient plane. Global postural parameters were also collected: sagittal vertical axis (SVA: as the distance from the C7 plumbline to the posterior corner of the sacrum), CAM-HA plumbline (as the distance from the plumbline passing by the center of auditory meatus to the center of the hip axis), T1 and T9 tilt and C7CSL (the distance from the center of C7 plumbline to the center of the sacral plate in the frontal plane).

The collected 3D acetabular parameters were: acetabular tilt [START_REF] Lazennec | Hip-spine relationship: a radio-anatomical study for optimization in acetabular cup positioning[END_REF], acetabular anteversion, acetabular abduction [START_REF] Anda | Pelvic inclination and spatial orientation of the acetabulum. A radiographic, computed tomographic and clinical investigation[END_REF], center-edge angle (CEA) [START_REF] Tönnis | Acetabular and femoral anteversion: relationship with osteoarthritis of the hip[END_REF], anterior and posterior sector angles [START_REF] Anda | The acetabular sector angle of the adult hip determined by computed tomography[END_REF] and sacro-acetabular angle (SA) [START_REF] Lazennec | Hip-spine relationship: a radio-anatomical study for optimization in acetabular cup positioning[END_REF]. Acetabular anteversion and abduction were calculated morphologically, i.e., in the Lewinnek plane (M), and positionally (P), i.e., in the horizontal or vertical planes (Fig. 1). The collected 3D lower limb parameters were: femoral torsion, hip-knee shaft angle (HKS), knee flexion-extension, neck-shaft angle (NSA), tibial torsion, valgus/varus of the knee (hip-knee angle: HKA) and the tibial mechanical angle [START_REF] Assi | Specific 3D reconstruction for children lower limbs using a low dose biplanar X-ray system. Reproducibility of clinical parameters for cerebral palsy patients[END_REF]. The ratio of the femur length over the tibial length [START_REF] Rampal | Lower-limb lengths and angles in children older than six years: reliability and reference values by EOS ® stereoradiography[END_REF], as well as the anatomical (sum of the femoral and tibial lengths) and functional lengths (distance between the center of the femoral head to the center of the ankle) of the full lower limbs were also calculated and normalized to height.

The validity and reliability of the aforementioned parameters have already been studied [START_REF] Rehm | 3D-modeling of the spine using EOS imaging system: inter-reader reproducibility and reliability[END_REF][START_REF] Assi | Three-dimensional reconstructions for asymptomatic and cerebral palsy children's lower limbs using a biplanar X-ray system: a feasibility study[END_REF].

Statistical analysis

Mean differences between AIS and controls for demographic data were tested using either Mann-Whitney's U test or a two-sample t-test depending on data normality (Shapiro-Wilk's test).

The two limbs were included for each subject with AIS and grouped according to the pelvic obliquity in the frontal plane (obtained from the 3D reconstruction) into elevated side (ES) and lowered side (LS). Acetabular, lower limb and 3D length parameters were first compared between each side of AIS (ES or LS) using either a paired t-test or Wilcoxon signed rank test. For the control group, the left and right sides were averaged after confirmation of no statistical differences between both sides. Then, each side of the AIS was compared to controls using a Mann-Whitney's U test or a two-sample t-test.

Differences between groups were also investigated by studying the distribution of the parameters: CEA, NSA and acetabular anteversion were compared between groups according to specific ranges used in clinical classifications (CEA for risk of overcoverage or dysplasia; NSA and acetabular anteversion for risk of femoro-acetabular impingement) [START_REF] Tönnis | Acetabular and femoral anteversion: relationship with osteoarthritis of the hip[END_REF][START_REF] Stem | Computed tomography analysis of acetabular anteversion and abduction[END_REF][START_REF] Tannast | What are the radiographic reference values for acetabular under-and overcoverage?[END_REF]. When no clinical classifications were found in the literature, the control group was divided into 3 classes, which were defined as: low, if inferior than mean-1 SD (17% of subjects); intermediate, if it falls between mean and 1 SD and mean + 1 SD (66% of subjects); high, if superior than mean + 1 SD (17% of subjects). The distribution of the AIS sides was then evaluated based on these classifications. Heterogeneity was assessed using a Chi-squared test; pairwise comparisons were computed using adjusted residuals.

In order to investigate the relationship between the 3D acetabular and lower limbs parameters that differed between groups and spino-pelvic parameters, a univariate analysis using Pearson's correlation test was applied. Then, in order to explore the most significant determinants of the acetabular and lower limb 3D parameters among demographics and spino-pelvic parameters, a multivariate analysis using stepwise multiple linear regression was computed.

Statistics were performed using Xlstat ® (version 2019.1.2, Addinsoft ® , Paris, France). The level of significance was set at 0.05.

Results

Study sample

In total, 274 subjects with AIS were included in this study (232 females, age: 14.4 ± 2 years). Frontal Cobb angle and AVR were 33.5° ± 18° [10°-110°] and 14.3° ± 9° [0.1°-39°], respectively. Subjects with AIS were classified as follow: 128 Lenke type-1, 8 Lenke type-2, 8 Lenke type-3, 119 Lenke type-5 and 11 Lenke type-6; there were no subjects with Lenke type-4. Lower limb discrepancy had a median of 0.3 cm [0-0.9 cm]. In total, 84 asymptomatic subjects were also included in the control group (60 females, age: 14.1 ± 3.1 years). There were no significant differences between AIS and controls in demographic data (all p > 0.05, Table 1).

Mean values of the spino-pelvic and postural parameters were compared between groups (Fig. 2). Briefly, T1T12 and CAM-HA were significantly lower in subjects with AIS (33.6° ± 12°, -27.5 ± 23 mm, respectively) when compared to controls (42.7° ± 8°, -19.9 ± 24 mm, respectively). Lateral pelvic obliquity and C7CSL were significantly higher in subjects with AIS (5.3 ± 3.5 mm, 11.5 ± 9 mm, respectively) when compared to controls (4 ± 3.5 mm, 7.8 ± 6 mm, respectively).

The detailed comparison of acetabular and lower limb parameters between the ES, LS in AIS and controls were presented in Table 2. Acetabular abduction (M and P) were significantly higher in the ES group (59.2° ± 6°, 56.6° ± 4°, respectively) when compared to both LS (55.6° ± 6°,

Distributions of 3D acetabular parameters

When the CEA was evaluated based on the clinical ranges published by Tannast [START_REF] Tannast | What are the radiographic reference values for acetabular under-and overcoverage?[END_REF], the ES group tended toward dysplasia and the LS group was significantly shifted toward overcoverage (Fig. 4). Acetabular anteversion and NSA were similar to normal ranges when assessing the risk of femoro-acetabular impingement based on the clinical classifications published in the literature [START_REF] Tönnis | Acetabular and femoral anteversion: relationship with osteoarthritis of the hip[END_REF][START_REF] Stem | Computed tomography analysis of acetabular anteversion and abduction[END_REF]. When the distribution of the ES and LS groups were compared to controls for both the morphological and positional acetabular abduction, the LS group tended toward the low class and the ES to the high class of controls (Fig. 3). For the anterior sector angle, morphological and positional acetabular anteversion, both ES and LS groups tended toward the low class of controls (Figs. 3,4). For the posterior sector angle and SA angle, both ES and LS groups tended toward the high class of controls (Fig. 4).

Univariate analysis

CEA was significantly correlated to: age (r = -0.20, p = 0.05), T1 tilt (r = -0.25, p = 0.01) and PT (r = -0.25, p = 0.01). Positional acetabular abduction was significantly correlated to: T1 tilt (r = 0.23, p = 0.02), T9 tilt (r = 0.25, p = 0.01), SS (r = -0.20, p = 0.04) and PT (r = 0.32, p = 0.001) (Fig. 5). Positional acetabular anteversion was significantly correlated to CAM-HA plumbline (r = -0.36, p < 0.01), T1 tilt (r = 0.30, p = 0.002), PI (r = 0.41, p < 0.001) and PT (r = 0.45, p < 0.001) (Fig. 5).

Discussion

Adolescent idiopathic scoliosis (AIS) is known to alter the orientation of the pelvis in the 3 planes, which may lead to alterations in acetabular and lower limb morphologies. This study investigated the changes that might occur in acetabular and lower limb morphologies in these subjects while analyzing both the elevated and lowered sides of the pelvis as well as their correlation to the spino-pelvic parameters. Subjects with AIS had a more abducted acetabulum at the lowered side, more anteverted acetabulum and a lack of anterior coverage of both acetabula. These alterations were strongly related to pelvic tilt.

The spino-pelvic and global posture alterations found in the AIS group were similar to those reported in previous studies [START_REF] Nault | Relations between standing stability and body posture parameters in adolescent idiopathic scoliosis[END_REF]. The analysis of acetabular and lower limb parameters between both sides of AIS and controls showed some morphological and positional alterations. Along with the comparisons of means of acetabular and lower limb parameters between both sides of AIS and controls, a comparison of the distributions of these parameters has also been investigated. This type of study allowed for a more thorough analysis of the heterogeneous anatomy of subjects with AIS and differences with previously published clinical ranges or normative data.

CEA and acetabular abduction are frequently used in the assessment of the acetabular coverage. These parameters are inversely related: when the CEA increases, the acetabular abduction decreases, and vice versa. According to the clinical ranges of CEA published by Tannast et al. [START_REF] Tannast | What are the radiographic reference values for acetabular under-and overcoverage?[END_REF] (Fig. 4), it was found that the LS of subjects with AIS is significantly more shifted toward overcoverage than the ES and controls and the positional acetabular abduction to be significantly more shifted toward the higher class of controls (Fig. 3); in contrary, the ES were more shifted toward dysplasia ranges for the CEA and to the lower class of controls for the positional acetabular abduction. Since the positional acetabular abduction was significantly determined by the position of the pelvis in both the frontal and sagittal planes, the frontal obliquity might have moved the lateral edge of the acetabulum on the LS externally, which might lead to a lower acetabular abduction, and consequently to a higher external coverage of the femoral head. The opposite effect takes place on the ES, showing more subjects having undercoverage compared to controls. Our findings, based on 3D data, are in disagreement with Schmitz et al. [START_REF] Schmitz | Spectrum of radiographic femoroacetabular impingement morphology in adolescents and young adults: an EOS-based double-cohort study[END_REF], who, by grouping both acetabula together, found no differences while comparing the CEA, calculated in 2D, of AIS subjects to controls. It is therefore interesting to consider each side separately when analyzing the acetabula of subjects with AIS.

When analyzing the anterior sector angle, the ES and LS hips were shifted toward the low class in controls (Fig. 4), thus indicating a high prevalence of decreased anterior femoral head coverage in subjects with AIS in both hips (ES and LS). Moreover, positional acetabular anteversion in both sides of AIS pelvis was significantly more shifted toward the high class of controls (Fig. 3). This increase in acetabular anteversion was also present morphologically. Both the increase of acetabular anteversion and the decrease of the anterior sector angle show that subjects with AIS have a more exposed femoral head anteriorly on both the ES and LS that could predispose them to hip dysplasia. These findings are in accordance with previous study showing that subjects with AIS have a higher incidence of dysplasia compared to normal population [START_REF] Segreto | Incidence, trends, and associated risks of developmental hip dysplasia in patients with Early Onset and Adolescent Idiopathic Scoliosis[END_REF].

Moreover, acetabular anteversion and acetabular abduction were both positionally and morphologically significantly different between groups (Table 2), this might show that subjects with AIS have already morphological alterations of the acetabula in addition to the positional impact of the spinal deformity on the acetabula.

The alterations of the CEA, acetabular abduction and anteversion were found to be correlated (Fig. 5) and mostly determined by PT (β = -0.08, β = 0.32 and β = 0.51, respectively) showing that the alteration of the position of the pelvis in the sagittal plane have a major impact on the acetabular coverage over the femoral head as shown in a previous study [START_REF] Henebry | The effect of pelvic tilt on radiographic markers of acetabular coverage[END_REF].

Surgical spinal realignment of subjects with adult spinal deformity showed that improving the sagittal alignment by increasing the lumbar lordosis had consequently decreased the pelvic tilt and acetabular anteversion [START_REF] Buckland | Acetabular anteversion changes due to spinal deformity correction: bridging the gap between hip and spine surgeons[END_REF]. In this study, the acetabular anteversion, abduction and CEA were correlated and determined by the pelvic tilt; this might highlight the importance of the continuous monitoring of the sagittal alignment of subjects with AIS since they might be at risk of developing acetabular alteration in case they did not reach the proper sagittal alignment.

Differences in spino-pelvic parameters in patients with spinal pathologies and on patients with hip osteoarthritis have been extensively studied before. Moreover, many studies have explored the relationship between hip and spine pathologies, especially in the adult setting. This is a descriptive study of the changes that occurs in the acetabular orientation and lower limb morphology in subjects with AIS. The major limitation of this study is its retrospective nature and that the included patients were not followed up in order to confirm whether they later developed hip pathologies, although such a task might require the observation of these subjects for many years into the future. A prospective study is developed in order to follow up these patients.

In conclusion, subjects with AIS were found to have significant asymmetry in hip morphology leading to a more abducted acetabulum on the LS and a more anterior undercoverage as well as anteverted acetabula on both sides. These alterations were essentially correlated and determined by the pelvic tilt in the sagittal plane.

Fig. 1 a

 1 Fig. 1 a Full-body biplanar X-rays for a patient with adolescent idiopathic scoliosis, b 3D reconstructions of the spine, pelvis and lower limbs with classification of elevated and lowered sides, c acetabular

Fig. 2

 2 Fig. 2 Comparison of 3D spino-pelvic parameters between AIS and controls. T1T12 kyphosis (T1T12), L1S1 lordosis (L1S1), pelvic incidence (PI), pelvic tilt (PT), pelvic axial rotation (PAR), T1

Fig. 3

 3 Fig. 3 Distribution of morphological and positional acetabular abduction and anteversion according to the normative classes (low, intermediate and high) as defined by the control group. *p value > 0.05

Fig. 4

 4 Fig. 4 Distribution of center-edge angle according to the criteria's as defined by Tannast et al. 2005. In addition to the distribution of sacroacetabular angle, posterior and anterior sector angles according to the

Fig. 5

 5 Fig. 5 Correlations between center-edge angle, positional acetabular abduction, positional acetabular anteversion and pelvic tilt

Table 1

 1 Comparison of demographics between controls and adolescent idiopathic scoliosis (AIS)

	Demographics	Control		AIS		p value
		Mean	SD	Mean	SD
	Age (years)	14.1	3.1	14.4	2.0	0.06
	Weight (kg)	52.0	14.8	52.3	11.4	0.37
	Height (m)	1.6	0.1	1.6	0.1	0.06

Table 2 Between

 2

	Parameters	Control		Elevated side	Lowered side	Control versus ES Control versus LS ES versus LS
				(ES)-AIS	(LS)-AIS
		Mean SD	Mean SD	Mean SD	p value	p value	p value
	Acetabular abduction M (°)	57.5 3.9	59.2	6.0 55.6	6	0.01	0.005	< 0.001
	Acetabular abduction P (°)	55.5 3.8	56.6	4.2 53.9	4.2 0.04	0.001	< 0.001
	Acetabular tilt angle (°)	20.6 6.3	21.6	8.1 21.3	7.8 0.27	0.44	0.64
	Center-edge angle (°)	29.8 4.8	28.7	5.1 32	6.1 0.10	0.005	< 0.001
	Sacro-acetabular angle (°)	56.6 9.9	60.4 12.0 60	12.6 0.01	0.03	0.53
	Acetabular anteversion M (°)	19.1 4	19.8	5.1 20.5	5.7 0.21	0.03	0.03
	Acetabular anteversion P (°)	14.8 3.9	15.5	4.5 15.9	5	0.16	0.02	0.18
	Anterior sector angle (°)	61	4.4	59.1	6.1 59.2	6.5 0.01	0.03	0.84
	Posterior sector angle (°)	94.2 4.4	94.7	5.5 94.2	5.9 0.44	0.66	0.30
	Femoral mechanical angle (°)	93.9 1.5	94.1	1.9 93.9	2	0.31	0.98	0.05
	Femoral torsion (°)	16.7 9.6	16.9 10.9 17.5 11.1 0.79	0.43	0.22
	Hip-knee shaft angle (°)	4	0.8	4.2	1.1	4.3	1	0.25	0.04	0.14
	Knee flexion-extension (°)	-3.1 5	-2.4	5.4 -3.4	5.3 0.27	0.72	< 0.001
	Neck-shaft angle (°)	131.4 4.3	130.8	4.6 130.6	4.4 0.27	0.14	0.38
	Tibial torsion (°)	28.5 6.6	28.6	7.2 29.3	7.1 0.88	0.37	0.11
	Valgus/varus (°)	0.4 2.2	0.5	2.6	0.3	2.8 0.86	0.76	0.22
	Tibial mechanical angle (°)	89.1 2.4	89.3	2.9 89.8	2.8 0.67	0.05	< 0.001
	Ratio of femur length over tibia length	1.16 0.03	1.16 0.03 1.16 0.03 0.24	0.11	0.98
	Anatomical length (cm)	74.5 6.2	76.4	4.3 76.2	4.3 0.002	0.01	< 0.001
	Normalized anatomical length	0.471 0.01	0.475 0.02 0.474 0.02 0.01	0.09	< 0.001
	Functional length (cm)	74.9 6.2	76.8	4.3 76.6	4.3 0.002	0.01	< 0.001
	Normalized functional length	0.474 0.01	0.478 0.02 0.477 0.02 0.01	0.10	< 0.001

-group comparisons of 3D acetabular and lower limbs parameters in controls, elevated side (ES) and lowered side (LS) of subjects with adolescent idiopathic scoliosis Significant p values are indicated in bold

Acknowledgments This research was funded by the University of Saint-Joseph (grant FM300). The funding source did not intervene in study design; in the collection, analysis and interpretation of data; in the writing of the report; and in the decision to submit the article for publication.

Funding This study was funded by the University of Saint-Joseph (Grant No. FM300).

Compliance with ethical standards

Conflict of interest

The authors declare that they have no conflict of interest.