Alexandre Bergel

St Éphane Ducasse

Oscar Nierstrasz

Classbox/J: Controlling the Scope of Change in Java

Keywords: D.3.3 [Programming Languages]: Language Constructs and Features; D.1.5 [Programming Languages]: Object-oriented Programming Module, Package, Open-classes, Class extension Component Window Button Frame Container java.awt Component Window Button Frame Container javax.swing

Unanticipated changes to complex software systems can introduce anomalies such as duplicated code, suboptimal inheritance relationships and a proliferation of run-time downcasts. Refactoring to eliminate these anomalies may not be an option, at least in certain stages of software evolution. Classboxes are modules that restrict the visibility of changes to selected clients only, thereby offering more freedom in the way unanticipated changes may be implemented, and thus reducing the need for convoluted design anomalies. In this paper we demonstrate how classboxes can be implemented in statically-typed languages like Java. We also present an extended case study of Swing, a Java GUI package built on top of AWT, and we document the ensuing anomalies that Swing introduces. We show how Classbox/J, a prototype implementation of classboxes for Java, is used to provide a cleaner implementation of Swing using local refinement rather than subclassing.

INTRODUCTION

Programming languages traditionally assume that the world is consistent. Although different parts of a complex system may only have access to restricted views of the system, the system as a whole is assumed to be globally consistent. Unfortunately this means that Preprint of the ACM OOPSLA 2005 Version OOPSLA'05, October 16-20, 2005, pp. 177-189, San Diego, California, USA. . unanticipated changes may have far-reaching consequences that are not good for the general health of the system. Consider, for example, the development of Swing, a GUI package for Java that was built on top of the older AWT package. In the absence of a large existing base of clients of AWT, Swing might have been designed differently, with AWT being refactored and redesigned along the way. Such a refactoring, however, was not an option, and we can witness various anomalies in Swing, such as duplicated code, sub-optimal inheritance relationships, and excessive use of run-time type discrimination and downcasts.

In this paper we argue that unanticipated changes are better supported when we abandon the principle of the consistent world-view. Classboxes offer us the ability to define a local scope within which our world-view is refined without impacting existing clients. Classboxes can collaborate to control the scope of change in a way that can significantly reduce the need for introducing anomalous design practices to bridge inconsistencies between the old and the new parts of a system.

In recent years, numerous researchers have proposed better ways to modularize code in such a way as to allow a base system to be easily extended, following the philosophy behind CLOS [START_REF] Keene | Object-Oriented Programming in Common-Lisp[END_REF] or Smalltalk [START_REF] Goldberg | Smalltalk-80: The Language[END_REF]. For instance, Open Classes [START_REF] Millstein | Relaxed multijava: balancing extensibility and modular typechecking[END_REF], AspectJ [START_REF]AspectJ home[END_REF] and Hyper/J [START_REF] Ossher | Hyper/J: multi-dimensional separation of concerns for java[END_REF] allow class members to be separately defined from the class they are related to. They do not, however, permit multiple versions of a class to be present at the same time. Other approaches, like virtual types (as in Keris [START_REF] Zenger | Programming Language Abstractions for Extensible Software Components[END_REF], Caesar [START_REF] Mezini | Conquering aspects with caesar[END_REF], gbeta [START_REF] Ernst | gbeta -a Language with Virtual Attributes, Block Structure, and Propagating, Dynamic Inheritance[END_REF], and Nested Inheritance [START_REF] Nystrom | Scalable extensibility via nested inheritance[END_REF]), allow multiple versions of a given class to coexist at the same time: classes are looked up much the same way that methods are. These mechanisms, however, only allow one to refine inner classes inherited from a parent class. Refinement divorced from inheritance is not supported.

We have previously proposed classboxes as a means to control the scope of change in the context of Smalltalk [START_REF] Bergel | Classboxes: Controlling visibility of class extensions[END_REF][START_REF] Bergel | Classboxes: A minimal module model supporting local rebinding[END_REF]. A classbox is essentially a kind of module which not only provides the classes it defines, but may also import classes from other classes and refine1 them by adding or modifying their features. There are three key characteristics to classboxes:

• A classbox is a unit of scoping within which classes and their features (i.e., fields, methods, inner classes) are defined, imported and refined. Each class is always defined in a unique classbox, but it may be imported and refined by other classboxes. Refinements are either new features or redefinitions of features.

• A refinement is locally visible to the classbox in which it is defined. This means that the change is only visible to (i) the refining classbox, and (ii) other classboxes that directly or indirectly import the refined class.

• A local refinement has precedence over any previous (i.e., imported) definition or refinement. This means that, although refinements are locally visible, their effect impacts all their collaborating classes. A classbox thereby determines a namespace within which local class refinements behave as though they were global. From the perspective of a classbox, the world appears to be consistent.

Classboxes were first introduced with an implementation in Smalltalk [START_REF] Bergel | Classboxes: A minimal module model supporting local rebinding[END_REF] and subsequently formally described [START_REF] Bergel | Classboxes: Controlling visibility of class extensions[END_REF]. In particular, we were able to demonstrate that classboxes could be implemented efficiently in a dynamically-typed language with minimal run-time overhead. In this paper we demonstrate how classboxes can be applied effectively to control unanticipated change in a large, industrially-developed application framework written in a statically-typed language, namely Java. The contributions of this paper are:

• A proof-of-concept implementation of classboxes for statically typed languages. Classbox/J consists of a minimal extension of Java: (i) package import clauses are made transitive, and (ii) packages are able to refine imported classes and export these classes to other packages.

• The original classbox model is extended with a mechanism enabling refinements to access prior definitions. The Swing refactoring towards classboxes motivates the need to invoke original methods from their redefined bodies.

• Presentation of a large case study in which (i) the limits of subclassing are clearly identified, and (ii) classboxes are used to remove code duplication and incoherence in the class hierarchy.

In Section 2 we use the Swing case study to point out anomalies that can arise when subclassing is used to introduce significant crosscutting changes. In Section 3 we present the model of classboxes for Java. In Section 4 we present an example illustrating how classboxes support the implementation of cross-cutting changes. In Section 5 we apply classboxes to refactor Swing. In Section 6 we describe our Java implementation of classboxes. In Section 7 we provide a brief overview of related work. In Section 8 we conclude by summarizing the presented work.

SWING/AWT ANOMALIES

Using subclassing to incorporate crosscutting changes often introduces serious drawbacks such as duplicated code and mismatches between the original and the extended class hierarchy. We illustrate these problems by analyzing Swing [START_REF]Swing api[END_REF], the Java standard framework for building GUIs. We first describe the Abstract Window Toolkit (AWT [START_REF]Awt api[END_REF]) and its relationships with the Swing framework. Then we show how inheritance is used to share properties between classes. Finally we identify some important drawbacks of the Swing design.

AWT and Swing History

In its first release launched in 1995, Java included AWT 1.0, a framework for building graphical user interfaces. AWT evolved rapidly in version 1.1 to provide a better event handling mechanism. AWT is close to the underlying operating system, therefore only a small number of widgets are supported to make code easier to port. In its latest version AWT consists of 345 classes and contains more than 140,000 lines of code.

Release 1.2 of the Java Development Kit included a completely new GUI framework named Swing. Swing contains 539 classes and more than 260,000 lines of code. This GUI framework is built on top of AWT. It provides a "pluggable look and feel", double buffering and more widgets. A small subset of the core of AWT (Component, Container, Frame Window), and Swing is depicted in Figure 1.

In AWT, the root of the graphical widget hierarchy is Component. It provides the essential functionalities of the GUI framework. JComponent is the base class for most of the Swing widgets. The core of Swing is defined by subclassing the core classes of AWT. Each Swing widget can be a container for other widgets, so JComponent inherits from Container. All the widgets except top-level containers (like windows and frames) inherit from JComponent. The classes JFrame and JWindow inherit from Frame and Window, respectively.

The AWT and Swing class hierarchies guarantee certain properties and behavior. In the AWT framework (i) a widget is a component -every widget inherits from Component, (ii) a frame is a window -Frame is a subclass of Window. On the other hand, the Swing framework has the following properties: (i) a Swing widget is not necessary a Swing component because not all of the Swing classes inherit from JComponent, (ii) a Swing frame is an AWT frame and an AWT window: JFrame inherits from Frame which has Window as its superclass, (iii) a Swing window is an AWT window: JWindow inherits from Window.

Problem Analysis

Subclassing and refinement relationships are fundamentally different: the former results in a new class containing the incremental changes to its parent class, whereas the latter results in the creation of scope within which the original class is changed. As pointed out by Findler et al. [START_REF] Findler | Modular object-oriented programming with units and mixins[END_REF] and Torgersen [START_REF] Torgersen | The expression problem revisited -four new solutions using generics[END_REF] under the extensibility problem, subclassing does not solve the problem of adding new In Java, if we wish to extend the class Component by subclassing, without impacting existing clients, we can use either of two strategies (see Figure 2): either we build a completely new hierarchy derived from the root of the old hierarchy, duplicating old features in the new hierarchy, or we derive new classes from the leaves of the original hierarchy, duplicating the new features.

Swing illustrates an example of this problem. Swing is built on top of AWT and uses subclassing to extend AWT core classes with Swing functionalities. Since Java supports neither multiple inheritance nor class extension, this design leads, however, to the following severe consequences: Duplicated Code. Due to the absence of an inheritance link between JFrame and JWindow, features defined in JWindow have to be duplicated in JFrame. In Swing, each widget can (i) describe itself (the accessibleContext variable refers to a description of the component) and (ii) support double buffering to provide smooth flickerfree animation (methods update(), setLayout(), . . . ). The source code of JWindow is 551 lines, and JFrame is 829 lines. As a result, 241 lines of code are duplicated between these two classes: 43% of JWindow reappears as 29% of JFrame.

Breaking Subtyping Inheritance. Whereas all AWT widgets are AWT components (because they inherit from Component), widgets defined in Swing can either be AWT or Swing components. Furthermore, the Swing design breaks the AWT inheritance relation: while a Window is a Component in AWT, a JWindow is not a JComponent in Swing. While a Button is a Component and JButton is a JComponent, a JButton is not a Button [START_REF] Lalonde | Subclassing = Subtyping = Is-a[END_REF].

Explicit Type Checks and

CLASSBOX/J

