Aspect-OrientedProgrammingandSeparation ofConcernsProceedings of the International WorkshopLancaster University, UK24 August 2001

Awais Rashid, Lynne Blair (eds.)

Computing Department, Lancaster UniversityTechnical Report No. CSEG/03/01

http://www.comp.lancs.ac.uk/computing/users/marash/aopws2001/

Preface

These proceedings contain the position papers and extended abstracts accepted for presentation at the Workshop on Aspect-Oriented Programming (AOP) and Separation of Concerns held on 24 August 2001 at Lancaster University, UK. The goal of the workshop was to increase awareness about AOP and other separation of concerns mechanisms in the UK computer science community by bringing together both UK-based and international researchers working in these areas. The workshop was aimed at providing a forum to present on-going or completed research work and exchange ideas about outstanding research issues. A tutorial was held before the workshop on 23 August 2001 to provide an introduction to AOP concepts and hands-on experience with AspectJ: an AOP language from Xerox PARC which enables writing aspect-oriented programs in Java. The tutorial was aimed at people relatively new to the area. Since the tutorial was held before the workshop, tutorial participants attending the workshop had an opportunity to expand their knowledge to state of the art research in the area. The accepted papers for the workshop covered a wide but coherent set of topics including adaptive systems, persistence, mapping and automation, middleware and future directions for AOP. We wish to extend our thanks to the authors of the papers for their contribution to the workshop. We also wish to express our gratitude to Cooperative Systems Engineering Group at Computing Department, Lancaster University for providing funding for the workshop and the British Computer Society Advanced Programming Group for their help in advertising the workshop. In addition, we wish to thank Aimee Doggett, Chris Needham and Michelle Spence for local arrangements. Last but not least we thank all the participants without whom the workshop would not have been possible.

Awais Rashid Lynne Blair August 2001

Table of Contents

Adaptive Systems

Grouping Objects using Aspect-Oriented Adapters 1 Stefan Hanenberg, Rainer Unland From Software Parameterization to Software Profiling 8 Philippe Bouaziz, Lionel Seinturier Aspect-Based Workflow Evolution 13 Boris Bachmendo, Rainer Unland

Mapping and Automation

Some Insights on the Use of AspectJ and Hyper/J 20 Christina von Flach G. Chavez, Alessandro Farbricio Garcia, Carlos J. P. de Lucena Translation of Java to Real-Time Java using Aspects 25 Morgan Deters, Nick Leidenfrost, Ron K. Cytron

Middleware

Middleware Architecture Design based on Aspects, the Open Implementation Metaphor and Modularity 31 H.-Arno Jacobsen Aspects of Exceptions at the Meta-Level 38 Ian S. Welch, Robert J. Stroud, Alexander Romanovsky JReplica: An AOP Approach for a Transparent, Manageable and ORB Independent Object Replication 44 Jose Luis Herrero, Fernando Sanchez, Miguel Toro

Miscellaneous

Transferring Persistence Concepts in Java ODBMSs to AspectJ Based on ODMG Standards 53 Arno Schmidmeier Alternatives to Aspect-Oriented Programming? 58 David Bruce, Nick Exon

Grouping Objects using Aspect-Oriented Adapters

Stefan Hanenberg, Rainer Unland

Institute for Computer Science University of Essen, D - 45117 Essen

{shanenbe, unlandR}@cs.uni-essen.de

Abstract. Aspect-Oriented Programming (AOP) is an approach for realizing separation of concerns and allows different concerns to be weaved into existing applications. Concerns usually cross-cut the object-oriented structure. When-ever a concern needs to invoke some operations on objects of the given structure the problem arises, that those objects have different types, but the concern ex-pects them to be handled in the same way. Therefore a mechanism for grouping objects of different types is needed.This paper discusses different mechanisms and proposes aspect-oriented adapters for grouping types and shows how this approach permits a higher level of flexibility and reduces the limitations of known approaches. Aspect-oriented adapters are not limited to a specific gen-eral purpose aspect language (GPAL). Nevertheless the examples in this paper are realized in AspectJ, which is by far the most popular and well-established general purpose aspect language.

1 Motivation and Problem Description

Let us assume we want to make objects persistent, which are created by an existing simulation-application. As pointed out in [3] persistency is a concern and so this is a typical application of Aspect-Oriented Programming [4]. Every newly created object should be added to a persistent storage and whenever the state of a certain object changes, its representation on the store must be updated. There is no need to offer an interface for retrieving objects, because the simulation itself does not use former ob-jects. Instead the information is used by another application which directly accesses the storage for retrieving information about the simulation. The objects to be stored are all instances of class Point.

A suitable (straight-forward) solution for this problem in AspectJ [5] would be an aspect, which writes the state to the store every time an object is created and when-ever its state changes (fig. 1). An instance of the aspect PersistentPoint is created for every Point instance. The aspect generates an object id (realized as an instance counter) and stores it in its attribute id. After creating a new Point the object is written to the persistent storage realized in the constructor of Persis-tentPoint.

The state of a point changes, whenever the methods setX() or setY()are in-voked. Therefore a pointcut setPC() is defined for any instance of Point receiving a set-message. Whenever this happens the corresponding pointcut method (or advice in the AspectJ terminology) is executed which reads a point's state (getX() , getY()) and updates the persistent storage.

aspect PersistentPoint

of eachobject(instanceof(Point)){ private static int idnum = 0; private int id = ++idnum; public PersistentPoint() { .. write new (unitialized) object to storage} pointcut setPC(Point p): instanceof(p) && (receptions(void setX(float)) || receptions(void setY(float))); after(Point p): setPC(p) { float x = p.getX()); float y = p.getY()); …update x,y of object id} }

class Point { private float x=0; private float y=0; public float getX() { return x;} public float getY() { return y;} public void setX(float x) { this.x = x;} public void setY(float y) { this.y = y;} }

Figure 1: a) Class Point, b) Aspect PersistentPoint

Let us assume there is another (similar) application having its own implementation

of a point AnotherPoint identical to Point. The proposed solution directly de-pends on the class Point and cannot be used for other classes. Therefore it would be more desirable to define a persistency aspect without being limited to class Point.

AspectJ supports inheritance relationships between aspects and allows to declare abstract aspects, so it seems to be a good choice to define an abstract aspect Per-sistentObject, which is responsible for creating the object id and reading the object's state (fig. 2, see [2] for a detailed discussion on inheritance and AOP). Its sub-aspects only have to define the class this aspect should be weaved to. Therefore PersistentObject contains an abstract pointcut weavedClassPC(), which has to be defined by the subaspects. We want the aspects to be instantiated for every instance of Point and AnotherPoint, so the definitions of weaved-ClassPC()in our concrete aspects corresponds to that.

But now a new problem arises: how can the state of the object be read in the point-cut method? The intention of the aspect is to be woven to classes, having the meth-ods getX(), getY(), setX(float) and setY(float). The set-methods are used for the pointcut definition, and the get-methods are needed by the aspect in-stance to read an object’s state. But although knowing those method signatures the concrete type of those classes is unknown and left to those aspects, which make the abstract pointcut concrete. Because aspects crosscut the inheritance structure of classes usually those classes do not have any common type but java.lang.Object. So it is not possible to send getter-messages to the related object, because the type is unknown and therefore a typecast is not possible.1 A pos-

1 We assume here general purpose aspect languages with static type checking like AspectJ or

Sally [8] which are both based on the programming language Java.

sibility would be to use reflection for those method calls, but that requires an enor-mous effort.

abstract aspect PersistentObject of

eachobject(weavedClassPC) { private static int idnum = 0; private int id = ++idnum; public PersistentObject() { .. write new (unitialized) object to storage} abstract pointcut weavedInstances(Object o); pointcut setPC(Object o): weavedInstances(o) && (receptions(void setX(float)) || receptions(void setY(float))); after(Object p): setPC(p) { ..write state to data storage} }

aspect PersistentPoint extends PersistentObject { pointcut weavedInstances(Point p): instanceof (p); } aspect PersistentAnotherPoint extends PersistentObject { pointcut weavedInstances (AnotherPoint p): instanceof (p); }

Figure 2: abstract persistency aspect (trial)

The concrete problem is, that aspect-oriented programming groups objects in an-

other way than the predefined object-oriented structures do. So a mechanism is needed how to group objects of different types and allow to sent messages to them.

In the next section we discuss approaches related to this problem and demonstrate that they do not solve this problem appropriately. Afterwards we introduce and dis-cuss aspect-oriented adapters for grouping types and show how this approach allows a higher level of flexibility and reduce the limitations of other approaches. We will also apply the adapter to the introducing example. In the forth section we map the introduc-ing example to aspect-oriented adapters. Finally we summarize and conclude the paper.

2 Related Work

AspectJ offers a mechanism called introductions which can be applied to the given problem. The mechanism allows aspects to change the structure of the object-oriented classes. In this way additional methods and attributes can be inserted into existing classes. For the purpose of grouping objects introductions allow to insert new types to the target classes. So the interface needed by an aspect has to be defined and af-terwards integrated into those classes.

Applied to the example from the first section that means, that an interface needed by the aspect PersistentObject has to be specified. This interface has to con-tain the getter-methods the aspect needs to invoke for reading a point’s state. The concrete aspects PersistentPoint and PersistentAnotherPoint have to introduce this interface to the classes Point and AnotherPoint. The type of the parameter in the pointcut and pointcut method must be of that introduced interface, so the advice can invoke the getter-methods.

But this way to handle the problem leads to additional problems:

• Tangled introduction statements: The introduction-statements in every sub-aspect logically belong to the abstract aspect. They have to be implemented redundantly and are in that way tangled.

• Confusing class structure: After weaving the classes of the original application implement a new interface (fig. 3). If a lot of aspects are woven this approach leads to numerous interfaces spread all over the class structure. In this way the original code becomes confusing and makes it difficult for developers to understand the original code for reasons of reuse.

• Lack of structure after unweaving: After weaving developers extending the appli-cation can use the common interfaces introduced by the aspects, because they cannot distinguish the original interface from the introduced ones. So after unweav-ing the aspects the original classes do not implement those interfaces any longer, and so the extended application is incorrect. Because of this we regard introductions to be inappropriate for the given problem.

The problem of grouping objects has already been discussed widely in the context of object-orientation. Classes are templates from which objects are created (cf. [10]) and in that way group objects. [9] pointed out the importance of classification as a mecha-nism for conceptual modeling in object-oriented programming. The difference to the problem handled here is that the needed classification is not an inherent property of the objects, but depends on an aspect’s subjective perspective on the system.

AnotherPointPoint

Object Object

AnotherPointPoint

interface

PointInterfaceWeaving

Figure 3: Using introductions for Point and AnotherPoint

In that way the mechanism of generalization introduced in [7] seems to be appropri-ate for the problem stated. Generalization permits to define a super-type based on an existing class. In [7] one of the main purposes of generalization is to achieve a late classification. That is exactly what aspects are doing: while they cross-cut an existing structure they accomplish a late classification for their special purposes.

Neglecting the fact, that generalization is not available in popular object-oriented programming languages, the criticism of that mechanism is corresponds to the of criti-cism introductions in AspectJ: developers extending the original application can not distinguish between the original classes and those created for the purpose of late classification. Also the problem of the confusing class structure stays the same.

3 Aspect-Oriented Adapters

Adapters (cf. [1]) are special classes, which adapt the interface of a class in the way expected from its clients. In that way the functionality of adapters match the problem

stated above. The traditional use of adapters for mapping interfaces assumes, that clients expect a certain interface of a class which differs from that class which is able to fulfill the requests. The problem depicted here is different: advices expect their parame-ters to have some method signatures to send messages to them. Although the signa-tures are known, the type of those objects is unknown, respectively those objects do not have any common type. So an adapter is needed which has the interface expected by the aspect and which forwards messages to a certain object.

receptions(* *(*))

of eachobject (instanceof(Adapter)) <<aspect>>

ForwardingAspect Adapter

+refObject:Object +getRefObject():Object +createAdapter(o:Object,c:Class):Adapter

ConcreteAdapter1

+Operation1…… +Operation2……

ConcreteAdapter2

+Operation1…… +Operation2……

Figure 4: Aspect-Oriented Adapters2

An object-oriented solution for this problem is quite complex: the type of the object to which the messages have to be forwarded is unknown, so the developer has to use reflection to realized it. This code has to be used in every method which means an enormous effort. public aspect ForwardingAspect of eachobject(instanceof(Adapter)) { ... around() returns Object: receptions(* *()) { ... return invokeMethodFromReceptionsJoinPoint((ReceptionJoinPoint) thisJoinPoint);

...} private Object invokeMethodFromReceptionsJoinPoint(ReceptionJoinPoint jp) throws Exception { Method m = getMethodFromReceptionJoinPoint(jp); return m.invoke(((Adapter) jp.getExecutingObject()).refObject, jp.getParameters());} private Method getMethodFromReceptionJoinPoint(ReceptionJoinPoint jp) throws Exception { Adapter wrap = (Adapter) jp.getExecutingObject(); MethodSignature sig = (MethodSignature) jp.getSignature(); String methodName = sig.getName(); Class[] paramTypes = sig.getParameterTypes(); return wrap.refObject.getClass().getMethod(methodName, paramTypes);} }

Figure 5: Example-implementation for forward-adapter

The aspect-oriented solution for such adapters is much easier and allows a higher degree of reusability (figure 4). The abstract class Adapter contains the reference to the object to which every message is to be forwarded. The aspect ForwardingAs-pect is responsible for forwarding every message received by an instance of Adapter. Therefore an instance of ForwardingAspect is created for every in-stance of Adapter and the aspect contains pointcut methods, which forward every message received by the adapter to the corresponding object.

2 The UML-like notation used here serves the understanding of the ingredients of the aspect-

oriented wrapper, but does not match the UML standard.

The aspect-oriented adapter is used by creating a ConcreteAdapter, subclass of Adapter, which contains all methods needed by the aspect. Those methods have to contain a dummy implementation needed for compiling the class. The implementa-tion will never be executed, because the ForwardingAspect replaces it by forward implementations.

Whenever a client wants an object to be adapted, he has to create an adapter in-stance by invoking the static createAdapter(..)-method of Adapter. The parameters of this method are an instance of the object which is about to be adapted, and a reference to the concrete adapter class. The adapter uses reflection to create a new instance of the concrete adapter and initializes refObject with the adapted object. The developer doesn’t have to write glue code for forwarding messages, be-cause this is already done by the ForwardingAspect.

Figure 5 shows an extract from the implementation of a forward aspect in AspectJ. The advice overrides every method of the adapter having an arbitrary return type. This is realized by a receptions pointcut consisting only of wildcards. The implementation uses the Reflection API part of AspectJ for finding out, what the target method is and the Java Reflection API for getting a reference to and invoking the target method .

For applying the aspect-oriented adapter to the introducing example a concrete adapter (PointAdapter) has to be created containing both getter-methods used by the advice in PersistentObject. The advice has to create an adapter object for the incoming object using the create method of the abstract adapters:

PointAdapter a = (PointAdapter) Adapter.createAdapter(p, PointAdapter.class); Afterwards object a can be used as if it is an instance of PointAdapter.

4 Conclusion and further work

We introduced aspect-oriented adapters as a mechanism for grouping objects and compared it to existing approaches. The main advantage of using adapters is, that objects can be grouped without touching the existing inheritance structure. The effort of using aspect-oriented wrappers is compareable to introductions known from the GPAL AspectJ.

Nevertheless aspect-oriented adapters need to be used very carefully and in a dis-ciplined maner. Because forwarding messages is realized on object-level using reflec-tion there is no static type-checking available. So the developer has to be sure, that the interface of the adapted object really fulfills the signatures specified in the con-crete adapter.

This presented approach can be used for composing aspectual components [6], which represent aspects whose interfaces have to be adapted to let them interact with their environment. In the future we will examine, how such components can be realized in existing general purpose aspect languages.

References

1. Gamma, E., Helm R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable Ob-ject-Oriented Software. Addison-Wesley, 1995

2. Hanenberg, S., Unland, R.: Concerning AOP and Inheritance. In: Mehner, K., Mezini, M., Pulvermüller, E., Speck, A. (Eds.): Aspect-Orientation - Workshop. Paderborn, Mai 2001, University of Paderborn, Technical Report, tr-ri-01-223, 2001

3. Hürsch, W., Lopes C.: Separation of Concerns. Northeastern University, technical report, no. NU-CCS-95-03, 1995.

4. Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J.-M., Irwing, J.: Aspect-Oriented Programming. Proceedings of ECOOP '97, LNCS 1241, Springer-Verlag, pp. 220-242, 1997

5. Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., Griswold, W.: An Overview of AspectJ. Appears in ECOOP 2001

6. Lieberherr, K., Lorenz, D., Mezini, M.: Programming with Aspectual Components , Technical Report, NU-CCS-99-01, Northeastern University, Boston, 1999