A package can define new classes and it may refer to classes defined in other packages using an import clause. After importing a class, a package can either subclass it or reference it in a declaration. In pure Java, import statements are not transitive: a package p2 cannot import a class C from a package p1 if C was imported rather than defined in p1. In contrast to MultiJava [START_REF] Millstein | Relaxed multijava: balancing extensibility and modular typechecking[END_REF], Hyper/J [START_REF] Ossher | Hyper/J: multi-dimensional separation of concerns for java[END_REF], CLOS [START_REF] Demichiel | The common lisp object system: An overview[END_REF] and Smalltalk [START_REF] Goldberg | Smalltalk-80: The Language[END_REF], a Java package cannot add methods to a class defined in another package. Therefore a package can be adapted only by subclassing its member classes.

Classbox/J addresses these shortcomings by offering a means to refine classes within a well-defined scope.

Classbox/J in a Nutshell

Classbox/J is a module system for Java allowing classes to be refined with new class members, such as fields, methods and inner classes. A classbox in Classbox/J is essentially a Java package with the following three important differences: (i) imported classes can be refined by adding or redefining class members using the refine keyword, (ii) a class defined or imported within a classbox p can be imported by another classbox. This allows the import clause to be transitive, and (iii) a refined method can access its original behavior using the original keyword.

We illustrate Classbox/J with a small example based on the Swing case study.

Refining classes.

New Method Lookup Semantics

As shown in the previous section, class refinements have bounded visibility. Moreover, redefinitions have precedence over imported definitions. This behavior is obtained by a new semantics for method lookup. We illustrate this operationally.

Import over inheritance. Import statements between packages have to be taken into account when looking up a message. The main point is that the import clause has precedence over inheri- tance: before looking a method up in the superclass, the chain of imports has to be considered first. Figure 4 illustrates the lookup of messages update() and paint(). When the message update() is sent to an instance of Button in the classbox NewAppCB, the lookup algorithm first searches for the implementation of update() in the classbox NewAppCB (1). This method is not defined in this classbox, therefore the lookup follows the chain of import (2). In EnhWidgetsCB, update() is not defined, so the lookup continues in WidgetsCB [START_REF] Batory | Refinements and multi-dimensional separation of concerns[END_REF]. In this classbox, the class Button is not imported anymore but defined in it. Therefore, update() is looked up in the superclass Component but starting from the source classbox (NewAppCB, in step 4). Because Component is not visible within NewAppCB and Button is imported from Enh-WidgetsCB, the lookup continues to EnhWidgetsCB [START_REF] Bergel | Classboxes: A minimal module model supporting local rebinding[END_REF]. The class Component is visible, but the method update() is not implemented. Finally the method is found in WidgetsCB. The method update() triggers the message paint(). In a similar way, the method paint() is looked up as in steps 1 through 5.

Note that defining new semantics for the method lookup algorithm does not necessarily mean that the virtual machine (VM) must be modified. As described in Section 6, the desired behavior can be obtained by inserting some code that performs dynamic run-time stack introspection where a method redefinition occurs.

Multiple imports. As illustrated in Figure 5, a diamond graph of imports may imply the use of different class refinements defined by several classboxes. In the classbox AppCB, sending the paint() message to an instance of LabelButton invokes the implementation of paint() on Component defined by WidgetsCB. In a similar way, sending this message to an instance of Button triggers the implementation brought by NewWidgetsCB on Component.

Accessing the original method. When a method is redefined, the original method is accessible using the construct original().

For instance, in the classbox EnhWidgetsCB the extension of Component could be:

refine Component { private ComponentUI lookAndFeel; public void paint () { if (lookAndFeel == nil) { original();} else { /* use lookAndFeel */ } } }
The original() construct invokes the first method (e.g.,WidgetsCB .Button.paint() in Figure 6) in the import chain that was redefined by the method containing the expression original() (e.g.,EnhWidgetsCB.Button.pain Note that in particular super invocation in the original methods takes into account potential changes introduced by the classbox containing the original() invocation, preserving that way the method lookup semantics of classbox. In Figure 6, new Button().paint() displays a button having a MacOSX look since, first the method Wid-getsCB.Button.paint() is executed and the super invocation invokes

EnhWidgetsCB.Component.paint().
It is precisely this kind of scenario, which arises frequently in the Swing case study, that has motivated the addition of the original mechanism into the classbox model.

Properties of the Model

The model of classboxes defined in the previous section exhibits several properties related to the visibility of refinements.

Locality of Changes. MultiJava [START_REF] Millstein | Relaxed multijava: balancing extensibility and modular typechecking[END_REF] with its open-classes and Aspect/J [START_REF]AspectJ home[END_REF] with its inter-types allow class members to be defined separately from the class they are related to. Class members are not, however, contained in a unit of scope, therefore redefinition is not allowed and composition has to be explicitly stated. With classboxes, refinements of an imported class are visible to the refining classbox and to other classboxes that import this refined class. The refined class is a new version of the original class that coexists in the same system. Figure 3 shows two clients OldAppCB and NewAppCB using the old and new version of the widget framework. Any refinement introduced to WidgetsCB by EnhWidgetsCB does not impact OldAppCB. This is because changes are confined to EnhWidgetsCB and to other classboxes that may imported the classes it refines (e.g.,NewAppCB). Refinements along a chain of import. With classboxes, imports are transitive: a new version of an imported class can be re-imported. Figure 3 shows the class Button defined in WidgetsCB that is imported in EnhWidgetsCB and from this last, are imported in NewAp-pCB. From the point of view of an importing classbox, there is no distinction between a class that is defined or imported in the provider classbox (i.e., classbox where the class is imported from). An imported class can always be refined and then re-imported, even multiple times over a chain of imports.

CROSS-CUTTING CHANGES

Refining a class is superficially similar to subclassing: a classbox can add new interfaces, fields, methods, static field, inner classes and constructors as well as redefine methods of an imported class.

The key difference is that the changes are applied to the original class, not a subclass, but only within a well-defined scope. It is this feature that supports the introduction of cross-cutting changes. The following example shows how a look and feel feature is added to the root of a class hierarchy without breaking former clients, while propagating the refinements to collaborating classes. As shown in Figure 7, two classboxes WidgetsCB and FactoryCB define a base system which clients rely on. Since modifying these base classes would break these clients, changes cannot be directly applied to the classboxes WidgetsCB and FactoryCB, but are introduced in class- The following example shows some refinements defined with classboxes on a base system that (1) does not break clients that rely on the original definitions of this system, and that (2) propagate these refinements to collaborating classes defined in other classboxes.

Figure 8: An ideal refactoring based on classboxes

Frame is a Window, but in Swing a JFrame is not a JWindow. Not all Swing widgets are JComponent), (ii) a serious amount of code is duplicated to emulate missing inheritance links in Swing (i.e., 43% of JWindow is duplicated in 29% of JFrame), and (iii) Swing code is littered with explicit type checks.

Figure 8 shows an ideal situation where Swing would be extending AWT using classboxes. Obtaining such a situation would be possible if Swing would have been implemented by following the inheritance tree of AWT (i.e., introducing a JContainer class) or if we could afford to perform a complete overhaul of Swing. Since Swing, however, is a large framework with complex logic we cannot rewrite it totally to obtain the situation depicted. In order to illustrate how classboxes offer a working solution, we refactored Swing as a classbox that refines AWT classes. In this section we first describe the new architecture of Swing made out of classboxes, then we present the results obtained, and finally we describe some issues that we encountered while refactoring.

Swing Refined from AWT Class

We focus on the refactoring of the core class JComponent, and then we describe how the classbox SwingCB is defined.

Component refactored in two steps. The goal of refactoring JComponent is to make the Swing version JComponent a refinement of the AWT version Component. As depicted in Figure 1

Advantages with Classboxes

The Swing classes JComponent, JButton, JWindow and JFrame have been refactored as refinement of their AWT counterpart classes. The amount of code refactored is about 6,500 lines of code spread over these 4 classes. Designing Swing with classboxes has several advantages over the original implementation.

Inheritance coherence. The inheritance link defined in the AwtCB is fully preserved in the SwingCB. Therefore every Swing widgets, including frames and windows, are swing components. The relation "a frame is a window" stated by AWT is true in SwingCB.

Removed duplicated code. JWindow and JFrame are refactored into refinements of Window and Frame. As a result: Frame remains a subclass of Window in Swing and all the duplicated methods and variables related to the layout, root pane and content pane in JFrame are removed. The size of refined Frame is 29% less than the original JFrame.

Because JFrame and JWindow do not inherit from JComponent, the update() method defined by the latter had to be duplicated in JFrame and JWindow. With Swing as a classbox, this duplication is eliminated.

Explicit type checks avoided. Within the SwingCB classbox, a Swing component is a Component. Therefore, all the explicit typechecks and casts used in the original Swing to check if a subcomponent is a Component or a JComponent are useless.

Since the checks (... instanceof JComponent) are always true, downcasts from Component to JComponent are simply removed. The 16 type-checks (... instanceof JComponent) and 25 casts to JComponent were removed while refactoring the class JComponent (no such expressions are present in the other refactored classes).

Issues and Limits

Now we discuss the results obtained and the impacts on the packages in terms of their visibility.

Refactoring super calls. Several methods related to the content management in JWindow like remove(Component) and setLayout( LayoutManager) override methods defined in Window. These methods perform a check on a property of the root pane, then call the original definition using a super call. For instance, the definition of setLayout( LayoutManager manager) in JWindow is:

public void setLayout(LayoutManager manager) { if (isRootPaneCheckingEnabled()) { throw createRootPaneException("setLayout"); } else { super.setLayout(manager); } }
The expression super.setLayout( manager) triggers the implementation defined in the AWT class Window. Refactoring this overriding method into a refinement of Window implies that the original keyword must be used to invoke the original AWT definition. This scenario convinced us of the need to introduce the original() construct to the classbox model.

Need to enlarge visibility of some Swing classes. Replacing the Swing class

JComponent by a refinement of Component enlarges the visibility of some classes that were in Swing. For instance, JComponent references Swing classes like AncestorNotifier, which are private to the javax.swing package. Swing classes that were private to Swing need to be visible outside their defining package.

Limitations of our refactoring. Unfortunately, removing the class JComponent would entail a major overhaul of Swing. The reason is that each method of the class javax.swing.plaf.ComponentUI refers to the name JComponent. Given our limited resources for this experiment, we confined this overhaul to the classes JWindow, JFrame and JButton. As a consequence, our version of Swing does not contain the pluggable look and feel.

Execution cost. With our current implementation of classboxes, the new method lookup semantics is about 22 times slower than the normal one. This result is obtained from triggering 10000 times the update() methods redefined in Component. This loop takes 1008 ms, whereas it is 45 ms for the same method directly implemented in this class. As explained in the following section, our implementation is rather naive. In our previous work with classboxes in Smalltalk [START_REF] Bergel | Classboxes: Controlling visibility of class extensions[END_REF], we were able to optimize the implementation so that the cost of the redefined method lookup is only 1.1 times slower (compared to 22 times slower with the Java version).

IMPLEMENTATION

We implemented a preprocessor that translates classbox definitions into pure Java files, which are then compiled using a classical compiler. While producing Java source files, classboxes are compiled away by producing a Java package for each classbox. Our implementation is freely available at www.iam.unibe.ch/∼scg/Re- search/Classboxes. It offers an executable cbj compiler similar to the javac compiler, where argument files are classbox-aware. Please note that this implementation is naive and serves only as a proof-of-concept for Java.

Our implementation handles three different ways of refining an imported class: (i) a new class member is added (i.e., not redefined), (ii) a class member other than a method is redefined, and (iii) a method is redefined. The following sections examine each of these cases. We drew a distinction between redefined methods and other redefined class members because the former are dynamically looked up when messages are sent, but not the latter (which are statically bound). We then describe how the new method lookup semantics is implemented using dynamic introspection of the method call stack (Section 6.4). And finally we show how the transitivity of imports is handled (Section 6.5) and we present some limitations and possible improvements (Section 6.6).

Native methods. A native method is a function written in a language other than Java. Only the signature of the method is declared within the Java class. Because such methods do not contain any Java code, they cannot be rewritten using the mechanism described above. As a consequence, native methods cannot be redefined.

Super call in a constructor. Constructors can be redefined as well as methods. Constructor redefinitions are compiled into one single constructor following the mechanism described in Section 6.3. This approach is, however, limited when a constructor performs a super call. Java enforces the constructor of the superclass to be executed before the constructor of the subclass: the super call has to be the first statement of the constructor. Therefore the body of a constructor cannot be embedded in a if statement.

Debugging facilities. Even with our current approach where classboxes are compiled away, information about classboxes needed to structure the system is available (class ClassboxInfo). This information is accessible with a debugger, however it is tedious to manually retrieve the defining classbox for a given class member. Development with classboxes would be more comfortable with a classboxaware debugger.

Modifying the VM. Prior to this work, we implemented two versions of the classbox model in Smalltalk: (i) by implementing a new method lookup algorithm within the VM [START_REF] Bergel | Classboxes: A minimal module model supporting local rebinding[END_REF], and (ii) by using bytecode transformation and method context reification on a normal VM [START_REF] Bergel | Classboxes: Controlling visibility of class extensions[END_REF]. The cost of the former strategy is about 1.1 times slower and the latter is about 1.25 times slower (these figures were obtained by comparing the execution times of a normal Smalltalk application in a classbox and a plain environment ).

The Java VM does not provide a bytecode that reifies the context of a method call. Therefore, the latter strategy cannot be implemented in Java. By modifying the Java VM to implement a new method lookup algorithm [START_REF] Bergel | Classboxes: A minimal module model supporting local rebinding[END_REF], we expect to achieve a similar speedup. Whereas with this approach we would need to modify the VM (which can be tedious), the advantage is that classboxes would be transparent in term of run-time cost.

RELATED WORK

Over the last decade considerable research has focused on new ways to modularize or change a system. One main line of our work has been to keep the notion of class and package distinct. This has to be put in contrast with systems like virtual classes [START_REF] Madsen | Virtual classes: A powerful mechanism in object-oriented programming[END_REF] or hierarchy inheritance [START_REF] Cook | A Denotational Semantics of Inheritance[END_REF] where classes and modules are unified under a common lookup algorithm operating on namespaces that serve as classes and modules.

The related work presented in this section can be classified according to five families: (i) class extensibility (class extensions, Unit, Jiazzi, open classes), (ii) module (MixJuice, MJ), (iii) alternative inheritance (mixins, virtual classes, nested and hierarchy inheritance), (iv) other approaches (AOP, namespaces).

Class Extensibility

Class extension. CLOS [START_REF] Keene | Object-Oriented Programming in Common-Lisp[END_REF], Smalltalk [START_REF] Goldberg | Smalltalk-80: The Language[END_REF] and Objective-C [START_REF]The objective-c programming language[END_REF][START_REF] Pinson | Objective-C[END_REF] allow an already existing class to be extended with new methods or method redefinitions (not in Objective-C). These class extensions, however, are global, which leads to conflicts when two packages extend the same class with the same methods. The resolution policy usually adopted is that the last version of a redefined method is the one that will be globally used. As a consequence, only a single version of a class can be present in a running system.

Classboxes make it possible for multiple versions of the same class to be present in the system at the same time.

Unit. MZScheme [START_REF] Flatt | Units: Cool modules for hot languages[END_REF] offers an advanced module system in which a unit is the basic building block. A unit is a packaging entity composed of requirements, definitions and exports. Mixins are defined by creating within a unit a subclass of a class that will be provided by other units at linking time. Units have to be instantiated and composed with each other to form a program. Reusability and extensibility are expressed by recombining units. An application, made of units, can be recomposed and by aliasing new units can inserted. Units differ from classboxes since a unit acts as a black box: a class within a unit cannot be refined. Instead a new unit has to be provided and included in a recomposition. New mixins can be defined to extend a base system, but we fall again in all the problem related to using inheritance. Therefore not much would have been gained if Swing had been refactored with units.

Open classes. MultiJava [START_REF] Millstein | Relaxed multijava: balancing extensibility and modular typechecking[END_REF] is an extension of Java that supports open classes and multiple method dispatch. An open class is a class to which new methods can be added. Method redefinitions are not, however, allowed: an open class cannot have one of its existing methods refined.

Jiazzi. The unit system of MZScheme has been ported to Java. Jiazzi [START_REF] Mcdirmid | Jiazzi: New age components for old fashioned java[END_REF] is an enhancement of Java that adds support for encapsulated code modules as unit. The main difference with MZScheme is that Jiazzi enables the creation of open classes that can be enhanced with new methods and fields without invasively modifying the original definitions or breaking their existing subclasses. This enables a modularization of cross-cutting concerns [START_REF] Mcdirmid | Aspect-oriented programming with jiazzi[END_REF]. Refinements occur with links between units. The difference with classboxes are twofold: (i) classes defined in the same unit are tied together. Let's assume a class PointFactory and a class Point are contained into the same unit, and Point is imported and refined with a color feature in another unit. Because PointFactory is defined in the same unit that the colorless version of Point, even if PointFactory is also imported in the unit containing the color addition, there is no way for the factory to produce colored points. (ii) Refinement applications are implemented with subclassing, therefore an instance of Point produced in a unit is not an instance of the refined class Point.

Modules

Mixjuice. Mixjuice [START_REF] Ichisugi | Difference-based modules: A class independent module mechanism[END_REF] defines difference-based modules, in which a module can refine a class defined in another module by adding new class members. A refined class constitutes a new version. Contrary to classboxes, with MixJuice multiple versions of the same class cannot, be present in the system at the same time.

MJ. MJ [START_REF] Corwin | MJ: a rational module system for Java and its applications[END_REF] is a module system for Java that provides a high-level interface to abstract low-level Java technical issues related to class loading. The focus of MJ is to support the deployment of different versions of the same package. As such with MJ changes cannot be added to existing classes. In MJ, a module contains the following information: (i) class definition, (ii) dependencies with classes offered by other modules, (iii) access control for this module's provided classes like class privacy and restriction for the clients in subclassing provided classes, and (iv) some initialization code.

By removing some technical limitations of the dynamic class loading mechanism related to the use of CLASSPATH, MJ allows multiple versions of a class to coexist at the same time within a system. These versions are referenced by different namespaces (i.e., classloaders), therefore, they are considered to be two different classes. New versions of a class cannot be propagated to formerly collaborating classes without modifying the original dependancies: modules are considered to be black boxes in which contained classes cannot be modified. This mechanism differs from classboxes because, for a given class, formerly collaborating classes can be reused with new versions of the original class. MJ cannot be used to refactor Swing to our new architecture since classes cannot be extended with new changes.

Alternative Inheritance

Virtual classes. Virtual classes were originally developed for the language BETA [START_REF] Kristensen | The BETA programming language[END_REF], primarily as a mechanism for generic programming rather than for extensibility [START_REF] Madsen | Virtual classes: A powerful mechanism in object-oriented programming[END_REF]. Keris [START_REF] Zenger | Evolving software with extensible modules[END_REF], Caesar [START_REF] Mezini | Conquering aspects with caesar[END_REF], and gbeta [START_REF] Ernst | gbeta -a Language with Virtual Attributes, Block Structure, and Propagating, Dynamic Inheritance[END_REF] offer such a mechanism, where method and class lookup are unified under a common lookup algorithm. Virtual classes are not statically safe because they permit types of method parameter to change covariantly with subtyping. In a similar way that a method is looked up according to an instance, a class is looked up according to an instance (i.e., an encapsulating class). With such a unification of method and class lookup, the role of a class is overloaded with semantics of packages and objects constructor. With classboxes, we keep the original meanings of class and package separate.

Hierarchy Inheritance. Cook [START_REF] Cook | A Denotational Semantics of Inheritance[END_REF] presents a use of inheritance as a derivation of modified hierarchies or other graph structures. Links between nodes in a graph are interpreted as self-references from within the graph to itself. By inheriting the graph and modifying individual nodes, any access to the original nodes is redirected to the modified versions. For example, a complete class hierarchy may be inherited, while new definitions are derived for some internal classes. The result of this inheritance is a modified class hierarchy with the same basic structure as the original, but in which the behavior of all classes modified that depend upon the classes explicitly changed is modified. Hierarchy inheritance is based on having a lookup of classes and on relationship between group of classes, whereas with classboxes, no class-lookup is involved and import is done at the class-level.

Nested inheritance. The Jx programming language [START_REF] Nystrom | Scalable extensibility via nested inheritance[END_REF] is an extension of Java where members of an encapsulating class or package may be enhanced in a subclass or subpackage. Packages may have a declared inheritance relationship. Nested classes in Jx are similar to virtual classes. Unlike virtual classes, nested classes in Jx are attributes to their enclosing class, not attributes of instances of their enclosing class. The difference with classboxes is that in Jx (i) inheritance is overloaded with import semantics, and (ii) a class is defined in only one classbox and can be extended by others, whereas with Jx classes are looked up according to the inheritance defined between packages and between classes.