7. Pedersen, C.: Extending Ordinary Inheritance Schemes to Include Generalization. In: Mey-rowitz, N. (Ed.): Conference on Object-Oriented Programming: Systems, Languages, and Applications (OOPSLA'89), October 1-6, 1989, New Orleans, Louisiana, Proceedings. SIGPLAN Notices 24(10), October 1989

8. Sally: A General-Purpose Aspect Language, http://www.cs.uni-essen.de/dawis/ research/ aop/sally/, January 2001

9. Taivalsaari, A.: On the Notion of Inheritance. ACM Computing Surveys, Vol. 28, No. 3, pp. 439-479, 1996

10. Wegner, P.: Dimensions of object-based language design. In: Meyrowitz, N. (Ed.), Proceed-ings of OOPSLA '87, SIGPLAN Notices 22 (12), pp. 168-182, 1987

From Software Parameterization to Software

Pro�ling

Philippe Bouaziz1;2 and Lionel Seinturier1

1 Univ. Paris 6, Lab. LIP6, 4 place Jussieu, F-75252 Paris cedex 05, France

fPhilippe.Bouaziz, Lionel.Seinturierg@lip6.fr2 Prodware Group, 45 quai de la Seine, F-75019 Paris, France

Abstract. Over the last years, software engineering research applied

to separation of concerns has focused on new software paradigms such

as Aspect Oriented Programming. Aspects are abstractions which cap-

ture and localize crosscutting concerns. Many works have been conducted

with regard to non functional concerns such as performance or semantics

of component. This paper wants to demonstrate their interest for func-

tional concerns. It introduces a new software engineering process that

we call Software pro�ling which represents a step further in software pa-

rameterization using functional/non-functional aspects to provide highly

adaptable and evolving software.

1 Introduction

Over the last years, software engineering research applied to separation of con-

cerns has focused on new software paradigms such as Aspect Oriented Program-

ming [8][7]. It aims at optimizing software development by providing tools to

improve modularization, so that it corresponds to the natural view of concerns

such as de�ned by developers [10]. Aspects are abstractions which capture and

localize crosscutting concerns e.g. code which cannot be encapsulated within one

class but that is tangled over many classes. Synchronization, failure handling,

load balancing, real time constraints, memory management, optimization are

classical examples of aspects. Many works have been conducted with regard to

non functional concerns such as performance or semantics of component where-

as crosscutting concerns are widely presents in codes dealing with functional

aspect.

Research in AOP is in its early stage with programming tools available,

but its contribution to software development process is still not clearly de�ned,

especially in term of penetration degree in the functional part. We think that

capabilities of aspect are broader than system and environmental concerns, and

that they can be widely used in the software development process, and especially

concerning software parameterization that has been the last ten years goal in

software industry.

We present here the foundation of a software engineering process that we call

Software pro�ling which represent a step further in software parameterization by

2

using functional/non-functional aspects to provide highly adaptable and evolving

software. It permits to obtain clear, modular and strongly evolving software that

can be pro�led statically or dynamically depending on the problematic of the

user with no alteration of the standard source code which is only concerned

by standard evolutions, keeping this way ascendant compatibility in software

versions.

First of all, we describe quickly Aspect Oriented Programming. In a second

part we present the goals and fundamentals of Software pro�ling and its con-

tribution to software engineering industry. Finally we consider the bene�ts of a

Case tools for software pro�ling as a base for further works.

2 AOP

Aspect Oriented Programming aims to achieved separation of concerns by im-

proving code modularization using Aspects. Most of the time, aspects repre-

sent non-functional requirements. In AOP, components and aspects are separate

codes and the weaving process is done by a static (compile time) or dynamic

(run time) compiler that is called an aspect weaver. The aspect weaver, weaves

aspects and components at speci�c points named join points which can be im-

plicit such as language keywords or explicit. Speci�c code is then added at this

points. [6] classify join points among open, class-directional, aspect-directional,

and closed depending on the fact that the aspect or the class knows about each

other or not:

{ Open: Both classes and aspects know about each over,{ Class-directional: the aspect knows about the class,{ Aspect-directional: the class knows about the aspect,{ Closed: neither the aspect nor the class knows about the other.

AspectJ [1] and the Composition Filter Object Model (CFOM) [2] are some

of the leader tools in AOP. AspectJ is an aspect-oriented extension to Java that

is being developed at the Xerox Palo Alto Research center. It o�ers a language

to de�ne a new kind of module, called an aspect. Aspects are de�ned separately

from the standard code. AspectJ provides a static aspect weaver in Java, and oth-

er development tools. It is widely used in AOP research community, and version

1.0 is due next fall. A version of AspectJ for C [4] is under development. CFOM

is a project developed by the Trese group. The composition �lter approach [2]

extends objects with �lters that deal with inter-objects messages. Input and out-

put �lters are used to localize aspect code. Other AOP approach exists, among

them Subject Oriented Programming [5], Adaptive Programming [9], and other

language extension like AOP/St for Smalltalk [3].

3 Software pro�ling

3.1 Software parameterization

Customer requirements and needs tend to evolve as technology, business and

company processes advance. Software developed in the last decade with initial

3

customer needs in mind tend to be unsuitable to follow these changes as no

proper design technique is available for this. Development teams that try nev-

ertheless to achieve this goal, end up with source code more and more diÆcult

to maintain, upgrade, and reuse. Along a long embryo period, software is install

with many diÆculties and is in permanent beta stages to meet new requirements

or requirements that emerge from the analysis.

The increasing speed of technological evolution over the last twenty years and

the fact that computer software became more and more common, created a clear

need for rationalizing software processes to deliver cheaper products, with short

integration times, quality-oriented maintainability and evolution capabilities to

guarantee a longer software life.

To achieve this goal, software industry evolved, just as the textile industry did

with ready-made clothes, and committed itself in developing standard business

software, based on common needs of a signi�cant community of customers. Base

on this, customizations are being made possible with parameters that re ect

the various management practices of customer organizations. These software are

developed by editors that provide maintenance, that are permanently auditing

their market, and that are arbitrating the functional and technological changes

of software.

These days, the existing level of parameterization existing in major products,

such as ERPs1 (e.g. SAP), provides many important features to meet needs of

various industry �elds. Nevertheless, the level of adaptability of these products to

non-mutualizable features is weak due to the complexity introduced by the huge

number of available parameters. Most of the time, this adaptation is done in an

ad-hoc manner. Faced with this problem, partial solutions have been proposed

based on object technologies, n-tiers architectures and in the industry, relational

databases. They allow delocalizing treatments such as reporting, that can (re)

become speci�c, and to slightly amend software based on entry points, triggers

or stored procedures, to better integrate it with the information system.

Nevertheless, for simple needs such as ascending compatibility, the behavior

of the application or of the data model can never be altered. This prevents a strai-

ght and optimized answer to above mentioned issues. Furthermore, programs end

up being tangled due to the many possibilities introduced by parameterization

and cannot be reuse.

3.2 The bene�ts of functional aspects

Software design aims at: (1) factorizing functionalities, and (2) allowing that

these functionalities be parameterized in order to meet customer speci�c needs.

From an industrial point of view, the modi�cation of these parameters can induce

too deep modi�cations of the software internal structure preventing the addition

of new or customer speci�c features. Many technical solutions exist, but they

bring either an overload of scattered code, or a parameterization of existing

parameters, and in all cases are to diÆcult to maintain (each case needs to be

1 Entreprise Resource Planing

4

individually treated). Aspect oriented development should allow to standardize

and centralize these speci�cities in order to avoid overloading and tangling.

3.3 Software pro�ling

The notion of aspect allows to pro�le software depending on the needs and

notably:

{ to encapsulate in a clear and centralized way, parameters leading to massive

cross-cutting all along the code,{ to perform without altering the main code, modi�cations or extensions in

functional part, for example altering the behavior of business objects to

obtain a di�erent action on the information ows, and even its replacement

by another object,{ to encapsulate in a clear and centralized way system features such as syn-

chronization, load balancing, real time, ...,{ to ease code reuse,{ to bring capabilities of dynamic reactivity to the software depending on

the evolution of pro�les such as dynamic design of GUI and contents (for

instance to pro�le Internet applications furnished by ASPs - application

service providers).

Usage of aspects in parameterized software therefore allows to pro�le software

depending on data and strategy de�ned in static or dynamic ways. The pending

diÆculty is to be able to de�ne what in a pro�le is relevant to aspects.

4 Further works

As mentioned before, parameterized software design, is a global process. To be

a part of it, the notion of aspect should impact all levels, analysis, design and

implementation. To do so, CASE tools should integrate this notion, furnishing

an environment taking all this considerations in account. We can imagine to �nd

there :

{ a set of rules to help decide whether to use aspects or not,{ an extension to existing methods to take aspects into account during the

analysis phase,{ a graphic design tool to describe aspects and their relationships with other

aspects and components,{ an environment for managing and testing projects integrating aspects char-

acteristics.

Some works have been realised in this sense such as UML/UXF [11] for the

design phase or AJDE [1] as a development environment. Nevertheless, as far as

we know, no break throws have been made in terms of designing aspects and their

relationships or about methods, or decisional purpose. Our goal is to provide a

CASE tools for software pro�ling design taking all this needs in account. One of

the �rst steps will be to de�ne, method speci�cs, components speci�cations and

rules.

5

5 Conclusion

We show in this paper the interest of introducing aspects in software parameter-

ization, and by the way demonstrate the capabilities of aspects in the functional

�eld of software development. Aspects in the development process will bring

clear, modular, strongly evolving and adaptable parameterized software. In this

article we enlarged the scope of aspect to functional domains. We are now work-

ing, on de�ning rules to decide where and when aspects should apply. The next

step will be for us to de�ne fundamentals for Software pro�ling, especially in

terms of method speci�cs, components speci�cations and rules.

References

1. AspectJ home page. http://www.aspectj.org.

2. Aksit, M., Wakita, K., Bosch, J., and Bergmans, L. Abstracting object interactions

using composition �lters. vol. 791 of LNCS, pp. 152{184.

3. Bollert, K. On weaving aspects. In Workshop Aspect-Oriented Programming at

ECOOP'99 (June 1999). http://trese.cs.utwente.nl/aop-ecoop99/.

4. Coady, Y., Kiczales, G., Feeley, M., Hutchinson, N., and Ong, J. Structuring

system aspects. In Proceedings of the workshop on Aspect-Oriented Programming

at ICSE'01 (2001).

5. Harrison, W., and Ossher, H. Subject-oriented programming (A critique of pure

objects). In OOPSLA 1993 Conference Proceedings, A. Paepcke, Ed., vol. 28 of

ACM SIGPLAN Notices. ACM Press, Oct. 1993, pp. 411{428.

6. Kersten, M., and Murphy, G. Atlas: A case study in building a web-based learn-

ing environment using AOP. In Workshop Aspect-Oriented Programming at E-

COOP'99 (June 1999). http://trese.cs.utwente.nl/aop-ecoop99/.

7. Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., and Griswold, W.

An overview of AspectJ. In Proceedings of the 15th European Conference on

Object-Oriented Programming (ECOOP'01) (2001), Lecture Notes in Computer

Science.

8. Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J.,

and Irwin, J. Aspect-oriented programming. In Proceedings of the 11th European

Conference on Object-Oriented Programming (ECOOP'97) (June 1997), vol. 1241

of Lecture Notes in Computer Science, Springer, pp. 220{242.

9. Lieberherr, K. Adaptive Object-Oriented Software: The Demeter Method with

Propagation Patterns. PWS Publishing Company, Boston, 1996.

http://www.ccs.neu.edu/research/demeter/biblio/dem-book.html.

10. Parnas, D. On the criteria to be used in decomposing systems into modules.

Communications of the ACM 15, 12 (1972), 1053{1058.

11. Suzuki, J., and Yamamoto, Y. Extending UML with aspects: Aspect support the

design phase. In Workshop Aspect-Oriented Programming at ECOOP'99 (June

1999). http://trese.cs.utwente.nl/aop-ecoop99/.

Aspect-Based Workflow Evolution

Boris Bachmendo and Rainer Unland

Department of Mathematics and Computer Science University of Essen, D - 45117 Essen

{bachmendo, unlandR}@cs.uni-essen.de

Abstract. In this position paper we propose an approach for the flexible evolution of object oriented workflow implementations using AOP. We show how reusable aspects can apply changes (e.g. insertion of activities or control flow constructs) to OMG compliant implemented processes. Besides aspects providing different workflow auditing methods can trigger necessary alternations. In that way a cyclic workflow improvement can be realized.

1. Introduction

Aspect-Oriented Programming is a new software engineering paradigm which supports a separation of concerns. Concern composition is realized by extending programming language with special constructs: joinpoints (which define relevant points for the insertion of concern-related code in the application class structure), pointcuts (which describe interactions between joinpoints) and pointcut-methods (also known as advises, define action to be performed before, after or instead the invocation a certain pointcut is activated by) [6].

Different perspectives of workflow modelling and implementation, e.g. control flow (execution order), data flow (data interchange) or resources are described in [7]. The applicability of AOP for supporting flexible workflow execution was first identified in [12], that propose implementing these perspective separately using AOP and weaving them together in a workflow application.

Although workflow management arose from automating well structured repetitive production processes, the need for supporting dynamic altering workflows, e.g. in office and scientific areas, is obvious nowadays. [3] distinguish between static workflow evolution, i.e. modifying workflow models, and dynamic evolution, i.e. adapting running process instances. Unlike [12] we propose dynamic evolution of existing object oriented workflow implementations by weaving appropriate aspects. This approach allows the reuse of both adaptation cases realized as aspects (e.g. insertion of control flow constructs) and workflow implementations. At the same time aspects implementing arbitrary auditing methods can be used to control process execution and trigger workflow evolution when necessary.

In the next section we briefly present an object-oriented workflow implementation approach. Possible evolution scenarios of control flow as well as resource and auditing perspective are described in the third section. Section four summarizes the paper and discusses some open issues.

+requester

0..1

+performer

*

+container1

+step* +master

1

+instance of

*

+assignment

*

+activity

1

+assignee

1

+work_list

*

WfExecutionObject

WfActivity

WfProcess WfRequester

WfRessource

WfProcessMgr

WfAssignment

Fig. 1. Simplified Workflow Management Facility Model

2. Object-Oriented Workflow Implementation

First workflow management systems (WfMS) had a highly centralized architecture with a single workflow engine (e.g. FlowMark) or multiple replicated execution units (e.g. MOBILE [7]). But an optimal level of flexibility and scalability can only be provided by a truly distributed object-oriented implementation, where workflows are realized as independent distributed objects. In order to standardize object-oriented WfMS and to make them compliant to Object Management Architecture the OMG proposed the Workflow Management Facility Specification. Since we will explain our approach using this model as a reference, we will briefly outline it in the following.

A simplified version of Workflow Management Facility Model [10] is depicted in Figure 1. WfRequester interface represents a request for some job to be done. WfProcess has to perform the work, inform its requester upon completion and deliver him the execution result. The requester uses WfProcessMgr to create a process instance, i.e. it is a factory and locator for the instances of certain process type. WfExecutionObject is a basic interface which contains common members of WfProcess and WfActivity. While a WfProcess implements an instance of a particular process model, the single process steps are represented by WfActivity. The process creates corresponding activities and defines its context (i.e. input data). The result that is produced by activity can be used to determine the following one. WfActivity can also act as WfRequester, thereby the process it creates becomes a subprocess of its owner. WfResorce represents a resource necessary for activity execution.

3. Workflow Adaptation Using Aspect-Oriented Programming

3.1 Control Flow Perspective

First of all we consider the control perspective and describe how the control flow can flexibly be changed using AOP. Figure 2 depicts the insertion of activities and control flow constructs, defined by the Workflow Management Coalition [14], such as sequence, split, join and iteration. Activity diagrams on the left side show a process fragment, while sequence diagrams to the right represent interactions between objects. Replaced control flows are depicted by dashed arrows in activity diagrams, while interactions contain some special constructs showing interceptions by the aspects.

In Figure 2a an activity (A1) which is an instance of WfActivityA is replaced by the instance of WfActivityB (A2). We assume WfActivityA and

WfActivityB to be subtypes of the OMG-interface WfActivity. In this case we use an aspect that has a pointcut activated by the invocation of an WfActivityA-constructor performed by WfProcess instance P. The corresponding pointcut method is executed instead of the original invocation. In the sequence diagram the original call is depicted as a dashed connector with a transparent dot at the beginning and transparent arrow at the end. Although this call is not executed it should especially be depicted for instead-invocations to clarify what pointcut was activated. The aspectual invocation is depicted by the connector between the caller object and the aspect instance with the black dot on the aspect side. It is labelled with the original method call.

In this case (Fig. 2a) the pointcut-method creates an instance of WfActivityB and returns it to P instead of a WfActivityA-object (we assume the process is handling its activities through the WfActivity interface). The context used for the creation of A2 can differ from the original data. A2 considers P as its owner process and reports it the execution results. Deletion of activities can be realized analogously by replacement by dummy activities.

In Figure 2b a new activity (A2) is inserted between two existing ones and all of them are executed in a sequence. The activity constructor invocation is once again intercepted by the aspect. But in contrast to the first example the pointcut method is executed before the constructor. It creates a new instance of WfActivityB. This activity cannot report its results to the process, because P is not aware of its existence and it would interpret the call as the result of A1. So the result is reported to the aspect and thereafter the intercepted constructer call is executed. The context passed over to A1 can be derived from the A2 result which in that way can influence the rest of the process.

Figure 2c shows an inserted AND-Split between the activities A0 and A1. A single thread of control now splits into two concurrently executing threads [14]: the old (starting with A1) and the new one (A2). In contrast to the previous case the aspect does not wait until A2 is finished before it continues the instantiation of A1. Therefore the context of A1 cannot be affected by A2, whose returning result is omitted since it is not relevant. An OR-Split (i.e. branching into several alternative threads) can be inserted analogously to the activity replacement with the help of an instead pointcut method. The method evaluates given conditions and decides on creating either A1 or A2 (XOR-Split) or both of them.

Multiple threads converge into a single one by using the join construct [14]. The insertion of an AND-join that merges parallel threads is depicted in the Figure 2d. Since the coordination of A0 and A1 is already handled by the process, the aspect has to ensure that A1 can only start after A2 is finished. Therefore one pointcut observes the final call of A2 that return the result and sets an internal flag as soon as it was executed. Another pointcut method intercepts the instantiation of A1 and lets it proceed only after the flag was set. If the converging branches are alternatives (OR-Join) the aspect has to detect the termination of the both, A0 and A2. It has to trigger the creation of A1 at the moment the first of these events occurs and has to prevent the instantiation when the second one takes place.

An iteration (i.e. repetitive execution of a process segment) is added in Figure 2e. Activity A1 is performed repeatedly as long as a certain condition is fulfilled. A before pointcut detecting the result delivery of A1 and starting it again and again, is

P:WfProcess

A1:WfActivityA

Asp:WfAspectA0 A1

A2

A2:WfActivityBWfActivityB(context)

set_result(result)

WfActivityA(context)

Activity

A0 A1

A2

A0 A1

A2

P:WfProcess

A1:WfActivityA

Asp:WfAspect

A2:WfActivityBWfActivityA(context)WfActivityB

(context)

set_result(result)

set_result(result)WfActivityA(context)

P:WfProcess

A1:WfActivityA

Asp:WfAspect

A2:WfActivityB

WfActivityA(context)WfActivityB

(context)

set_result(result)

WfActivityA(context)

A0 A1

A2

P:WfProcess

A1:WfActivityA

Asp:WfAspect A2:WfActivityB

WfActivityA(context)

set_result(result)

WfActivityA(context)

set_result(result)

A0 A1

A2

[condition]

[not condition]

P:WfProcess A1:WfActivityA Asp:WfAspect

A2:WfActivityB

set_result(result)

[condition]start(context)

[not condition]set_result(result)

WfActivityB(context)

WfActivityA(context)

WfActivityA(context)

WfActivityA(context)

WfActivityA(context)

set_result(result)

a)

b)

c)

d)

e)

Fig. 2. Control flow adaptation using aspects.

not appropriate in this case, since it would mean that results are reported repeatedly to the process object, that cannot handle them, since it is not aware of the repetition. So the instead pointcut method is used. It checks the condition (which can be based on the returned result or an independent of A1) and either starts the activity once more or forwards the result of the last execution to the process. After the process object gets this result it instantiates the next activity A2.

3.2 Resources Perspective

Another workflow execution concern where flexibility is an essential requirement is the dynamic assignment of resources to activities. The WfMC differentiates four kinds of resources: human (person), organizational unit, role (e.g. the function of a person within an organization) and system (i.e. automated machine resource) [13]. As proposed in [15] the workflow resource model can be separated into the static meta model, the dynamic assignment rules and access synchronisation mechanisms. Although the frequent changes in the resource meta model are extremely seldom and, therefore, can be realized by redesigning the application, they can also be implemented by using aspectual introductions. It is a mechanism provided by the general purpose aspect language AspectJ [8] that allows extending given types or certain objects with additional member fields and methods.

Much more undecided and, therefore, changeable units are the dynamic assignment rules also referred to as policy resolution. They handle the resource assignment to process activities at runtime. In the Workflow Management Facility Specification of the OMG an object implementing the WfAssignment interface is responsible for linking WfActivity with WfRessource objects. It selects appropriate resources according to the given activity context and other process independent information. Although eligible resources are selected dynamically, the used resolution policy depends on the WfAssignment object the activity is related to. But often the assignment strategy itself has to be changed or extended dynamically. In this case reusable aspects can be used to either replace the assignment objects or extend the activity selection procedure by inserting additional code before or after it. Possible extensions can consider the actual workload (e.g. appropriate aspects can be dynamically added in overload situations) or history dependent assignment either in order to take advantage of personal experience or to ensure equal work partitioning [2]. On the other hand it can be necessary to replace a resource either for all assignments resp. activities (e.g. if an employee is absent and his work has to be delegated) or only for selected ones (e.g. for security reasons). This changes can also easily be realized by adding an aspect intercepting the resource invocations.

The third component of the workflow resource model mentioned above is the synchronisation of the concurrent access of multiple activities to a single resource. Since synchronisation of concurrent threads was the first application of AOP and the main purpose for the specification of the domain specific aspect language COOL [9], the suitability of aspects in this area doesn’t needs no further elucidation.

3.3 Auditing Perspective

Monitoring and logging of workflow executions as well as a comprehensive evaluation of recorded audit trails is an essential part of workflow management, since it closes the workflow development cycle comprising workflow identification,

modelling, implementation, execution and controlling [11]. The main tasks of workflow auditing are acquisition of execution data, its analysis and the utilization of the results. Both acquisition and utilization can be differentiated in short and long term, as well as active and passive approaches.

In the OMG Workflow Management Facility the acquisition of execution data is realized by the WfEventAudit and its subtypes which record certain types of workflow events (e.g. process or activity start and termination, context and result changes etc.). But this scheme means a passive way of acquisition, even if using the OMG Notification Service as proposed in [10], because only events published by workflow execution objects can be received. An active acquiring component can obtain arbitrary information it is interested in. It can be achieved by implementing the acquisition with the help of aspects. In the case of object-oriented (and especially OMG compliant) implementations all the relevant execution events can be detected by appropriate pointcuts. An arbitrary replacement or combination of multiple aspects without any modification of execution objects provides the necessary flexibility. For example the short term acquisition aspect providing an order processing status for a customer can be combined with an aspect implementing a long term history logging.

Using aspects modules implementing different analysis methods for audit data can be dynamically added or replaced. While passive utilization implies simple recording and/or visualisation of the results an active approach intends an intervention in the workflow execution. Long term utilization means changes to the process models that influence all future executions. Short term intervention concerns the current running process instances and can be realized by aspects adding or replacing activities and modifying control flow as described in the section 3.1, or changing the context data.

4 Summary

In this position paper we proposed an approach for the dynamic evolution of workflow instances by using aspects. It allows flexible process adaption and reuse of both the object-oriented process implementation and the adopting aspects. The changes can either be caused externally or triggered by the auditing component that can be realized by aspects too. In that way a cyclic workflow improvement can be realized.

Unfortunately the most implementations of aspect languages only support static aspect weaving at the pre-compile time (a good overview is e.g. offered by [4]). Though if using this languages a workflow has to be restarted, in order to be changed, the aspect-based adaption still allows the reuse of both primary workflow implementation and adapting aspects. Dynamic run-time aspect assignment is desirable, in order to realize automatic improvement cycle. The approaches allowing dynamic weaving are e.g. AOP/ST [1], that makes use of reflective capabilities of Smalltalk, or Aspect Moderator Framework [4], which is implemented in Java and introduces a special design pattern for objects aspects are assigned to. General purpose aspect language Sally [5] is an extension of Java realized by a pre-compiler. It also supports dynamic aspect assignment at the run-time.

Other potential application areas like process error handling are to be examined in the future. An open implementation issue is the aspect realization in distributed environments, which is especially important for workflow management systems.

References

1. Boellert, K.: On Weaving Aspects. In: Proceedings of the Aspect-Oriented Programming Workshop at ECOOP’99.

2. Bussler, Ch.: Policy Resolution in Workflow Management Systems. In: Digital Technical Journal, Vol. 6, No. 4, Maynard, MA: Digital Equipment Corporation, 1995.

3. Casati F.; Ceri S.; Pernici B.; Pozzi G.: Workflow Evolution. In: Proceedings of the 15 the International Conference on Conceptual Modeling, ER'96, Cottbus, Germany. Springer Verlag, Lecture Notes in Computer Science, 1996.

4. Constantinides, C.; Bader, A.; Elrad, T.: A framework to address a two-dimensional composition of concerns. In: Proceedings of the First Workshop on Multi-Dimensional Separation of Concerns in Object-Oriented Systems at OOSPLA'99.

5. Hanenberg, S.; Bachmendo, B.; Unland, R.: An Object Model for General-Purpose Aspect Languages. To appear in the Proceedings of the Third International Conference on Generative and Component-Based Software Engineering (GCSE) 2001.

6. Hanenberg, S.; Unland, R.: Concerning AOP and Inheritance. In: Mehner, K., Mezini, M., Pulvermüller, E., Speck, A.(Eds.): Aspect-Orientation - Workshop. Paderborn, Mai 2001, University of Paderborn, Technical Report, tr-ri-01-223,2001

7. Jablonski, S.; Bussler, Ch.: Workflow Management. Modeling Concepts, Architecture and Implementation. International Thomson Computer Press. London et. al. 1996.

8. Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., Griswold, W.: An Overview of AspectJ. To appear in ECOOP 2001.

9. Lopes, C.: D: A Language Framework for Distributed Programming. A Ph.D. Thesis. College of Computer Science. November 1997.

10. Object Management Group: Workflow Management Facility Specification, Version 1.2. April 2000.

11. Rosemann, M.: Workflow Monitoring and Controlling. In.: Jablonski, S.; Boehm, M.; Schulze, W. (Eds.): Workflow Management. Development of Applications and Systems. Heidelberg 1997, pp. 201-210. (in German).

12. Schmidt, R.; Assmann, U.: Extending Aspect-Oriented-Programming In Order To Flexibly Support Workflows. In: Lopes, C.; Murphy, G.; Kiczales, G.: Proceedings of the Aspect- Oriented Programming Workshop at ICSE’98.

13. Workflow Management Coalition: Interface 1: Process Definition Interchange Process Model. Document Number WfMC TC-1016-P. Version 1.1. October 29, 1999

14. Workflow Management Coalition: Terminology & Glossary. Document Number WFMC-TC- 1011. February 1999.

15. zur Muehlen, M.: Resource Modeling in Workflow Applications. In.: Becker, J.; R zur Muehlen, M.; Rosemann, M.(Eds.): Proceedings of the 1999 Workflow Management Conference “Workflow-based Applications” in Muenster. November 1999.

������������ �����������������������������������! "�$#&%'�(*),+-���!."/0#

132547698;:<69=?>@132?>BADC�EBFHG IKJ?LNMOCP8<87>Q=SRT4<UWVX>Q4ZY[6\>]FBJ?>Q=?R^1">Q47M9UD8`_a?Y�C�=?>bFc�d >eYZ2J5>QfhgD>Q4ZY[6\>5JbM9a?Y[Ci=?>TjQk06O=5fml n5aSYHop4<69U?l q54

rWs�tPuwvDxDymz7{3|Q}Z~�zZ�]}Zz"�`zZvb�[{�ymuwzZ�KyH�D��tP�Kym~��b}H����s��[ym�]tP��~�}!�"�D~��Pz7{m��~�y���ti����~�tw�Dz!�P�i�]z7~�{mte���~�tX�Dz��B���]zZ~�{mte�T�${;���Z~��h���s�tiuwv]xeymz7{3|e}Z~�zZ�D}Zz��`zZv]��{�ymuwzZ�KyH�e�]zZ�Dz7{;���S�3�]~��Bz7{m��~�y���t�����i�D~��e�T���i�]~��Q�T�${;���Z~��h�

�' �¡Z¢Z£[¤b¥i¢P¦X§ ��ym�]~��"v]�ivTz7{H�]¨�z!{mzZvTti{�y"��tPuwz!~��]��~�©P�Kym�`}Zti����z7}7ymzH�@�Dxe{m~��D©wym�]z!~�uXªvD��z7uwzZ�Ky;��ym~�tP�Wt��«ym�DzN¬Q­i®B¯Q°B±[²e°i®K³��p�D�pymz7u´�bx]��~��D©�µTt�ym��¶3��vTzZ}7y;�'���b�W·3�evTz7{<¸��D��]�[�Q~��]©X�i���¹�py;��{�ym~��D©XvTtP~��Ky3�i�´����vTzZ}7y�ªºti{m~�zZ�KymzH���DzZ��~�©P��uwtQ�DzZ�»�b¼"�]z`t���ym�]z`uwt�ªym~��i��ym~�tP�D��µTz7�]~��b�'ym�]~����DzZ�Bz7��tiv]uwzZ�Ky½z<¾Dz<{m}Z~���z�~����¹ve{;�i}7ym~�}H����������zZ����uwzZ�Ky�ti�zH��}<���v]vD{mtP�i};�S¿ �"��~�uw~�����{m~�ym~�zZ�`���b�W�e~�À5z<{mzZ�]}Zz7�Z�b�py�{mzZ�D©iym�]�3�i�]��¨�zZ�iÁQ�]zZ����z7�3ymtw�]z7��vW~��ym�Dz¹�i�i��~��]��ym~�ti�-t��½�'©PzZ�Dz7{m~�}X�i��vTz7}7y�ªºµb�i��zZ�-�ezZ��~�©P��uwtQ�ezZ�Âym�]��y�}H���@µTz¹u'�ivDvTzH�ymt¹ym�Dz`~�uwv]��zZuwzZ�Ky;�[ym~�ti��uwtQ�ezZ���½��x]v]vTt�{�ymzH��µK��¶3��vTz7}7y;�w�i�]��·3�evTz7{<¸��D�

à Ä]Å�ÆTÇ5È�É0ÊNËÂÆ5ÌmÈ�ÅÍ 25CÎ6\RTC�=]:<6OÏSYi>K:<69Ue=Ð>e=?RÑ8m:74<aSYH:<a?4<69=5gÒUQf'8<UQf»:mÓ`>Q47C^Y[UeÔ´nÂUe=5Ci=]:78iJ3Y[47UD8787Y[aT:<:<69=5gÒ>e8<nSCPYH:78iJ>Q=?RÕ:<2?C�694'4<CiM9>Q:<69Ue=?8<2569n?8w>Q47C´Ci878;Ci=]:<6\>QM�:7>D8;ÖT8X69=×Ue4ZRTC�4X:7U^n54<UTRTaSY[C´C[Ø�CiY[:<69AeC�M9ÙÚ47C�aS8<>eq5MOCY[UeÔ´nÂUe=5Ci=]:78!>e=?R->D8;nÂCiY[:78il?Û!UKÓ"C�ADC�4PJ]:<25CP8;CX:Z>e8<Öb8�>e4<Cw=?UQ:�:<4769A]6\>QM>e=?R�Y[UD=?8;CPÜ]a5C�=]:<M9Ù@47C[oÜDa?6O47CÎ>ÝRT6\8<Y�6On?MO69=5CiRÞR5Ci8<6OgD=Ñ>en5n547UD>DYZ2ß>D8WÓ3CiMOM¹>e8@8<a56O:7>eq5MOCÚ6OÔ´n5M9C�Ô´C�=]:Z>K:<69Ue=Ñ:7UbUeM\8�láà�=:<256\8�Y�Ue=]:<C�â]:PJ�:mÓ"U^4<CP8;CP>Q4ZYZ2�>DYH:<69Ab6�:76OCP8'Y[UD=?Y[Ci4<=?CiRÕ:<U^Ô�a5M�:76�o�RT69Ô´C�=?8<6OUD=?>QM38;Cin?>Q4Z>K:76OUD=ÕUefY[Ue=SY[C�47=?8'ãåäÎæXçbUb1`è0>Q47C'Y[a54747C�=]:<M9Ù-qÂC�69=5g-25C�M\R�Ó�6�:72569=Î:<2?C�çbUef»:mÓ">e4<C'é�=5ge69=5C�Ci4<69=5g@_$>QqToUe4Z>K:<UD4<ÙÒãå_«é3ç?è0>Q:'ê�ë¹1�o�ì�69U?í½ãh6»èN:<25C@>D8<8<Ci878<Ô�Ci=]:¹>Q=SRÚCiAB>eMOaS>K:<69Ue=ÕUQf`>Qn5n5M9Ùb6O=?g�>D8;nÂCiY[:;oUe476OCi=D:7CiR^RTCP8;69ge=Õ>Q=?R^n?4<UDge4Z>QÔ´Ô´6O=5g´:7CiYZ25=?69Ü]a5CP8!:7U@:<2?C�RTCP8;69ge=Ú>e=?R^69Ô´n5MOCiÔ´C�=]:7>Q:<69Ue=ÎUefÔ�a5MO:<6Oop>egeCi=D:�UDqTîmCiY[:;opUe476OCi=D:7CiR�8;Uef»:mÓ">e4<CDJT>Q=?R×ãh696»è":<25C'>D8<8<Ci878<Ô�Ci=]:�>e=?R-C�AK>QM9a?>K:76OUD=�UQf�:<25C8m:74<Ci=5gQ:72?8!>Q=SR�Ó3CP>QÖb=5Ci878<Ci8`UQfá>en5n547UD>eYZ2?Ci8`>Q=?R�:7UbUeM\8`:<2?>Q:08<a5n5nÂUe4<:0äÎæXçbUb1Ð:<U�25C�M9n^6O=:<25CwAK>QM96\R5>K:76OUD=-Uef�>�geCi=5C�476\Y0>D8;nÂCiY[:;opq?>e8<CiR�RTCi8<69ge=�Ô�UTRTCiMa5=?R5C�4!RTCiAeC�M9Uen?Ô�Ci=]:il

L!=ïa5=56OfhÙb6O=?g�8;a?qTîmCiY[:ÚUQfW8m:7a?RTÙðfhUe4^:725Ci8<Cñ>DYH:<69Ab6�:76OCP8^6\8^:<2?CñRTC�ADC�M9Uen5Ô´Ci=D:ÎUef´:<25CòTóDôbõ5öT÷Kø?öDô5ù 8<ÙT8m:7C�Ô,ú ûeü�JS>´Ó3CiqTo�qS>e8<CiR-C�=bAb6O47Ue=5Ô´Ci=D:�:72?>K:¹>Qn5n5M969Ci8�gD4<UDa5nbÓ">e4<CXY[UD=?Y[CinT:786O=ÝUD47R5C�4X:<U�8;a?n5nSUD4;:�>^RT6987Y[69n5M96O=?CiRÝ>en5n547UD>eYZ2ÕfhUe4�:<25C�Y[UD=?8m:74<aSYH:<69Ue=Ò>e=?R×ÔW>Q=?>egeC�Ô´Ci=D:UQf0C�opY�UeÔ´Ô´C�4ZY[C-nSUD4;:Z>QM\8�láçbUef»:mÓ">e4<C�>QgeCi=]:78�Ó3Ci4<C-6O=]:74<UTRTa?Y�CiRý6O= ò5óDô]õ5öT÷Qø?öeô5ù :7UÒ>e878;6\8m:6�:Z8!a?8<C�4Z8�Ó�6O:<2�:<69Ô´C[o�Y[UD=?8;a?Ô�69=5g@>DYH:<69Ab6�:76OCP8!>Q=SR�:<U@>Qa5:<UeÔW>Q:<Cw47C�nÂC[:<6O:<69AeC�a?8;Ci4�:7>D8;ÖT8il?L!=6O=5=?UKAB>Q:<69AeC!>D8;nÂCiY[:;opq?>e8<CiR´>QgDC�=]:áÔ´UTRTC�MÂn547UenÂUD8<CiR�6O=Îú þBüÂÓ">D8á>Qn?n5MO69CiR´69=´:<2?CNCi>e4<M9Ù�R5Ci8<6OgD=UQf�:<25C òTóDôbõ5öT÷Kø?öDô5ù 8;ÙT8;:<C�Ô�JT:7U�>QM9M9UKÓÐ:<2?C�8<C�n?>e47>Q:<69Ue=�>Q=?R d C�âb69q5M9C'69=D:7C�gD47>Q:<69Ue=�UQf�Ô�a5MOo:<69n5MOCW>D8;nÂCiY[:78¹UQf`>QgeCi=]:<25UbUTR�J�8;aSYZ2Õ>e8¹69=]:<C�4Z>eY[:<69Ue=J�>eaT:<UD=5UeÔ�ÙeJ�>eR5>enT:7>Q:<69Ue=Ú>e=?RÕUQ:<2?C�4Z8�lä^Ue47C�UKADC�4PJ$>Q=ßC[âTn5M9Ue4Z>K:7Ue47Ù×6OÔ´n5M9C�Ô´C�=]:Z>K:<69Ue=ýfhUe4 ò5óDôbõ5öb÷Qø?öDô5ù a?8<6O=?g×L08;nÂCiY[:7ÿÞú �Kü!Ó`>e8RTC�ADC�M9UenÂCiR�l?çbUDÔ´Cw6O=]:<Ci4<CP8m:76O=?g�47Ci8<a5MO:78`2?>BADC0qÂC�Ci=�fhUea5=?R�>e=?R-R56987Y[a?878<CiR�C�M\8;CiÓ�25C�47C´ú �Qü�l

Í 25C!47Ci8<a5M�:76O=?g�>e8<nÂCiYH:<o�qS>e8<CiRWRTCP8;69ge=WÔ´UTRTC�M�ãh2?6OgD25MOÙ´69= d a5Ci=?Y[CPRWqbÙ�:<25C¹LN8<nSCPYH:7ÿ�n547UQoge4Z>QÔ´Ô´6O=5g-Ô´UbR5C�M»èX>Q=?RÎ:<25CWLN8<nÂCiYH:Zÿ��Q8m:Z>Q=?R?>Q4ZRÚÿ]>BAB>-Y[UTRTC´Ó"C�47C�47C�a?8<CiRÚ6O=Õ:<2?C�69Ô´n5M9C[oÔ�Ci=]:7>K:76OUD=�Uef ò5óeôbõ5öT÷Qø5öDô5ù Ó�6O:<2´Û!ÙbnÂC�4��Kÿ´ú����[üpJP>N:<UbUDMD:72?>K:á8<a5n5nÂUe4<:78�Ô�a?M�:76�o�RT69Ô�Ci=?8<6OUD=?>QM8;Cin?>Q4Z>K:76OUD=�>e=?R�6O=]:7C�ge4Z>K:76OUD=�UQfáY[UD=?Y[Ci4<=?8!6O=Î8;:7>e=?R5>Q4ZR�ÿD>BAK>W8<UQf»:mÓ`>Q47Cel Í 2?C�>eRTUDnT:<69Ue=�Uef>Q=×>e8<nSCPYH:;opq?>D8;CPRÚRTCP8;69ge=�Ô´UbR5C�Má8<a5n5nÂUe4<:78XUea?4wqSCiMO69C[f":<2?>Q:X:<25CWq?>D8;C�op>D8;nÂCiY[:XR569YZ25Ue:<UDÔ�Ù8;69Ô´n5MO6OÏ?CP8!Y[UD=?Y[Ci4<=Topq?>D8;CPRWÔ´UbR5a5M9>e4<6O:mÙÚú��Qü�l

¶3��vTzZ}<y;� ·��DvTz<{<¸i�s${mtP����}Zxey�ym~��]©X}Zti�]}Zz<{m� �i��vTzZ}<y �K�DvTz<{m����~�}Zzs�tPuwvTti��~�ym~�ti�¨á�]z7{mz ��tP~��WvTtP~��Ky }Zti{�{mzZ��vTti�b�e~��D©Xx]�D~�y�]tH¨ uwz<{m©Pz�µTz7�9ti{mzP�b���9ymz<{H�T��{mtix]�]� uwz7{m©izP�Dt��Pz7{�{m~��Dzs�tPuwvTti��~�ym~�ti�@|evTzZ}7~��]}H��ym~�ti� ~��D��~��Dz!�i��vTz7}7y tixDym��~��Dz��K�evTz7{m����~�}Zzs�tPuwvTti��~�ym~�ti�W�{mz7}ZzH�Dz7�]}Zz �p�Dtiuw~��b��ymz7�� ��t�{;�Dz7{� ~�uwv]��~�}Z~�y�{mxD��zZ� �K�evTz7{m����~�}Zz!�Dz7}Z����{;��ym~�ti�s�tPuwvTti��~�ym~�ti����~�uwz }ZtPuwvD~���z<ªºym~�uwz }ZtPuwvD~���z<ªºym~�uwz

� ¤] ������]¦ s�tPuwvb�[{m~��]©w¶���vTzZ}7y;�w�i�]��·��DvTz<{<¸i�

Í 25C�n54<69ÔW>Q47ÙÝn5a547nÂUD8<C�Uef0:7256\8WÓ3UD4<Öñ698�:7UÒ4<CinSUD4;:@8<UeÔ´C�6O=?8<69ge2]:78WÓ"C�2?>BAeC�gDUQ:W6O=6OÔ´n5M9C�Ô´C�=]:76O=5gÚ:<25C�87>QÔ´C�>Qn?n5MO6\Y�>Q:<69Ue=J$:<2?C ò5óDôbõTöT÷Qø?öDôTù 8<ÙT8m:7C�Ô�J�a?8;69=5gÎqÂUQ:72ýL08;nÂCiY[:7ÿ>Q=?RÒÛNÙ]nÂC�4��KÿSJ2?>BAb69=5gÚ>D8'>Î8;:7>Q4<:<69=5g^nÂUe69=]:�>Q=Ò>D8;nÂCiY[:;opUe476OCi=D:7CiR×RTCP8;69ge=ÒÔ´UTRTC�M�l«à�=Ý:<25CfhUeM9MOUKÓ�69=5gÝçbCiY[:<69Ue=J3Ó3CÎR5Ci87Y[476OqÂC�:<25CÚÔ´>en5n569=5g×fh47UeÔ�:725CÚ>D8;nÂCiY[:;opq?>e8<CiRßRTCi8<69ge=ÑÔ´UbR5C�M:<UÕÛNÙbnSCi4��QÿÎ>Q=?RñRT6987Y[aS8<8':<25C-6O=?8<69ge2]:78�Ó3C@2S>BAeC@g]>K:<2?C�47CiRÒRTa54769=5g^:<2?C@:<4Z>Q=S8mfhUD4<ÔW>K:76OUD=n54<UTY�Ci878�l� ��Ç?È�� � �"!$#«ËÂÆ%�×ÆTÈ'&)(*!$#Ç+��,;Ì<Ë-#.�Í 25C"L08;nÂCiY[:7ÿXn547UegD47>eÔ´Ô�69=5g!Ô´UTRTCiMb8<a5n5nÂUe4<:78$:725C3qS>e8<C[o�>e8<nSCPYH:�R569YZ25Ue:<UDÔ�ÙelQ1347UD878<Y�aT:;:76O=5gY[Ue=SY[C�47=?8�>Q47CÕÔ´UTRTa5M\>Q4769E�CiRÐq]Ù0/2143%57698:1Hl013UeÔ´nÂUD8<6�:76OUD=�qÂC[:mÓ"C�Ci=�q?>D8;C×>Q=?Rð>e8<nSCPYH:Z8-6\8RTC[Ï?=?CiR@69=W:7C�47Ô´83UQf$q?>e8<C[op4<CiM9>Q:<CPR<;9=?>A@B3+=2>A@+8C1!ú �Qü�l?1347UD878<Y�aT:;:76O=?g'qSCi2?>BAb6OUD43Yi>Q=@qÂC0>DR5RTCiRD 5CE�=2FG5[J+/HE78I59FUe4J/2FK=?LM@ONîmUe69=�nÂUe69=]:78ilK13UDÔ�nÂUD8<6O:<69Ue='6\8�RTC[Ï?=?CiR'69=?8<69R5C3>e8<nÂCiYH:Z8�lBêá47CiY�CiRTCi=?Y[C>QÔ´Ue=5g->e8<nSCPYH:78N698047Ci8<UeM9AeCiR�69Ô´n5MO6\Y[6O:<M9ÙÒãhqÂC[fhUD4<CDJÂ>Qf»:<C�4PJS>e4<UDa5=?R�47a5M9Ci8Zè�Ue40C[âTn5M969Y�6�:7MOÙ×ã»:725CNP=2QR>A@O/?8I5�1�Y[M\>Qa?8<CPè[lÛ!ÙbnSCi4��Qÿ´8;a5n?nSUD4;:Z8�Û!ÙbnSCi478<n?>DY[Ci8Xú��P��ü�JT>Q=�C�ADUeM9aT:<69Ue=-Ue=-:<25CwCP>Q47MOÙWÓ"Ue47Ö´Ue=�8;a?qTîmCiY[:;o