Scala. Scala [START_REF]Scala home[END_REF] is a statically-typed object-oriented and functional programming language developed at EPFL, the École Polytechnique Fédérale de Lausanne. Scala introduces a new concept to solve the extensibility problem (Section 2.2): views allow one to augment a class with new members. Views follow some of the intuitions of Haskell's type classes, translating them into an objectoriented approach. The scope of a view can be controlled, and competing views can coexist in different parts of one program. A view is statically applied by the compiler to satisfy type constraints. For instance, if a variable anA is of type A, the compiler would translate an expression var aB: B = a, which declares a variable aB of type B and initializes it with a reference to anA, as var aB: B = view(anA), where view is a method (or a function) provided by the programmer, taking an argument of type A and returning an object of type B. In Scala a conversion is done by using type information provided by the programmer whereas with classboxes the scope of change depends on the graph of classboxes involved in the computation.

Mixin Layers. A collaboration-based design [START_REF] Holland | Specifying reusable components using contracts[END_REF][START_REF] Vanhilst | Using Role Components to Implement Collaboration-Based Designs[END_REF] aims at supporting large-scale refinements. A collaboration is a set of roles applied to a set of participant objects. Collaborations are layered linearly to form an application. In mixin layers [START_REF] Smaragdakis | Mixin layers: an object-oriented implementation technique for refinements and collaboration-based designs[END_REF], Smaragdakis and Batory represent a collaboration as a C++ template, a role as a mixin [START_REF] Bracha | Modularity meets inheritance[END_REF], and a participating object as a class. A layered application that uses mixin layers is open to changes by adding new collaborations. However, for an application that is not layered, mixin layers do not offer a satisfying solution to support unanticipated changes.

Feature-oriented programming. Feature-Oriented Programming is the study of feature modularity in product-lines [START_REF] Prehofer | Feature-oriented programming: A fresh look at objects[END_REF]. AHEAD [START_REF] Batory | Refinements and multi-dimensional separation of concerns[END_REF][START_REF] Lopez-Herrejon | Evaluating support for features in advanced modularization technlogies[END_REF] is an approach to Feature-Oriented Programming (FOP) where a base system is regarded as a constant and refinements intended to be added are functions adding features to this base system. A refinement is a function that takes a program as input and produces a refined program as output. FOP advocates program construction as a set of functions applied to a base system. New changes are modeled as new functions. Contrary to classboxes, AHEAD does not support multiple versions of the same class living in the same system.

Generic type. Torgersen [START_REF] Torgersen | The expression problem revisited -four new solutions using generics[END_REF] uses generic type extensions of C# and Java to solve the extensibility problem in a secure and type safe manner. His solutions rely on the use of F-bounds [START_REF] Canning | F-bounded polymorphism for object-oriented programming[END_REF] and wildcards in the declaration of type variable to make them type-safe when a system is extended with new data-types and operators. However, use of generic type has to be foreseen prior to apply an extension, as a consequence, this approach does not fit to support unanticipated changes.

Other Approaches

Aspect-oriented programming. Hyper/J [START_REF] Ossher | Hyper/J: multi-dimensional separation of concerns for java[END_REF] is based on the notion of hyperspaces, and promotes composition of independent concerns at different times. Hyperslices are building blocks containing fragments of class definitions. They are intended to be composed to form larger building blocks (or complete systems) called hypermodules. A hyperslice defines methods for classes that are not necessarily defined in that hyperslice: class members are spread over several hyperslices. With its notion of inter-type, AspectJ [START_REF]AspectJ home[END_REF] allows class members to be separated from the class definition by being defined in an aspect. Whereas with classboxes a class can be refined in two classboxes with two method having the same name, with Aspect/J conflicts are not allowed: two aspects cannot define two methods having the same name on the same class. This kind of extension does not allow redefinition and consequently does not help in supporting unanticipated evolution. Sister namespaces. In Java, a class type is uniquely identified at runtime by the combination of a class loader and a fully qualified class name. The same class loaded into two different class loaders (i.e., namespaces) has two distinct types [START_REF] Sato | Loosely-separated "sister" namespaces in java[END_REF]. Let's assume that two classloaders N1 and N2 load the same class C. One instance of the class C in the classloader N1 cannot be regarded as an in-stance of C in a second classloader N2 because they have different types. This is identified as the problem of the version barrier. Sister namespaces [START_REF] Sato | Loosely-separated "sister" namespaces in java[END_REF] relax the version barrier between application components by defining the notion of binary compatibility and extending the type checker. Sister namespaces make the exchange of instance of different class versions possible across classloaders by relaxing the type checker. To be compatible, two class versions has to be "close enough", whereas with classboxes a class can be refined with any kind of class members.

CONCLUSION

Classboxes address the problem of delimiting visibility of a change to a restricted scope in order to avoid conflicts with other changes and to avoid impacting clients that should not be affected. In a classbox, classes can be defined, classes can be imported from other classes, and class members can be defined for any classes visible (i.e., defined or imported) in this classbox. Classboxes offer an elegant way of bringing some unanticipated changes over a system while delimitating the impact of these changes.

In this paper, we present the Java implementation of this model by adding a small number of constructs to Java. A classbox is a Java package where imported classes can be refined with new class members and imported classes that are refined or not to be reimported in other classboxes. Having a Java version of the model shows that classboxes can be applied to a statically-type language like Java.

By refactoring Swing, we stress-tested the classbox model by applying it to a large case study. Our new version of Swing removes (i) the incoherence in the original Swing hierarchy and (ii) the code duplication that was introduced due to the limitations of the Swing inheritance hierarchy. Moreover, while refactoring, we found the need to extend the classbox model with a new construct that allows a previous definition of a redefined method to be accessed.

As a future work we plan to enhance the notion of refinement in order to enable the use of classboxes as a way to express general changes that can be applied to a system (and not just additions or redefinitions of class members).

Figure 1 :

 1 Figure 1: Swing is a GUI framework built on top of AWT. Fields and methods shown in JFrame, JWindow and JComponent are duplicated code (gray portion). More than 43% of JWindow is duplicated in JFrame.

Figure 2 :

 2 Figure 2: Two strategies (gray portions) to introduce changes without impacting existing clients

Figure 3 Figure 3 :

 33 Figure 3: Two versions of classes Component and Button are used by two different clients OldAppCB and NewAppCB.

Figure 4 :

 4 Figure 4: Locality of changes entails a new method lookup semantics. The numbers within the black boxes indicate the steps taken in looking up a message sent to a button.

1Figure 5 :

 5 Figure 5: Within one classbox, different versions of the same class can be accessible. From AppCB sending the paint() message sent to a LabelButton triggers WidgetsCB's refinement, whereas sending it to a Button triggers NewWidgetsCB.

Figure 6 :

 6 Figure 6: The original() construct invokes the hidden method but in the context of the classbox changes.

  Precedence of redefinition. Redefined class members have precedence over the imported definition. EnhWidgetsCB redefines the method paint() for Component, thus hiding the previous definition. From this classbox and other classboxes that may import Component or its subclasses, the original definition of paint() is no longer accessible. Within the classbox EnhWidgetsCB or NewAppCB, sending the message update() or paint() to an instance of Button will trigger the new definition of paint().

Figure 7 :

 7 Figure 7: From the viewpoint of AppCB, refinements of the root of the hierarchy (Component) are propagated to the class Factory. This is a consequence of importing the version of widgets that have a look and feel.

box

  LookAndFeelCB and used by a new client in AppCB. The rest of this section shows how classboxes allow one to incorporate these changes without having to modify WidgetsCB and FactoryCB.

Figure 9 :

 9 Figure 9: The refactoring of the AWT class Component is performed in two steps: (i) the intermediate class is merged to JComponent, then (ii) this merge becomes a refinement of the AWT class Component.

Figure 10 :

 10 Figure 10: Swing refactored as a classbox.

  Casts. A Swing component is a container for other components. This is a feature obtained from Container by inheritance (JComponent is subclass of Container). Therefore types of subcomponents are Component, and not JComponent (the type of the collection of components is Component[]). The following code typifies what happens in Swing components: JComponent needs to know if its subcomponents use double buffering or not. 16 type checks (... instanceof JComponent) and 25 casts to JComponent are performed in JComponent. In the whole Swing library, these numbers rise to 82 and 151, respectively.

	...
	}
	public Component getComponents(int index) {
	return component[index];
	}
	}
	public class JComponent extends Container {
	public void paintChildren (Graphics g) {
	...
	for (; i > = 0 ; i--) {
	Component comp = getComponent (i);
	isJComponent = (comp instanceof JComponent);
	...
	((JComponent)comp).getBounds();
	...
	}
	}
	}
	In the Swing framework numerous explicit type checks need to
	be performed to determine if a subcomponent is issued from Swing
	or from AWT. For instance, a
	public class Container extends Component {
	int ncomponents;
	Component components[] = new Component[0];
	public Component add (Component comp) {
	addImpl(comp, null, -1);
	return comp;
	}
	protected void addImpl (Component comp,
	Object constraints, int index) {
	...
	component[ncomponents++] = comp;

  , the class JComponent is a subclass of the AWT classes Container and Component. As Container is an intermediate class between JComponent and Component, the refactoring of the class JComponent is done in two steps, as illustrated in Figure 9: 1. Incorporating the class Container in JComponent. A Swing component has the ability to contain other components. Features defined by Container have first to be included in JComponent. Container defines 108 methods and 21 fields, however only a few of them have to be duplicated (32 methods related to container management (e.g.,add, remove) and events management, and 3 variables). We define this "enlarged" JComponent in the classbox SwingCB. This new class is a subclass of Component, which is imported in the new classbox SwingCB. JComponent overrides 22 methods in Container and most of the overriding methods do not perform any super call. For the methods in JComponent that perform a super call, the two implementations are simply merged. 2. Making this new JComponent a refinement of Component The inheritance link between JComponent and the imported

Component is replaced by a refinement link.

In the literature, such modifications are usually termed "extensions", but to avoid confusion with Java's extends keyword, we refer instead to "refinements".

Acknowledgments. We gratefully acknowledge the financial support of the Swiss National Science Foundation for the projects "Tools and Techniques for Decomposing and Composing Software" (SNF Project No. 2000-067855.02) and "Recast: Evolution of Object-Oriented Applications" (SNF 2000-061655.00/1).

We also like to thank Gabriela Arévalo, Marcus Denker, Günter Kniesel, Sean McDirmid, Eric Tanter, Matthias Rieger, Klaus D. Witzel for their valuable comments and discussions.

Refinement of the base system. To introduce the changes that add a "look and feel" to the widgets, two new classboxes are added: LookAndFeelCB, which effectively defines the changes, and Ap-pCB, which is a new client of the resulting system. In LookAnd-FeelCB the root class Component is refined with a lookAndFeel variable. In order for classes Button and Window to use this new variable added to their superclass, their constructor and paint() are redefined. These refinements are defined as: A small application is built in the classbox AppCB. This classbox imports the class Factory from FactoryCB and the widgets having a look and feel from LookAndFeelCB. Now when the new application uses the factory to create widgets, it gets widgets with the look and feel as defined in the LookAndFeelCB classbox, whereas the clients of the original code defined in WidgetsCB are not impacted, i.e., get widgets without look and feel. As AppCB imports the version of Window and Button with a look and feel, from the perspective of AppCB, this version of the widgets takes precedence over the one present in FactoryCB.

SWING AS A CLASSBOX

Because the mechanism provided by Java to specialize code is inheritance, Swing is built on top of AWT using subclassing. As already shown in Section 2 this extension of AWT is developed at a high cost: (i) properties defined in AWT according to the inheritance property are not valid in Swing anymore (i.e., in AWT a The pure Java source code produced contains only one paint() method that gathers the two implementations of the method.

ClassboxInfo is a generated class that (i) gathers some informations about the composition of classboxes needed at runtime like a description of the classboxes that were used to produce the Java code, and (ii) offers some methods useful to introspect the method calls stack. At runtime, when the update() method is invoked, one of the two implementations is executed according to the structure of classboxes inferred from the method calls stack.

Dynamic Introspection of the Method Call Stack

Whenever a redefined method is invoked, the method call stack is reified (by using the exception handling mechanism of Java) to build the structure of the classboxes. When the main(...) method of the OldApp is invoked, before entering the paint() method the corresponding method call stack given by Java is:

WidgetsCB.Component.update() //Top of the stack OldAppCB.OldApp.main() //Bottom of the stack Using this stack reification and the information about the structure of classboxes kept in ClassboxInfo, the static method Classbox-Info.methodVisible ("EnhWidgetsCB", "Component", "paint") yields false, whereas ClassboxInfo.methodVisible ("WidgetsCB", "Component", "paint") return true. In a similar way, before entering the paint() method, the method call stack is:

WidgetsCB.Component.update() //Top of the stack NewAppCB.NewApp.main() //Bottom of the stack Because the paint() method is redefined in the classbox NewAp-pCB, the new implementation has to be used: the static method ClassboxInfo.methodVisible ("EnhWidgetsCB", "Component", "paint") yields true, whereas ClassboxInfo.methodVisible ("WidgetsCB", "Component", "paint") return false.

Adapting Classbox Import to Package Import

Since class imports are transitive in Classbox/J, but not in plain Java, all transitive imports must be compiled away. In the resulting Java source code, each import statement must refer to the original package that defines this class.

For example, while producing the package corresponding to the classbox NewAppCB the import statement import EnhWidgetsCB. Component is translated into import WidgetsCB.Component because the class Component is defined in WidgetsCB.

Limitations and Possible Improvements

Since the current implementation is only intended to serve as a proof of concept, we feel it is important to raise a few points concerning the limitations of this prototype.


Marc Jungers

Eugênio B Castelan

Sophie Tarbouriech

Jamal Daafouz

Finite L 2 -induced gain and λ-contractivity of discrete-time switching systems including modal nonlinearities and actuator saturations $

Keywords: Switching systems, Nonlinear systems, Saturations, Switching Lyapunov functions, LMIs, L 2 -induced gain

    Finite L2-induced gain and lambda-contractivity of discrete-time switching systems including modal nonlinearities and saturating actuator.

Hybrid Systems are dynamical systems exhibiting heterogeneous interactions between logic and differential or difference dynamics [START_REF] Van Der Schaft | An introduction to hybrid dynamical systems[END_REF]. The classical case is given by a finite family of differential or difference processes supervised by logical decision-making algorithms. Among this generic class of systems, two important and wide classes could be pointed out: switched systems and switching systems. In switched systems, the control inputs include (at least partially) the switching rule σ(•). In switching systems, the switching rule σ(•) is not a manipulable variable and is often generated by a complex logical decision-making algorithm, which could be state-, or outputor heterogenous input dependent. Such a switching rule is then modeled by an a priori unknown and induced signal, whose current value could be available. The properties of the designed control law should be thus satisfied for any arbitrary switching rule. One can also consider only switching sequences which are admissible for the physical process [START_REF] Lee | A new stability analysis of switched system[END_REF][START_REF] Liberzon | Basic problems in stability and design of switched systems[END_REF]. This paper focuses on switching systems, which are an elegant framework to deal with a large number of applications as, for example, power converters, automotive domain or air traffic control.

Stability and stabilization of such a general switching system is nowadays a theoretical challenge, which has attracted growing attention in the literature. Lyapunov-like functions and multiple Lyapunov functions introduced in [START_REF] Branicky | Multiple Lyapunov functions and other analysis tools for switched and hybrid systems[END_REF] offer adapted tools to deal with the stability of hybrid systems. Considering a common Lyapunov function is known to be highly conservative. For switching linear systems, a switching Lyapunov function approach has been provided in [START_REF] Daafouz | Stability analysis and control synthesis for switched systems[END_REF][START_REF] Mignone | Stability and stabilization of piecewie affine and hybrid systems: an LMI approach[END_REF][START_REF] Ferrari-Trecate | Analysis and control with performance of piecewise affine and hybrid systems[END_REF] (see also references therein). Nevertheless this technique has been developed for systems switching between only linear modes.

Depending on the physical application, the concept of linear system is valid only in a limited area, due to the fact that actuators cannot provide unbounded magnitude signals. Thus some nonlinearity with respect to the state or nonlinearity with respect to the control input, as saturation, should be taken into account to improve the modeling step and make it more realistic. Control design for classical systems including a saturation has been tackled in the literature, mainly by using a polytopic or a sector-bounded nonlinearity representation for the saturation phenomenon.

The polytopic representation of the saturation requires important computational capabilities [START_REF] Hu | Control systems with actuator saturation: analysis and design[END_REF]. This is why a sector bounded approach is preferred to cope with saturated control input (see for instance [START_REF] Tarbouriech | Stability analysis and stabilization of systems presenting nested saturations[END_REF][START_REF] Gomes Da | Anti-windup design with guaranteed regions of stability for discrete-time linear systems[END_REF][START_REF] Hu | An analysis and design method for linear systems subject to actuator saturation and disturbance[END_REF][START_REF] Castelan | Absolute stabilization of discrete-time systems with a sector bounded nonlinearity under control saturations[END_REF]). The case of nonlinear systems, with a dynamic being a sum of an actuator saturation, a sector bounded nonlinear term and a linear term with respect to the state as in [START_REF] Kokotović | Constructive nonlinear control: a historical perspective[END_REF][START_REF] Arcak | Circle and popov criteria as tools for nonlinear feedback designs[END_REF], is treated in [START_REF] Castelan | Control design for a class of nonlinear continuous-time systems[END_REF][START_REF] Castelan | Absolute stabilization of discrete-time systems with a sector bounded nonlinearity under control saturations[END_REF] for continuous-and discrete-time systems, respectively.

The input-output properties, and particularly L 2 -induced gains, play an essential role in control theory [START_REF] Van Der Schaft | L 2 -Gain and Passivity Techniques in Nonlinear Control[END_REF][START_REF] Zhou | Robust and Optimal Control[END_REF] for both linear and nonlinear (especially for saturated systems [START_REF] Dai | Output feedback design for saturated linear plants using deadzone loops[END_REF][START_REF] Fang | Analysis of linear systems in the presence of actuator saturation and L 2 -disturbances[END_REF][START_REF] Castelan | L 2 -stabilization of continuous-time linear systems with saturating actuators[END_REF][START_REF] Garcia | Finite L 2 gain and internal stabilisation of linear systems subject to actuator and sensor saturations[END_REF]) systems. The extension of such methods for switching systems implies some difficulties and is still an open problem [START_REF] Hespanha | L 2 -induced gains of switched linear systems[END_REF]. Some results should be noticed on this topic [START_REF] Hirata | L 2 -induced gain analysis for a class of switched systems[END_REF][START_REF] Zhai | Disturbance attenuation properties of time-controlled switched systems[END_REF] for continuous-time linear switching systems. To the best of our knowlegde, the problem of L 2 -induced gain for discrete-time nonlinear switching systems has not been addressed in literature. Neural network approaches have been proposed for discrete-time systems [START_REF] He | Reinforcement learning neural-network-based controller for nonlinear discrete-time systems with input constraints[END_REF]. However, the proposed methods do not take into account switching phenomena which is the main purpose here.

This paper aims at investigating discrete-time switching systems including nonlinearities with respect to the state for each mode, actuator saturations and additive L 2 -bounded disturbances. Two problems are then addressed in this context. The first one is to design a switching feedback control ensuring that the controlled system in the disturbance-free case is locally λcontractive at the origin with a basin of attraction as large as possible. The second one is to design a switching feedback control guaranteeing the boundedness of the closed-loop trajectories and minimizing the L 2 -gain from the disturbance to the output. Sufficient conditions, associated with both these problems, are provided by using a classical and a modified sector condition for taking into account the nonlinearity of each mode and the saturation of control inputs, respectively. These conditions, involving Linear Matrix Inequalities (LMI) [START_REF] Boyd | Linear Matrix Inequalities in System and Control Theory[END_REF], allow to pose the control design as a convex programming problem.

It should be emphasized that switched linear continuous-time systems including saturated actuators have been already the objective of investigation, dealt with using a polytopic representation of the saturation [START_REF] Benzaouia | Stability and control synthesis of switched systems subject to actuator saturation[END_REF][START_REF] Lu | Design of switched linear systems in the presence of actuator saturation[END_REF]. In these papers, the considered systems are however not affected by modal nonlinearities.

The paper is organized as follows: Section 1 is devoted to the description of the system, while Section 2 gathers some preliminary results and definitions and Section 3 the statement of considered problems. The main results, formalized as convex programming problems, are proposed respectively in Subsections 4.1 and 4.2. Sections 5 and 6 contain respectively simulation results and a brief conclusion.

Notation. Relative to a matrix A ∈ R m×n , A ′ denotes its transpose, and

A (i) , i = 1, . . . , m, denotes its ith row. If A = A ′ ∈ R n×n , then A < 0 (A ≤ 0)
means that A is negative-(semi-)definite. The components of any vector x ∈ R n are denoted by x (i) , ∀i = 1, . . . , n. Inequalities between vectors are component-wise: x ≤ 0 means that x (i) ≤ 0 and x ≤ y means that x (i)y (i) ≤ 0. I n (resp. 0 n ) denotes the n × n identity (resp. null) matrix. The symbol ⋆ stands for symmetric blocks in matrices. For a symmetric and positive-definite matrix M ∈ R n×n , the ellipsoidal set E(M, α) associated with the matrix M and the positive scalar α is given by {x ∈ R n ; x ′ M x ≤ α}. We will use the shortcut E(M ) = E(M, 1).

System Description

Consider the following discrete-time switching nonlinear system (Σ):

(Σ) :

   x k+1 = A σ(k) x k +G σ(k) ϕ σ(k) (y k ) +B σ(k) sat(u k ) +E x σ(k) w k , z k = C z σ(k) x k +L σ(k) ϕ σ(k) (y k ) +D σ(k) sat(u k ) +E z σ(k) w k , y k = C y σ(k) x k +E y σ(k) w k , (1) where
x k ∈ R n , u k ∈ R m , z k ∈ R pz , y k ∈ R py and w k ∈ R r
are respectively the state, the control input, the controlled output, the output involved in the nonlinearities ϕ σ(k) (•) and the disturbance. The assumptions satisfied by system (Σ) are now specified.

Remark 1. The output y k is independent with respect to ϕ σ (y k ) and to sat(u k ) in order to guarantee the well-posedness of this nonlinearity. It is possible to consider

y k = C y σ(k) x k + D y σ(k) sat(u k ) + E y σ(k) w k + L y σ(k) ϕ σ(k) (y k ) if it
W δ = w : N → R r ; k∈N w ′ k w k ≤ 1 δ . ( 2
)
Assumption 2. The switching rule σ(•) takes its value in the finite set

I N = {1, • • • , N }.
In order to avoid a complex description of the decision-making automaton, σ(•) is assumed to be not known a priori, but its current value σ(k), the output of the automaton, is assumed to be available in real-time.

The evolution of the switching rule is assumed to be not governed by the user.

The mode characterized by σ(•) will be called the active mode of the switching system. In other words, the notation M σ(k) means that at each time k, M σ(k) takes the matrix value in the set

{M 1 , • • • , M N } indexed by σ(k).
Assumption 3. The N nonlinearities ϕ i (•) : R py → R py associated with each mode i ∈ I N are assumed to be decentralized [START_REF] Khalil | Nonlinear Systems -Third Edition[END_REF].

Thus they verify the cone bounded sector condition ϕ i (•) ∈ [0 py , Ω i ], [START_REF] Khalil | Nonlinear Systems -Third Edition[END_REF], i.e., ϕ i (0) = 0 and there exist N diagonal positive definite matrices

Ω i = Ω ′ i ∈ R py×py such that independently, ∀y ∈ R py and ∀l = 1, • • • , p y : ϕ i,(l) (y) [ϕ i (y) -Ω i y] (l) ≤ 0. (3)
Thus, we have the following inequality, ∀i ∈ I N :

ϕ ′ i (y)(∆ i ) -1 [ϕ i (y) -Ω i y] ≤ 0, (4)
where

∆ i △ = diag{d q,i } q=1;••• ;py ∈ R py×py
is any diagonal and positive matrix. Thus, ∆ i represents a degree-of-freedom and is an optimization variable. Notice, however, that in a more general case where there may exist dependencies among different components of ϕ i (•), it could be possible to consider only the sector condition provided in [START_REF] Khalil | Nonlinear Systems -Third Edition[END_REF], by restricting the degree-of-freedom ∆ i to

∆ i = d i I py : ϕ ′ i (y) [ϕ i (y) -Ω i y] ≤ 0.
Note that Ω i is given by the designer and assumed to be known in the sequel for each mode i ∈ I N .

The control inputs are bounded in magnitude and the standard saturation function is considered:

sat(u(k)) (ℓ) = sign(u (ℓ) (k)) min(ρ (ℓ) , |u (ℓ) (k)|) (5)
∀ℓ = 1, . . . , m, where ρ (ℓ) > 0 denotes the symmetric saturation level relative to the ℓ-th control. Throughout this work, the vector ρ is supposed to be given.

By extending the kind of control law provided in [START_REF] Castelan | Absolute stabilization of discrete-time systems with a sector bounded nonlinearity under control saturations[END_REF], we consider:

u k = K σ(k) x k + Γ σ(k) ϕ σ(k) (y k ) (6)
where the m × n-matrix K σ(k) is a switching state feedback gain and the m × p y -matrix Γ σ(k) is a switching feedback gain associated to the active nonlinearity ϕ σ(k) (•). Thus, with non trivial Γ σ(k) , this feedback control law requires the following assumption.

Assumption 4. The nonlinearity ϕ σ(k) (•) is assumed to be known. This assumption could be weakened by assuming only the availability of ϕ σ(k) (y k ) as a signal [START_REF] Arcak | Circle and popov criteria as tools for nonlinear feedback designs[END_REF].

Preliminaries

It is helpful to introduce the indicator function ξ(•) mapping N into R N , defined by

ξ (i) (k) △ = 1, if i = σ(k); ∀i ∈ I N . 0, if i = σ(k); (7)
Note that the indicator function satisfies

N i=1 ξ (i) (k) = 1; ∀i ∈ I N , ξ (i) (k) ∈ {0, 1}, (8) furthermore
, ∀(i, j) ∈ I N × I N , i = j, ξ (i) (k) 2 = ξ (i) (k), ξ (i) (k)ξ (j) (k) = 0. (9)
It is then possible to rewrite the switching matrices involved in the system (1) as matrices that are linear with respect to the indicator function:

M σ(k) = N i=1 ξ (i) (k)M i . ( 10
)
Consider in addition the generic dead-zone nonlinearity:

Ψ(u k ) = u k -sat(u k ). (11)
By considering u k given by ( 6), the closed-loop system (12) can be written under the form

x k+1 = A cl σ(k) x k + G cl σ(k) ϕ σ(k) (y k ) -B σ(k) Ψ(u k ) + E x σ(k) w k , (12)
z k = C z,cl σ(k) x k + L cl σ(k) ϕ σ(k) (y k ) -D σ(k) Ψ(u k ) + E z σ(k) w k , (13)
y k = C y σ(k) x k + E y σ(k) w k , (14)
u k = K σ(k) x k + Γ σ(k) ϕ σ(k) (y k ), (15)
where

A cl σ(k) = A σ(k) + B σ(k) K σ(k) , (16)
G cl σ(k) = G σ(k) + B σ(k) Γ σ(k) , (17)
C z,cl σ(k) = C z σ(k) + D σ(k) K σ(k) , (18)
L cl σ(k) = L σ(k) + D σ(k) Γ σ(k) . (19)
The following lemma will be used to consider the dead-zone as a nonlinearity belonging to a generalized sector condition. For given switching matrices

H i ∈ R m×n , i ∈ I N consider the set S(H i , ρ) defined by S(H i , ρ) = {x ∈ R n ; -ρ ≤ H i x ≤ ρ ; ∀i ∈ I N } . ( 20
) Lemma 1. Consider switching m × n-matrices K i , J i , i ∈ I N . If x k is an element of S((K i -J i ), ρ)
, then with u k defined by ( 6), the nonlinearity Ψ(u k ) satisfies the following inequality

Ψ(u k ) ′ T σ(k) -1 Ψ(u k ) -J σ(k) x k -Γ σ(k) ϕ σ(k) (z k ) ≤ 0 (21)
for any diagonal positive definite switching matrix T i ∈ R m×m , i ∈ I N .

Proof: It follows the same lines as the proof of Lemma 1 in [START_REF] Tarbouriech | Stability analysis and stabilization of systems presenting nested saturations[END_REF] (see also [START_REF] Montagner | Improved estimation of stability regions for uncertain linear systems with saturating actuators: an LMI-based approach[END_REF] or [START_REF] Castelan | Control design for a class of nonlinear continuous-time systems[END_REF]).

Let us consider a switching Lyapunov Function (SLF) defined by

V :    R n × N -→ R + , (x k , k) -→ V σ(k) (x k ) = N i=1 ξ (i) (k)V i (x k ). (22)
The Switching Level Set (SLS) associated to V and δ is given by

L V (δ) △ = x ∈ R n ; V i (x) ≤ 1 δ , ∀i ∈ I N . ( 23
)
The notion of contractive sets is basic for determining regions of asymptotic stability for the saturating closed-loop system [START_REF] Castelan | Absolute stabilization of discrete-time systems with a sector bounded nonlinearity under control saturations[END_REF]. The following definition of λ-contractivity is adapted to consider the sector bounded nonlinearity ϕ i (•) and to consider some time-domain performance associated with the coefficient λ. Definition 1. Consider a non-negative scalar 0 < λ ≤ 1. The SLS L V (δ) is absolutely λ-contractive with respect to the trajectories of system [START_REF] Castelan | Absolute stabilization of discrete-time systems with a sector bounded nonlinearity under control saturations[END_REF], with

w k = 0, if ∀x k ∈ L V (δ), ∀σ(k) ∈ I N and ∀ϕ σ (•) ∈ [0 py , Ω σ ], ∆ λ V = V σ(k+1) (x k+1 ) -λV σ(k) (x k ) < 0. ( 24
)
To provide the desired λ-contractivity conditions, the class of SLF of the form

V σ(k) (x k ) = x ′ k P σ(k) x k , (25)
with

P σ(k) = N i=1
ξ (i) (k)P i and P i = P ′ i > 0 is considered throughout the paper. It is noteworthy that by invoking the property (9), P σ(k) and its inverse are linear with respect to the indicator function ξ(k):

P -1 σ(k) = N i=1 ξ (i) (k)P -1 i = N i=1 ξ (i) (k)Q i , (26)
by noting

Q i = P -1 i , ∀i ∈ I N .
The property of ξ(k) allows obviously to rewrite the SLS L V (δ), defined by ( 23), as

L V (δ) = σ(k)∈I N E(P σ(k) , 1 δ ) = i∈I N E(P i , 1 δ ) = i∈I N E(Q -1 i , 1 δ ). ( 27
)
Definition 2. The L 2 -induced gain [START_REF] Van Der Schaft | L 2 -Gain and Passivity Techniques in Nonlinear Control[END_REF], Σ L 2 , associated to the closed-loop system (12) of the system Σ, is defined by

Σ 2 L 2 = max x 0 =0 ; w∈W δ z 2 w 2 . ( 28
)
The L 2 -induced gain of the closed-loop system ( 12) is equal or less to √ γ if and only if

1 γ k∈N z ′ k z k ≤ k∈N w ′ k w k . ( 29
)

Formulation of the problems

The goal of the paper is twofold and corresponds to provide a solution to the two following problems.

Problem 1 (λ-contractivity). For w k = 0, ∀k ∈ N, a fixed δ > 0 and 0 < λ ≤ 1, design a control law in the class [START_REF] Mignone | Stability and stabilization of piecewie affine and hybrid systems: an LMI approach[END_REF] that allows the λ-contractivity of some L V (δ), verifying [START_REF] Benzaouia | Stability and control synthesis of switched systems subject to actuator saturation[END_REF], so that the closed-loop system is locally asymptocally stable to the origin with a basin of attraction as large as possible.

Problem 2 (Disturbance rejection). The objective in this case consists in ensuring that the trajectories, with x 0 = 0, of the system (1) are bounded for any disturbance belonging to W δ , as defined in [START_REF] Lee | A new stability analysis of switched system[END_REF] and, in addition, in minimizing the L 2 -induced gain Σ L 2 from the disturbance w k to the regulated output z k .

Let us consider the following technical essential lemmas, which are required to derive the main results.

Lemma 2. For a fixed 0 < λ ≤ 1, consider for i ∈ I N , the existence of symmetric positive definite matrices

Q i ∈ R n×n , positive diagonal matrices ∆ i ∈ R py×py and T i ∈ R m×m , matrices U i ∈ R n×n , Y 1,i ∈ R m×n , Z 1,i ∈ R m×n , Y 2,i ∈ R m×py and a scalar γ such that M ij < 0, ∀(i, j) ∈ I 2 N , (30)
where

M ij =           (E x i ) ′ (E z i ) ′ 0 -(E y i ) ′ Ω ′ i 0 -I r           . ( 31
)
Then, applying the control law

u k = K σ(k) x k + Γ σ(k) ϕ σ(k) (z k ), = (Y 1,σ(k) U -1 σ(k) )x k + (Y 2,σ(k) ∆ -1 σ(k) )ϕ σ(k) (z k ), (32)
implies that

V σ(k+1) (x k+1 ) -λV σ(k) (x k ) + 1 γ z ′ k z k -w ′ k w k -2ψ ′ (u k )T -1 σ(k) ψ(u k ) -J σ(k) x k -Γ σ(k) ϕ σ(k) -2ϕ ′ σ(k) ∆ -1 σ(k) ϕ σ(k) -Ω σ(k) y k < 0. ( 33
)
Proof: Due to the properties of ξ(k) given by ( 9) and LMIs [START_REF] Montagner | Improved estimation of stability regions for uncertain linear systems with saturating actuators: an LMI-based approach[END_REF], the sum

M(ξ(k), ξ(k + 1)) = i∈I N j∈I N ξ (i) (k + 1)ξ (j) (k)M ij (34)
is negative definite. For a sake of clarity, the dependency with respect to ξ(k) will be avoided and the dependency with respect to ξ(k + 1) will be denoted with a ' + ' in the matrix index i.e. Q(ξ(k + 1)) = Q + . Thus rewriting Inequality (34) leads to

          -(BT ) ′ -(DT ) ′ Z 1 Y 2 -2T ⋆ (E x ) ′ (E z ) ′ 0 -(ΩE y ) ′ 0 -I r           < 0. (35) It follows that Q > 0 and U ′ + U -Q > 0, which imply that U has full rank. Then (Q -U ) ′ Q -1 (Q -U ) ≥ 0 and λ (Q -U -U ′ ) ≥ -λU ′ Q -1 U. ( 36
)
Combining the change of basis diag I; I; U -1 ; ∆ -1 ; T -1 ; I and Inequality (36) leads, by introducing

K σ(k) = Y 1,σ(k) U -1 σ(k) , Γ σ(k) = Y 2,σ(k) ∆ -1 σ(k) , J σ(k) = Z 1,σ(k) U -1
σ(k) and by using a Schur complement, to inequality

    (A cl ) ′ (G cl ) ′ -B ′ (E x ) ′     Q -1 +     (A cl ) ′ (G cl ) ′ -B ′ (E x ) ′     ′ +     (C z,cl ) ′ (L cl ) ′ -D ′ (E z ) ′     1 γ     (C z,cl ) ′ (L cl ) ′ -D ′ (E z ) ′     ′ +     Lemma 3.
For a fixed 0 < λ ≤ 1, consider for i ∈ I N , the existence of symmetric positive definite matrices

Q i ∈ R n×n , positive diagonal matrices ∆ i ∈ R py×py and T i ∈ R m×m , matrices U i ∈ R n×n , Y 1,i ∈ R m×n , Z 1,i ∈ R m×n and Y 2,i ∈ R m×py such that L ij < 0, ∀(i, j) ∈ I 2 N , ( 38
)
where

L ij =     -Q j ⋆ ⋆ ⋆ (A i U i + B i Y 1,i ) ′ λ(Q i -U i -U ′ i ) ⋆ ⋆ (G i ∆ i + B i Y 2,i ) ′ Ω(C z i U i + D z i Y 1,i ) -2∆ i ⋆ -(B i T i ) ′ Z 1,i Y 2,i -2T i     , ( 39
)
then applying the control law defined by (32) implies that

V σ(k+1) (x k+1 ) -λV σ(k) (x k ) -2ϕ ′ σ(k) ∆ -1 σ(k) ϕ σ(k) -Ω σ(k) y k -2ψ ′ (u k )T -1 σ(k) ψ(u k ) -J σ(k) x k -Γ σ(k) ϕ σ(k) < 0. ( 40
)
Proof: The proof of Lemma 3 follows the one of Lemma 2 by noticing that L ij is an restriction of matrix M ij . It could also be found in [START_REF] Jungers | Stabilization of discrete-time switching systems including modal nonlinearities and saturating actuators[END_REF]. Lemma 4. Consider, for i ∈ I N , that there exist matrices U i ∈ R n×n , symmetric positive definite matrices

Q i ∈ R n×n , matrices Y 1,i ∈ R m×n , Z 1,i ∈ R m×n and a scalar δ such that ∀i ∈ I N and ∀ℓ = 1, • • • , m: N i,ℓ = -Q i + U i + U ′ i ⋆ (Y 1,i -Z 1,i ) (ℓ) δρ 2 (ℓ) > 0.
(41)

Then L V (δ) ⊂ S(K(•) -J(•), ρ), ( 42
)
with J σ(k) = Z 1,σ(k) U -1 σ(k)

and definition (32).

Proof: The proof is obtained from derivation of classical conditions of inclusion (see [START_REF] Boyd | Linear Matrix Inequalities in System and Control Theory[END_REF]). By noting

N ℓ (ξ(k)) = -Q(ξ(k)) + U (ξ(k)) + U ′ (ξ(k)) ⋆ (Y 1 (ξ(k)) -Z 1 (ξ(k))) (ℓ) δρ 2 (ℓ) , (43)
and due to the property (9), we have

N ℓ (ξ(k)) = i∈I N ξ (i) (k)N i,ℓ . (44)
It implies that the inequality

N ℓ (ξ(k)) > 0 is equivalent to ∀i ∈ I N , ℓ = 1, • • • , m, N i,ℓ > 0.
By using the change of basis diag[U -1 (ξ(k)); 1] and Inequality (36), N ℓ (ξ(k)) > 0 leads to

Q -1 (ξ(k)) ⋆ (K(ξ(k)) -J(ξ(k))) (ℓ) δρ 2 (ℓ) > 0. ( 45
)
Schur complement induces

δQ -1 (ξ(k)) > 1 ρ 2 (ℓ) (K(ξ(k)) -J(ξ(k))) ′ (ℓ) × (K(ξ(k)) -J(ξ(k))) (ℓ) . ( 46
)
By multiplying this last inequality at left by x ′ k and at right by its transpose, one has

δV σ(k) (x k ) ≥ 1 ρ 2 (ℓ) K σ(k) -J σ(k) (ℓ) x k 2 . ( 47
) For all x k ∈ L V (δ), V σ(k) (x k ) < 1 δ , which implies that x k ∈ S((K i -J i ), ρ).
We obtain the relation (42).

Main results

Control design solving λ-contractity problem

This subsection is dedicated to provide an optimization problem which solves Problem 1 related to the λ-contractivity of the system (12) without disturbance. Since no disturbance is considered, the value δ has not anymore physical sense and could be arbitrarily fixed. To simplify, δ is normalized in the following by δ = 1, as in [START_REF] Jungers | Stabilization of discrete-time switching systems including modal nonlinearities and saturating actuators[END_REF]. The SLS L V (1), defined by ( 23) is then the set S 0 of initial condition x 0 of switching closed-loop system which is λ-contractive for any nonlinearities ϕ i (•) (i ∈ I N ) verifying the sector condition (4), without disturbance (w k = 0). This set L V (1) is convex, since it is the intersection of convex sets.

The optimization problem consists of determining a control defined by (32), with the largest set L V (1) = S 0 , under the constraints ( 30) and (41). For obtaining the largest set L V (1), let us consider, as in [START_REF] Castelan | Absolute stabilization of discrete-time systems with a sector bounded nonlinearity under control saturations[END_REF], a given and scaled polyhedral shape set included in L V [START_REF] Van Der Schaft | An introduction to hybrid dynamical systems[END_REF]. The goal is to maximize the scaling factor of this set. However this approach depends on the direction of the vectors of the polyhedral set. In order to avoid this dependency, a √ α-radius ball included into L V (1) is considered:

E (I n , α) = {x ∈ R n ; x ′ x ≤ α} ⊂ L V (1) = S 0 . (48)
Being the SLS L V (1) the intersection of the N ellipsoidal sets E(Q -1 i ), Inclusion (48) is equivalent [START_REF] Boyd | Linear Matrix Inequalities in System and Control Theory[END_REF] to:

1 α I n I n I n Q i > 0, ∀i ∈ I N . (49)
An important property is exposed in the following Proposition.

Proposition 1. Given 0 < λ ≤ 1 and δ > 0, by considering symmetric positive definite matrices

Q i ∈ R n×n , positive diagonal matrices ∆ i ∈ R py×py and T i ∈ R m×m , matrices U i ∈ R n×n , Y 1,i ∈ R m×n , Z 1,i ∈ R m×n and Y 2,i ∈
R m×py , for i ∈ I N and a scalar µ, the convex optimization problem

min Q i ,U i ,∆ i ,T i ,Z 1,i ,Y 1,i ,Y 2,i ,µ
µ subject to LMIs (38), (41) and

µI n I n I n Q i > 0, ∀i ∈ I N ,
leads to a switching control law represented by (32), solution of Problem 1.

Proof: Being LMIs (41) satisfied, Lemma 4 implies that the modified bounded sector condition for the dead-zone function ( 21) is verified on L V (1). LMIs (38) being satisfied, Lemma 3 allows to write Inequality (33). Since there is no disturbance and the modified bounded conditions ( 21) and ( 4) are verified, we obtain ∆ λ V < 0, which proves the λ-contractivity of the set. The proof of the proposition is obtained by denoting µ = 1/α.

Control design solving disturbance rejection problem

This subsection presents the solution of Problem 2, dealing with the best L 2 -induced gain for a null initial condition (x 0 = 0) and for a priori given upper bound of the energy of the admissible disturbances

1 δ
. The idea consists in minimizing the upper bound √ γ for the L 2 -induced gain Σ L 2 from disturbance w k to output z k . The following convex programming problem is given in Proposition 2, where the names and the dimensions of free variables are consistent with the ones of Proposition 1.

Proposition 2. Given 0 < λ ≤ 1 and δ > 0, by considering symmetric positive definite matrices

Q i ∈ R n×n , positive diagonal matrices ∆ i ∈ R py×py and T i ∈ R m×m , matrices U i ∈ R n×n , Y 1,i ∈ R m×n , Z 1,i ∈ R m×n and Y 2,i ∈
R m×py , for i ∈ I N and scalar γ, the convex optimization problem Proof: We proceed by recurrence to prove this proposition. Assume

min Q i ,U i ,∆ i ,T i ,Z 1,i ,Y 1,i ,Y
that x k ∈ L V (δ), that is V σ(k) (x k ) < 1 δ for all k = 0, • • • , k 0 . Let us prove firstly that x k 0 +1 satisfies V σ(k 0 +1) (x k 0 +1 ) < 1 δ
: since LMIs (41) are satisfied, Lemma 4 implies that the modified bounded sector condition for the deadzone function ( 21) is verified at each instants k = 0, • • • , k 0 . Being LMIs [START_REF] Montagner | Improved estimation of stability regions for uncertain linear systems with saturating actuators: an LMI-based approach[END_REF] satisfied, Lemma 2 allows to write Inequality (33), that is, we have

∆ λ V + 1 γ z ′ k z k -w ′ k w k < 0. (50)
By assuming that x 0 = 0 (V σ(0) (0) = 0), Inequality (50) (or more particularly ∆ λ V < w ′ k w k ) leads to ∀k 0 ∈ N:

V σ(k 0 +1) (x k 0 +1 ) ≤ k=k 0 k=0 ∆ 1 V ≤ k=k 0 k=0 ∆ λ V ≤ k=k 0 k=0 w ′ k w k ≤ 1 δ . ( 51
)
The limit lim k 0 →+∞ V σ(k 0 ) (x k 0 ) exists and is positive and bounded by 1 δ .

By summing Inequality (50), we have In Figure 2, the sets E(Q -1 1 ) and E(Q -1 2 ) corresponding to the above synthesis result are plotted with symbol '+'. The solid line denotes the intersection of E(Q -1 1 ) and E(Q -1 2 ), that is the set L V (1). Finally the solid circle denotes the largest circle E(µI), included in L V (1). In the same figure, one illustrative example of trajectory is presented. The trajectory (circles linked by solid lines) starts from a point in L V (1). The initial point x 0 = -0.3 -1 ′ is depicted with a square. One can note that L V (1) is contractive. ) and E(Q -1 2 ) obtained from the optimization problem, the intersection L V (δ) and the largest circle included in L V (1).

1 γ k∈N z ′ k z k ≤ k∈N w ′ k w k .
The trajectory x k is plotted with the control u k and its saturation in Figure 3, in function of the time. The saturation sat(u k ) is emphasized at instants k = 0, 1, 3.

The convergence rate λ is conflicting with the size of L V (δ). A compromise should be obtained by a correct choice of λ, as shown in Table 1. The associated sets L V (1) are represented on Figure 4 for the different values of λ from Table 1.

If Assumption 2 does not hold, the active mode is not known. Furthermore if the Assumption 4 is not applicable, the value of the active nonlinearity is not available. By considering the additionnal constraints

! " # $ % &! &" &# &$ &% "! & !'( ! *+,-.) " *+, /012.+ ! " # $ % &! &" &# &$ &% "! !'( ! !'( & &'( /012.+ 3*+,-..456*3*+,, ! " # $ % &! &" &# &$ &% "! ! !'" !'# !'$ !'% & /012.+
(Y 1,i , Y 2,i , U i , ∆ i ) = (Y 1 , Y 2 ,
U, ∆) independent on the mode i, ∀i ∈ I N , or Y 2,i = 0, it is possible to obtain particular control laws with constant gains, or a pure state feedback control law. For λ = 0.9, the conservatism is emphasized in Table 2.

Applying the algorithm provided in Proposition 2 leads, with λ = 1 and The energy of this disturbance is equal to 1.7616 ≤ 1 δ = 2. A trajectory associated to this disturbance is depicted on Figure 5. We can note that the disturbance is rejected.

As in the previous problem, a trade-off should be found between the values δ and γ, as presented in Table 3

Conclusion

This paper has investigated the control problems of λ-contractivity and L 2 gain induced gain minimizing, related to discrete-time switching systems, which include modal nonlinearities, actuator saturations and additional energy-bounded disturbances. These modal nonlinearities are assumed to satisfy their own cone bounded sector condition. The class of switched control laws, composed of a state feedback and an active nonlinearity feedback is considered. Optimization problems under LMIs constraints are provided to solve the considered problems. A numerical example is studied to illustrate these results. Several problems are still open: for example designing controllers subject to decentralized control structure. Furthermore, the design problem of output dynamic controllers for both the cases where the cone bounded nonlinearity is available or not for feedback could be also investigated.

Figure 1 :

 1 Figure 1: Nonlinearities ϕ 1 (•) and ϕ 2 (•) verifying the sector condition.

2 Figure 2 :

 22 Figure 2: Sets E(Q -1 1) and E(Q -1 2 ) obtained from the optimization problem, the intersection L V (δ) and the largest circle included in L V (1).

Figure 3 :

 3 Figure 3: A particular trajectory: a) state components (x 1 with '+'; x 2 with '×'); b) control u k with blue '+' and saturated control sat(u k ) with red '×'; c) first component of the indicator function ξ (1 )(k).