Ue476OCi=D:7CiR�n547UegD47>eÔ�Ô´69=5gWãåç+S¹ê"è�úUTPü?:72?>K:"RTUbCi8á=?UQ:�=5CPY[CP8<87>Q476OM9Ù�R5698;:<69=5gea?698<2WqSC�:mÓ3CiC�=Wq?>D8;C>Q=?RÒY�4<U]8<87Y[aT:<:<69=5gÎY[UD=?Y[Ci4<=S8�l$13UD=?Y[Ci4<=?8�>Q47CWÔ�UTRTa?M9>e4<69E�CPRÕaS8;69=5gWVMXG3%59F71�YZ>:675�1Hl�13UeÔ´nÂUD8<6�o:<69Ue=Ú47a5M9Ci80>Q47C�RTC�Ï?=5CiRÚ6O=Î:<C�47ÔW8¹UQf<67=2F�FK5�143%=?@ON?>A@"[\LM@]>A8:1wú��P�[üpl Í 25Ci8<C�a5=?6�:Z8¹>e4<C�4<CiM9>Q:<CPRq]Ù^QB59FC["5`Ue4R=2_25�F�F�>:N�5!47C�M\>K:76OUD=?8;2?6On?8ilS13UeÔ´nÂUD8<6�:76OUD=-6\8!RTC�Ï?=5CPR�6O=?R5C�nÂC�=?RTCi=]:<M9Ù�fh47UeÔ :<25C2]ÙbnÂC�4Z8;M96\Y[Ci8il?ê�4<CPY[CiR5C�=?Y�CX>eÔ´Ue=5g´2bÙbnSCi478<MO6\Y[CP8�6\8�4<CP8;UDMOADCiR-C[âTn5M969Y�6�:7MOÙ×ãºR5CiY[M\>Q4Z>K:76OUD=-Uef½2]Ù]onSCi478<MO6\Y[CP8N69=^:725C�2bÙbnÂC�47Ô�UTRTa?MOCDJ?:725C`=?FKNP59FNY[M\>QaS8;CBèHl Í >eq5MOCa��8<a5Ô´ÔW>Q476OEiCi8�:725Ci8<C�YZ2S>Q4Z>eYHo:<C�476\8m:769Yi8�lb C32?>BAeC">eRTUDnT:<CPR'>N8<6OÔ´n5M9C38<C[:�UQfT:747>e=?8;fhUe47Ô´>Q:<69Ue=w47a5M9Ci8iJ�q?>D8;CPRwUe=�ãº6\è$47C�Ó�476�:76O=?g!Ci>DYZ2

>e8<nSCPYH::7U!Ue=5C�Ue4Ô´Ue47CáY[M\>e878<Ci8�Ci=?Y�>en?8;a?M9>Q:<CiR¹qbÙX>!8;Cin?>Q4Z>K:7C�2]ÙbnÂC�4Z8;M96\Y[CeJ]ãh696\è�:<4Z>Q=?8;fhUe47Ô´6O=?g>eRTAb6\Y[C`Y[UTRTC`6O=]:7U0UD47RT69=?>e4<ÙXÔ´C[:725UTR�Y�UTRTC">e=?R�ãh696O6»è�>eRTUDnT:<69=5g0:<25CcQ�5�FC["57d*X9ef/2Q�5½geCi=5C�4Z>QMY[UeÔ´nÂUD8<6�:76OUD=ß8;:<4Z>K:7C�gDÙel Í 256\8@RTCiY�698<69Ue=ßÓ">D8´256OgD25M9ÙÝ6O= d a5C�=SY[CiRßqbÙÒ:725C�fº>eY[:W:<2?>Q:�8;UDÔ�CY[Ue=S8m:74<a?Y[:78¹fh47UeÔ ÛNÙbnSCi4��Qÿ^>Q47C�ADC�47Ù^MO69Ô´6�:7CiRÞãhfhUe4wC[â5>eÔ�n?MOCDJ�:<25C D FK/P67g�5�8"RT6O47CiY[:<69AeC F è¹Ue4=5UQ:�>BAK>e6OM\>Qq5M9CWÙeC�:-ã»:725ChQ�59FC[�5�Y[UDÔ�nÂUD8<6O:<69Ue=Ò47C�M\>K:<69Ue=S8;2569n�:<UÎqÂC�aS8;CPR×Ó�6�:72Ò:<25CW5Gi9L+/28�54<CiM9>Q:<69Ue=?8<2569nSè¹ú����[üplj�kCl man mpoq�r�s?t�u vxwOy:z{t|Cw]nÍ 25C0L08;nÂCiY[:7ÿ�8;UDMOaT:76OUD=�Y[UDÔ´n54<6\8<CiR�}'UKADC�47M9>en5n569=5g'>e8<nÂCiYH:Z8Nãºà�=D:7C�4Z>eY[:<69Ue=JbL!aT:7Ue=5UDÔ�Ù´>Q=?RLNR5>enT:7>Q:<69Ue=Sè�>Q=?R@>eMOÔ´U]8m:�þ?'Y�M9>D8<8<Ci8il Í 25CNfhUeM9MOUKÓ�69=5g'69=56O:<6\>QM�Y[UD=?RT6O:<69Ue=@25CiM9RJ]8<6OÔ´n5M96OfhÙ]69=5g:<25CX:747>e=?8mfhUD4<ÔW>Q:<69Ue=�n?4<UTY[CP8<8iír ���]z�~G�I���H���K���e~�{mz7}7ym~��Bz"{mzZ��zZu0µ]��zZ�½ym�]z"µTz7�\t�{mz[¸i�[�9ymz7{`�P�D�Q~�}Zz�}Zti�]�py�{mxD}7ym�½�9{mtPu ¶���vTzZ}7y;�D�

� Í 25C'ÿ]>BAB>�8<Uea54ZY[C0Ï?M9Ci8�Ó"C�47Cw>BAB>e6OM\>Qq?MOCX>Q=?R�Y[UDÔ´n56OM\>Qq?MOCDl� é�>DYZ2�>D8;nÂCiY[:��KY�M9>D8<8"Ó`>e8`RTC�Ï?=5CiR�69=^>�8<C�nS>Q4Z>K:<C0Ï?M9Cel� éáADC�47ÙWnSUD6O=]:7Y�aT:!a?8<CiR�Ue=?MOÙW:725C\�;C�âTCiY[a5:<69Ue=?8G��n?4<69Ô´6�:76OADC¹nÂUe69=]:7Y�aT:il�0� UD40CP>eYZ2Ú>D8;nÂCiY[:¹RTC�Ï?=56O:<69Ue=J�=5U-qSC�fhUe47C��K>Qf»:<Ci4¹>DRTAb69Y�Ci80Ó3Ci4<C�R5C[Ï?=5CPRÎUKADC�4!:725C´8<>eÔ�CnSUD6O=]:ZY[aT:N>e=?R-:<25Ci4<CXÓ"C�47C¹=?U´>e4<UDa5=?R�>eRTAb6\Y[CP8�l

j�kAj ����r����2�%n{o��Iw+�2���%t|:wOnLï8;C�:!UQf«:747>e=?8;fhUe47Ô´>Q:<69Ue=-4<a5M9Ci8`Ó"C�47Cw>Qn5n?MO69CiR�fhUeM9MOUKÓ�69=5g�:<2?C'8m:7C�n?8�RTCP8<Y�4<69qÂCiR�qSCiMOUKÓwí�el!çbC�nS>Q4Z>K:<C¹Ï?M9Ci8`Ó�6O:<2^8;:7>e=?R5>Q4ZR�ÿD>BAK>�Y[UTRTCXfh47UeÔ Ï?M9Ci8`Ó�6O:<2^L08;nÂCiY[:7ÿ@Y�UbR5C I l� lN134<CP>K:7C�>@=5CiÓ Ï?M9C�l 2?8�ãº2bÙ]nÂC�4Z8<n?>eY�CwÏ?M9CPèHJ�RTCPY[M\>Q476O=5g@:<25C´Y[M\>e878!=?>eÔ´Ci8�:72?>K:¹Ó�6OM9M�MO69AeC6O=�:725Cw2bÙ]nÂC�4Z8<n?>eY�Cel

}5lN134<CP>K:7CX>�=5CiÓ�ÏSMOCWl 25Ô�ãº2bÙ]nÂC�47Ô´UTRTa5M9C0ÏSMOCBèHlû?l � UD4�Ci>eYZ2�>e8<nÂCiYH:��<�H�K�����P�H�Õ>Q=?R� �¡� ��Ó�6O:<2�25CP>eRTCi4ö+¢�£?ù%¤Kõ �<�¦¥�§ ó�¨{©ª?öDõ5ù+¢ �J«�¬ ó"­ðùbö+¤�®?ó?¯+°bù+¤Kõ²±©�ª-¢KõTö?ª-¤Kùbó"­�±K³�´5ö�¨Sù]µ"µãº>Dè�1347Ci>K:7Cw>�nS>eYZÖK>QgDC0=?>eÔ´CiR��¶�ãhqSè^1347Ci>K:7Cá>"Ï?M9C½=?>QÔ´CiR$�<�I�QY[UD=?Y[Ci4<=?8il Y[ÔÐY[UD=]:7>Q69=569=5g?í £?ö+¤2·Tö�¸5ù �¶�*¹º�¶�P»�¼ ùDô"ª?ùT÷þTl�æNCPY[M\>Q47CX6O=�:<2?CXÏ?MOCWl 25Ôãº>Dè Í 25C\�<q?>e8<C��2bÙ]nÂC�4Z8<MO6\Y[CãhqSè Í 25C!2bÙbnÂC�4Z8;M969Y�Ci8½� � l ¾XC�47=5CiMåJKfhUD4áCi>DYZ2W>e8<nSCPYH:�� � �K���¿���H��>Q=?R� \¡� �ZJeY�Ue=]:7>e6O=?6O=5g

ö+¢�£?ù+¤Bõ � � ¥�§ ó�¨{©�ª?öeõ5ù+¢ � « ¬ ó�­ ùbö%¤�®?óP¯+°]ù+¤Kõ½±©ª-¢Kõ5ö2ª-¤QùbóP­²±G³P´5ö�¨�ù+µ"µÓ�25Ci4<CDJT6�f²À © § ó�¨.©�ª?öDõ5ù%¢ À ° Jb:<25Ci=\� � l ¾XCi4<=5CiM�698�R5CiY[M\>Q47CiR�>Kf»:7C�4�� « l ¾XCi4<=?C�MÂÁKlãåYiè Í 25CwgDC�=5Ci47>eM�Y�UeÔ´nÂUD8<6�:76OUD=�8;:<4Z>K:7C�geÙ�í ¨�ùDô"¸5ùPÃMÄ�´Tö�¨�ù�5l � UD4�Ci>eYZ2�>e8<nÂCiYH:��<�H�K�����P�H�Õ>Q=?R� �¡� �38<a?YZ2-:<2?>Q:ö+¢�£?ù%¤Kõ �<�¦¥�§ ó�¨{©ª?öDõ5ù+¢ �J«�¬ ó"­ðùbö+¤�®?ó?¯+°bù+¤Kõ²±©�ª-¢KõTö?ª-¤Kùbó"­�±K³�´5ö�¨Sù]µ"µãº>Dè�1347Ci>K:7Cw>�ÏSMOCw=?>eÔ´CiR��¶�I� ³�ª?ö�¨�ù l î;>BAB>�>Q=?R�RTCPY[M\>Q47CXY�M9>D8<8 ³�ª?ö�¨�ù 69=�6�:ãhqSè^13UenbÙ@69=]:<47UTRTa?YH:76OUD=?8"fh47UeÔ >D8;nÂCiY[:¶�¶��:<U@Y�M9>D8<8 ³�ª?ö�¨�ùãåYiè � UD4�Ci>DYZ2-nÂUe69=]:7Y[a5:�:<2?>Q:NY[Ue=]:Z>Q69=?8 ù�ÅTù+¤�ÆTõ-©KóPª-¢.±KÇW¨�ùDõ�®?ó § ´5ö�¨�ù]µ J6ål�æ0C[Ï?=?C'=5C�ÓðÔ´C[:<2?UbR�Ô´C[:725UTR%ÈN>eÔ´CwÓ�6�:72�qÂUTRTÙaÉðRTC[ÏS=5CiR�69=-:725C'>eR5A]6\Y[C

696ål`àpf½>eRTAb6\Y[CwRTC�Ï?=5CiR�UD=�nÂUe69=]:7Y�aT:!698 ¯?ù"­TóDôTùæ0CiY�M9>e4<CX69=-:725CXÏ?M9CWl 2?ÔóDô § ùeô ö+¤Kõ-©KóPª À © »�¼ ùDô"ª?ùT÷ » ³"´5ö�¨Âù » ¨�ùeõ�®?ó § ´Tö�¨Âù

¯?ù"­Tóeô5ùÞö+¤Kõ-©KóPª À ¸5ùPªbõ »�¼ ùDô�ª?ùT÷ » ³�´5ö�¨�ù » ¨�ùQõ"®?ó § ´Tö�¨�ù�Ê6O696ål`àpf Í ¡�ÒADUe6\R�J[Y[47Ci>Q:<Cá>�8<a5Ô´ÔW>Q47Ù�fha5=?Y[:<69Ue='>Q=SR¹R5CiY[M\>Q47C ¢eùDõ¿¢�Æ?¨�¨�öDô�ÄË­PÆ�ª-¤Kõ-©KóPª69=�:<25CXÏ?M9CWl 25Ô�lj�kÂÌ man Í�Î�q�r"�?ÏMuÐv.w]yCz.t�|:wOnÍ 25C`4<CP8;a5MO:<69=5gX8;UDMOa5:<69Ue=�69=´Û!ÙbnSCi4��QÿNÓ`>e8�8;:<47a?YH:7a547CiR'69=´>Q=�2bÙbnÂC�4Z8;n?>DY[C"Ó�6�:72�fhUDa54½RT69Ô�Ci=To8;69Ue=?8�ãºL!gDC�=]:iJ�à�=D:7C�4Z>eY[:<69Ue=J�LNaT:<UD=5UeÔ�ÙeJ�L0R5>Qn5:7>K:76OUD=SèHJ[fhUea54ÔW>e6O=w2bÙbnSCi478<M969Y�Ci8½ãºLNgeCi=D:Pl ¾XCi4<=?C�M�Jà�=D:7C�4Z>eY[:<69Ue=l ¾XC�47=5C�M�JSLNaT:<UD=5UeÔ�Ùel ¾XC�47=5C�M�J�LNR5>enT:7>Q:<69Ue=l ¾XC�47=5C�M»èHJ�>Q=Ú2]ÙbnÂC�4Z8;nS>eY[C�Ï?M9CeJ�Ue=5CY[Ue=SY[C�47=�Ô´>en�Ï?MOC`fhUD4áCi>DYZ2�R56OÔ´C�=S8;69Ue=JD>Q=´2bÙ]nÂC�47Ô´UTRTa5M9C`Ï?MOC!>e=?R´>X8;C�:áUQf�8m:Z>Q=?R5>e47R�ÿ]>BAB>Y[M\>e878;CP8�l�é�>DYZ2Õ8<Uea54ZY[CW>D8;nÂCiY[:¹ÏSMOC´Ó�6O:<2Ò>Q=×LN8<nSCPYH:ZÿÎ>e8<nSCPYH:'RTCPY[M\>Q4Z>K:<69Ue=Õ2?>e8XgDC�=5Ci47>Q:<CPRUe=5C'UD4NÔ´Ue47C'ÿ]>BAB>WÏ?MOCP8�JÂRTC�nÂC�=SRT6O=?g�Ue=�:725C�47CiÜ]a56947C�Ô´C�=]:78!UQf�RTCPY[M\>Q4Z>K:<69AeC'Y�UeÔ´n5M9C[:7C�=5CP8<86OÔ´nÂUD8<CiR�qbÙ�Û!ÙbnÂC�4��KÿSl� ���]z�t�{m~�©i~��b�i�?�b��zZ�½¨á~�ym�´�py;�i�]�]�[{;�´�B�H�P�N¨�z7{mz��Dtiyá{mz7¨½{m~�y�ymzZ�S�Ñ �]ti{�t[�Bz7{m����v]v]~��D©¹ym�D{mtix]©P�����Oymz7{`�i�D�Q~�}ZzZ�Z�

j�k�Ò Ó`|:o�sPz�oo�|:wOn

çbÖb6On5nÂC�4Xú��Kü�Y[UDÔ�nS>Q47Ci8á8<a5qTîmCPYH:;opUe4769C�=]:<CPR´n54<UDge4Z>QÔ´Ô´6O=?gX>e=?R@>D8;nÂCiY[:;opUe476OCi=D:7CiR�n547UegD47>eÔ�oÔ�69=5gß>Q=?RÐR54<UDn?8@69=]:<C�47Ci8;:<69=5gñY�Ue=?Y�MOaS8;69Ue=?8-8;2S>Q47CiRÑqbÙß:<256\8-R5C�AeCiMOUDn5Ô´C�=]:�C�âbnÂC�4769Ô�Ci=]:il� Ue4�C�â5>QÔ´n5M9CeJb:<2?C'q?>e8<C[o�>e8<nÂCiYH:�RT6\YZ25UQ:7UeÔ�ÙeJTÓ�6O:<2�C[âTn5M969Y�6�:NR5C�nÂC�=?RTCi=?Y[Ù-Ue=^8<UeÔ´C��;q?>D8;C��Ó�25UD8<C�ADUbYi>Qq5a?M9>e4<Ù-698X8<2?>Q47CiR^>eÔ�UD=5g@:725Ch�7>e8<nSCPYH:Z8K�?JSÔW>BÙ�qSC�4<CigD>e47RTCPR^>e8¹>�RT6\87Y[69n5MO69=5C:<2?>Q:�ÔW>BÙÑ8;69Ô´n5MO6OfhÙÑ:<2?CÕRTCiAeC�M9Uen?Ô�Ci=]:-UQf�äÚæ¹çbUT1�8<UeM9aT:<69Ue=?8iJ�CP8;nÂCiY�69>eMOM9Ùß:<25C�47a5MOCP8@UefY[UeÔ´nÂUD8<6�:76OUD=l

_«>Q6�JSäÎa54<n?2]Ù^>e=?R b >QM9ÖeC�4�ú ÔQü�R5Ci87Y[476OqÂC�>e=ÎC[âTnÂC�476OÔ´C�=]:¹Ó�6�:72ÕÛ!ÙbnÂC�4��Kÿ�>Q=?RÚRT6987Y[aS8<88;UDÔ�C¹Y[UTRTC¹4<CP8m:74<aSYH:<a?4<69=5g�aS8;CPRW:<U�C�=S>Qq5M9C!:725CwY�>Qn5:<a5476O=?g�>Q=SR�Y[UDÔ´nSU]8;6O:<69Ue=@Uef$Y[UD=?Y[Ci4<=S8�là�=-:7256\8�C[âTnÂC�476OÔ´C�=]:PJ5Ó3CX2?>BADC¹8<2?>e4<CPR�qÂUQ:72-:725Cw47C�nÂUe4<:<CiR-qÂC�=5C�Ï5:780>Q=?R-MO69Ô´6�:Z>K:76OUD=?8�n547C[o8;Ci=D:7CiRýã;ú ÔKüpJ�8<CiY[:<69Ue=ÎûSl � èHJ�>QMO:<2?Uea5gD2ÎÓ3C�RT6\RÚ=5Ue:¹47Ci8;:<47a?Y[:<a547C�Y[M\>e878<Ci8ÕS69=?8;:<Ci>DR�J�Ó3C�2?>BAeC4<CiÓ�4<6O:;:7C�=Õ>D8;nÂCiY[:7806O=]:7U-UD=5C�UD40Ô´Ue47C´Y[M\>e878;CP8�lÂæNa54769=5g�:725C�:<4Z>Q=?8;fhUe47ÔW>K:<69Ue=Ún54<UTY�Ci878�JSÓ3C2?>BAeC0=5UQ:769Y�CiR´:72?>K:�LN8<nSCPYH:Zÿ+Ö 8`>e8<nSCPYH:78">Q=SR@=?>eÔ�CPRWnÂUe69=D:ZY[aT:Z8`>Q47CNgeUbUTRWÔ´CiYZ2S>Q=56\8;ÔW8�fhUe46OÔ´n547UKAb6O=5gÚ:<25C�47Ci>DR5>Qq569M96�:mÙÒUef!:<25C^Y�4<U]8<87Y[aT:<:<69=5gÕY�UTRTCel½É"ÙÒ47Ci8;:<47a?YH:7a54<69=5gÕCi>eYZ2ß>e8<nSCPYH:RTC[Ï?=?6�:76OUD=�69=]:<U^Ô�a5M�:76On?MOC@Y�M9>D8<8<Ci8iJ�4<CiÓ�4<6O:<69=5g^>eR5A]6\Y[CWY�UbR5C�69=]:<U^UD47RT69=?>e4<Ù^Ô´C[:725UTR58iJ«>Q=?Rfha5MOM9Ù�aS8;69=5g�:<25C�Q�59FC[�57d�X9e×/2Q�5!Y�UeÔ´nÂUD8<6�:76OUD=�8;:<4Z>K:7C�geÙW69=^Û!ÙbnÂC�4��KÿSJTÓ3CX2?>BADCX8<69Ô�n?MO6OÏ?CiR:<25C�:747>e=?8mfhUD4<ÔW>Q:<69Ue=Ýn547UTY[CP8<8iJ�q5aT:@Ó"C�ÔW>BÙÝ2S>BAeC�MOU]8m:@8<UeÔ´C-UefN:725C^4<CinSUD4;:7CiRýqSCi=5C[Ï?:78n54<UKAb6\RTCiR-qbÙ�>e8<nÂCiYH:Z8�>Q=?R�=?>eÔ´CiR-nSUD6O=]:7Y�aT:78�ú���ü�lÈ!C�ADC�4<:<25CiMOCP8<8iJ«Ó�2?C�=ý:<25C�6O=?6�:769>eM`Y�Ue=?R56�:76OUD=?8�4<CinSUD4;:7CiRÒ69=ý8<CiY[:<69Ue= � l���RTUÚ=?UQ:´25UeM\R�J

:<25CN:<4Z>Q=?8;fhUe47ÔW>K:<69Ue=WÔW>BÙ�4<CPÜ]a56O47CN>�MOUe:3UQf«>DR5RT6O:<69Ue=?>eM?Ó"Ue47Ö�JD>Q=SRWnSU]8<8<69q5MOÙDJD8<UeÔ´CNÖb69=?RWUef4<C�fº>eYH:7Ue476O=?gw6O=�8;UDÔ�CNÔ�C�:<25UTR58369=?8;6\RTCN:<25CX>e8<nSCPYH:3R5C[Ï?=56O:<69Ue=«l%S0=?CN8;UDa54ZY[C!Uefn54<UDq5M9C�Ô fhUe4:<25C�:747>e=?8<M9>Q:<69Ue=�:<U'Û!ÙbnÂC�4��KÿX6\8á8<UeÔ´C[:7256O=?gX:<2?>Q:áa?8;aS>QM9MOÙ�2?>Qn5nÂC�=S8½6O=@L08;nÂCiY[:7ÿwn?4<UDge4Z>QÔW8�í:<25C'>DR5RT6O:<69Ue=�UQf�8<UeÔ´C�:<2569=5g�:<U´:725Cwq?>e8<C¹A]6\>´>Q=�6O=]:74<UTRTa?Y[:<69Ue=�>Q=?R�>´8<a5q?8<CiÜ]a5C�=]:!>eR5A]6\Y[CRTC[Ï?=?CiR^UD=^6�:PJÂ>eMOM$6O=?8<6\RTC':725C�87>QÔ´C'>e8<nÂCiYH:Pl�çT6O=?Y�C'Ó"C�Y�>e=Î=5UQ:02?>BAeCX:mÓ"U@Ô´C[:725UTR58NÓ�6O:<2:<25Cw87>QÔ´C¹8<69ge=?>Q:<a547C069=�>�Y�M9>D8<8iJe:7256\8`Ó3UDa5M9R-47CiÜ]a5694<C¹>�Ô´Ue47CXY[UeÔ´n5M9C[â@47C�Ó�476O:<C¹4<a5M9CeJTÓ�6O:<2RT6�Ø�C�47C�=]:`=?>QÔ´69=5g´Y[Ue=bADC�=]:<69Ue=´fhUD43:725CX>eRTAb6\Y[CX>Q=?R@:<25C¹6O=SY[M9a?8;69Ue=-UQf$>e=->DR5RT6O:<Ue=S>QM²5Gi9L+/28�5Y[M\>Qa?8<C!69=´:<25C02]ÙbnÂC�47Ô´UbR5a5MOC!Ï?MOCDl � Ue43>�Y[UeÔ´n5M9C[:7C!47C�nÂUe4<:�Ue=´:725C!n547Ueq5M9C�ÔW8áfhUea5=?R�RTa5476O=5g:<256\8�C[âTnÂC�476OÔ´Ci=D:PJ58;CiC@ú � ü�l

Í 25C@C[âTnÂC�476OÔ´Ci=D:�>QM\8;UÎ>eMOM9UKÓ3CPR�a?8w:7UÎC�AK>QM9a?>Q:<C@25UKÓ :725C�Y[UDÔ´nSU]8;6O:<69Ue=ÒÔ´CiYZ2S>Q=56\8;ÔW8UQfáCi>DYZ2^:<UbUDM$Ó"Ue47Ö-69=În54Z>eY[:<6\Y[CDlSà�=ÚL08;nÂCiY[:7ÿSJ�C�AeCi=ÎÓ�6O:<2Î:725C�C�âTn54<CP8<8<69AeC'nÂUKÓ3Ci4NUefáÓ�6OM\RboY�>Q4ZR58¹69=�nÂUe69=]:7Y�aT:78iJ�6�:'ÔW>BÙÎqÂC´C�ADC�=]:<a?>eMOM9ÙÎ=5CPY[CP8<87>Q47Ù�:<U�6O=bAK>e8<69AeC�M9ÙÎÔ´UTRT6OfhÙÚ>Q=×>e8<nSCPYH:RTC[Ï?=?6�:76OUD=J�qÂCiYi>Qa?8<C^:<2?CÚY[UDÔ�nÂUD8<6O:<69Ue=ÞqÂC[:mÓ"C�C�=Þ>D8;nÂCiY[:78�>e=?RÞY[M\>e878<Ci8´6\8@2?>e47RTÓ�6947CiRß6O=:<25C�>e8<nSCPYH:02?Ci>eR5C�4Pl?ä^Ue47C�UKADC�4PJb:<25C�a?8<C�UQf<N�=2QR>A@O/?8I5�1�Ci8;:7>Qq?MO6\8;2?Ci8N>�8m:74<6\YH:¹4<CiM9>Q:<69Ue=?8<2569n>QÔ´Ue=5gw>D8;nÂCiY[:78iJe>Q=?RWY�Ue=?8<CiÜ]a5Ci=]:<M9ÙeJQ>QÔ´UD=5gp/2YAYB:725C�694�nÂUe69=]:7Y[a5:78ilQàp:�Ó"Uea5M\R�qSC!69=]:<Ci4<CP8m:76O=5g6�f�:725C�RTCP8;69ge=5Ci4�Y�Uea5M\RÒ8;nÂCiY�6�fhÙ�C[â5Y�C�nT:76OUD=?8w:7U^:<25C�Y[UDÔ�nÂUD8<6O:<69Ue=×Ue4ZRTC�4'fhUe4�8<UeÔ´C@Uef`:<25CnSUD6O=]:7Y�aT:78il�Û!ÙbnSCi4��Qÿ@n547UKAb69R5Ci8!>WÔ´UD4<C'CiMOCigD>e=D:N>e=?R d C�âT6Oq5M9C�8<UeM9aT:<69Ue=«J?qbÙ-47CiÜ]a569476O=5g@:<25CRTC[Ï?=?6�:76OUD=ßUef0:725CÎY[UDÔ´nSU]8;6O:<69Ue=Ñ8m:747>Q:<CigeÙÝC�âbn?MO6\Y[6O:<M9ÙñUDaT:78<69R5C-:725CÎ2bÙbnSCi478<M969Y�C�R5C[Ï?=56O:<69Ue=>Q=?R�qbÙ�>QM9MOUKÓ�69=5g´:<2?C�8;nÂCiY�6�ÏÂY�>K:76OUD=^UQf½C[â5Y�C�nT:76OUD=?8`:<U@:<25C�Y[UeÔ´nÂUD8<6�:76OUD=Î8m:747>Q:<CigeÙ�>e=?R�:<U:<25C'Y�UeÔ´nSU]8;6O:<69Ue=-Ue4ZRTC�4�>eÔ�UD=5g�a5=56O:78wãº>eM98<UW>K:`:<2?C¹M9C�ADC�M�Uef$UenÂC�4Z>K:76OUD=?8ZèHl Í 256\8�>Qn5n547UD>DYZ26O=?Y�4<CP>e8<Ci8�:725CNnÂUQ:7C�=]:<6\>QMSfhUe43=5Ue=5o�69=bAB>D8;69AeC�Ô´UTRT6OÏSY�>Q:<69Ue=@>e=?RW47CiY[UD=TÏ?gDa547>Q:<69Ue=l � 69=?>QM9M9ÙeJ]6�:698�Ó3UD4;:72ÒÔ�Ci=]:<69Ue=569=5g^:72?>K:�>e=Ò6OÔ´nÂUe4<:7>e=D:�4<CPÜDa?6O47C�Ô´C�=]:�8;:7>Q:<CPR�fhUe4 ò5óDôbõ5öb÷Qø?öDô5ù�Ø :<25C>K:;:Z>eYZ25Ô´Ci=D:�UQfNRT6OØÂCi4<Ci=]:�>e8<nÂCiYH:Z8w:7UÕRT6\8m:76O=SYH:�69=?8;:7>e=?Y[CP8�Uef�>egeCi=D:Z8�ú þBü Ø 2?>D8'=5Ue:�qÂC�C�=fha5M�ÏSMOM9CiR^RTa?C0:7U@Y[a54747C�=]:�MO69Ô´6�:Z>K:<69Ue=S8`UQf�:<25C'Y�UeÔ´nSU]8;6O:<69Ue=�Ô´CiYZ2?>e=56\8;ÔW8`UQf�qSUe:<2�:<UbUDM98il

Ù ÚÕÈ3ÅNË�,;Ê<�bÌmÈ�Å<�b C@2S>BAeC´4<CinSUD4;:7CiR�8;UDÔ´CW6O=?8<69ge2]:78wY�UeM9MOCPYH:<CPR×RTa5476O=5g�:725C@69Ô´n5MOCiÔ´C�=]:7>Q:<69Ue=×UQf":<25C-8<>eÔ�C>Qn5n5M96\Y�>K:76OUD=J�:<2?C òTóDôbõ5öT÷Kø?öDô5ù 8<ÙT8m:7C�Ô�J�a?8<6O=5g�qÂUQ:72×L08;nÂCiY[:7ÿÎ>e=?R�Û!ÙbnSCi4��Qÿ?J�2?>BAb69=5g^>e8>Ú8;:7>Q4<:<69=5gÎnÂUe69=]:�>e=Ý>e8<nSCPYH:;opUe4769C�=]:<CPRÒRTCi8<6OgD=ÝÔ´UTRTC�M�l Í 2?Ci8<C@6O=S8;69ge2]:78�47C[fhC�4�=5UQ:�:<UÚ:<25CÔ´>Q:<a5476O:mÙ@Ue4`nÂC�4<fhUe47Ô´>e=?Y[C¹UQf�Ci>DYZ2�:7U]UDMåJTq?aT:�:<U�:<2?C�694!>Qq569MO6O:mÙW:7U´8<C�nS>Q4Z>K:<CX>Q=SR-Y�UeÔ´nSU]8;CY[Ue=SY[C�47=?8iJT>Q=?R-:<2?C'Y[Ue4747Ci8<nSUD=?RTC�=SY[CX>QÔ´Ue=5g�:<2?C�694!n547Uege4Z>QÔ´Ô´69=5g�CiMOCiÔ�Ci=]:78ilb CÕqSCiMO69C�ADCÎ:<2S>K:iJ"2?>DRÑÓ3C�8m:Z>Q4<:<CiRß:7256\8�C�âbnÂC�4769Ô�Ci=]:-Ó�6O:<2�2bÙbnÂC�4Z8;M969Y�Ci8W69=?8;:<CP>eRÞUef

>e8<nSCPYH:78iJ5:725C':747>e=?8;fhUe47Ô´>Q:<69Ue=�n547UTY[Ci878!Ó"Uea?M9R�nÂUD8<C'Ô´Ue47C�RT6�Û@Y[a5MO:<69Ci8iJSnS>Q4<:<6\>QM9MOÙ�qSCPY�>ea?8;C:<25CWY[UDÔ´nSU]8;6O:<69Ue=ÕÔ�CPYZ2?>Q=?698<ÔW80n?4<UKAb6\RTCiR^qbÙÚÛNÙbnSCi4��Qÿ->e4<C�Ô´Ue47C�nÂUKÓ3Ci4;fha?M�>e=?R d C[âT6Oq?MOC:<2?>e=^:<25U]8;C�n54<UKAb6\RTCiR�qbÙ�LN8<nSCPYH:7ÿSJÂn?>Q4<:<6\>QM9MOÙ-qSCPY�>ea?8;C�Ó3C'Ó"Uea?M9R�2?>BADC'8;UDÔ´C�>eR5R56�:76OUD=?>QMÓ3UD4<Ö^:7U^Y[Ue=S8;6\RTC�4X:725C@2bÙbnSCi478<M969Y�Ci8¹a5=?RTCi4w:<2?C@q?>e8<C[o�>e8<nÂCiYH:wRT6\YZ25UQ:7UeÔ�ÙÎnSCi478<nÂCiYH:76OADCelà�=ú }Qü�J!13M9>e4<ÖDCÚ>Q47gea?Ci8´:72?>K:�:<25Ci4<CÕ698�>ÒnÂUQ:7C�=]:<6\>QM¹fhUe4�>Ý47C�M\>K:76OADC�M9ÙßY�MOCP>Q=ÐÔW>Qn?n56O=?gÒfh4<UDÔ13UeÔ´nSU]8;6O:<69Ue=×ê½>K:<:<Ci4<=?8 Ø >�RTCi8<6OgD=ÚÔ´UTRTC�M�6O=?8<n5694<CPRÎ69=�:<25CWäÎæXçbUb1 Ô´UTRTC�M½n547Ci87Y[4769qSCPRq]Ù�ç+S¹ê Ø :7U@Û!ÙbnÂC�4��KÿWY[UTRTCDJTÓ�2569MOCX:725CwÔW>Qn5n569=5g�:<UWL08;nÂCiY[:7ÿ@Y�UbR5CwÔ´>BÙ�qSC'8<a5qTîmCPYH:`:<U8<Yi>K:;:7C�476O=?g´>e=?R�:7>Q=?geM96O=5g´69=^>e8<nSCPYH:78ilb C0C[âTnSCPYH:3:<2?>Q:�:<2?CNgeCi=5C�476\Y!>e8<nSCPYH:<o�q?>D8;CPR´RTCi8<6OgD=WÔ´UbR5C�MÂÓ3C02?>BAeC�qÂC�Ci=@Ó3UD4<Öb69=5gwUe=

>QM9MOUKÓ!8á:<25CXYZ2?>Q4Z>eY[:<Ci4<69Ei>Q:<69Ue=W>Q=?R�Y[UeÔ´n?>e4<6\8<Ue=´UQf«C�âT698;:<69=5g�>e=?RW=5CiÓÐ>Qn5n?4<U]>eYZ25CP8�J]>e8áÓ"C�M9M>e8X>Q=ÕCi>e8<Ù�ÔW>Qn5n569=5g-fh4<UDÔ�:<25CWRTCP8;69ge=ÕÔ´UbR5C�M�:<U�RT6OØÂCi4<Ci=]:¹n547UegD47>eÔ´Ô�69=5g-Ô�UTRTCiM980:72?>K:8;a5n?nSUD4;:!8<C�n?>e47>Q:<69Ue=�Uef�Y�Ue=?Y�C�47=?8ilÜ #.ÝG#«Ç%#«ÅNË-#{�Þ �!���?¶3��¨á~��`z7y!���h�!s�tQ�D~��]© § ����x]z7�`~��-¶���vTzZ}7y;�D� § �`ßHà"��á â�ãBä����å�äàpæ�çè9�à��H��çRéM�CêP����9�AëìäàhäIíî ä9àM�H�K�Kà�ï¶��ñðñð.ò²é2ó-æ"�Mô9õ�õõe�ôQ�Ns3�5s��b�H�BzZ�P�b¶N�Mö`��{m}Z~��e�?���b�@s3�%÷?x]}Zz7�b�e��¶��ùø¾evTz7{m~�zZ�D}Zz!�3z7vTti{�y3tP�Wym�]z��3��z0t���¶���vTzZ}7y;����b��·3�evTz7{<¸i�e�Mô9õ�õ Þ ���SzZ}<�?�]��zZvTt�{�yH�]���s$ªº��~�tBú\ymtw�ivDvTzH��{Kû<�

ü �N|T�Âs��O�[{mÁBzw���b�-�!�%ý^����ÁPz7{H�$þ´��v]vD~��D©@s�tPuwvTti��~�ym~�ti�^����y�ymz<{m�]�`ymt´¶���vTzZ}7y;�´���b��·3�evTz7{<¸i�e�§ �ùßHà���á â î äà�í��K���KàM�H�ÿäàùé�äIíK���{������²à��ëÂà%���K�HëÂà����Aß î é���� � ���[�Mþ´�Z��ô9õ�õ Þ �� �!¶!�²ö`�[{m}Z~��e��þ-�½s�ti{�ymzZ�Z�á���b�Òs3��÷SxD}ZzZ�b�Q�Þ¶ ý�zZµ ø�Q�e~�{mti�]uwzZ�Kyw�\t�{�ym�DzW�`zZ�BzZ��tiv]uwzZ�Ky���b� þ´�i~��KymzZ�]�i�]}7z-t��cø�ª�s�tPuwuwz7{m}Zz-��ti{�y;�����´µb����zH�ñti�ñ�^ö3{mtix]vK¨½�[{mz�¶�v]vD{mtP�i};�S��ô9õ�õ Þ �§ �D�9ti{mu'��ym~�ti����zZ��tPxe{m}ZzZ��þ´�i�]�i©Pz7uwzZ�Ky"¶�����tK}Z~���ym~�tP� § �KyH¿ �Âs�tP�e�\z7{mz7�]}Zz�ú § �ñþ´¶ ôõ�õ Þ û<�� �!¶!�%ö`�[{m}Z~������b�@s3�%÷?x]}Zz7�b�e�½¶3�@¶3��vTz7}7y�ªå���i��zH�@¼"µ?�pz7}7y�ª�¼3{m~�z7�QymzZ��þ�tQ�DzZ�S�\ti{*þ�x]��ym~�ªå¶3©Pz7�Qy|K�e�pymzZuw�Z� § �Ræ�çè9�9àM�H��ç�éM�CêP�����AëAäàaäIí î äà��K�K�Hà"ïñëÂàRé�äIíK���{�������à��ëÂàM�H�K�HëÂà��×���ß î é��$á ���� ���

� ä��äà��:äi�%þ´�Z�Bôõõ Þ �� �!¶!�?ö`�[{m}Z~��e�]s3�?÷SxD}ZzZ�]�e�Q���b�X�¹�es�tH¨��i�S�]ø�]©i~��DzZz7{m~��]©ÿþ�x]��ym~�ªå¶3©izZ�Ky½¼"µ?�pzZ}<y�ªp¼3{m~�zZ�KymzH�'|Qti�Oy�ª¨���{mzX¨á~�ym�^¶���vTzZ}7y�ª�¼3{m~�zZ�KymzH�-��{mtP©�{;�iuwuw~��]©e�Oôõ�õ Þ ��|exDµ]uw~�y�ymzH�´ymt@|Qti�9y娽�[{mz�����{;�i}7ym~�}Zz��ø�¾evTz7{m~�zZ�]}7zP��ø����zZ�Q~�z7{H�T¶�vD{m~��]ôõ�õ Þ �

� �Jýß��·`�[{�{m~���tP�ý�i�b�×·N�á¼"�����Dz7{H� |ex]µ?�pz7}7y�ª�¼3{m~�z7�QymzZ�×�{mti©i{;��uwuw~��D©�úh¶ s${m~�ym~��Kx]z�ti�0�xD{mz¼"µ?�pz7}7ym�Hû<� § �Bò²�Iä��K����çëÂà��ï<äIícðJð.ò�é?ó-æBá �� i�]v]�i©Pz7� � Þ�Þ"! � ô�#e� Þ%$�$�ü �#e�¶ö0�'&�~�}Z�H����zZ�Z�²ø½�«·"~����m�]�i��zP���D�$·"xD©Px]�D~��S�{þ-�'&�z7{m�pymzZ�?���e��������u´�$���b�\ýÑ��ö3{m~��p¨�tP���?�ñ¶��¼"�Pz7{m�Q~�z<¨�ti�´¶3��vTzZ}<y;�D�<ôõõ Þ � ú»�Ky�ymv(� ¸i¸i����vTzZ}7yA�7� t�{m©K¸i�etK}Zx]uwz7�Qy;�[ym~�tP�T¸[t[�Bz7{m�Q~�z7¨3¸i����vTzZ}7yA��ªt[�Bz<{m�e~�z7¨�� v5�Q�Hû<�$ �!¶!�.÷Â��~h��ö0��s3��þ�xD{mvD�Q�K���i�b�Î�!�«�D�xý^�i��ÁBz<{H�Ò|QzZvb�[{;��ym~��]©�s�tP�D}Zz7{m�]�w¨á~�ym�Ú·3�evTz7{<¸i����¶��ø�¾evTz7{m~�zZ�]}7zN��zZvTt�{�yH� § �ùßHà"��á â½ãBä9���9ï*)�äKê\äà,+�-�â �Aë/.�0Jë/1��Kà�ïHëAäàM��â+é%�CêP��I��Aëìäà�äIí î äàM�H�K�Hà"ïë�à�éMäIíK���{�������à��ëÂàM���K�KëÂà��R��xß î é����Mô9õ�õ�õQ�

Þ õe�¶þ-�S|QÁQ~�vDvTz7{H�¶���]z¶ý^�[ym��tP��|ex]µ?�pz7}7yNs�tPuwvD~���z<{2� ¶3��vTz7}7y;�`úh¶�s${m~�ym~3�KxDz¹ti���{;��}7ym~�}H�i��¼"µDª��zZ}7ym�Hû<� § � ãBä���9ï*)�äKêpäà4+,-Pâ �Aë�./0*ë/1$�Kà"ï�ëìäà���â"éM�CêP�����AëAäàpäIí î ä9àM�H�K�Kà�ïJ�9�²ðJð.ò�é?ó-æ"� Þ%$�$5$ �

ÞÞ �!�������[{�{`���b��·N�]¼"�����]z7{H�«·3�evTz7{<¸��X�"��z7{����b� § �]�py;�������[ym~�ti�ùþ´�i�Qx]�i�»�%ô9õ�õ�õQ�

Translation of Java? to Real-Time Java Using Aspects??

Extended Abstract

Morgan Deters, Nicholas Leidenfrost, and Ron K. Cytron? ? ?

Washington University Box 1045Department of Computer Science

St. Louis, MO 63130 USA

Abstract. The Real-Time Specification for Java [1] (RTSJ) introduces the con-cept of nested-scope memory areas to Java. This design allows a programmer toallocate objects in areas that are ignored by the garbage collector. Unfortunately,the specification of scoped memory areas currently involves the introduction ofunwieldy, application-specific constructs that can ruin the reusability of the af-fected software.We propose the use of aspects [2], in particular the AspectJ [3] system, to trans-form a Java program into a scope-aware RTSJ program automatically. Moreover,we have developed analysis that automatically determines storage scopes, in re-sponse to information provided by an instrumented form of the application athand. That instrumentation is also accomplished using aspects. Here we presentour ongoing work in using aspects to detect and specify memory scopes automat-ically in Java programs.

1 Motivation

One major roadblock to the widespread acceptance of Java as a language forreal-time and embedded systems is its reliance at runtime on an asynchronousgarbage collector. Such a collector may preempt threads running in a real-timeenvironment or take control of the system during memory allocation requests.The collector can then take an unbounded amount of time to complete its task,introducing unacceptable unpredictability into the system. To address these con-cerns and provide greater programmatic control over memory allocation and us-age, the Real-Time Specification for Java [1] (RTSJ) introduces to Java the useof structuralmemory areasthrough theMemoryArea type, the subtyping ofwhich can admit multiple strategies for allocating and deallocating storage.

One of the key memory strategies of RTSJ is provided with theScope-Memory type, which allows for memory areas to be associated with a particular

? A registered trademark of Sun Microsystems?? Funded by the National Science Foundation under grant 0081214 and by DARPA under con-

tract F33615-00-C-1697? ? ? Contact author: mdeters@cs.WUSTL.edu

scope of thread execution. When an execution scope is exited, objects in thememory area are released without the need for a garbage collector. However,the unit of a thread is not necessarily the most natural or useful level at whichto create and manipulate memory areas. Consider the introduction of aCachetype into a system (Figure 1(a)). A singletonCache object is constructed whenthe cache is first accessed. In a corresponding RTSJ design, we want this ob-ject to be allocated inImmortalMemory , because the singletonCache isaround for the length of the program. Placing it inImmortalMemory keepsthe garbage collector from scanning or marking it. This would be a waste of timesince we know that it will never become collectible: the scope of theCache ob-ject is global. To realize this RTSJ design, the programmer replaces occurrencesof new Cache with invocations ofnewInstance on the desired memoryarea, as shown in Figure 1(b).

If classCache had a more complicated design that supported multiple in-stances, this recoding ofnew instructions tonewInstance invocations wouldneed to be pushed into the user’s code ateverysite that aCache object was con-structed. This breaks the encapsulation of theCache type. Memory instructionsare sprinkled throughout user code rather than being factored out into a separate,decoupled memory strategy. The resulting code will not be easily reusable.

Figure 1(c) shows a better approach. With theCacheMemory aspect, wecan write theCache class just as we did in the Java implementation; the aspectassumes the responsibility of placing it into the correct type of memory area.Further, if we extendedCache to support multiple instantiations, thenCache-Memory could weave into user code, allowing the user to construct aCacheinstance naturally, without being responsible for its memory requirements.

We propose an automatic system for translating Java code intoMemory-Area -aware RTSJ code by determining the necessary RTSJ memory scopes re-quired to describe it. By employingprobing aspects, we determine where scopescan be used and develop a graph from which we can compute provably legalscope hierarchies. A scope hierarchy is selected, runtime execution points arechosen for opening and closing scopes, and an aspect is generated to enforce thestructure on the original program’s execution. Objects in the modified programare located in scoped memory areas rather than in the garbage-collected heap.

2 Scope Determination

As specified by RTSJ, a thread becomes associated with a scope when thatthread callsenter on the scope. The scope then resumes the thread by call-ing its run method. Any number of threads can enter a scope, and that scopecan be deleted only when all threads that have entered it have exited theirrun

class Cache {protected static Cache singleton;public static Cache instance() {

if(singleton == null)try {

singleton = new Cache();} catch(Exception e) { ... }

return singleton;}// etc.

}

(a)

class Cache {protected static Cache singleton;public static Cache instance() {

if(singleton == null)try {

singleton = (Cache)ImmortalMemory.instance().

newInstance( Cache.class );} catch(Exception e) { ... }

return singleton;}// etc.

}

(b)

aspect CacheMemory {around() returns Cache : calls(Cache.new(..)) {

ConstructorCallJoinPoint ccjp =(ConstructorCallJoinPoint) thisJoinPoint;

ConstructorSignature cs =(ConstructorSignature) ccjp.getSignature();

return (Cache)( ImmortalMemory.instance().newInstance( Cache.class )

}}

(c)

Fig. 1. (a)A partial Java implementation of aCache type.(b) A partial RTSJ implementation of aCache type inImmortalMemory . (c) An AspectJ aspect used to rewriteCache instantiationsto be in ImmortalMemory . RTSJCache objects can now be constructed vianew, just likeobjects in Java.

method; detection of this condition is accomplished by reference-counting thescope. Any memory allocated via a simplenew instruction is allocated in thememory area currently associated with the allocating thread. ExplicitMemory-Area allocation instructions are also permitted via thenewInstance method,as in theCache example of Figure 1.

ScopeMemory scopes can be nested, and it makes sense to design nest-ing relationships when small and perhaps iterative pieces of code produce a lotof garbage during their computation—this garbage can then be cleaned up allat once, on exit of the inner scope, without the need for a garbage collector.Programmers and program analysis tools tend to associate notions of storagescope with method scope. Thus, it may be desirable for aScopeMemory tobe associated with a particular scope of execution—a method, for example. Thescope could then be deleted when the method exits. RTSJ avoids the impropercollection of objects that are still reachable by mandating that object referencesmay only point to objects within the same scope or outward from inner scopes

A

B

C

D E

A

D E

BC

A B C

D

E

(a) (b) (c)

Fig. 2. A doesReference graphfor a programP (a) before and(b) after grouping strongly con-nected objects. An arrow fromA toB indicates that objectA stores a reference to objectB. (c)shows one possible scoping structure, whereE is in the outermost scope,D is in a sub-scope, andA,B, andC are in a sub-scope ofD’s scope. Object references in RTSJ may only point outwardto enclosing scopes.

to enclosing scopes; scopes are at least as long-lived as those that nest withinthem, so these outward-pointing references are considered safe.

If a Java program were simply moved to an RTSJ platform, then by defaultall objects would be allocated in the garbage-collected heap, which offers noguarantees for real-time activities. To generate an RTSJ scope hierarchy out ofJava’s flat memory model, we work backwards, tracking which objects referencewhich others, to build a set of scope nesting structures that do not violate theobject referencing regulations of RTSJ.

We have developed areference-probing aspectto determine these legalRTSJScopeMemory assignments. The probe defines as join points [2] the ob-ject instantiations and assignments of interest to us and builds adoesReferencegraph to track which objects refer to which other objects. ThedoesReferencegraph may contain strongly connected objects; these objects are grouped to-gether as they must share a scope. This collapses the more general graph into adirected acyclic graph (DAG).

For example, if objectA references objectB, the DAG contains an edgefrom A to B. ThenB’s scope must be at least as long-lived asA’s. There aretwo legal scoping hierarchies in this instance: that whereB is in an outer scopeandA is in an inner scope, and that whereA andB are both in the same scope. Asimple (but nonoptimal) algorithm for determining suitable scopes is to performa topological traversal of the DAG, which corresponds to a right-to-left preordertraversal of any depth-first spanning tree of the DAG. Figure 2 shows an exampleillustrating this procedure.

3 Join Point Discovery

The join points in the original program at which we need to inject instructionsto enter these scopes must also be determined. Consider Figure 3, a possible

stackpointer

4

3

2

1

0

.

..

.

..

E born

D born

stackpointer

0

4

3

2

1

.

..

.

..

E born

D born

A, B, & C born

(a) (b)

stackpointer

0

3

2

1

4

.

..

.

..

A, B, & C born

E born

D bornD still live

A, B, & C die

stackpointer

4

3

2

0

1...

A, B, & C

E born

D bornA, B, & C die

D dies

(c) (d)

Fig. 3. A view into the execution stack of programP at different points inP ’s execution.(a)Eis born first, in frame 0. In frame 3,D is allocated, then(b) A, B, andC (which refer back toD) are allocated in frame 4.A, B, andC are not returned or thrown from the execution scopethat generated them, and we know from Figure 2 that there are no references to them, so theymust die upon exiting their birth stack frame—this indicates that we can close their associatedmemory scope when frame 4 pops.(c) However,D escapes the execution scope of its birth (itwas returned or thrown), and it is still live in frame 2.(d) Therefore,D’s scope must not closeuntil frame 2 is popped andD is known to be dead.

execution stack for the programP whose reference behavior is described byFigure 2. First,E is constructed, then in some later stack frameD is constructed(and stores a reference toE). If we can determine thatD is always dead at thetime a particular stack frame pops, we can close its scope at that point. This isdemonstrated in the figure.

We can reason about the frame events of Figure 3 by engineering advice onmethod and constructor join points. To determine the points at which objectsare dead, we weave aliveness-probing aspectinto programP . This aspect in-spects method and constructor executions to determine when objects are bornand when they become unreachable.

By combining thedoesReferencescope information harvested by therefer-ence-probingaspect and the frame birth and death data from theliveness-prob-ing aspect, we can discover a scoping hierarchy that respects both RTSJ’s re-quirements on object references and the observed execution flow ofP .

4 Conclusion

Our approach has the following advantages:

1. The memory concerns of the system are described and enforced in a mod-ular fashion.The memory concerns are described through the use of as-pects, rather than sprinkling memory instructions throughout the code vianewInstance invocations. This is a particularly important issue for ob-jects in real-time Java packages that want or need to manage their own mem-ory concerns under RTSJ. Without aspects, the user would have the respon-sibility of placing packaged objects in the correct type of memory area.

2. Automation ofScopeMemory detection and management lowers develop-ment costs.This dynamic analysis approach can be used to find a memory-efficient scoping structure, and the resulting, automatically generated mem-ory aspect is easily tested by weaving it in to user code. Human-readable de-scriptions of object behavior can be generated that allow a useful view intothe system and point out inefficiencies or unintended design consequencesin the system.

3. The introduction of aspect code into the target program introduces real-timepredictability.Because the scoping hierarchies are computed and the neces-sary join points are discovered offline, the aspect that enforces the runtimeuse of RTSJ scoped memory areas consists mainly of a table lookup. Thiscan be done in bounded time, and we expect the translated program’s per-formance to be more predictable (and suitable to real-time environments)than the original program.

4. User source files are unchanged.The real-time modifications are completelydescribed in separate aspect source code; our aspect weaves into the user’ssource in order to modify it. For large source code trees, disk space require-ments can be dramatically smaller. Additionally, one source code tree issufficient for both Java andScopeMemory -enhanced RTSJ code.

In summary, we have proposed a mechanism for automating the creation ofRTSJ memory scopes. The expression of those scopes is accomplished via as-pects, as is the offline dynamic analysis to determine the scopes. At present wehave pieces in place to perform the analysis and to create scopes that are re-spectful of object references from program runs. Our future plans call for inves-tigating tradeoffs between various scope nesting structures, in terms of footprintand the overhead incurred for managing the scopes.

References

1. Bollella, Gosling, Brosgol, Dibble, Furr, Hardin, and Turnbull.The Real-Time Specificationfor Java. Addison-Wesley, 2000.

2. Gregor Kiczales. Aspect-Oriented Programming. InProceedings of the 11th European Con-ference on Object-Oriented Programming, June 1997.

3. The AspectJ Organization. Aspect-Oriented Programming for Java.www.aspectj.org ,2001.

� ����������� ����������������������������������! #"%$& ����%'("���*)+������-,������/.0)+��"21435)��!��36�7"(��8����'#"9� �-��:)���'#�

:"��%� ';�����! �<�=�?>

@:A BDCEGFIHKJMLMN�HPORQTSUFVFIWYXPSUEGQZW\[^]KH`_�abHMEZHMFM[GH

c7S!dRL`EZ[ZefS!Fg[H`_�h<iYSUN�[ZEGWYNUL`ijL`FRk�lmHMe(donp[ZSUE�h<FIqMW\FoS!S!EGWYFIq(LPFokc�SUdoL`EZ[ZefS!Fg[rH`_�lmHPefdInI[ZS!E�sIN�WYS!FoN!St LPN!HPOoQZS!Fvu7SUSUN!qoA [ZHPEGHPFg[GHoA SUkpnKw

x ygz�{p|I}r~7���v{I�^}�z

C��Pe(W�kIkpiYS!�-L`EGS�QZ]pQ^[GS!eK��N!HPFoQT[ZW\[Znp[GSUQ�L�QZS�[�H`_�QZS!EGX�WYN!SUQ;[Z�oL`[�LPW\e6L`[�_�LPN!W\iYW\[GL�[GW\Foq[Z�IS�kIS!XPSUi\HMdIefS!Fg[<H`_jkpW�Q^[GEZWYOInp[GSUkKLPdIdIiYWYNUL�[ZWYHPFRQ*W\FK�IS![ZSUEZHMqPS!FoS!HPnRQ*S!F�X�W\EGHPFIefSUFM[=Q!A`a-�oSdIEZWYeKL`EG]�HPO t S�N�[ZWYXPS�Q;HP_#L�efW�kIkpiYS!�-L`EGS�L`EGS�[GH�_�HgQ^[GS!E�L`dIdIiYW�N!L�[GW\HMF�dvHPEZ[GL`OoW\iYW�[^]�LPFokkpWYQT[ZEGWYOInp[ZS�k QT]pQT[ZSUe�WYFM[GS!EGHPdvS!E=L`OIWYiYW�[^]MA�C�[bi\S�LPQT[bN�HMFoN�SUdp[ZnoLPi\iY]P��[Z�IS��PefWYkIkIi\SU��LPEZS*i�L�]PS!E=�N�HPefdIEGW�QTS�Q(L+i�L�]PSUE#OvS!iYH��&[G�IS�L`dIdIiYW�N!L�[GW\HMF�LPFok�L`OvH�XPS�[Z�IS�HPdvS!E=L�[GW\Foq+QZ]pQ^[GS!e�LPFokFIS�[^��HPEG��QZnIOoQT[ZE=L�[GSPA-lmHMefe(HMF�efWYkIkIi\SU��LPEZS�doiYL`[T_�HPEGeKQ;WYFoN�iYnokpS�lr�8� -C:�-c¡lr�8¢£�L`Fok�[Z�IS:JgL�X�LfQTnIW\[ZS HP_¤dIEGH`[GHpN�HPi�QUAa-�IS�PSU]KkpSUQZW\qMFKdIEGW\FoN!W\dRL`ionoFokpS!EGiY]gWYFIq#e(W�kIkpiYS!�-L`EGSkpS�QTWYqPF;�RLPQ<OvS!SUFK[ZH#�IW�kpS7LPFok

S!FoNUL`doQZnIi�L�[ZS�QT]pQT[ZSUe¥kpS�[=L`WYiYQ�OvS!�IWYFok�N!HPefefHPF(L`OoQT[ZE=LPN�[ZWYHPFoQ¤L`Fok�H`¦?S!E�X�LPEZWYHPnRQ¤kpWYefS!FpBQTWYHPFoQ7H`_�[ZE=L`FoQZdoL`EGS!FRN�]�[ZH�[Z�ISfL`dIdoi\W�N!L`[ZWYHPF�kpSUXPSUi\HMdRSUE(§�SPA qoAY�v�rW\[Z��EZS�QTdvSUN�[7[GH�HMO t SUN�[i\HpN!L`[ZWYHPF4��kIL�[=L�LMN!N�S�QZQU�bLPFok�QZS!EGXgW�N�S�W\efdIiYS!efS!Fg[=L�[ZWYHPF£i�L`FoqPnoLPqPS�¨�A¤C7Q#QZ]pQ^[GS!eKQ�N!H�kIS§�HPE�FISULPEQT]pQT[ZS!eKQN!HpkpS�¨-QT[GLPFokIL`E=k�e(W�kIkpiYS!�-L`EGS �oLMQrFIH`[OvS!SUF�kpSUQZW\qMFISUk©�rW\[Z��ªG«M¬­ª!®o¯°=±�²!±´³µ± ¬·¶��R¸K¹�º�» ³\¼`½�± ¬¾¶��?¿G¹`®UÀ�Á`» ½Z¼ ¬ ± ¹`®o�R¹=ÂIª!®o®?ª °=° �MLPFok�¿�» ° ¬D¹�¸ ±\ÃU¼ ¬ ± ¹`®:WYF(efWYFokjAMÄ­[�WYQU��_�HMEW\FoQT[GLPFoN�SM��W\efdvHMQGQTWYOIiYS�[GH¡S!FI�oLPFoN�SrL7dIi�L�[T_�HMEZeÅ�rW�[G��[GSUN=�IFIW�ÆgnISUQ�[G�oL�[<LMkIkpEGSUQGQbFIS![^�mHMEZ�L���LPEZSUFISUQGQ!�jefHMOIW\iYS�L��-L`EGS!FIS�QZQU�jL`Fok£kI]gFRL`efWYN�LPkILPdp[GLPOIW\iYW\[^]P�bHME [ZH�S�ÇpdIiYHPW\[#L`dIdoi\W�N!L`B[ZWYHPF�iYS!XMS!i?QTSUeKL`Fg[ZW�N_�HME�QZ]pQ^[GS!eÈHPdvS!E=L�[GW\HMF4AIlmHPefefHPFIiY]P�g[Z�oS8LPEZqMnIefS!Fg[�LPqML`WYFoQT[mQZnoN=�L(kISUQZW\qMF�W�QL(dRHgQ^[GnIi�L�[ZS�k�QZLMN�EGW�ÉRN!S7HP_�dvS!EZ_�HPEGeKL`FoN!SPAs�HPefS H`_*[G�ISUQZS:W�QZQZnISUQ��oL�XPS¡OvS!SUF�doL`EZ[ZW�L`iYiY]�EGSUN�HMqPFIWYÊ!S�k�O�]©ORHpkpWYSUQ7kpS�ÉRFIW\Foq;efWYk�B

kpi\SU��LPEZSKQZdRS�N�W\ÉRN!L`[ZWYHPFoQU�4efHPEGSKFIHP[GL`Ooi\]�[Z�IS©�8¢�Ë(�4�r�IH��oLMQ W\Fg[GEZHpkpnoN!SUk�L�F�nIe�OvS!EH`__�S�L�[ZnoEZS�Q(LMkIkpEGSUQGQTWYFIq�[Z�IW�QKkpWYi\SUe(eKLoA<a-�IWYQ(WYFoN�iYnokpS�Q!�*_�HMEfW\FoQT[GLPFoN�SM�*e(S�QZQGL`qMS�LPFoke(S![Z�IHpkÌi\SUXPSUi8WYFg[ZSUEGN!S!dp[GHPE=Q!���IH�HP�pQ�_�HPE�N�nRQ^[GHPeÍeKL`E=QT�RL`iYi\WYFIq̧�EZS�Q^[GEZW�N�[GSUk�[ZH�X�LPi\noS[^]gdvSUQ=¨���HMdRSUF�QT[ZnoOpB¾[GH`B­HPEGO�WYFg[ZS!EZ_�LPN!S+§�EZS�Q^[GEZW�N�[GSUk�[ZH+[Z�IS�JgL�X�L�i�L`FIqMnoL`qMS�eKL`dodIW\Foqg¨��L`Fok�doi\nIqMqMLPOIi\S¡[GEGLPFoQZdRHMET[=Q�§�EGSUQT[ZEGW�N�[ZS�k©[ZH�[Z�IS#EZS�L`i\B¾[GW\efS(lr�8� -CÅdIEZHPÉoiYSP�RLPi�[G�IHPnoqP�H`_´[ZSUF#WYefdIiYS!efS!Fg[ZS�k:O�]:QT[GL`FRkIL`E=k(�8� -Q=¨�A�a-�IS�QTS�S!FI�RL`FoN!S!efS!Fg[GQ¤iYS!XPSUEGLPqPSmdoL`EZ[¤HP_o[Z�oSdIEZHMOIiYS!e��bOInI[#iYSUL�XPSfe#noN=��[ZH�ORS�kISUQZW\EGSUkjA�h�Ç�[ZSUFokpWYFIq+�8� -Q �rW\[Z��iYLPFIqPnoLPqPSfeKL`dpBdIW\FoqMQU�bdIEGH`[GH�N!HPi�eKL`dodIW\FoqMQU�bHPO t SUN�[(LPkILPdp[ZHMEGQU�jqPSUFIS!E=L`i<N!noQ^[GHPeÎeKL`E=QT�oLPi\iYWYFIqo�bQZeKL`EZ[Ï�Ð*ÑgÒµÓ4Ô*ÕUÖ^×7ÒµÓ¤ÓDØMÙgÙpÕUÖDÚ^Û=Ü8Ý�Þ7ß-àMá4â�ãmä�å?ÕUÓDÒæÚ^Ò�ÕUç�åjèUÙpÛGÖ¤Òµç¡é�ÕUÖ^×`ÓDÑMÕ�Ù¡ÕUç êmÓDÙpÛ=ëZÚDì­ímÖ^ÒµÛ=ç�Ú^Û�Üå4Ö^ÕUîUÖTè!ï ï Ò�çMî èUçgÜfà`Û=Ù�è�ÖTè!Ú^ÒµÕ�çfÕ!ð¤ã�Õ�çMë=ÛGÖ^çgÓ=ñgòvè!çgë�è!Ó­Ú^ÛGÖ�ñ�ómô¡ñMêmØgîUØgÓ­Úmõ!ö�öP÷Uä

dIEZH�ÇpWYSUQU�?HPE¡[ZS�N=�IFIW�ÆgnISUQ8[GH�LPN=�IWYS!XMS#FIS![^�mHMEZ��L��-L`EGS!FoSUQGQ7LPFok�kI]gFRL`efWYNKLMkIL`dI[GL`OoW\iYW�[^][ZH¡EZnoFpB¾[GW\efSrN�HMFokpW\[ZWYHPFoQ*W�Q�QT[ZWYi\ipFIHP[<L7qMW\XMS!F�§�QZS!S ø ùI�Zú�ûp_�HPE<L7e(HMEZSrkpS![GLPW\iYSUk(kpW�QZN!noQZQZWYHPFH`_�QTHMe(S¡HP_b[Z�oSUQZS WYQGQTnoSUQUA ¨¢�HPEGS!H�XMS!E��pe(W�kIkpiYS!�-L`EGS#QZ]pQ^[GS!eKQ8L`EGS�S�Ç�[GS!FokpS�k�[GH�LPkokpEZS�QZQ7EGSUÆgnIWYEZSUe(SUFg[GQHP_<[Z�oS

e(HgQ^[�kpWYXPSUEGQZSmLPdIdIiYWYNUL�[ZWYHPF(kpHPeKLPW\FoQ�L`FRk:FISU��efWYkIkIi\SU��LPEZS-QTSUEZX�W�N�S�Q¤QZnIdIdvHPEZ[ZWYFIq7LPdIdIiYW�BN!L�[GW\HMF [ZE=L`FRQZN!S!FokpWYFIqEGSUÆgnIWYEGS!efS!Fg[GQ¤L`EGS�N�HMFoQT[GL`Fg[Gi\] LPkokpSUkjA�a-�IS�L`dIdIiYW�N!L�[GW\HMF�kpHMefLPW\FRQLPkIkpEGSUQGQZSUkfO�]f[Z�IS lr�8� -C�doiYL`[T_�HPEGeüL`iYHPFISM�ME=L`FoqPSr_�EGHPeý§�kIWYQT[ZEGW\Oonp[ZS�ko¨<OonoQTWYFIS�QZQ-L`dIBdIi\W�N!L`[ZWYHPFoQ7§�QT[GLPFokIL`E=k;lr�8� -C7¨��MEGSULPi�B·[ZWYefSQT]pQT[ZS!eKQ7§��rS�L`iRa-WYefS8lr�8� -C7¨��gLPFokKQGN�W\BS!Fg[ZW\ÉRN�L`Fok �oW\qM��dvS!EZ_�HPEGefLPFoN�SmN�HPefdInI[ZWYFIq(§¾c7L`[GL8þ�L`E=L`iYi\SUiglr�8� -C7¨���[ZH8�rW\EGS!iYSUQGQbLPFokS!e�OvSUkokpSUk:QZ]pQ^[GS!eKQ�§�¢�WYFIWYe�nIeÅlr�8� -C7¨�A�a-�oSmQZS!EGXgW�N�SmQTS![GQ4S!Ç�[ZS!FRk¡_�EZHMeÿ_�L`nIi\[b[GHPiYS!EZBL`FoN!SP�pQTS�N�nIEGW\[^]P�pL`Fok�HPO t S�N�[-qPEGHPnId�efLPFoL`qMS!efS!Fg[�[ZHfQT]�FoN=�oEZHMFIHPnoQmL`Fok�LPQZ]�FoN=�IEGHPFIHMnoQN�HPefe#nIFIW�N!L�[GW\HMF4��[ZH t noQT[�FoLPefS¡L#_�SU� A

� ± ºMº ³ ª�� ¼�½ ª- ³\¼ ¬ ��¹ ½ ¸�� ¼ ¸ ±´³µ± ª ° L`EGSSUXPHPiYX�W\Foq7[GH#QZnIdIdvHPEZ[<[Z�oSUQZS�kpW\¦vSUEZSUFM[-L`dIdoi\W�N!L`B[ZWYHPFfkpHPeKL`WYF(EZS�ÆMnoW\EGS!efS!Fg[=Q*�rW�[G�IW\F([G�ISQZLPefS< ³\¼ ¬ ��¹ ½ ¸ ³µ± ®?ªr§�W·A SPAY�`SUQGQTSUFg[ZW�L`iYi\] dIEGHpkpnoN�[i\WYFIS�¨�Agc7W\¦vSUEZSUFM[mdIEZHPÉoiYSUQ§�W¾A SPAY�gQZdvSUN�W�L`iYWYÊ!SUkKQZnIOoQZS�[=Q<HP_v[G�IS�N!HPEGSre(HpkpSUi�¨�L`EGSkpS�ÉRFISUk([GHLPkIkpEGSUQGQ<QZS!EGX�WYN!S�QTS![GQmL`FokKQZdRS�N�W\ÉRN�kIHPeKL`WYFKEZS�ÆgnIW\EGS!efSUFM[=Q!Ags�W\efWYiYLPE�S!¦vHMET[=Q�L`EGSrS!efSUEZqPBW\FIq�_�HPE JgL�X�L�B­OoLPQZSUk�efW�kIkpiYS!�-L`EGSP�?L`Fok�[ZH�QTHMefS#S!Çg[GS!Fok�_�HPE c lr�8¢�B·ORLPQZSUk�QZ]pQ^[GS!eKQ!Aa-�IWYQ�dIEGHPiYW�_�SUEGL`[ZWYHPFfLPQ���S!iYiRLMQ*[Z�IS7L`WYe¥[ZH#QTnIdodRHMET[�L X�LMQ^[�_�nIFRN�[ZWYHPFRL`iRQZdvSUN�[GEZnoe �rW\[Z�pBW\F�HMFIS:S!F�X�WYEZHMFIefS!Fg[rWYQ�i\S�LPkpWYFIqf[ZH;[Z�IS�N!H`B­S�ÇpW�Q^[GS!FoN!S H`_*e(W�kIkpiYS!�-L`EGS dIi�L�[Z_�HPEGefQ�rW�[G�efLPF�];FIHPFIB·HMET[G�IHPqMHPFoLPio_�S�L�[ZnoEZS�QrL`Fok©N�HMFoQTW�kpSUEGLPOIi\S7_�nIFoN�[ZWYHPFoLPi4H�XPSUEZi�L`dbAabH�QZnIefeKL`EGW\ÊUSP�*[Z�oS��PSU]�dIEGHPOIiYS!e �rW�[G��N�nIEGEGS!Fg[;efWYkIkIi\SU��LPEZS�QZ]�QT[ZSUeKQKWYQ;FIHPFpB

S�Ç�[ZSUFoQTWYOIWYi\W\[^]P��dIEZHMi\W\_�S!E=L�[GW\HMF��rW\[Z��EGSUQZdvSUN�[f[GH�QTnIdodRHMET[GSUk�_�SUL`[ZnIEGSUQ;LPFok�L`dIdoi\W�N!L`[ZWYHPFkpHPeKL`WYFoQU��L`Fok�L�[GHgH+N�HgL`E=QTS!B·qMEGLPW\FIS�k�QTSUEZX�W�N�S�efHpkpSUirS�Çp�IWYOIW�[GW\Foq�_�nIFRN�[ZWYHPFRL`i-EZS�kpnIFpBkIL`FoN!]PA

���IW\iYS8�mS¡N!LPFIFIH`[-H`¦?S!ErL�_�nIiYi4QTHMi\np[GW\HMF;[GH�[G�ISUQZS7doEZHMOIi\SUeKQ!����S7WYFg[ZS!FRk;[GH#HMnp[ZiYW\FoSHPnIE�dvHMQZW�[GW\HMF�[GH���LPEGkoQ�L8FISU��LPEGN=�oW�[GSUN�[GnIEGS�_�HME�e(W�kIkpiYS!�-L`EGSrQT]pQT[ZSUefQUA��+S-ÉoEGQT[<kpW�QZN!noQZQL#F�nIe#ORSUEH`_*dIEGW\FRN�WYdIi\S�Q�[ZH;LMkIkpEGSUQGQ�QZ�IHMET[=N�HPefWYFIqMQ�WYF�N�nIEGEGS!Fg[�efW�kIkpiYS!�-L`EGS L`E=N=�IW�[GSUN�B[ZnIEGSUQLPFok©[Z�oS!F�dIEGSUQZS!Fg[dvH`[ZSUFg[ZW�L`i¤QZHPiYnp[GW\HMFoQ-[ZHf[G�IS#LPORH�XMS¡HPnp[Gi\WYFISUk�doEZHMOIi\SUeKQ!Aoa-�oSFIS!� e(W�kIkpiYS!�-L`EGS�L`E=N=�IW\[ZSUN�[ZnIEGS©�rW\iYirORS�ORLPQZSUk�HPF�[Z�IEGS!S��PSU]�N�HMFoN�SUdp[U�r¸K¹�º�» ³\¼`½�± ¬¾¶��¼�° ÂIª=¿!¬¹ ½�± ª!®o¬ ¼ ¬ ± ¹�®o�vL`Fok�[G�IS�¹GÂoª�® ± ¸� ³ ª!¸fª!®o¬ ¼ ¬ ± ¹�®�efS�[GLPdI�IHMEUA��+S�L`i�QZHfQZnIefeKL`EGW\ÊUSEZSUiYL`[ZSUk���HPEG�f[Z�oL`[�oLPQrLMkIkpEGSUQGQTS�k�QZHPefS H`_¤[Z�IS�QTS W�QZQZnIS�Q!A

� ��|��} ���^{p�T}�z����(}����*|o~�����z�y����7|I}�� �b~����Z~�~� !�"����|#�$ |o�&%��^{'�¤�v{p��|(�)� }r~���

�7nIE-dRHgQTW\[ZWYHPF©WYQ�[G�oL�[���_�HPE�[Z�oS:L`OvH�XPS�HMnp[ZiYWYFISUk©EGSULPQZHPFRQ!�M[Z�IS kpS�QTWYqPF�H`_*L#efW�kIkpiYS!�-L`EGSdIiYL`[T_�HMEZeÈQT�oHPnIi�kfORS7EZS!B¾[G�IHPnoqP�g[�_�EZHMeÅqMEZHMnIFokfnId;LPFok([Z�IS7��]gdvH`[G�ISUQZW�Q<H`_j�r�IS![Z�ISUE�HMEFIH`[rL`F;S�*;N�WYS!Fg[�efHpkpnIi�L`E�dIi�L�[Z_�HPEGeÈNUL`FIFoH`[mOvS¡kpS!XMS!iYHPdvSUkj�ge�noQT[-ORS7[ZS�Q^[GSUkjA'�+S�ÉoE=QT[kpWYQGN�nRQZQ#L�QTS![#HP_-doEZWYFoN�WYdIiYSUQ#L�FIS!�üefW�kIkpiYS!�-L`EGSKdIi�L�[T_�HMEZe kpS�QTWYqPF�QZ�IHPnoiYk£OvS�ORLPQZSUknIdRHMF;L`Fok([G�IS!F;kIWYQGN�noQGQ<�oH���[GH�LPN=�IWYS!XMS-[Z�IW�Q<�rW\[Z�KSUefS!EGqPWYFIq:kpS!XMS!iYHPdIefSUFM[�N!HPFoN!S!dp[=Q!A

+-,/.0.�132�465�7�298:2';<,/=?>A@B7C,3>�DE,GFH1/2';

I AJ� ± ¿ ½ ¹`¯3KPª ½ ®vª ³b³�± KPª ¼�½ ¿ML ± ¬­ª=¿!¬¾» ½ ª<N

lmnIEGEZSUFM[;efW�kIkpiYS!�-L`EGS�L`E=N=�IW�[GSUN�[ZnIEGSUQ(_�L�XMHPEfHPFIS�doEZWYeKL`EG]�N�HMe(e#nIFIW�N!L`[ZWYHPF�Q^[^]�iYSO QT]�FoN=�IEGHPFoHPnoQ(�þ�l O LPQfOoLMQTW�QfL`Fok�OInIWYiYk�HP[Z�ISUE;Q^[^]�iYSUQU�<LPQfQTS�N�HMFokIL`EG]�LPkok OHPF£QZS!EGXgW�N�S�Q8FIS�Ç�[ [ZH�W\[QP©§�SPA qoAY�bLPQZ]�FoN=�IEGHPFIHMnoQ8N�HPefe#nIFIW�N!L�[GW\HMF4�4FIHMFpBDN�HPFg[GW\F�nIHMnoQHPdvS!E=L�[GW\HMFoQ!�vEGS!iYWYLPOIi\S�RKnIFoEZSUi\W�L`OIiYS�e#nIi\[ZW�N!LPQT[U�vdInIOoi\W�QT�SRKQZnIOoQGN�EGWYORSM�RqMEZHMnId�N�HMe(Be�nIFoWYNUL�[ZWYHPF�S![GN`Aæ¨KC eKL t HME;kpE=L��rOoLPN=�£HP_7[G�IWYQ�L`dIdoEZHgLPN=��WYF�N�nIEGEGS!Fg[KdIiYL`[T_�HMEZeW\efdIiYS!efSUFM[=L�[GW\HMFoQ;W�Qf[Z�oS�H�XPSUEZi�L`d�H`_¡[Z�oS�kpW\¦vSUEZSUFM[�e(HpkpSUiYQU�<[G�IS�EGS!dIiYW�N!L�[GW\HMF�H`_N�HMEZS�_�nIFoN�[ZWYHPFoLPirnIFIW\[GQ([Z�RL�[�L`EGS©doL`EZ[(HP_8LPi\iN!HPefe�nIFoWYNUL�[ZWYHPF�Q^[^]�iYSP��[Z�oS�QTnIOI[ZiYSkpW\¦vSUEZSUFoN�S:WYF�[G�IS�efHpkpS!i�Q�§¾LPQ[Z�ISU]���S!EGS:WYFoN�EGS!efS!Fg[=L`iYi\]©kpS!XMS!iYHPdvSUk�H�XPSUEr]PS�L`E=QG¨��L`Fok;[Z�IS¡N�HMefdIi\S!ÇpW�[^]fH`_j[G�IS8ÉoFoLPiRdIEGHPqMEGLPefe(WYFIq:efHpkpSUivQZnIdIdvHPEZ[ZWYFIqfQTSUXPS!E=L`ioFIHPFpBHPEZ[Z�IHMqPHMFoL`i?H�XPSUEZi�L`dodIW\Foq:_�SUL`[ZnIEGSUQUAabH�LPkIkpEGSUQGQf[G�ISUQZS�W�QZQZnISUQU��L£FoS!� efWYkIkIi\SU��LPEZS�LPEGN=�IW\[ZS�N�[GnIEZS�QZ�IHMnIiYk�doEZH�X�W�kpS�LefH�kIS!ivW\F��r�IWYN=�;LPi\i?N�HMefe�nIFIW�N!L`[ZWYHPF;QT[^]�i\S�QmLPEZSS�ÆgnoL`iYi\](dIi�LPN!SUkKQZWYkpS!B·O�]gBDQTW�kpS�LPFokefH�kInIiYLPEZiY]¡OIEGHP�PSUF kpH��rF:WYFM[GH_�nIFRN�[ZWYHPFRL`ignIFIW\[GQUA�c7W\¦vSUEZSUFM[*N�HMe(e#nIFIW�N!L`[ZWYHPF�QT[^]�i\S�QL`EGS�WYFoN!EZSUe(SUFg[GL`iYiY]+HMOp[GLPW\FoSUk�_�EZHMe [Z�IS�N�HMefdRHgQTW\[ZWYHPF�HP_7nIFRkpS!EGi\]�WYFIq�_�nIFoN�[GW\HMFoL`inIFIW\[GQUAoÄDF©[Z�oWYQ�e(HpkpSUi4FIHKHMFIS:Q^[^]�iYS¡WYQ-_�L�XMHPEGSUk�W\F©[G�IS�L`E=N=�IW\[ZS�N�[ZnoEZS¡H�XPSUErL`FIHP[Z�ISUEHPFISM�b_�noFoN�[GW\HMFoL`i�EZS�kpnIFokoL`FoN!]�W�Q#L�XMHPW�kpSUk4�bL`Fok�N�HPFRQTW�Q^[GS!FoN!]�W�Q#efLPW\Fg[=L`WYFISUkjA0�+SEZS!_�S!E([ZH�[Z�oWYQKLMQ(L�efWYN!EZHPB·�MS!EGFIS!imi\WY�PS�kpS�QTWYqPF�[ZH+S!efdI�oLMQTWYÊ!S�[Z�oL`[f[Z�ISUEZS�QT�oHPnIi�kHPFIiY]�ORS(L;XMS!EG]�efWYFIW\eKLPi�N!HPEGS:HPFg[ZH��r�IWYN=��kpW�¦?S!EGS!Fg[¡N�HPefe#nIFIW�N!L�[GW\HMF�QT[^]giYSUQ7L`EGS[ZHKOvS:N�HMFpÉoqPnoEZS�kjA

T A�U¤ÂIª!® ¼ ®vºK¸K¹�º�» ³\¼`½ ¸ ± ºMº ³ ª�� ¼�½ ª� ³\¼ ¬ ��¹ ½ ¸ ºMª °�± ÁP®?NCiYi�dIi�L�[T_�HMEZe _�noFoN�[GW\HMFoL`iYW�[GW\S�Q!�?WYFoN�iYnokpWYFIq©[Z�oS#FIHMFpBDL`dIdIiYW�N!L�[GW\HMF�S�ÇpdvHMQZSUk�e(W�kIkpiYS�B��LPEZS�QTSUEZX�W�N�S�i�L�]PSUEGQU�bQZ�IHPnoiYk�ORS�N�HPefS©LPN!N!SUQGQTWYOIiYSP��HPdvS!F�LPFok�efHpkpnIi�L`E(OInIWYi�kpW\FoqOIiYH�N=�pQUARa-�IW�Q7EZS!_�S!E=Qr[ZH�dIi�L�[T_�HMEZe nIFoW�[=Q7QZnoN=��LMQ�N�HMefe�nIFIW�N!L`[ZWYHPF�QZnIOpBDQT]pQT[ZSUe©�?QTB[ZnIORQ!��QT�MS!iYS�[ZHMFoQU���8� Å[ZE=L`FoQZdRHMET[ i�L�]PSUEU�jWYFg[ZS!EZ_�LPN!S;EGS!dvHMQZW�[GHPEG]P�jWYe(doi\SUe(SUFg[GL�[GW\HMFEZSUdRHgQTW\[ZHMEZ]M�pL`Fok�L`iYijdoLPET[=Q-H`_b[G�IS HPO t SUN�[�LMkIL`dI[ZS!E�A

V A�W ³´³ �=»p®v¿!¬ ± ¹`® ¼`³ »p® ± ¬ °#± ®�¬GLIª¡Â ³\¼ ¬ ��¹ ½ ¸ ° LI¹`» ³ º ² ª ¼ ¿=¿Gª °=°�±�²�³ ªYX7¿!» ° ¬D¹�¸ ±\Ã�¼P²!³ ªYX ¼ ®vº½ ªD ³\¼ ¿Gª ¼M²�³ ª ² ¶�¿!» ° ¬D¹�¸ ± ¸Â ³ ª!¸fª!®o¬ ¼ ¬ ± ¹�® ° NC _�nIFRN�[ZWYHPFRL`ibnoFIW�[7EZS!_�S!E=Q-[ZH;HMFIS�QT[ZSUd�W\F�[G�IS�S!Ç�S�N�np[GW\HMF�N=�oL`WYF�H`_<LKQZS!EGXgW�N�S doEZHPBX�WYkpS�k�O�]�[G�ISfe(W�kIkpiYS!�-L`EGS�§�SPA qoAY�?[Z�oWYQ N!HPnIi�k�OvSfHPFIS(H`_m[Z�ISfOInIWYi�kpW\Foq©Ooi\HpN=�pQ8EZS!B_�S!EGEZS�k�[GH�WYF�[Z�IS�W\[ZSUe�L`OvH�XPS�¨�A�a-�IS�S�ÇILPN�[KS�Ç�[ZSUFok�HP_8L+Q^[GS!d�kpSUdRSUFokIQfHPF�[Z�oSN�HMFoN�EGS�[GS7dIi�L�[Z_�HPEGe&kpSUQZWYqPF�LPFok;[G�IS¡QTSUEZX�W�N�S8H`¦?S!EGSUkjA'ZIHME-L(QZ]gFRN=�IEZHMFIHPnRQ<efS�[G�IHpkW\F�XMH�NUL�[GW\HMF�[Z�oS�_�nIFoN�[GW\HMFoL`i�nIFIW\[GQKeKL�]�OvS�kIL�[=L�Q^[GEZnoN�[ZnIEGS�doLPN=��WYFIqo��LPEZqMnIefS!Fg[eKL`E=QT�oLPi\iYWYFIq�§�nIFodoLPN=��WYFIq�L`FRk�nIFIeKL`E=QZ�oL`iYi\WYFIqKEGSUQZdRS�N�[GW\XMS!iY]p¨��RQZ]pQ^[GS!e(B·iYS!XMS!ib��þ�l§�dvHMQGQTWYOIiY]�OIEGHP�MS!F�kpH��rF�WYF�W�[=Q;N�HMFoQT[ZW\[ZnISUFM[KdIEGH`[GHpN�HPi�Q=¨��<L`FRk�NUL`iYi�kpW�QTdoL`[GN=�IWYFIqRAa-�ISUQZSnIFoW�[=QmQZ�IHPnoiYk(FIHP[�ORS�[ZH�H�N!HML`E=QZSP��[ZH�S!FoLPOIi\S�EZSUnoQTSM�`SULMQTS�H`_4N�noQT[ZHMefW\Ê�L�[ZWYHPFb�L`Fok�iYH�� i\SUXPSUi¤LPNUN�S�QZQ-[GHK[Z�oS!WYE�S!FRk�B·dvHPWYFg[GQ#§�FISUSUkpS�k�LPQ t HPWYF�dRHMW\Fg[GQ_�HPE8LPQZdRS�N�[GQ=¨�Ac�W\¦?S!EGS!Fg[f_�nIFoN�[GW\HMFoL`irnoFIW�[KWYefdIi\SUefS!Fg[GL`[ZWYHPFoQU��QTdvSUN!WYLPi\WYÊ!S�k£_�HPEfX�L`EGWYHPnoQ(S!F�X�WYEZHMFpBefS!Fg[GLPimN�HMFokpW\[ZWYHPFoQ�L`Fok�noQGL`qMSfdoL�[Z[ZS!EGFoQU�beKL�]�OvS;WYFoN�iYnokpS�k��rW�[G��[Z�IS�dIiYL`[T_�HMEZe[ZHKOvS�QZS!iYSUN�[GSUk�L�[�N!HPFpÉRqPnIE=L�[GW\HMF�[GW\efS HPE�dIEZH�X�W�kpSUk©LPQrN!noQT[ZHPe S�Ç�[ZSUFoQZW\HMFoQ!ARa-�IWYQnIFIW\[mOIEGSULP�pkpH��rFfWYQ�L`i�QTH EGSUÆgnIWYEGSUk([ZH�S!FoLPOIi\S7XPSUEZ]#i\H��-B­i\SUXPSUioLPQZdRS�N�[=Q�[ZH#ORS7�mH�XMS!FL`EGHPnIFRk�nIFIW\[;S!FRk�B·dvHPWYFg[GQUA<þ<i�L�[Z_�HPEGe�LPQZdRS�N�[GQfQZnoN=��LPQU��S�ÇIN�SUdp[ZWYHPF�efLPFoL`qMS!efS!FIB[U��efHPFoW�[GHPEGW\FIqR��LPnp[Z�oS!Fg[ZW�N!L`[ZWYHPF4�*S!FRN�EG]gdI[ZWYHPFAR�kpSUN!EZ]�dp[GW\HMF4��L`Fok�QTSUi\S�N�[GW\XMS�[^]�dvSQTnodIdRHMET[�rWYiYijFIS!S�k�[G�IW�QrefH�kInIiYLPErOIEGSUL`��kpH��rF©LMQ-�mSUi\i·A

[ ß�Õ!Ú<è!Ö^ÕUØgç�Ü�ÕUÖ<ÕUç�Ú^ÕUÙ(ÕUðvÒæÚ�ñMÒ´ä Û�äµñPÚ^ÑgÛ=ÓDÛ-ÓDÛZÖ]\PÒµë=ÛGÓ<è!Ö^Û-ë=ÕUï ï Õ�çE^µÞ¡Ó­ÚTèUç�Ü#è_^µÕ�çMÛ-Òµï Ù�^µÛ=ï Û=çPìÚTè!Ú^ÒµÕ�çMÓ=ä

`oA�a ± ®vª!¯�Á ½Z¼`± ®vª=º©¿G¹`®UÀ�Á`» ½Z¼ ¬ ± ¹`®+¹!�m ³\¼ ¬ ��¹ ½ ¸�NabH#kIL�[GSefWYkIkIi\SU��LPEZSQZ]pQ^[GS!eKQ<L`EGSrFIHP[mN�HMFpÉoqPnoEGLPOIi\SL`[mL`iYi·AbZIHME<[Z�oSefHMQT[�doL`EZ[U�MLHPFIS�QTWYÊ!SmÉI[=Q¤LPi\ipL`dodIEZHgLPN=�¡W�Qb[=L`�MS!F4A�VFokIS!E¤ÉoFIS�B­qPE=L`WYFIS�k N�HPFIÉoqPnIE=L�[GW\HMF �mSmnIFokpSUETBQ^[=L`Fok([G�IS7QZdvSUN�W�L`iYWYÊUL�[GW\HMFfH`_4L dIi�L�[Z_�HPEGe WYFoQT[GL`FRN�Sr_�HME�HPFoSdoL`EZ[ZW�N�noiYLPE�L`dIdoi\W�N!L`[ZWYHPFkpHPeKLPW\F�L`Fok4��dRHP[ZS!Fg[GWYLPi\iY]P�*_�HMEKHPFIS�doLPET[GWYN!nIiYLPEKL`dIdIiYW�N!L�[GW\HMF�WYF�[Z�IW�Q;kpHMefLPW\FbA<C�IWYqP�ISUEri\SUXPS!i¤QTdvSUN!W�ÉRNUL�[GW\HMF�HP_¤[G�IS:LPQZdRS�N�[=Q-[Z�IS doiYL`[T_�HPEGe&EGSUÆgnIWYEZS�QrL`Fok�[Z�oS:W\Fg[GS!EZB_�LPN!SUQ8§�SPA qoAY��EZS�ÆgnIW\EGSUkKQZS!EGX�WYN!SUQU�P[^]�dvSUQU�gLPFok;S!ÇIN�S!dI[ZWYHPFoQ=¨�HP_j[Z�IS¡L`dIdoi\W�N!L`[ZWYHPF;qMnIWYkIS[Z�IS:QZ]�Fg[Z�IS�QTW�Q-H`_�[Z�IS doiYL`[T_�HPEGe&WYFoQT[GL`FRN�SPA

úpAdc�®?ºPªDÂIª!®vºMª�®?¿Gªf¹!� ¼ ¿=¿=¹�¸� ¼ ®o¶ ± ®gÁ� ³\¼ ¬ ��¹ ½ ¸ ¬D¹U¹ ³æ° N �]KdIiYL`[T_�HMEZe�[ZH�HMiYQm�mS8efSULPF�Q^[GnIOpB!R QZ�PSUi\S![ZHPFIB·qMS!FISUEGL`[ZHPEmL`FokKefS![GL�BDkIL`[GL:EGS!dvHMQZW\B[ZHMEZWYSUQ-§�Ä^cJe�L`FRk�WYefdIi\SUefS!Fg[GL`[ZWYHPF(EZSUdRHgQTW\[ZHMEZWYSUQ=¨�A`lmnIEGEZSUFM[�efW�kIkpiYS!�-L`EGSmdIi�L�[Z_�HPEGeKQ[ZWYqP�g[ZiY]¡W\Fg[GS!qPE=L�[GS�[Z�oSUQZS�[GHgHMiYQbW\Fg[GH[Z�oSmdIi�L�[Z_�HPEGeKQ!A�a-�IW�QbEGS�_�E=L`WYFoQj_�EGHPeÿ[G�IW\E=k doLPET[^]W\efdIiYS!efSUFM[=L�[GW\HMFoQ�H`_R[Z�IS�QTSN!HPefdvHPFISUFM[=Q!�PnoQTS-HP_?QT[GLPFokIL`E=k�[ZSUN=�oFIHPiYHPqM]P��HPE*[G�ISrnoQZSH`_m[Z�IS�QTSKN�HMefdRHMFIS!Fg[GQ8_�HME¡dInIEGdRHgQTS�Q�[G�IS!]��mSUEZS(FIHP[¡WYefefSUkpW�L�[GS!iY]�W\Fg[GS!FokpS�k�_�HMEUAa-�ISUQZSr[GHgHMiYQmQT�oHPnIi�kfORS8QTSUdoL`E=L`Ooi\S�_�HPEGe [Z�IS7dIiYL`[T_�HMEZe��POonIW\i�kKHMFKHPdvS!FKWYFM[GS!EZ_�LPN!SUQU�L`Fok�_�HMi\iYH���L`F�S!Çg[GS!FoQZWYOIi\S kpS�QTWYqPF�[Z�oS!eKQTSUi\XMSUQUA

fhg 465(7C.0;ji:2�5#1/,/kE,/>0=ml_n02�;<29@B7�,/>0Db,/F0132�;Eo

��S([Z�oW\FI��[Z�oL`[:L`iYi�H`_�[G�ISKL`OvH�XPS#dIEZWYFoN!W\dIiYSUQ NUL`F+ORSKLMN=�IW\SUXPS�k�O�]�kpS�ÉRFIW\Foq�LPF�HMdRSUF_�EGLPe(SU�mHMEZ��H`_�L�e(W�kIkpiYS!�-L`EGS:dIi�L�[Z_�HPEGe��RO�]©noQTWYFIq�[ZSUN=�oFIWYÆgnIS�Q_�EGHPe LPQZdvSUN�[ZB·HMEZWYS!Fg[GSUkdIEZHMqPE=L`efefW\Foq7_�HME<[G�IS�qMS!FISUEGL`[ZWYXPSrN�HMFpÉoqPnoEGL`[ZWYHPFfH`_jefWYkokpi\SU��LPEZS�dIiYL`[T_�HMEZe W\FoQT[GLPFoN�S�Q!�L`Fok�LPdIdIiY]�W\FIq�[Z�IS©HPdvS!F�W\efdIiYS!efS!Fg[=L�[ZWYHPF�e(S![GLPdI�IHPE#[ZH�_�nIFoN�[ZWYHPFoLPimnIFoW�[KkpSUQZWYqPF£[GHHPOp[=L`WYF©N!noQ^[GHPefWYÊUL�[GW\HMF©L`[�L(XPS!EG]KiYH���iYS!XPSUi¾A

f n�2:i g 1/2 g?p 5(>rqsF 2'>t+-,/.0.�132�465�7�2s@u1/5�l pvg 7�wyxz7�5(wS2�4 g 7C{|o-a-�oSr_�EGLPefS!��HPEG�iYL�]pQ�HMnp[<[Z�oSefWYkIkIi\SU��LPEZSLPEGN=�IW\[ZS�N�[GnIEZSM�PkpS!ÉoFISUQmL`iYiodIi�L�[Z_�HPEGe WYFg[ZSUET_�LMN�SUQU�PkpS!ÉoFIS�Q<S�ÇpS!BN�np[GW\HMF�N=�oL`WYFoQ¤L`Fok LMN!N�S�QZQbdRHMW\Fg[=Qm§�W¾A SPAY�UWYFg[ZSUET_�LMN�SUQ4[ZHWYFokpWYX�WYkInoL`i�Q^[GS!doQ¤WYF�L`F S!Ç�S�N�np[GW\HMFN=�oL`WYFR¨��4LPFok+kpS�ÉoFoSUQ¡�IH�� [G�IS!]�W\Fg[GS!EZB·EGS!i�L�[GSPA?a-�IWYQ8_�E=L`efSU�mHMEZ��W�Q8[Z�ISfdIEGWYFoN�WYdoL`i�doEZS!BEZS�ÆMnoWYQZW�[GS¡_�HPE�LPi\i4[Z�IS EGSUQT[UAIÄ­[8kpS�ÉoFoSUQ-[G�IS:iYS!XPSUibL�[�r�oWYN=��LPQZdvSUN�[=QN!LPF�W\Fg[ZSUEZXMS!FIS LPFok[Z�ISUW\E(qPE=L`F�nIi�L`EGW�[^]MA4Ä­[(LPiYQZH�WYefdoLPN�[GQ�[Z�IS�dRHgQZQZW\Ooi\S�kISUQZW\qMF�N=�IHPW�N�S�Q _�HME#L`iYim_�nIFoN�[GW\HMFoL`inIFIW\[GQUA

f n�2si g 132 g&p|} ;�F 2'Dbl_;Eo�C�FfLMQTdvSUN�[<WYQ�L¡QZ]pQ^[GS!e¥_�S�L�[GnIEZS�[G�oL�[�N!EZHgQZQTB­N!np[GQ¤[G�ISrW\efdIiYS�Be(SUFg[GL�[GW\HMF:H`_p[G�ISmQZ]pQ^[GS!e L`FRk WYQ¤eKL`FIW\_�SUQT[�L`[¤e#nIi�[GW\doi\S�i\HpN!WMWYF [Z�oSmN�HpkpS8ø ~`û·A�h�ÇILPe(doi\S�QH`_�LPQZdRS�N�[GQ-WYF©[Z�IS:N!HPFg[ZS!Ç�[-HP_¤efW�kIkpiYS!�-L`EGS¡LPEZSE�

� S�ÇIN�SUdp[ZWYHPF©eKL`FoLPqPSUe(SUFg[ §�EGLPWYQZWYFIqo�pdIEGHPdRL`qML`[ZWYHPF4�g�oLPFokpiYW\FIq�¨Ä­_¡LPF�S�ÇIN�SUdp[ZWYHPF��mSUEZS©[GH£ORS�kpS!ÉoFIS�k�LMQKL£QT]pQT[ZSUe�LPQZdRS�N�[�LPFok�L�efW�kIkpiYS!�-L`EGSdIi�L�[T_�HMEZeýN!HPnIi�k�ORSfN�HMFpÉoqMnIEZS�k�_�HPE¡LKdoL`EZ[ZW�N�noiYLPE7L`dodIi\W�N!L`[ZWYHPF�§¾kpHPeKL`WYFR¨��o[G�IS#S!Ç�BN�SUdp[ZWYHPF£LPQZdvSUN�[�N!HPnIi�k�ORS�N!HPFpÉRqPnIEGSUk�W\F�HPE:N!HPFpÉRqPnIEGSUk�HPnp[��bkpSUdRSUFokpWYFIq�HPF+[Z�oSL`dIdoi\W�N!L`[ZWYHPF�QTSUefLPFg[ZW�N8LPFok©EZnoFM[GW\efS¡S!F�X�WYEZHMFIefS!Fg[UA �

� é£ÑgÛGç�Ú^ÑMÛj�(ÒµçgÒµï8ØMïýã�í�âh�*ê��´ÛGï8ÝpÛ�ÜMÜMÛ�Ü�Ó­ÞPÓ­Ú^Û=ï ÙPÖ^Õ_�'^µÛY�8Ó­ÚTè!ç�ÜMè!ÖTÜ�Ô*èUÓ:ë=ÕUçgë=Û=Ò�\�Û=ÜèfÜMÒµÓDë=ØMÓDÓDÒµÕ�ç�Õ!ð*Ô<ÑgÛGÚ^ÑMÛGÖÕUÖçMÕUÚrÚ^Õ#Ò�çMë�^µØ�ÜPÛ¡ÛM�Pë=Û=ÙPÚ^Ò�ÕUç©ÑgèUç�Üb^µÒ�çMî(ë�è!ï Û¡ØgÙoäví�ÙgÙpÕ�çMÛ=ç�Ú^Ó

� QT]�FoN=�oEZHMFIW\Ê�L�[GW\HMF�eKL`FoLPqPSUe(SUFg[-LPFok�N�HPFRN�nIEGEZSUFoN�];N!HPFg[ZEGHPis�]�FoN=�IEGHPFIWYÊUL`[ZWYHPF¡N�HMFoQ^[GEGLPW\Fg[=Qj�oL�XPS*HP_´[ZS!F OvS!SUF noQZSUk8[ZHrWYiYi\noQT[ZE=L�[GS<LPQZdRS�N�[bHMEZWYS!Fg[GSUkdIEGHPqPE=L`efefWYFIq�[GSUN=�IFoWYÆgnIS�Q ø ~`û·A

� W\Fg[GS!EZ_�LPN�S kpS!ÉoFIW\[ZWYHPF�i�L`FIqMnoL`qMS7S!Çg[GS!FoQZWYHPFoQ¢�L`F�](S�Ç�[ZSUFoQZW\HMFoQ*_�HPEmW\Fg[GS!EZ_�LPN�S7kpS�ÉoFoW�[GW\HMF;iYLPFIqPnRL`qPS�Q*�oL�XPSrOvS!SUF;dIEGHPdvHMQZSUkjAMa-�IWYQW\FRN�iYnokpSUQU�?_�HPE S!ÇIL`efdIiYSP�jÆgnoL`iYW�[^]�H`_�QZS!EGX�WYN!S#LPFIFIH`[=L�[GW\HMFoQ!�?EGSULPi�B·[ZWYefS(N!HPFoQT[ZE=L`WYFg[GQU�LPQGQTSUET[GW\HMFoQU�`dIEGS7L`FRkKdRHgQ^[-N�HMFokpW\[ZWYHPFoQU�gLPFokfOvS!�oL�X�WYHPE=L`iRLPFIFIHP[GL�[GW\HMFoQUAMCiYivH`_j[Z�oSUQZSN�HMFoQ^[GW�[Gnp[ZS:LMQTdvSUN�[GQUA

� LPNUN�SUQGQrN�HMFg[ZEGHPijL`Fok©QZSUN�noEZW\[^]C�NUN�SUQGQ�N�HPFg[GEZHMi¤§�SMA qRA\�gHPO t SUN�[ZB·ORLPQZSUkj�Me(S![Z�IHpk�B­OoLMQTS�kj�MWYFg[ZSUET_�LMN�S�B­OoLMQTS�ko¨�L`FRk�QZSUN�nIBEZW\[^]�§�SPA qoAY�?L`np[G�IS!Fg[ZW�N!L`[ZWYHPF�LPFok�S!FRN�EG]gdI[ZWYHPFmRfkISUN�EG]�dp[ZWYHPFv¨N�HMFoQT[ZW\[Znp[GS�S�ÇILPe(doi\S�QH`_*efWYkIkIi\SU��LPEZS LPQZdvSUN�[=Q-[Z�RL�[�eKL�];FISUSUk�[ZHKOvS:OIiYS!FRkpSUk©WYF�HPErHPnI[�kpS!dvS!FokIW\FIqKHMF[Z�IS S!ÇpSUN�nI[ZWYHPF�N�HPFg[GS�Ç�[UA

� N�HMe(donp[ZWYFIq;L`FRk�FIS![^�mHMEZ�KEGSUQZHPnoEGN!S7efHPFoW�[GHPEGW\FIq� W\FRkpW\X�W�kpnoLPi4dIi�L�[T_�HMEZe&[^]gdvSUQC�efW�kIkpiYS!�-L`EGS�dIiYL`[T_�HMEZe/QTnodIdRHMET[=Q�L�N!S!EZ[GLPW\F�[^]�dRS�efH�kIS!i·��E=L`FIqMW\FIq�_�EGHPe�OoL`BQTW�N#[^]�dRS�QK§�SPA qoAY�jWYFM[����oHML`[U�4N=�oLPE=¨[ZH�XMS!EG]�QTHMdI�IW�Q^[GWYNUL�[ZS�k�kI]gFRL`efWYNUL`iYi\]�eKLPFoL`qMSUk[^]�dRS�Q�§�SMA qRA\�o[^]�dRS�C�����W\F�[G�ISflr�8� -C efHpkpS!i´¨�A?a-�IS:doEZHpN�S�QZQZWYFIqfH`_<Lf[^]�dRS�W\FpB[ZSUEZXMS!FIS�Q�L`[<kpW�¦?S!EGS!Fg[�iYS!XPSUiYQ�HP_o[Z�oSrdIiYL`[T_�HMEZe §�SPA qoAY��W\F(eKL`E=QT�RL`iYi\WYFIqo��WYF(dRLPN=��L`qMW\FIqR�W\Ff[GEGLPFoQZdRHMET[<S![GN`Aæ¨*ÄDFf[G�oL�[mQZS!FRQTSL¡doLPET[GWYN!nIi�L`E�[^]�dvSN�HPFRQ^[GW�[Gnp[ZS�Q�L`FKLMQTdvSUN�[�H`_?[Z�oSefWYkIkIi\SU��LPEZSMAa-�ISrL`OvH�XPS�i\W�Q^[�N!HPefdIEGWYQZSUQ*N!HPFoN!EZS![ZSrLPQZdRS�N�[=Q!��[G�IS!EGSrL`i�QTH¡S�ÇpW�Q^[=Q�L8Fgnoe�OvS!E�H`_?efHPEGS

L`OoQT[ZE=LPN�[�LPQZdRS�N�[GQU�p[G�oL�[��rWYiYibEGSUÆgnIWYEZS:LfefHPEGS EGS�ÉoFIS�k�kpSUN!HPefdvHMQZW�[GW\HMF4Aoa-�IS�QTS:WYFoN!i\nokISEZS�L`i\B¾[GW\efSP�IÆgnoLPi\W\[^];HP_�QZS!EGXgW�N�SM�IL`Fok�_�L`noi�[[GHPiYS!E=L`FoN!S8LMQTdvSUN�[GQUAC�QZdRS�N�[GQ7N�HMnIiYk�W\Fg[ZSUEZXMS!FIS:L`[8QZS!XMS!E=L`ibQT[GLPqPSUQW\F�efW�kIkpiYS!�-L`EGS dIi�L�[T_�HMEZeKQUA&ZoHPE�HMFISP�

[Z�ISU]�N�HMnIiYk�OvS8nRQTS�k;[GH(S!Ç�[ZS!FRk�[G�IS¡dIi�L�[T_�HMEZe �rW�[G�©N!S!EZ[GL`WYF�_�SUL�[GnIEGSUQ¡§�N�_^AIi\W�QT[rLPORH�XMS�¨��OInp[U��efHMEZS�W\Fg[GS!EGSUQT[ZWYFIqPiY]P��LPQZdRS�N�[=Q�N!HPnIi�k#ORS-L`dIdoi\WYSUk�[ZH¡N�HMFpÉoqPnoEZS�L�dIi�L�[Z_�HPEGe W\FRQ^[=L`FoN!S_�HPEL(doL`EZ[ZW�N�noiYLPEL`dIdIiYW�N!L�[GW\HMF©kIHPeKL`WYF©LPFok©QTdvSUN!W�ÉRN LPdIdIiYWYNUL�[GW\HMF4Aa-�IS#qMEZS�L�[8ORSUFIS�ÉI[ HP_<[Z�IW�Q¡W�Q�[G�oL�[¡[G�ISfdIEZHMi\W\_�S!E=L�[GW\HMF�H`_�Q^[=L�[ZW�N#dIiYL`[T_�HMEZeýdIEGH`ÉRi\S�Q

�mHMnIiYk�kpW�QGL`dIdvSULPE:L`Fokj�¤LPQ¡FISU��EGSUÆgnIWYEGS!efS!Fg[GQK§¾kpHPeKLPW\F£L`FRk�_�S�L�[GnIEZS�¨¡L`EGWYQZSP�4QZWYe(doi\]e(HMEZS�LPQZdvSUN�[=Q�FoS!SUk�[ZH+OvS�LMkIkpS�kjA�lmi\S�L`EGi\]M�¤[G�IW�Q(LPdIdIEGHMLMN=��WYQ(SUFM[GW\EGS!iY]£OoLMQTS�k£HPF�Le(HpkpnoiYLPE�HMdRSUFÌefW�kIkpiYS!�-L`EGS�dIi�L�[Z_�HPEGe _�E=L`efSU�mHMEZ��[Z�oL`[�dRSUEZefW\[GQ�[ZH�kpS�ÉRFIS+LMN!N!SUQGQdRHMW\Fg[GQ�L�[r�r�IW�N=��LMQTdvSUN�[GQrNUL`F©W\Fg[ZSUEZXMS!FISMA

f n�2mi g 1/2 g&p l_n02mq�Fh2�>)�YwtFH1/2'wS2'>�l_5�l<, g >�+�2El<5�FHn g 7'o:a-�IS:HPdvS!F�WYefdIiYS!efS!FpB[GL�[GW\HMF�efS�[=L`dI�oHPE-EZSUXPS�L`i�Q!��L�[L�_�nIFoN�[GW\HMFz� Q-W\Fg[ZSUET_�LMN�SM��kIS�[GLPW\i�Q-L`OvHPnp[-W\[GQ-WYe(doi\SUe(SUFg[GL�B[ZWYHPF�ø I<� û­AIC N�iYW\SUFM[rHP_b[Z�oS W\Fg[ZSUET_�LMN�S8eKL�];W\F(�onIS!FRN�S¡[Z�oS8noFokpS!EGiY]gWYFIqfWYe(doi\SUe(SUFg[GL�[GW\HMFLPN!N!HPE=kpWYFIq�[ZH�W�[=Q�nRQZLPqPS;doL`[T[GS!EGF�§´[G�IWYQ(eKL�]�ORS©kpSUN!WYkISUk�QT[GL`[ZW�N!LPi\iY]�HME(kI]gFRL`efWYNUL`iYi\]kpS!dvS!FokIW\FIq#HPFK[G�IS¡QTHMdI�IW�Q^[GWYNUL�[ZWYHPFKHP_j[Z�IS7HPdvS!F;WYefdIiYS!efS!Fg[GL`[ZWYHPF;ORLPQZSUk;kpS�QTWYqPF�H`_j[Z�oS_�nIFoN�[GW\HMFz� Q�W\efdIiYS!efSUFM[=L�[GW\HMF4A ¨*a-�oWYQ<N!HPFoN!S!dp[�NUL`F(ORSLPdIdIiYW\S�k#[ZH N�noQT[ZHMefW\ÊUS-_�nIFoN�[GW\HMFoL`iè!Ö^îUØgÛ�Ü8Ú^Ñgè!Ú¤Ò�ç¡Ú^ÑMÛ�ë=Õ�ç�Ú^ÛM�`ÚbÕUðoÛ=ï7ÝpÛ�ÜgÜPÛ�Ü7Ó­ÞPÓ­Ú^Û=ï Ó4ÛM�Pë=ÛGÙMÚ^ÒµÕ�çMÓbÔ�ÛGÖ^ÛmçMÕUÚbçgÛGÛ�ÜMÛ�Ü è!ç�Ü7Ú^ÑMÛÙMÖ^Òµï:è!ÖDÞ©ÜMÛGÓDÒ�îUç�î�Õ�è_^*Ô*ÕUØ�^�Ü�ÝpÛ�èKÓDï:è_^�^�ï Û=ï Õ!ÖDÞ;ð�Õ�ÕUÚ^ÙPÖ^Òµç`Ú�ä4àPÒµï Ò�^\è�Ö]^æÞ�ñ?ÕUÚ^ÑMÛGÖ�ð�Û�è�Ú^ØMÖ^Û=ÓÕUð�Ú^ÑMÛ Ù�^�è!ÚDðYÕUÖ^ïüÔ<ÑgÛGÖ^Û:è�Ú8ÓDëZÖ^ØMÚ^Òµç�Þ��´ÛUä îPäµñ�\Uè!Ö^ÒµÕ�ØMÓ�Ú¾ÞMÙpÛGÓrÕUð�Ú^ÑgÛ�ã�í�âh�*êÌÚ¾ÞPÙpÛ¡ï Õ`ÜMÛ�^´ñÜPÞPç�è!ï Òµë�Òµç�\�Õ�ë�è!Ú^ÒµÕUçKÓDØgÙgÙpÕ!ÖDÚ<ÛGÚ^ë�ä �

nIFIW\[GQ#H`_-[Z�IS�e(W�kIkpiYS!�-L`EGSKdIi�L�[Z_�HPEGe©A��7Ä QTnIqMqPS�Q^[=Q:QTSUXPSUEGLPi<kpW�¦?S!EGS!Fg[�iYS!XMS!i�Q:HP_rkIHPWYFIq[Z�oL`[U�IE=L`FIqMW\Foq�[GHfN!i\WYS!Fg[dIEGH�X�WYkISUk�W\efdIiYS!efS!Fg[=L�[ZWYHPF©H`_�[Z�oS nIFIW\[�LPQ�ÉoFoLPi4WYFoQ^[=L`FoN!SPA

� �A�� !�¤{��b~���}<|(�

�rS!i�L�[GSUk���HPEG��HPF�[Z�IS+[ZHMdIW�N!Q�kpW�QZN!noQZQZSUk�W\FÌ[Z�oWYQ©dvHMQZW�[GW\HMFÌdoLPdRSUE�N!L`F�ORS�OIEGHMLMkpi\]N�i�LPQGQTW\ÉoSUk�W\Fg[GH(LPdIdIEGHMLPN=�oSUQ�[G�oL�[rdIEGH�X�WYkIS(¿!» ° ¬D¹�¸ ±\Ã�¼ ¬ ± ¹�®([Z�oEZHMnIqP��QT[GL`[ZW�N8HPE-kp]�FoL`efW�NdRHMi\W�N�]£QZS!iYSUN�[GW\HMF4� ½ ª/�rª=¿!¬ ± ¹`®�[ZH+LPkILPdp[�efW�kIkpiYS!�-L`EGS;W\Fg[GS!EGFoL`i�Q [GH�N=�oLPFIqPWYFIq�EGnIFg[ZWYefSN�HPFRkpW�[GW\HMFoQU�ML`FRk�¿G¹`®UÀ�Á`» ½Z¼ ¬ ± ¹`®:OoLMQTS�kfHPFKX�L`EGW\HMnoQ*_�HMEZeKQ�HP_jLMQTdvSUN�[�kpS!ÉoFIW\[ZWYHPFoQUAM¢�noN=�H`_?[Z�IS7kpWYQGN�nRQZQZSUkfdIEGH t S�N�[=Q�noQZSQTSUXPS!E=L`ioH`_?[Z�IS�QTS[ZSUN=�oFIWYÆgnIS�Q!Ab��S7OIEZWYSY�R]#kpW�QZN!noQGQ�QZHPefSH`_�[Z�ISUe OvS!iYH�� AC�QT[ZiYS!]�ª!¬ ¼�³ � ø I ûjLPN=�IWYS!XMS�efWYkokpi\SU��LPEZS¡N�nRQ^[GHPefW\Ê�L�[GW\HMFK[Z�IEGHPnoqP�;[GSUN=�IFoWYÆgnIS�QmORLPQZSUk

HPF�QTSUdoL`E=L�[GW\HMF�H`_*N�HMe(e#nIFIW�N!L`[ZWYHPF�QT[^]�i\S�Q�_�EZHMe&dIEGH`[GH�N!HPi�QmLPFok©L�_�E=L`efSU�mHMEZ�(_�HPErdoEZHPB[ZHpN�HMiIN�HPefdvHMQZW�[GW\HMF4A�ZInoET[G�IS!E�LMQTdvSUN�[GQ�[G�oL�[�N!EZHgQZQ*N�nI[�[Z�ISQZ]pQ^[GS!e¥WYefdIi\SUefS!Fg[GL`[ZWYHPFKL`EGSFIH`[S!Ç�doi\W�N�W\[ZiY]�LPkokpEZS�QZQZSUk4As�S!XMS!E=L`iodoEZH t SUN�[=Q�S!ÇpdIi\HMW�[-EGSY�oS�N�[ZWYXPS7dIEGHPqPE=L`efefWYFIq [ZS�N=�IFIW�ÆgnISUQm[ZHfL`iYiYH���[Z�IS8efWYk�B

kpi\SU��LPEZS#dIi�L�[T_�HMEZe�[ZH�LPkILPdp[8W\[GQZS!i\_�[ZH�N=�oL`FIqMW\Foq�EGnIFg[ZWYe(SKN!HPFokpW\[ZWYHPFRQ!Aja-�IW�Q¡W\FRN�iYnokpSUQdIEZH t SUN�[GQ<QZnoN=�;LPQ<HPdvS!Fv�8� ÿø T û­�`HPdvS!Fvlr�8�� �CÅø ICT û­�PL`FokKkI]gFRL`efWYNUa¤C�� ø IbI û·AP�SUN�SUFg[dIEZHMqPEGSUQGQ4WYF�[G�IW�Q�LPEZS�L�oLMQ�ORSUS!FfQTnIefeKL`EGWYÊ!SUk�W\F(L�EGSY�RSUN�[GW\XMSmefW�kIkpiYS!�-L`EGS���HPEG�pQT�IHMd6¡`A

e4S!qp�8� £¢£ø I<V û�L`FRk�V�FIWYXPS!E=QGL`iYi\]£ÄDFg[ZSUEZHMdRSUEGLPOIiYS�lmHMEZS£§¾VÄZl-¨]¤�L`EGS©efW�kIkpiYS!�-L`EGSdIiYL`[T_�HMEZeKQ8kpSUQZW\qMFISUk�_�HPE��RL`Fok�B­�ISUiYk�kIS!X�WYN!SUQU�R�r�oWYN=�+L`iYi\H��ÿ_�HPE8WYFM[GS!EGHPdvS!E=L`OIWYiYW�[^]��rW�[G�Q^[=L`FokILPEGk�doiYL`[T_�HPEGeKQ!A- �H`[G��H`¦?S!E©Q^[=L�[ZW�N�LPFok�kp]�FoLPefWYN�N�HPFIÉoqPnIE=L�[GW\HMF�L`Fok�LPW\e�[GHefLPW\Fg[=L`WYFfL QZeKL`iYiIefS!efHPEG] _�H�H`[GdIEGW\Fg[<O�]�HMFIi\]#H`¦?S!EGW\Foq7[G�ISr_�nIFRN�[ZWYHPFRL`iYW�[^](L`FKL`dIdoi\W�N!L`B[ZWYHPFfLPN�[GnoL`iYiY]8FoS!SUkoQ!AMlmnoQT[ZHMefW\Ê�L`OIiYS�_�noFoN�[GW\HMFoQ�EGLPFIqPS�_�EZHMe [Z�ISm[ZE=L`FRQTdvHPEZ[�doEZHP[ZHpN�HMiP[GHe(S![Z�IHpk©kpW�QTdoL`[GN=�IWYFIq(L`Fok�efLPEGQZ�oLPi\iYW\FoqoAM �HP[Z��doiYL`[T_�HPEGeKQmkIH#FIHP[-QZnIdIdvHPEZ[�[Z�IS8FIH`[GW\HMFH`_<LPQZdRS�N�[=Q�LPQ�N�HpkpS�N!EZHgQZQN!np[T[GW\Foq�N�HMFoN�SUEZFRQ!AoC7QTdvSUN�[GQ�W\F�[G�IS�QZS!FoQZS:HP_|ebS!qp�8� �LPFokVÄZl�L`EGS7_�noFoN�[GW\HMFoL`ijnIFoW�[=QQTnodIdRHMET[GW\FoqfLPdIdIiYWYNUL�[GW\HMFpB·iYS!XMS!i?EGSUÆgnIWYEZSUe(SUFg[GQUAs�W\efWYiYLPEZiY]P��JMHPFoL`[Z�oLPF#¥�N!HPFoQT[ZW\[Znp[GSUQ�L`F�HPdvS!F;efW�kIkpiYS!�-L`EGS_�E=L`efS!��HPEG��[G�oL�[-N!LPF�OvS

N�noQT[ZHMe(WYÊ!S�k��rW\[Z��EGSUQZdvSUN�[7[ZH©L;i�L`EGqPS:F�nIe#ORSUE7HP_�_�nIFoN�[GW\HMFoQUA?JMHPFRL�[Z�RL`F�L`WYeKQ[GH�SUe#BOIEGLMN�S QZS!XPSUEGLPijQ^[=L`FokILPEGk�efWYkokpi\SU��LPEZS¡dIi�L�[Z_�HPEGeKQrL`Fok©H`¦?S!E7N�noQT[ZHMe(WYÊUL`[ZWYHPF�LPNUN�HPE=kpWYFIq[ZH;L`dodIi\W�N!L`[ZWYHPF�FIS!S�kIQ!AoÄ­[�N!L`F©OvS:N�HPFIÉoqPnIEGSUk�[ZHfnoQZS ÄTÄZ�8þ�HME-��¢�Ä�Aa-�ISfS�¦?SUN�[GW\XMS!FIS�QZQ¡HP_�[G�ISKHPdvS!F+W\efdIiYS!efSUFM[=L�[GW\HMF+efS![GL`do�IHPE¡_�HME7[G�IS;kpS�QTWYqPF+H`_-L

i\WYqP�g[TB­��S!WYqP�g[-[Z�IEGSULMk�dRLPN=��L`qMS8W�QkpSUefHPFoQT[ZE=L�[GSUk©O�]�@�LPW\FoSUQ:ø ``û­Aoa-�IS:EGS!FoS!��SUk©kpSUQZW\qMFi\S�LPkIQ�[ZH�L�efHMEZS#SY*;N�WYS!Fg[ L`Fok�dvHPEZ[GLPOIiYS#doLMN=��L`qPSMA#���IWYiYS#[G�IW�Q8LPdIdIEGHMLMN=��WYQ8FIHP[8dIEGW\BefLPEZWYiY];LPkIkpEGSUQGQZW\FIq#efWYkIkIi\SU��LPEZS8dIi�L�[T_�HMEZeüW�QGQTnIS�Q�dRSUEQTSM�gW\[reKL�];L`i�QTH(dIEGH�XPS�S!¦vS�N�[GW\XMS_�HPE-[Z�oS:kpSUQZW\qMF�HP_¤_�noFoN�[GW\HMFoL`i4noFIW�[=Qr�rW\[Z�IWYF�L#doiYL`[T_�HPEGe�A mEGHpkIQZ�g]�ª!¬ ¼�³¦� ø V û4kpSUe(HMFoQT[ZE=L�[ZS7XPSUEZ]KSUi\SUqML`Fg[Gi\]([Z�oS8nRQTS8H`_¤LMQTdvSUN�[rHPEGW\SUFM[GSUkKdoEZHPB

qPE=L`efefW\FIq�_�HPE N�nRQ^[GHPefW\Ê�L�[GW\HMF�L`FRk�S�Ç�[GS!FoQZW\OoW\iYW�[^]�HP_mL©kpWYQT[ZEGWYOInp[ZS�k�ÉRi\SKQZ]�QT[ZSUeýefWYk�Bkpi\SU��LPEZS8�rW\[Z�©_�L`nIi\[[GHPiYS!E=L`FoN!S�_�S�L�[ZnoEZS�Q!AJMLMN�HPORQTSUF�L`Fok�§¡E<¨LPe(SUE#ø ù�û<QZ�IH�� �IH�� [ZH©��SUL�XPS#W\Fg[GS!EZ_�LPN�S#i\SUXPSUi�QZdRS�N�W\ÉRN!L`[ZWYHPF�H`_

QT]�FoN=�IEGHPFoW\Ê�L�[ZWYHPFKN!HPFoQT[ZE=L`WYFg[GQ<WYFg[ZH(Q^[GnIOoQ�L`Fok;QZ�PSUi\S![ZHMFoQ<qMS!FISUEGL`[ZSUk;Og]fQT[GL`FRkIL`E=kKÄ^cJe© Ñ�ÚDÚ^Ù&ª «<«�Ô�Ô�Ôrä ëGÕ�ï ÙRä ^�èUçMë=Ó=ä èUë�ä ØM×�«�ë=Õ�ï ÙMØMÚ^ÒµçgîC«�Ö^ï�õ!ö�ö�ö<«¬ Ñ�ÚDÚ^Ù&ª «<«!ÜMÛ�\`ÒµØgÓ=ä ë=Ó=ä ØgÒµØMë�ä Û�ÜMØ'«�õ!×E«!òRÛ=î�í�â£�|«­ Ñ�ÚDÚ^Ù&ª «<«�Ô�Ô�Ôrä ØMÝgÒæì�ë=ÕUÖ^ÛUä ëGÕ�ï6«® Ñ�ÚDÚ^Ù&ª «<«�Ô�Ô�Ôrä ÕUÝb¯·Û=ëGÚ¾Ô*Û=Ýoä Õ!Ö^î�«°¯­Õ�çgè!Ú^ÑgèUç�«°¯­ÕUç�è!Ú^ÑgèUçE±�Õ�ï Û=åjèUî�ÛUä Ñ�Ú^ï

N�HPefdIWYiYS!E=Q!A?a-�IW�Q���HPEG��W�Q8S�Ç�[ZSUFok�WYF�JgLPN!HPOoQZS!F�LPFok²§¡EC¨L`efS!E(ø ³`û¤[GH�LPiYQZH�LMN!N�HMnIFg[�_�HMEH`[Z�oS!EfLPQZdRS�N�[GQ(kpS!ÉoFISUk�L�[([Z�IS©WYFM[GS!EZ_�LPN!S�iYS!XPSUi8§�SPA qoAY�|´7H�s£L`FoFIH`[=L�[ZWYHPFRQ!��ORSU�oL�X�W\HMEGLPiL`FIFIHP[GL`[ZWYHPFoQU��LPFok�dIEZS�L`FRk�dvHMQT[fN!HPFokpW\[ZWYHPFRQG¨�A*C0dIEGHpN�S�QZQZW\Foq�_�E=L`efS!��HPEG��ORLPQZSUk�HMF[Z�IS S!Çg[GS!FokISUk©eKL`EG�gnod�i�L`FIqMnoL`qMS(§/µ7¢²e�¨m_�HPE-[G�IWYQ�L`dIdIEGHMLMN=��W�Q-dIEGSUQZS!Fg[ZS�k�WYF£ø ¶�û·A

�·��¸M�b|(�bz������

÷�ä���ä�êmÓ­Ú]^µÛGÞ�ñ_¹8ä`ãmä�à`Ú^ØPÖ^ï:èUçRñUè!ç�Ü�º7ä�êä�ê�î�ÑgèPäoã�ØMÓ­Ú^Õ�ï Ò�»�èUÝE^µÛ�ï Ò�ÜMÜE^µÛGÔ�è�Ö^Û�ð�ÕUÖ¤ï Õ`ÜMØE^�è!ÖÓDÕ!ðYÚ¾Ô�è!Ö^ÛUä½¼�¾?¿À¾�Á_Â�ÂJÃ�Ä�ÅGÆ]Ç_ÈÉÅÉÁ_Ä�Ê^ñ'Ë_Ë��/Ì_�Zñ��fè=ÞfõUö�ö`÷�ä

õ`ä�º7ä<àIä|��^\è!ÒæÖ�ñhº7ä�ã�Õ�ØE^�ÓDÕUçRñ�êä<êmçgÜMÛGÖ^ÓDÛ=çoñ½��ä�ã0^�è�Ö^×�Û�ñ½Í�ä ��ä<ã�Õ�Ó­ÚTèPñ ±�ä�ê�ä0¹-ØMÖTè!çRñâä��(ÕUÖ^Û=ÒæÖTè`ñIß7äMåjè!Ö]^�èQ\�è!ç�Ú]»�èUÓ=ñIè!ç�Ü�ô¡ä'�mäpàMè!Ò�×�Õ�ÓD×`Ò´ä*Ð*ÑMÛÜMÛ=ÓDÒµî�ç;è!ç�Ü�Ò�ï ÙE^µÛ=ï Û=ç�ÚTè!Ú^ÒµÕ�çÕ!ðbí�ÙpÛ=ç�í�â£�m\�ÛGÖ^ÓDÒµÕ�ç;õ�ä0ÎvÏ�Ï�ÏtÐ�ŦÊ!ÈÉÑ!ÅGÒMÃ�È3Ó°ÔÖÕ�×�Ê]È3ÓØÂJÊuÙHÄ�Ú ÅÛÄ(Ó�Ü�Á_Ã�Ñ!Ä�Ç<Ú ñ�õb�GÝ<�ZñIõUöUöP÷Uä

Þ äê ^µÛM�u�¤Ö^Õ`ÜPÓD×�Þ�ñC¹-Òµï:èß�¤Ö^Õ`ÜPÓD×�Þ�ñ�à­ÜMèã�Ñ�èUçoñ<á£\�Õ�çMçgÛmã�Õ�èUÜPÞ�ñ�âUÕ`ÜPÞ:å?ÕUï ×�Õ�ÓD×`Ò´ñ�è!ç�Ü�ºmÖ^ÛGìîUÕUÖ7ôrÒµë�»�è_^µÛ=Ó=äfêmÓDÙpÛ=ëZÚDì¾Õ!Ö^ÒµÛ=ç�Ú^Û�Ü�ÒµçgëZÖ^Û=ï Û=ç�ÚTè_^bë=ØgÓ­Ú^ÕUï Ò�»�è!Ú^ÒµÕ�ç�Õ!ð<ï Ò�ÜgÜE^µÛGÔ*è!Ö^Û ÓDÛGÖ]\`Òµë=Û=Ó=äà`ØgÝMï ÒµÚDÚ^Û=Üoä

ËMä��fè�ÚDÚ^ÑgÛGÔ�±-è!ÒµçgÛ=Ó=ä�êmç�ÕUÙpÛ=ç�Òµï Ù�^µÛ=ï Û=ç�ÚTè�Ú^Ò�ÕUç�è!ç�è_^æÞPÓDÒµÓfè!ç�Ü�ÜPÛ=ÓDÒµî�ç�ð�Õ!Öã^µÒµî�Ñ�Ú¾Ô*Û=Òµî�Ñ�ÚÚ^ÑPÖ^Û�è�ÜPÓ=äzà·çäÙßÙ�åHÕ�æ�¼�ñMÙ�èUîUÛ=Ómõ�õ�ç�è#õ�Ë�õ`ñv÷�ç<ç<é`ä

Ì`ä�±�ä ì·êäzâ�è!ë=Õ�ÝMÓDÛ=çRä�åjÖ^Õ�î!ÖTèUï ï Òµçgîê^�èUçgîUØ�è!î�ÛfÒµç�Ú^ÛGÖ^Õ�ÙpÛZÖTèUÝgÒ�^µÒæÚ·Þ�Òµç�ÜMÒµÓ­ÚDÖ^ÒµÝgØPÚ^Û�Ü�ëGÕ�ï ÙgØPÚDìÒµçMî�ÛGçb\`ÒæÖ^Õ�çMï Û=ç�Ú^Ó=ä½à·ç;òoÛ�è�ôrØPÚ]\�Õ�çMÛ=çRñE±-è�Ö^ï8ØMç`Ú�ôrçMÒ�îPñIèUçgÜê�fè!ÖDÚDÚ^ÒjÐ*ÒµÛ=çgè!Ö^Ò´ñoÛ�ÜMÒæÚ^ÕUÖ^Ó=ñÕ�Ó°Æ!Á�Ä�Ô:ÎvëzÎvåíìãÁ_Ñ°î�ÅÛÄ�ïm¾�Á_Ä�ðQÓØÑ]ÓØÄ'Æ!Ó:Á_Ä�ÐßÅÛÊ]ÈÉÑØÅÉÒMÃbÈ3Ó°Ô:¼0ñCñ�Ú ÅGÆ]Ç_ÈÉÅGÁ�Ä�ÊsÇ�Ä�ÔêÎ!Ä�È3ÓØÑvÁØñEÓØÑ°Ç<Ò�ÚòÓÕE×_Ê]È3ÓØÂ�ʣΰÎJóÛн¼ Î!ÕCô�ñ'±mÛ�^µÓDÒ�çM×`Ò�ñ�Í?Òµç�^�èUçgÜoñ�â�ØgçMÛ8÷Qç_ç<ç`äpô�^µØ`Ô�ÛGÖmêmë�èUÜMÛ=ï Òµërå4ØgÝE^µÒ�ÓDÑMÛGÖ�ä

ÝPä�±�ä ì·êä(â�è!ë=Õ�ÝMÓDÛ=ç�èUçgÜ:��äRô-ÖYõè!ï ÛGÖ�äd¹-Û=ÓDÒµîUç©Ù�è�ÚDÚ^ÛGÖ^çgÓmð�ÕUÖÓ­ÞPçMëZÑPÖ^Õ�çgÒ�»�è�Ú^ÒµÕ�ç�èUÜgè!ÙMÚ^ÕUÖ^ÓrÕ!ðã�í�âh�*ê�Õ�Ý�¯­ÛGëGÚ^Ó=äÖÕ_ñEÓ°ÆMÅGÇ<Ú"ÅÛÊ]Ê]Ã'Ó�Ávð�ædö Ù�÷ Ü�Ï�øtÜ�Á_Ã�Ñ!Ä�Ç<Ú�Á_ÄSù_Ù|ÒÛúYÓ°ÆMÈ�ÙHÑ!Å/ÓØÄEÈ/Ç_ÈÉÅGÁ_IJÇ�Ä�Ôë&Á_ÑØÂBÇ<Ú'¿ûÓØȦüEÁQÔ_Ê^ñoõ!ö�ö�ö`ä0±mÛGÖ^ï Û=Ó<å4ØgÝE^�ÒµÓDÑMÛGÖ�ä

é`ä�±�ä ì·êä�â�è!ë=Õ�ÝMÓDÛ=ç�èUçgÜu�mä�ô-ÖYõèUï ÛZÖ�ä&�(Õ`ÜMÛ�^µÒµçgî�Òµç`Ú^ÛZÖDð´èUëGÛ�ÜPÛM��çMÒµÚ^ÒµÕUçu^\è!çgîUØ�èUîUÛ�ÛM�`Ú^Û=çMÓDÒµÕ�çgÓ=äà¾çsýbþYȦüBÎ!ÄEÈ3ÓØÑØÄ'Ç_ÈÉÅGÁ_Ä'Ç<Ú"¾�Á_ÄQð�ÓØÑ]ÓØÄ�Æ!Ó�Á_Äûø(Ó°Æ!ü�Ä�Á<Ú�Á]ï_×BÁvð�Ù½ÒÛúQÓ]ÆMÈGÿ]ÙHÑ!Å/ÓØÄ�È3Ó°Ô�æ?Ç_Ä�ï_ÃEÇQï�ÓØÊßÇ�Ä�ÔÕE×_Ê]È3ÓØÂ�ÊuóØøHÙ£Ù�æzÕ�ÿ3ýbþ]ô�ñpà`ÞMÜMçMÛGÞ�ñPêmØMÓ­ÚDÖTè_^µÒ�èPñpõUö!ì·õ Þ ß�ÕY\�Û=ï7ÝpÛGÖ�õ!ö�ö�ö`ä

� ä�±�ä ì·êä�â�è!ë=Õ�ÝMÓDÛ=çfè!ç�Ü6�mäbâMäPô-ÖYõèUï ÛGÖ�ävê�ÜMÛ=ÓDÒµî�ç�Ù�è�ÚDÚ^ÛGÖ^ç:Ý�è!ÓDÛ�Ü(è!ÙgÙMÖ^Õ�èUëTÑ�Ú^Õ�î�ÛGçgÛGÖTè�Ú^Ò�çMîÓ­ÞPçMëZÑPÖ^Õ�çgÒ�»�è�Ú^ÒµÕ�ç;è�ÜMèUÙPÚ^ÕUÖ^Ó<ðYÖ^Õ�ïÅè!çgçgÕ!ÚTè!Ú^Û�Ü�à3¹ròbä0à·çêÎvÏ�Ï�ÏS¼ ÃbÈ/Á�ÂuÇ_È3Ó°ÔÖÕ'ÁvðØÈ���Ç_Ñ]Ó£Ï|Ä�ÿï_ŦÄ(Ó]ÓØÑØŦÄ�ï�¾�Á_ÄQðQÓØÑ°ÓØÄ�Æ!Ó6óÛ¼£Õ�Ïuö ����ô�ñPÙ�è!î�Û=Ó Ý Þ èbéUõ`ä'à·á¤ábá�ã�ÕUï ÙgØPÚ^ÛGÖ�àPÕ�ëGÒ�ÛZÚ·Þ�ñgàPÛ=ÙPÚ^Û=ï8ÝpÛZÖ÷�ç<ç � ä

çPä�º7ä`ôrÒµë�»=è_^µÛ=Ó=ä4ê�ÓDÙpÛ=ëGÚDì�ÕUÖ^ÒµÛ=ç�Ú^Û�Ü ÙMÖ^ÕUîUÖTè!ï ï Ò�çMîMä"¼�¾?¿ ¾�Á_Âhñ'Ã�È��&Õ�Ã�Ñ��ñgõ � �ÉË��Zñb¹-ÛGë7÷Qç_ç<Ý`ä÷=öPä�ºmÖ^ÛGî�ÕUÖ8ôrÒµë�»�è_^µÛ=Ó=ñ�âUÕ�Ñgç�òRèUï ÙMÒ�çMîMñjã�ÑMÖ^ÒµÓ­Ú^Òµç�è��Ò�ÜMÛGÒµÖTè;òoÕ�ÙpÛ=Ó=ñbã�ÑPÖ^ÒµÓu�fèUÛ=ÜgèPñjêmç`ØMÖTè!î

�(ÛGç�ÜMÑMÛ=×Uè!Ö�ñIè!ç�Üêº-èUÒ�^��(ØMÖ^ÙMÑ�Þ�ärí�ÙpÛ=çKÒµï ÙE^�ÛGï Û=ç�ÚTè!Ú^ÒµÕ�ç;ÜPÛ=ÓDÒµî�ç�î�ØgÒ�ÜPÛ�^µÒ�çMÛ=Ó=ä�à¾ç²Å¦Ä�È3ÓØÑØÿÄ'Ç_ÈÉÅGÁ_Ä'Ç<Ú�Æ]Á_Ä�ðQÓØÑ]ÓØÄ'Æ!ÓJÁ_ÄjÕ�Ávð!È��0Ç�Ñ]ÓJÓØÄ�ï_ÅÛÄ(Ó]ÓØÑ!ÅÛÄ�ïUñ�Ù�èUîUÛ=Ó½Ë � ÷ßè�ËCçUöPñv÷�ç<ç<é`ä

÷U÷�ädÍgèUÝgÒµÕ7ôrÕ�çRñE�fè!ç`ØgÛ�^Iâ�Õ�ï �èUçoñPåbÒµçMî¡òRÒµØoñ�âUÒ�çgèu�fèUÕPñ�ÐRÕ�ï Õ�çMÕUÖ^Ò'á�èUï:è!çgÛ�ñPòoØgÒ�»ã0^�èUØgÜMÒµÕ�fè!î�è�^�Ñ��èUÛ=Ó=ñjèUç�Ü�âmÕ�Þê±7ä?ã*èUï ÙMÝpÛ�^�^�äã�(ÕUçgÒæÚ^ÕUÖ^ÒµçgîPñbàPÛGë=ØMÖ^ÒæÚ·Þ�ñRè!ç�Ü:¹mÞMçgèUï Òµë:ã�ÕUçE��îUØMìÖTè�Ú^ÒµÕ�ç©Ô<ÒæÚ^Ñ�Ú^ÑMÛ ÜPÞPçgèUï Òµë�Ð?ê�íÌâ�Û���ÛGëGÚ^Ò�\�Û í�âh�mä�à·çûåHÑ°ÁQÆ!Ó]Ó]Ô�ÅÛÄ�ï_Ê6ÁvðBȦü�ÓJÎvëzÎvå���¼�¾?¿Î!ÄEÈ3ÓØÑØÄ'Ç_ÈÉÅGÁ_Ä'Ç<ÚH¾�Á_Ä�ðQÓØÑ]ÓØÄ'ÆØÓuÁ_ÄsÐ�ŦÊ!ÈÉÑ!ÅGÒMÃ�È3Ó°ÔãÕ�×�Ê]È3ÓØÂJÊ£å½Ú�Ç�È ð�Á_Ñ!ÂJÊ�Ç_Ä�ÔêÙ�ñEÓØÄjÐßÅÛÊ]ÈÉÑØÅÉÒMÃbÈ3Ó°ÔåHÑ°ÁQÆ!ÓØÊ]Ê]ÅÛÄ�ïûóÛ¿jÅGÔ<ÔEÚòÓ��Ç_Ñ]Ó�ö �������Øô�ñIç`Øgï7ÝpÛGÖr÷Yé�çCÌ Òµç�òoßrã�àpñ�Ù�è!î�Û=Ó�÷�õ�÷Øè�÷MË Þ ñvßmÛGÔ�á¤ÕUÖ^×pñê�ÙMÖ^Ò�^RõUöUö�öPäIàPÙMÖ^ÒµçMî�ÛGÖDì�bÛGÖ]^�èUîMä

÷�õ`äÐ�ä�òRÛ=ÜMÕ�Øb�Iä�í�ÙpÛ=çpã�Õ!Ö^Ý�è�ª*ê¥Ö^Û���Û=ëZÚ^Òò\�ÛfÕ�ÙpÛ=ç�ÝMÖ^ÕU×�ÛGÖ�äræ�Ó°ÆMÈÉÃ�Ñ]Ó��dÁ_È3ÓØÊãÅÛÄA¾�Á_Âhñ'Ã�È3ÓØÑÕ'ÆMÅ/ÓØÄ�Æ!ÓZñR÷QÝP÷�Ýbªµ÷Qç<éQè�����ñ4÷Qç_ç<ç`ä

÷ Þ ä��fè!ç`ØgÛ�^¤âmÕUï:èUçRñ?��ä?¹-Û=çgçMÒµÓB�(ÒµëT×PØMç�è!Ó=ñ"Í�è!ÝgÒµÕKôrÕ�çoñ?è!ç�Ü©â�Õ�Þ�ã*è!ï ÙgÝpÛ�^�^´äKòoÛ=î�í�âh�è!ç�Ü�ØMÝgÒ���ØgÒæÚ^Õ�ØMÓ8ã�í�âh�*êä�â�Û��gÛ=ëGÚ^Ò�\�Û6�(Ò�ÜgÜb^�ÛZÔ�è!Ö^Û�é�Õ!Ö^×PÓDÑMÕ�Ùoä�±�ÛM^\Ü�Òµç�ë=ÕUç_¯­ØMçgëGÚ^ÒµÕUçÔ<ÒæÚ^ÑA�(Ò\ÜMÜE^µÛGÔ*è!Ö^Û�õUöUö�öPä�Ñ�ÚDÚ^Ù&ª «<«�Ô�Ô�Ôrä ëGÕ�ï ÙRä ^�èUçMë=Ó=ä èUë�ä ØM×�«�ë=Õ�ï ÙMØMÚ^ÒµçgîC«�Ö^ï�õ!ö�ö�ö<«`ñ�é�Ú^ÑMì� Ú^Ñfê�ÙMÖ^Ò�^?õ!ö�öUöPä

Aspects of Exceptions at the Meta-Level(Position Paper)

Ian S. Welch1, Robert J. Stroud, and Alexander Romanovsky

Department of Computing, University of Newcastle upon Tyne,United Kingdom NE1 7RU

{i.s.welch, r.j.stroud, alexander.romanovsky}@ncl.ac.ukhttp://www.cs.ncl.ac.uk/research/dependability/reflection/

1 Introduction

This paper describes the design and usage of a metaobject protocol that explic-itly includes support for handling exceptions. We do not propose implementingexception mechanisms anew [3, 5] or proposing a unified meta-level software ar-chitecture for exception handling [4]. To make our discussion concrete we de-scribe an extension of the Kava [9] metaobject protocol that includes exceptionsas first class values, provide examples of Kava’s use, and compare Kava withrelated Java extensions.

We believe that insufficient attention has been paid to exceptions by de-signers of metaobject protocols for object-oriented languages. Most metaobjectprotocols provide a way of intercepting method execution but these protocols areusually discussed solely in terms of arguments and results. Signalled exceptionsare rarely discussed. However, in order to successfully implement non-functionalrequirements using metaobject protocols it is important that exceptions are ex-plicitly considered. For example, consider using a metaobject protocol approachto implement distributed objects. It is not sufficient just to convert method callsinto remote method calls, exceptions must be converted into remote exceptionsas well. Therefore, a metaobject protocol should be designed to treat methodarguments, method return values and exceptions equally. This means that ifthe behaviour of method execution is reflected upon, then any signalled excep-tion should be reified and be manipulable at the meta-level. Note that such a“exception-aware” metaobject protocol should not lead to base-level program-mer’s expectations being confounded, as doing so would make both programmingand verification very difficult. For example, the exception model should not beable to be changed dynamically, say from a termination model to a resumptionmodel (as opposed to [2]).

2 Meta-Level Requirements

What facilities should a “exception-aware” metaobject protocol have? We pro-pose that such a metaobject protocol needs two facilities: meta-level interception

of exceptions signalled from the base-level, and meta-level raising of exceptionsat the base-level.

Meta-level interception is required to handle new exceptions introduced asa side-effect of the implementation of non-functional requirements. It may alsobe required to reinterpret existing base-level exceptions in the context of newnon-functional requirements. An example of this was given in the introductionwhere distribution requires that local exceptions are reinterpreted as remoteexceptions.

Meta-level raising of exceptions at the base-level is required to allow metaob-jects to raise new types of exceptions and maintain the transparency of the meta-layer. For example, a metaobject may enforce a security policy by raising a secu-rity exception whenever the security policy is violated. Since we normally wishto implement non-functional requirements transparently this exception shouldappear to be raised at the base-level. If it appears to have been raised by themetaobject then the meta-level becomes visible to any clients of the base-leveland then transparency is shattered.

These two features allow the metaobject protocol to support the followingmappings between exceptions and values: from one exception to another, fromone exception to a value, or from a value to an exception. In the remainder ofthis section we provide examples of how these mappings can be used.

Exception to exception. Adding debugging information to exceptions re-quires that one exception is mapped to another. Here, we want to add meta-information to an exception such as the time it was signalled. An extendedversion of the exception class could be defined that encapsulates the base-levelexception and the meta-information. At the meta-level the signalled exceptionis replaced by an instance of the extended exception class.

Exception to value. Logging and then ignoring an exception requires thatan exception is mapped to a value. Here, the base-level exception is suppressedand the method terminates normally returning a value specified at the meta-level.

Value to exception. Assertion checking [7] requires that a value is mappedto an exception. Here, a value of a member variable or argument of the methodcauses an exception to be raised. This exception will appear to be raised at thebase-level to preserve transparency.

3 Kava

Kava is a reflective Java implementation [9]. It uses byte code transformations tomake constrained changes to the binary structure of a class in order to providea metaobject protocol that brings object execution under the control of a meta-level. These changes are applied at the time that classes are loaded into theruntime Java environment. The meta layer is made up of metaobjects that arewritten using standard Java. The binding between classes and metaobject classesare specified in an XML configuration file called a binding specification. Kava

brings the sending of invocations, initialisation, finalization, state update, objectcreation and exception signalling under the control of a metaobject protocol.

When a meta-level programmer creates a new metaobject class, the pro-grammer extends the default metaobject class and overrides those methods thatcontrol the behaviours the programmer wishes to redefine. In Kava we definearound style meta methods, so for each behaviour there is a before and aftermethod.

The following listing shows the methods relating to overriding method exe-cution in the metaobject class interface,

public interface IMetaObject {...public void beforeMethodExecution(IMethodExecution context)throws Exception;

public void afterMethodExecution(IMethodExecution context)throws Exception;

}

A context object is passed as an argument to each of the meta-level methods.The context reifies the context of the metainterception as a context object thatimplements the IMethodExecution interface. In earlier versions of Kava excep-tions that were raised during the execution of a method were not included inthe context. Now, any exceptions that have been raised is included in the con-text in addition to reified method, its actual parameters, and the result of theexecution of the method. In addition to reifying exceptions the context API hasbeen extended to support the reflection of the exception back to the base-leveland the overriding of the exception signalling at the base-level.

We are currently examining how this extended metaobject protocol can beused to implement Java language extensions such as multi-level handlers forexceptions (statement, block, method, class and exception level), design by con-tract, and n-version programming).

4 Examples

In this section we show how to use Kava to implement the examples describedin the meta-level requirements section.

First, we show how an exception can be intercepted and converted to anothertype. Here, the exception is converted to an instance of an exception class usedfor debugging which encapsulates the base-level exception, the key to this is usingthe setException method to change the exception raised at the base-level,

public DebugMetaObject extends MetaObject {public void afterMethodExecution(IMethodExecution context)throws Exception {if (context.isExceptionRaised()) {

context.setException(new DebugException(context.getException())); }}}

The next example shows how an exception can be mapped to a value andthe exception raising at the base-level suppressed. This metaobject is used tolog and suppress IOExceptions exceptions. It checks that the base-level methodexited because an exception was raised. The base-level exception is suppressedthrough the use of the overrideException method,

public LogMetaObject extends MetaObject {public void afterMethodExecution(IMethodExecution context)throws Exception {if (context.isExceptionRaised()) {

Exception e = context.getException();if (e instanceof java.io.IOException) {

context.overrideException();log(e); }}}}

The final example shows a mapping from a value to an exception. We wantto check that a method never returns a null value. First, we check using theconvenience method getReturnType returns an object reference, then we checkthat the value of that reference is not null. If it is null then we throw anAssertionFailed exception,

public AssertMetaObject extends MetaObject {public void afterMethodExecution(IMethodExecution context)throws Exception {if (context.getReturnType() == Type.OBJECT) {

if (context.getReturnValue() == null) {throw new AssertionFailed(); }}}}

5 Related Work

Although exceptions are an integral part of the Java language there has beenlittle explicit attention paid to them by the Java reflection community with theexception of Garcia et. al. [4]. Garcia et al. have proposed a unified meta-levelsoftware architecture for sequential and concurrent exception handling that isdescribed using a set of design patterns. The patterns cover: Exceptions, Handler,Exception Handling Strategy, and Concurrent Exception Handling Action. Theyare attempting to codify “best practice” with regard to the implementation ofreflective exception handling. They have made an implementation using a customJava VM (Guarana [8]) which means it is non-portable. In contrast, our work ismore narrow in focus but has resulted in a portable implementation.

Explicit support for exceptions has been introduced into some Java imple-mentations of portable compile-time Java extensions for programming using ad-vanced separation of concerns. Below we describe the approach to exceptionstaken with AspectJ1 [6] and ComposeJ [10].

1 the version described here is 0.8

AspectJ allows programmers to use aspect-oriented programming techniquesin Java. AspectJ like Kava can be used to map exceptions and values to eachother. An around advice applied to a receptions pointcut can be used to im-plement the mapping of an exception to exception, exception to value, value toexception. This is because around advice selectively pre-empts the normal com-putation at the specified join point. AspectJ also has two new features relatedto exception handling. First, the advice after throwing allows aspects to beinvoked when an exception is thrown (in Java throw is used to raise an excep-tion). This allows extra code to be executed when an exception is signalled butdoes not allow the signalling to be overriden. This is roughly equivalent to theinterception feature in Kava. Second, aspects can be woven into existing excep-tion handler code through the use of the handles pointcut. This allows extracode to be invoked when an exception is handled, and it allows handling codeto overriden. This is feature is not supported in our metaobject protocol as wecurrently choose to intervene only at the level of a method rather than withintry ... catch ... finally clauses.

ComposeJ allows programmers to use composition filters in Java. Composi-tion filters [1] allow messages sent and received by objects to be intercepted andmanipulated. Filters can be composed with other filters to implement complexnon-functional behaviour. There are different types of filters in the model, oneof which has explicit support for exceptions. The Error filter allows predicateson base-level state to be evaluated and an exception to be raised that causes thesystem to halt. This allows the implementation of assertions and contracts inJava. In the current version it is not clear if signalled exceptions are consideredto be message or not. If they are then other filters such as Dispatch could beused to implement mappings that are similar to Kava.

Kava could implement the same functionality as the Error filter. It cannotadd behaviour to exception handlers like AspectJ although we believe that manyuseful extensions for dependability can be developed without that capability. Interms of implementation Kava differs from AspectJ and ComposeJ in that it is aload-time extension to Java and can be used to add non-functional behaviour tocompiled code. This makes it useful for dealing with mobile or third-party codewhere the API may be understood but the source code might not be available.

6 Conclusions

Metaobject protocols must be “exception aware” so that they can be used toimplement a wide range of non-functional requirements. Such a metaobject pro-tocol requires two features to support the successful implementation of non-functional requirements. The first feature is the ability to intercept exceptionssignalled from the base-level, and the second feature is the meta-level raising ofexceptions at the base level. These two features allow the metaobject protocol toimplement mappings between exceptions and values that can be used to improvethe dependability of applications.

There is one reflective Java implementation that is “exception aware” but itis non-portable. There are portable extensions to Java that introduce “exceptionawareness” for advanced separation of concerns but these require access to sourcecode. Our implementation in Kava is portable and applies reflection and load-time. This allows Kava to be used for a wide range of applications such as mobilecode or third-party code.

Acknowledgements

We would like to acknowledge the financial support of the ESPRIT projects:MAFTIA project (IST-1999-11583), and DSOS project (IST-1999-11585).

References

1. M. Askit, L. Bergmans, and S. Vural. An Object-Oriented Language-DatabaseIntegration Model: The Composition-Filters Approach. In ECOOP, volume LNCS615, pages 372–395. Springer-Verlag, 1992.

2. A. Burns, S. Mitchell, and A. J. Wellings. Mopping up Exceptions. In ECOOP’98Workshop on Reflective Object-Oriented Programming and Systems, pages 365–366, 1998.

3. Christophe Dony. Exception Handling and Object Oriented Programming : To-wards a Synthesis. In Proceedings of ECOOP/OOPSLA’90, pages 322–330, Ot-tawa, Canada, 1990.

4. Alessandro F. Garcia, Delano M. Beder, and Cecilia M. F. Rubira. Unified Meta-Level Software Architecture for Sequential and Concurrent Exception Handling.The Computer Journal (Special Issue on High Assurance Systems Engineering),2001.

5. M. Hof, H. Mossenbock, and P. Pirkelbauer. Zero-Overhead Exception HandlingUsing Meta-Programming. 1338:423–431, 1997.

6. Gregor Kiczales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffery Palm, andWilliam G. Griswold. An Overview of AspectJ. In ECOOP 2001, volume LNCS2072, pages 327–353, Budapest, Hungary, 2001. Springer-Verlag.

7. B. Meyer. Design by Contract. In D. Mandrioli and B. Meyer, editors, Advancesin Object-Oriented Software Engineering, pages 1–50. Prentice-Hall, 1991.

8. Alexandre Oliva and L. E. Buzato. The Design and Implementation of Guarana.In Usexnix COOTS, pages 203–216, San Deigo, California, USA, 1999. Usenix.

9. Ian Welch and Robert Stroud. Kava – Using Byte-Code Rewriting to Add Behav-ioral Reflection to Java. In 6th USENIX Conference on Object-Oriented Technolo-gies and Systems (COOTS 2001), pages 119–130, San Antonio, Texas, 2001.

10. J. C. Wichman. ComposeJ: The Development of a Preprocessor to Facilitate Com-position Filters in the Java Language. Master’s thesis, University of Twente, 1999.

Fault tolerance AOP approach1

José Luis Herrero1, Fernando Sánchez1, Miguel Toro2

1 Computer Science DepartmentUniversity of Extremadura.Spain

{jherrero, fernando}@unex.es

2 Computer Science DepartmentUniversity of Sevilla.Spainmtoro@lsi.us.es

Abstract.Object oriented systems are composed by a collection of interactingobjects. Distributed object oriented systems consider that all theseobjects can be located at different computers connected through anetwork. Reliability and availability are very important trends in thedevelopment process of these kinds of systems. In order to improvethese features, object replication mechanisms have been introduced.Programming replication policies for a given application is not an easytask, and this is the reason why transparency for the programmer hasbeen one of the most important properties offered by all replicationmodels. However, this transparency for the programmer is not alwaysdesirable. There are situations in which programmers need tomanipulate by hand the replication properties. In this paper we present areplication model, JReplica, based on Aspect Oriented Programming(AOP). JReplica allows the separated specification of the replicationcode from the functional behaviour of objects, providing not only ahigh degree of transparency, as done by previous models, but also thepossibility for programmers to introduce new behaviour to specifydifferent fault tolerance requirements. Derived from the use of AOP,JReplica also obtains two important added benefits: the possibility ofobtaining an ORB independent replication and the possibility of reusingentire replication policies. Moreover, the replication aspect has beenintroduced at design time, and in this way, UML has been extended inorder to consider replication issues separately at the moment ofdesigning fault tolerance systems.

Introduction

This work tries to introduce replication in object orientation by means of a newaspect. For this purpose, a new language called JReplica has been developed. Thislanguage tries to capture the relevant aspects of replication, encapsulating them into a 1 This work has been developed with the support of CICYT TIC 99-1083-C02-02

component or group of related components favouring the reusability and dynamicadaptability of replication policies. This language also favours the use and reuse ofreplication policies independently from the middleware used to communicate objects.

The work is not limited to the definition of this new language. AOP ideas havebeen translated to the design level. In this way, the semantic of UML has beenextended in order to represent replication properties. From a given design, the samefor whatever middleware, a visual tool is able to generate code. The rest of the paperis as follows: section 2 explains the different approaches to introduce replication inobject orientation. Our proposal is introduced in section 3. Section 4 shows relatedworks. Finally, future works are outlined in section 5.

Fault tolerance approaches

There has been proposed different approaches to introduce fault tolerance in objectoriented systems. These models are the followings:

1. Integration approach : In this approach, replication is integrated inside themodel. Replication is coded inside the ORB. In this way, each ORB must bemodified in order to provide fault tolerance. Electra [Maf95], Orbix+Isis [II94] aretwo models that are based on this approach (figure 1).

2. Interception approach : In this model, every message is intercepted andredirected to a replication toolkit. This new tool is in charge of providing faulttolerance. The ORB must be modified introducing the interception mechanism.Eternal [Mos98] is an example of this approach (figure 2).

3. Service approach : A new replication service is added to the ORB. This serviceprovides mechanisms for object replication. OGS [Fel98] and the new Corba FaultTolerance specification [OMG00] are based on this approach (figure 3)

Client S S’

Replication

ORBCom

Replication

Interception

Client S S’

ORBCom

Client S S’

Replication

ORBCom

Fig. 1. Integration approach Fig. 2. Interception Approach Fig. 3. Service Approach

All these models introduce new elements to provide fault tolerance throughreplication. Transparency is the most important property achieved. In this way,programmers do not have to take care about replication, and they do not need todefine any protocol to develop fault tolerance applications because replication isobtained automatically by the model. However, all these models can be consideredtoo restricted in the following sense:

• Close: A totally transparent system doesn’t allow programmers to changereplication mechanisms. Replication properties can not be established, such as thereplication granularity, or the moment when replication protocols must beexecuted. These properties are defined automatically by the model and they are thesame for every system. In this way, programmers can not take advantage fromsystem requirements.

• ORB dependent: Replication depends on the ORB implementation. Anyreplication policy must be coded into an individual ORB, and it can not be reusedin a different ORB. There’s no way to port the same replication policy to otherORBs.

Although transparency is a good property to be achieved, it is not alwaysnecessary, moreover, sometimes it is not advisable. Sometimes the nature of theproblem may require establishing the replication properties and behaviour by theprogrammer. Even more, if requirements guide the replication behaviour, the systemcould take advantage of them, and system performance could be increased. If thereplication model is totally transparent, there is no way to define fault toleranceapplications according with system requirements.

Proposal

The model here proposed is based on the paradigm of Aspect Oriented Programming(AOP). Our research group has gained experience with AOP during the last few yearsworking with the synchronization, coordination and distribution aspects [Mur99,San00]. Here we go one step further introducing the replication2 aspect as a new non-functional property of the object. With this separation transparency is granted becausereplication policies can be reused among applications with no changes. In addition,programmers can get control over the replication policy using the specific replicationlanguage provided: JReplica.

In order to accomplish this separation, the model is based on reflectivearchitecture. The following two levels have been defined:

• Object level: Object functionality is defined at this level. Object code does notrefer to any replication mechanism, it just only defines object functional behaviorusing whatever language.

• Replication level: Replication policies are defined at this level using JReplica.

The model is based on the same concept that the interception model, that is, all themessages arriving at an object are intercepted and redirected to another entity (figure4). The interception and replication level is located just before the ORB, that is,

2 Although there are different replication strategies, in this paper we only focus on the backup

replication model due to it being suitable for deterministic and non-deterministic objects.

before sending and receiving messages to and from the ORB, they are intercepted. Itis in this moment when new actions for replication can be added. Figure 5 illustratesthis fact. The order of messages is the following:

1. A message arrives at the target object.2. After the message is executed, the new state is sent to the replication component

of the target object.3,4. This replication component propagates the new state to the rest of replication

components.5,6. Every replication component updates the state of the replica objects.

ReplicationInterception

Client S S’

ORBComuni

Object Level

Replication Level

Fig. 4. Proposed model

Object Replica Replica

Replication Aspect Replication AspectReplication Aspect

Base level

Replication level

1

2

3

4

56

Fig. 5. Message order

1. Those benefits derived from the use of AOP, mainly modularity, reusability ofcode and adaptability of applications.

2. ORB Independence: Replication algorithms are independent from de ORB. In aprevious work [San00] different distribution protocols were defined as a separatedaspect providing a dynamic, adaptable and transparent object distribution. Now, asthe replication module is defined outside the ORB, the combination of distributionand replication aspects offer the possibility of reusing the same replication policyin different ORBs. Figure 6 illustrates this fact.

3. Open: Thought replication algorithms are hidden and separated from objectbehaviour, replication properties and behaviour can be defined. Reflectivemechanisms can communicate the object level with the replication level. Thiscommunication provides the way to introduce new replication actions.

JReplica: Java Fault Tolerance Language

JReplica is a language with the only purpose of defining replication policies. Itssyntax is based on Java. It introduces new primitives, which are shown in figure 7.

This Java extension introduces two main elements:1. Replication Policy: A new entity called Disguise3 Replication defines the

replication aspect. This entity is divided into the following parts:• Attributes: Represent the information that defines the replication policy.• State: Represent the set of replication states.• Operations: Represent methods that can manipulate the replication state.• Guard: Represent a condition that must be true before replication. If this

condition is false, replication won’t be executed.• Before Replication: Represent the set of actions that must be executed just

before replication.• After Replication: Represent the set of actions that must be executed just

after the replication is executed.• Error: Represent the set of actions that must be executed when a replication

error appears.2. Composition: A class can be composed with different aspects, this means that

every object will extend its functionality with replication mechanisms.

Client S S’

CORBA

ReplicationInterception

Client S S’

JavaRMI

ReplicationInterception

Fig. 6. Replication policies reuse

Class <name>{ ........}

........................x=new C1Compose x with R;y=new Replica of x;........................

Diguise Replication <name>{ Attributes: ..... Operations: ..... State: ..... Guard: ..... Before Replication: .... After Replication: ..... Error: .....}

Fig. 7. Jreplica replication primitives

Representing Replication at Design Level

Replication policies now can be defined with JReplica language. This language helpsprogrammers to define easily replication properties in object oriented systems. But we

3 The word disguise comes from the original model: Disguises Model.

consider that replication must be introduced at earlier stages of object life cycle, moreconcretely at design level. In this way, UML [UML99] is used as the modelinglanguage due to it being a standard. As UML does not provide mechanisms torepresent replication, its semantic has been extended in order to express replicationproperties and behavior.

UML semantic can be extended with the introduction of new stereotypes. At thispoint, we have considered that replication policies can be designed separately andindependently, in the same way as has been explained at the implementation level. Assuch, the aspect concept is introduced in UML to express the AOP philosophy. Thereplication aspect is represented with a new stereotype, called <Replication>. Thisnew stereotype is shown if figure 8.

The replication stereotype represents a particular replication policy. Information isrepresented as follows:• Stereotype Attributes: Represent the information that defines the replication

policy.• Stereotype Methods: Define the set of methods that can manipulate the

replication state.

As it can be shown, there are other elements that can not be represented in thisstereotype. The dynamic behaviour of replication can not be represented in a normalclass diagram. Statechart diagrams represent dynamic behaviour. So the solution goesby attaching a statechart diagram to this replication stereotype. In this way, replicationstatic properties and dynamic behaviour can be designed. The dynamic behaviour ofreplication policies can be represented in a statechart diagram as it is shown in figure9.

< Replication >Name

Attributes

Methods

Class

Attributes

Methods

<Replicated>

Fig. 8. UML extension

State 1 Replication[Replication Guard]

Entry : Actions before replication

Exit : Actions after replication

Fig. 9. Statechart Representation

The elements that are represented in this statechart diagram are:

• State: Each replication state is represented by an state. There is a special statecalled Replication that represents the moment when replication is to beexecuted.

• Guard: Guards are represented in the transition of each state.• Before Replication: The set of actions that is executed just before the

replication begins is represented in the entry actions of the Replication state.• After Replication: The set of actions that are executed just after the replication

ends are represented in the exit actions of the Replication state.• Error: Replication errors are represented as a new state.

A tool is being developed in order to generate JReplica code starting from thisextension of UML. In this way Replication aspect has been introduced from design toimplementation level. This tool is based on other one we have developed for thesynchronization aspect [Her00].

Related works

There are several models that provide replication mechanism to achieve faulttolerance. In [Nar00], a new interception mechanism called Aroma is introduced inthe Java RMI architecture. Other models are based on the introduction of separatedentities that implement replication protocols. The Cadmium Model [Bag99] defines acouple of new entities called Stub and Scion, which are attached to a client and aserver respectively and offer replication mechanisms. In [Bru95] a new replicationentity and a consistency manager are introduced, both separated from the object. InAspectIX [Gei98] a single object is divided into fragments, all of which have adifferent purpose. One of these fragments offers replication facilities. The GARF[Gar95] model defines two different entities in order to introduce replication, they arecalled encapsulator and mailer. A two level reflective architecture was defined forJava in [Kle96]: object functionality is defined in the first level, while replicationprotocols are established in the second one. All these models only take into accountthe implementation level, they are focused on replication protocols and the definitionof a framework that provides fault tolerance, ignoring the design phase.

A new pattern [Gon97] has been defined in order to provide support for therepresentation of replicated objects. Moreover, a new language that helpsprogrammers to build fault tolerance systems has been defined in [Fab97, Fab00].This proposal is based on the concept of separation of concerns and extends AspecJlanguage [Lop97] with replication primitives. It is possible to define the attributes thatneed replication and what to do when a replication error happens. But there is no wayto express new replication actions or when replication must be executed. Althoughthese models help programmers to implement fault tolerance systems, it is necessaryto introduce mechanisms that help software engineers to design this kind ofrequirements.

Future works

Future works will consider extensions to JReplica in order to express more complexreplication mechanisms. The current version showed us the suitability of the model.

References

[Bag99] Aline Baggio. Adaptable and Mobile-Aware Distributed Objects. PhD Thesis,Université Pierre et Marie Curie and INRIA, Paris, France, June 1999.

[Bru95] Georges Brun-Cottan and Mesaac Makpangou. Adaptable Replicated Objects inDistributed Environments. BROADCAST TR No. 100. Appeared in the proceedings of the2nd BROADCAST Open Workshop, Grenoble, July 1995.

[Gar95] B. Garbinato, R. Guerraoui, and K. R. Mazouni. Implementation of the GARFreplicated object platform. Distributed Systems Engineering Journal, 2:14-27, 1995.

[Fab00] Johan Fabry. A Framework for replication of objects using Aspect-OrientedProgramming. Phd Thesis 1998. University of Brussel .

[Fab97] Johan Fabry. Replication as an Aspect - The Naming Problem. ECOOP Workshops1998: 424-425.

[Fel98] Pascal Felber. The CORBA Object Group Sevice. A Service approach to objectgroups in CORBA. Phd Thesis 1998. University of Lausanne.

[Gei98] Martin Geier, Martin Steckermeier, Ulrich Becker, Franz J. Hauck, Erich Meier, UweRastofer. Support for mobility and replication in the AspectIX architecture. Object-OrientedTechnology, ECOOP'98 Workshop Reader, LNCS 1543, Springer, 1998; pp. 325-326.

[Gon97] Teresa Gonçalves and António Rito Silva. Passive Replicator: A Design Pattern forObject Replication.Second European Conference on Pattern Languages of Programs. July1997.

[Her00] J.L.Herrero. Introducing separation of concerns at design time. PhDOOS Workshop,European Conference on Object-Oriented Programming (ECOOP’2000).

[II94] IONA and Isis. An Introduction to Orbix+Isis. IONA Technologies Ltd. and IsisDistributed Systems, Inc., 1994

[Kle96] Jürgen Kleinöder, Michael Golm. Transparent and Adaptable Object ReplicationUsing a Reflective Java. Tech. Report TR-I4-96-07, Universität Erlangen-Nürnberg: IMMDIV, Sept. 1996

[Lop97] C.V. Lopes. D: A Language Framework for Distributed Programming. Phd Thesis1997. University of Northeastern

[Maf95] S.Maffeis. Run-Time support for object-oriented distributed programming. PhdThesis, University of Zurich, 1995.

[Mos98] L.E.Moser, P.M. Meliar-Smith and P. Narasimhan. Consistent object replication inthe Eternal system. Theory and Practice of Object Systems, 81-92, 1998.

[Mur99] J.M. Murillo, J. Hernández, F. Sánchez, L.A. Álvarez. Coordinated Roles: PromotingReusability of Coordinated Active Objects Using Events Notification Protocols. InCoordination Languages and Models. Springer-Verlag, LNCS 1594, April, 1999

[Nar00] N. Narasimhan, L.E. Moser and P. M. Melliar-Smith. Transparent ConsistentReplication of Java RMI Objects.2nd Intl. Symposium, Distributed Objects & Applications(DOA 2000).

[OMG00 ] OMG TC document ptc/2000-03-04. Fault Tolerant CORBA. Draf AdoptedSpecification. 2000.

[San00] F. Sánchez, J.Hernández, J.M.Murillo, J.L.Herrero, R.Rodríguez. Adaptability ofObject Distribution Protocols Using the Disguises Model Approach. 2nd Intl. Symposium,Distributed Objects & Applications (DOA 2000).

[UML99] Object Management Group. Unified Modeling Language, version 1.3.http://www.rational.com/uml/resources/documentation

Transferring Persistence Concepts in Java ODBMSs to AspectJ Based on ODMG Standards

Arno Schmidmeier

Sirius Software GmbH, Oberhaching

Abstract: Aspects are abstractions that capture and localise crosscutting type concerns. Although the persistence of aspects has received an increasing interest among researchers in software engineering, basic distinctions between persistent and transient aspects, and their relationship to weaved objects, are lacking clarification. This paper introduces definitions and illustrates how an existing object oriented database management system (ODBMS) can be used as an aspect oriented database management system (ADBMS) based on such definitions and previously established ODMG standards.

Introduction Implementation approaches dealing with typical usage scenarios of an object oriented database raise the importance of persistent aspects [1]. The capability to store aspects in an ODBMS requires extending the ODBMS to an ADBMS. This can be achieved by enhancing the persistent object model of an object oriented programming language to that of a general aspect oriented programming language (GAPL) , which enhances the first programming language and can be compiled back to it. At the design level, enhancing the persistent object model consists of two major steps:

1. Porting the concept of persistent capable classes to persistent capable aspects 2. Extending the concept of persistence through reachability to encompass aspects.

Once these steps are accomplished, it is relatively easy to write persistent capable aspects. The GAPL compiler enables translating the persistent capable aspects into persistent capable classes, which can then be stored in the ODBMS. As a result, existing commercial ODBMSs can be reused with little or no modifications. The approaches discussed in this article are based on AspectJ, versions 0.8beta1 to beta3 [2], the standards outlined in ODMG 2.0 [3], and compliant database Objectivity 6.0 [4]. A similar implementation of this approach is discussed in [1].

Analysis of the Object and Aspect Models of AspectJ AspectJ offers, in addition to the java type construct, the aspect type construct. According to the aspect language reference: ”An aspect is a crosscutting type defined by the aspect declaration. The aspect declaration is similar to the class declaration in that it defines a type and an implementation for that type. It differs in that the type and implementation can cut across other types (including those defined by other aspect declarations), and that it may not be directly instantiated with a new expression. Aspects may have one constructor definition, but it must be of a nullary constructor throwing no checked exceptions.” [6]

Instances of an aspect class are called aspect instances1, which only the AspectJ runtime environment is capable of generating. The aspect class is instantiated based on the aspect signature. However, the standard aspect signature ‘of eachJVM()’ can be omitted. In this case, one instance is generated inside each Java Virtual Machine where the aspect is used. ‘of eachJVM()’ realises a kind of a singleton [10] pattern for an aspect. If a user wants to have more instances of an aspect, the aspect class must be declared using ‘of eachobject(PCD2)’, of ‘eachcflow(PCD)’, or ‘of eachcflowbelow(PCD)’. In the first case, a new aspect instance is created for every object associated with the pointcut P. If an aspect class A is defined ‘of eachcflow(P)’, then one object of type A is created for each flow of control at the join points of pointcut P. If an aspect class A is defined ‘of eachcflowbelow(P)’, then one object of type A is created for each flow of control below the join points of pointcut P. Except the difference in generating aspect instances, aspect instances and aspects classes behave like objects and classes. Aspect classes not only can extend both java classes and aspects classes, but also can implement interfaces. Aspect instances can be used anywhere a java object is expected. The AspectJ compiler transforms an aspect class into a java class.

Transferring the Persistence Model of Java Classes to Aspects. For such a transfer to take place, a definition can be made similar to that which is defined for java by the ODMG. Mainly, persistent capable aspects classes are aspect classes, whose instances can be stored in an aspect oriented database. All aspect classes are persistent capable if the following conditions are met:

1. The class either implements a specific interface or extends a specific root class. 2. All attributes must be either:

a. An atomic data type b. A persistent capable class c. A persistent capable aspect d. An atomic data structure e. An array consisting only of elements, which fulfil a, b, c, d or e. f. or, marked as transient, static or final.

All aspect classes, which are not persistent capable, are transient aspect classes. Instances of transient aspect classes cannot be stored in the aspect oriented database. All aspect instances, which are stored in the persistent storage, are called persistent aspect instances. All other aspect instances are called transient aspect instances. Transient aspect instances can become persistent aspect instances, like transient objects can become persistent objects, by either storing the aspect directly in the database (e.g. clustering) or achieving persistence through reachability.

Extending the Concept of Persistence through Reachability It is necessary to extend the concept of persistence through reachability, which takes into account aspect classes , in addition to the existing mapping of java classes drawn by the ODMG [3], [5].

1 For clarity, we use the term “aspect class” for an aspect and the term aspect instance for an instance of an aspect class in this paper. 2 PCD Pointcut discriminator

To be made persistent at the end of a transaction, all transient aspect instances and objects, must be:

1. An instance of a persistent capable class or an instance of a persistent capable aspect instance.

2. Directly or indirectly referenced from a persistent aspect instance or from a persistent object.

This concept is called: persistence through Reachability for aspects and classes (or in the context of aspects, simply,: persistence through Reachability.) A persistent aspect instance remains persistent, till it is removed explicitly from the database, or till it is removed from the database by the database garbage collector. So it is obvious, that the lifecycle of a persistent aspect instance, can easily extend the lifecycle of some Java virtual machines. Additionally, one can use the same aspect instance in several Java virtual machines at the same time. Persistence through reachability, as just defined, allows an aspect instance to get stored alone without the object instance for which it was bound; and, vice versa, an object gets stored without the aspects , which it was bound to it. Some usage patterns: A new instance of an persistent capable aspect class A is generated at any time, when a public method foo() is called in any class. The constructor of the aspect class A stores the aspect instance in the database. One could use explicit techniques, (e.g. clustering or using named roots) or apply persistence through reachability. The aspect instance will be made persistent independent from that fact, if the object that the aspect binds is persistent capable. When an instance of such an aspect is loaded from the database to a different JVM, it is quite clear, that it is not bound to any object anymore, if no reweaving takes place. A more common usage pattern is, that only instances of transient aspect classes are bound to an object of a persis tent capable class. If this object is made persistent, the aspects instances could not be saved. In some other cases the weaving relationship shall be counted as a reference according the newly established definitions for persistence through reachability. For example, when an object is made persistent all aspect instances bound to this object should be made persistent as well, and vice versa.

Persistence of Weavings The usage patterns above illustrate the need to further define such patterns and specify which of these patterns are to be supported by the runtime environments of the GAPL and the ADBMS. Definitions: Let O is any transient object and A is a transient aspect instance weaved to O. If the weaving between O and A fulfils the following conditions:

If O is made persistent, then A is automatically made persistent too and If A is made persistent, then O is automatically made persistent too,

…the weaving is considered a persistent weaving. When weaving between O and A meet these conditions:

If O is made persistent, then A is automatically made persis tent or

If A is made persistent, then O is automatically made persistent.

…the weaving is called a partial persistent weaving . All other weavings are considered transient weavings. Based on further investigations, it is necessary to differentiate the transient weavings even more. If a persistent object or aspect with a transient weaving is loaded into a JVM and the weaves could be re-established, the transient weaving is considered a rebindable transient weaving, or in short a rebindable weaving. If the reweaving is not initiated by the programmer or by another “user”-aspect, (e.g. from the database runtime or from the runtime of the GAPL), the weaving is called transient, automatic rebindable weaving or, in short , automatic, rebindable weaving. If a reweaving is not possible we speak from a lost through persistence weaving. it is possible that some weavings can be persistent, some other weavings of the same persistent object might be rebindable transient, and some other are lost through persistence weavings. Any ODBMS, supporting at least lost through persistence weavings and (partial) persistent weaving can be called an ADBMS from an aspect point of view.

Experiences Sirius Software’s Research and Development is currently using Objectivity 6.0 [4] with AspectJ (version 0.8beta1 through 0.8beta3) for the ADBMS, and its GAPL based on the concepts demonstrated in this article. Neither were the AspectJ compiler, nor the AspectJ and Objectivity runtimes changed. Partial persistent weavings, lost through persistence weavings and automatic rebindable transient weavings are supported out of the box and heavily used. In the last case, the class is persistent capable, while the aspect class is transient and from a ‘of eachJVM ’ type. An automatic rebindable weaving for transient aspect classes of the type ‘of eachobject()’ can be realized by modifying the AspectJ compiler. Currently, the AspectJ compiler does not allow the user to directly invoke the automatically generated methods responsible for initiating the (re)weaving. Therefore, if rebinding is necessary for transient aspects of type ‘of eachObject()’ the Java Reflection API is used to bypass these restrictions. The combination of Objectivity and AspectJ version 0.8beta3 does not currently support rebindable weavings where the aspect class is persistent capable and the class is transient. It was further discovered in a real world example, that no aspect class of the type ‘of eachcflow()’ and ‘of eachcflowbelow()’ is currently stored in the database. Moreover, no aspect instances of the type ‘of eachJVM()’ which is stored in the database. However, these transient aspect instances are often used in rebindable weavings. Aspects instances of the type ‘of eachobject()’ are quite often stored in persistent database, most of which are stored through persistent weavings. Sirius Software is due to release a proof of concept in the near future (as well as detailed website postings [7]) that will further substantiate, based on experiences, the feasibility of ADBMSs through existing commercial ODBMSs [8], [9].

Conclusions Concrete definitions of persistent and transient aspects are required to establish and realize the concept of persistence of aspects in object-oriented programming. The definition in this article proved to be a solid foundation for a common wording of Sirius developers and architects in discussing and designing persistency in aspects. The common wording is a prerequisite for pattern hatching in such an environment. It is still important to examine which patterns of persistent aspects are needed, as well as, the types of rebindable weavings that are really required to support these patterns, when applied in real world projects. The weaving relationship between an aspect and an object does not necessarily establish, or require, persistency. A dynamic weaving support from a GAPL can further propogate the use of persistent aspects. In fact, the Java Mapping of the ODMG can be easily extended to Java based GAPLs like AspectJ and closing the gap between existing commercial ODBMSs and future ADBMSs.

Biography Arno Schmidmeier (arno.schmidmeier@sirius-eos.com) is the Chief Scientist at Sirius Software GmbH. Prior to his current position he architected the EOS SLM Solution. He is the technical representative of Sirius Software in the TMF. He is also an independent member of the Java Specification Request 0090 ‘OSS Quality of Service API’.

References [1] “On to Aspect Persistence”, Awais Rashid, Proceedings of Second International Symposium on Generative and Component-based Software Engineering GCSE 2000 (part of Proceedings of NetObjectDays2000), pp. 453-463 (Also to appear in post symposium proceedings published by Springer-Verlag) [2] AspectJ Home Page, http://aspectj.org/, Xerox PARC, USA [3] Cattell, R. G. G., et al., “The Object Database Standard: ODMG 2.0”, Morgan Kaufmann, c1997 [4] Objectivity Home Page, http://www.objectivity.com/, Objectivity inc. Mountain View, USA [5] Cattel, R.G.G., et al, “The Object Database Standard: ODMG 3.0”, Morgan Kaufmann, 2000 [6] Gregor Kiczales, Erik Hilsdale, et al, “Language Semantics“, http://aspectj.org/doc/primer/ref/semantics.html, [6] “Jasmine 1.21 Documentation”, Computer Associates International, Inc., Fujitsu Limited, c1996-98 [7] Sirius Research AOD Page, http://www.sirius-eos.com/ [8] Versant Home Page, http://www.versant.com/, Fremont CA, USA [9] Fast Objects by Poet, http://www.fastobjects.com/ [10] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995 [11] Gregor Kiczales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffrey Palm, William G. Griswold. An Overview of AspectJ. To appear in ECOOP 2001, 2001

Alternatives to Aspect-Oriented Programming?

David Bruce Nick Exon

Distributed Technology GroupQinetiQ ltd

St Andrews Road, MALVERN WR14 3PS, UK

dib@QinetiQ.com njexon@QinetiQ.com

Abstract. In the interest of stimulating debate, we present a broad, all-inclusive view of aspect-oriented programming (AOP) and related initiatives.In particular, we contrast the compelling vision used to �sell� the idea of AOPwith the more finicky nature of its realizations to date. We outline a scenariothat we feel AOP ought at least aspire to address, and ask whether the directionit is currently following is likely to take us as far as we really need to go.

Separation of concerns: there is no alternative!

In the general software world, there would appear to be an irresistible trend towardsthe widespread use of components. There are countless articles, both in the technicalliterature and the computing press, that expound various reasons for this, and we haveneither the space nor the inclination to re-iterate them all here. We will simply notethat much the same forces are at work in computer simulation, our core research focusin recent years. Indeed, amidst the inevitable debates on the desirability or otherwiseof �federating� simulation components for large-scale simulations, Richard Weatherlyin particular has noted on several occasions that �there is no alternative!�.

The view of many researchers is broadly similar for aspect-oriented programming(AOP) [1,2]. The limitations of traditional, time-honoured but fundamentally quitebasic techniques for software construction are increasingly making themselves felt,most notably through our inability to construct and evolve programs at the pacedemanded by modern times. Proper separation of concerns [3,4] plays a vital rôlehere, but the abstraction and composition mechanisms we have today far from suffice.What AOP and related initiatives can offer are exciting glimpses of how we might beable to articulate and encapsulate hitherto-elusive concepts in qualitatively new ways.Thereby springs a much-needed sense of hope; surely there can be no alternative?

An anecdotal non sequitur

Back in autumn 2000, the first author gave an internal talk to our group, entitled�Aspect-oriented programming and AspectJ�. This talk first examined the nature ofcomputer software, and some of the fundamental problems caused by inadequate

separation of concerns. It went on to present the vision motivating aspect-orientedprogramming, that one could provide independent specifications for each distinctconcern and then �weave� them together to build the resulting system. The talk finallytouched on some of the prototype AOP systems / tools that were available at that time.In particular, it outlined Xerox PARC�s AspectJ [5,6,7] and the sorts of things thatthat language lets you do � specify program �pointcuts�, add or modify functionalitythrough before/after/around advice, extend classes using introduction, and associate�aspect� classes with objects, pointcuts, etc.

Several of our colleagues pointed out � some there and then, others later � thatthe early part of this talk was fine, as was the later part, but the two seemed a voidapart. The idea of AOP was great, they said, and AspectJ made perfect sense in itsown right � but the former was a grand conceptual vision while the latter focussedon low-level details.

Since then, the authors and various other members of our group have experimentedwith AspectJ from time to time. This continued exposure to AspectJ has done little tobridge the gap, however; if anything, it�s reinforced it! (We should note that we�renot picking on AspectJ in particular here; it�s just the most prominent example, andthe one that we�ve had most experience with. Other AOP and related systems seembroadly comparable in this regard. More on this later.)

So, maybe our colleagues� gut-reactions were founded; maybe there is somethingmissing? But what? Could it just be that we�re being dumb? We�d like to think not!The Xerox PARC team behind AspectJ acknowledge that its documentation often lagsbehind their implementation efforts, but it would be churlish as well as disingenuousto suggest that that�s the problem. Aspect-oriented programming is, of course, arelatively new field, so it is only natural that the community at large will take sometime to learn and communicate good design principles; perhaps we just need to wait?(It is worth noting here that excellent tutorials such as [7] are now starting to emerge.)One final option remains: it could be that AspectJ et al. really are too low-level forour ambitions � or, turning that around, that we�re guilty of expecting too much.

A multi-dimensional functionality thought experiment

We have spoken of aspirations, but given few details. What sort of thing do we havein mind?

One way to articulate such matters is by means of a �thought experiment� � in thiscase taking inspiration from the military simulation domain. Our intent is to show thebreadth of multi-dimensional functionality in what for that domain is a relativelysimple problem, and to stimulate thought about how software construction techniquesinfluence its subsequent evolution.

Consider a computer generated forces (CGF) assault on an enemy position. Therequirement is for a simulation (component) to plan and execute an operation:

� according to some specified scenario (location, time, military resources,opposition, �)

� using a given form of reasoning process (broad agents, rule based, scripted, �)� following particular doctrinal principles (tactics, rules of engagement, �)

� inside certain computational resource limits (time, memory, �)� implementing a particular style of simulation (training, analytic, predictive, �)� visualized as required (immersive VR, plan view display, statistical summary, �)� within acceptable validity tolerances� �

Each of the above represents a design decision that could � in principle at least �be changed independently. To get a sense for how hard it is to plan ahead for allpossible eventualities, think about how you might go about coding such an example.What abstraction mechanisms would you use to structure it? How well could yourapproach cope with this range of changes, and with other possible variations that youcan think of?

Clearly, some of the flexibility that we and our customers demand can beaccommodated using conventional methods (e.g., parametrization of scenario).Aspects as we currently know them might well serve for others (e.g., at least for someforms of visualization). However, entirely new techniques would also seem to berequired (e.g., for separating out elements of �intelligent� behaviour such as doctrine� especially if this is to be in some way independent of the reasoning approach).

So what�s the point?

Having started by arguing the case for aspect-oriented programming, we conclude byturning about-face to knock our strawman down � if only on a technicality.

Although there may be no alternative but to pursue such mechanisms, that does notmake the future entirely predestined and inevitable. We actually have a lot of choice.It is not the choice of whether to adopt something like AOP, but the more exactingchoice of how best to adopt it. This might not be the choice we thought that we had,but it�s actually a pretty good one; being so wide-ranging and open-ended, it givesplenty of room for manoeuvre.

In other words, the principle seems sound, but the practice still needs a good dealof refinement. The real question is whether the mechanisms that we know about now(e.g., those in AspectJ, in other variations on the theme such as HyperJ [8], or eventhose investigated in related initiatives such as Minsky�s law-governed regularities [9]or Microsoft�s intentional programming [10,11]) suffice to satisfy the aspirations thatwe already have, and those that we are going to formulate over the coming years.

Our honest answer is that we don�t know, but on balance we remain sceptical.We therefore challenge the research community to join us in looking for new forms

of program abstraction, composition and transformation � which may or may not endup resembling (or being called) aspect-oriented programming � that address both theprecisely formed targets of academic fascination and the less easily characterizedproblems that software developers really face. Bridging the gulf between conceptuallevels, and exploring the full life-cycle viability of aspect-oriented programs, are buttwo of the more interesting that immediately spring to mind.

Aspect-oriented programming as we know it now is doing a grand job of exploringinteresting territory; we simply urge that the research community widen its horizons,to see what else remains uncharted.

References

1. Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopez,John-Marc Loingtier and John Irwin, �Aspect-Oriented Programming�, pp. 220 ff. inProc. 11th European Conference on Object-Oriented Programming (Jyväskylä, Finland,9�13 June 1997) � published by Springer-Verlag as Lecture Notes in Computer Scienceno. 1241 (Mehmet Akşit and Satoshi Matsuoka, editors).

2. �Aspect-Oriented Programming�.Xerox PARC website, URL: http://www.parc.xerox.com/csl/projects/aop/.

3. D. L. Parnas, �On the Criteria To Be Used in Decomposing Systems into Modules�,pp. 1053�1058 in Communications of the ACM, Vol. 15, No. 12, December 1972.

4. Edsger W. Dijkstra, �A discipline of programming�, Prentice-Hall, 1976.[See in particular �In Retrospect� (chapter 27; pp. 209�217), and also �note 1� (p. 203).]

5. �AspectJ: Crosscutting Objects for Better Modularity�.Xerox PARC website, URL: http://aspectj.org/.

6. Gregor Kiczales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffrey Palm and William G.Griswold, �An Overview of AspectJ�, pp. 327 ff. in Proc. 15th European Conference onObject-Oriented Programming (Budapest, Hungary, 18�22 June 2001) � published bySpringer-Verlag as Lecture Notes in Computer Science no. 2072 (Jørgen LindskovKnudsen, editor).

7. Gregor Kiczales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffrey Palm and William G.Griswold, �Getting Started with AspectJ�, tutorial article submitted for a special themesection on Aspect-Oriented Programming to appear in Communications of the ACM,Vol. 44, No. 10, October 2001.(Available on-line at URL: http://aspectj.org/doc/gettingStarted/index.html.)

8. �HyperJ�: Multi-Dimensional Separation of Concerns for Java��.IBM Research website,URL: http://www.research.ibm.com/hyperspace/HyperJ/HyperJ.htm.

9. Naftaly H. Minsky, �Law-Governed Regularities in Object Systems. Part I: An AbstractModel�, pp. 283�301 in Theory and Practice of Object Systems, Vol. 2, No. 4, 1996.

10. Charles Simonyi, �The Future Is Intentional�, pp. 56�57 in IEEE Computer, Vol. 32,No. 5, May 1999. [One of nine contributions to �Software [R]evolution: A Roundtable�,Kirk L. Kroeker (editor), pp. 48�57 of that issue.]

11. �Intentional programming�.Microsoft Research website, URL: http://www.research.microsoft.com/ip/.

Acknowledgements

One of the authors has twice had the privilege of seeing Gregor Kiczales� excellentpresentations on aspect-oriented programming. Our colleague David Allsopp offeredsome particularly thoughtful observations. This work has been supported by the UKMinistry of Defence under Corporate Research TG10 project 5.4.4, �Re-usableSimulation Components for Synthetic Environments�.

© Copyright QinetiQ ltd 2001