2 Figure 4 :

 24 Figure 4: Sets L V (1) for several λu k µ 1/ √ µ K σ(k) x k + Γ σ(k) ϕ σ(k) (y k ) 2.3542 0.4248 Kx k + Γϕ σ(k) (y k ) 3.7897 0.2639 K σ(k) x k 2.4804 0.4032 Kx k unfeasible

Figure 5 :

 5 Figure 5: A particular trajectory: a) state components (x 1 with '+'; x 2 with '×'); b) control u k with blue '+' and saturated control sat(u k ) with red '×'; c) first component of the indicator function ξ (1) (k).

is assumed that this relation defines one and only one value y k , for all possible x k , u k and w k . Assumption 1. The disturbance {w k } k∈N is assumed to have a bounded en-

	ergy, less than or equal to	1 δ	∈ R

+

, that is it belongs to the set

Table 1 :

 1 Compromise between λ and µ.

  . For δ ≤ 0.092, the optimization problem has no solution.

	δ	γ
	0.092 2.2576 × 10 7 0.093 6.0260 × 10 4 0.095 8.4925
	0.097	4.2079
	0.099	2.8066
	0.1	2.4087
	0.2	0.1976
	1	0.1182
	10	0.1182
	100	0.1182

Table 3 :

 3 Compromise between δ and γ.

-Q j ⋆ ⋆ ⋆ ⋆ ⋆ 0 -γI pz ⋆ ⋆ ⋆ ⋆ (A i U i + B i Y 1,i ) ′ (C z i U i + D i Y 1,i ) ′ λ(Q i -U i -U ′ i ) ⋆ ⋆ ⋆ (G i ∆ i + B i Y 2,i ) ′ (L i ∆ i + D i Y 2,i ) ′ Ω(C z i U i + D i Y 1,i ) -2∆ i ⋆ ⋆ -(B i T i ) ′ -(D i T i ) ′ Z 1,i Y 2,i -2T i ⋆

-Q + ⋆ ⋆ ⋆ ⋆ ⋆ 0 -γI pz ⋆ ⋆ ⋆ ⋆ (AU + BY 1 ) ′ (C z U + DY 1 ) ′ λ (Q -U -U ′ ) ⋆ ⋆ ⋆ (G∆ + BY 2 ) ′ (L∆ + DY 2 ) ′ Ω(C z U + DY 1 ) -2∆ ⋆ ⋆

-λQ -1 ⋆ ⋆ ⋆ ∆ -1 ΩC z,cl -2∆ -1 ⋆ ⋆ T -1 J T -1 Γ -2T -1 ⋆ 0 -(ΩE y ) ′ ∆ -1

& )&

& *+,

$ This work was partially supported by ANR project ArHyCo, Programme "Systèmes Embarqués et Grandes Infrastructures" -ARPEGE, contract number ANR-2008 SEGI 004 01-30011459 and from the European Community's Seventh Framework Programme (FP7/2007-2013) under grant agreement n • 257462: HYCON2 Network of Excellence "Highly-Complex and Networked Control Systems". E. B. Castelan has a financial support by CNPq Brazil. A preliminary version of the paper was presented at the 3rd IFAC Conference on Analysis and Design of Hybrid Systems at Zaragoza Spain in 2009.

In other words, the system verifies Σ L 2 ≤ √ γ. Since the optimization problem provides the minimal γ, this is the optimal L 2 -gain.

Remark 2. In the case of non-trivial initial condition x 0 belonging to

where β is a positive scalar, the definition of L 2 -gain should be extended to

Remark 3. The problem of maximizing the disturbance tolerance could be treated by an optimization problem similar to that one of Proposition 2. More precisely, the optimization problem aims at minimizing δ instead of γ. The value of γ is thus not essential, but should remain finite to ensure that Inequality [START_REF] Montagner | Improved estimation of stability regions for uncertain linear systems with saturating actuators: an LMI-based approach[END_REF] is verified (see for more details [START_REF] Garcia | Finite L 2 gain and internal stabilisation of linear systems subject to actuator and sensor saturations[END_REF]).

Illustrations

Consider system (1) switching between N = 2 modes, with the following matrices (n = 2; m = p y = p z = r = 1):

The nonlinearities ϕ 1 and ϕ 2 verifying the sector condition with Ω 1 = 0.6, Ω 2 = 0.5 and ρ = 0.5 are depicted in Figure 1 and are given by ϕ 1 (y) = 0.6 y(1 + sin(y)) 2 ; ϕ 2 (y) = 0.5 y(1 + exp(-y 2 /2)) 2 .

Applying the algorithm given in Proposition 1 with λ = 1, we obtain the following numerical results: γ = 1.4160 × 10 5 and µ = 1.1687.