Omar Badreddin

Timothy C Lethbridge

Maged Elassar
email: melaasar@ca.ibm.com

Modeling Practices in Open Source Software

Keywords: Open source, UML, Modeling, Coding, Version Control, Model Merging. Model versioning, Umple, Model Driven Architecture

It is widely accepted that modeling in software engineering increases productivity and results in better code quality. Yet, modeling adoption remains low. The open source community, in particular, remains almost entirely code centric. In this paper, we explore the reasons behind such limited adoption of modeling practices among open source developers. We highlight characteristics of modeling tools that would encourage their adoption. We propose Umple as a solution where both modeling and coding elements are treated uniformly. In this approach, models can be manipulated textually and code can be edited visually. We also report on the Umple compiler itself as a case study of an open source project where contributors, using the above approach, have and continue to routinely commit code and model over a number of years.

Introduction

Open-source software (OSS) is witnessing increasing adoption and impact [START_REF] Ye | Toward an Understanding of the Motivation of Open Source Software Developers[END_REF]. OSS development communities are collaborative, typically geographically distributed, working together to build software, often over multiple years with hundreds or thousands of contributors. OSS teams share common characteristics. For example, they use open-source version control systems, wikis, issue tracking systems, and automated test suites. Many teams use continuous integration -automated build servers to integrate contributions frequently and generate updated systems within minutes after a new commit.

However, code remains a key development artifact. Documentation and especially models are typically either absent or nearly so. This is despite evidence that modeldriven development can increase quality and productivity [START_REF] Selic | Models, Software Models and UML[END_REF]. In this paper, we propose an approach to help bring modeling to open-source development without disrupting the culture and methods open-source developers have found successful.

The use of modeling (e.g., UML) is considered to be a good practice that is expected to positively affect the quality of software [START_REF] Selic | Models, Software Models and UML[END_REF]. A recent survey of modeling practices in the industry reveals different levels of modeling adoption [START_REF] Forward | Perceptions of Software Modeling: A Survey of Software Practitioners[END_REF]. They range from full adoption of model-driven engineering, where engineers rely exclusively on models to generate complete running systems, to using models for documentation only. The survey also reveals that modeling adoption in general remains much lower than what would be desirable.

By only using a set of simple and readily-available tools, OSS communities are able to foster collaboration among a large number of members who often do not know each other. Despite this success, these teams rarely, if ever, use modeling as part of their development activities.

We surveyed the 20 most active open source projects according to Ohloh [START_REF] Ohlo | The Open Source Network[END_REF] based on the number of commits. The top of the list is Chromium [START_REF]Chromium[END_REF], with about 7 million lines of code, 150,000 commits, and more than 1,300 contributors. Chromium is mostly written in C and C++ (72%). When summing up all hours spent on the development, Chromium consumed 2,000 years of effort. The rest of the list includes projects such as Mozilla Core, WebKit, and GNOME.

The majority of these projects are written in C or C++ (87%). A small percentage of commits (0.3%) were XML based, which could indicate some use of modeling. However, none of these 20 projects listed any modeling notation as a notation where commits were accepted. We can therefore conclude based on this survey that there is no evidence that contributors commit models in any significant numbers. This finding validates our earlier survey results [START_REF] Forward | Perceptions of Software Modeling: A Survey of Software Practitioners[END_REF] and is in line with other existing observations [START_REF] Robbins | Adopting Open Source Software Engineering (OSSE) Practices by Adopting OSSE Tools[END_REF][START_REF] Hertel | Motivation of Software Developers in Open Source Projects: An Internet-Based Survey of Contributors to the Linux Kernel[END_REF].

Reasons behind this low adoption in the industry in general, and in open source projects in particular, have been investigated in our previous work [START_REF] Forward | Perceptions of Software Modeling: A Survey of Software Practitioners[END_REF]. In summary, low adoption can be attributed to the following reasons: • Code generation doesn't work as well as it needs to; • Modeling tools are too difficult to use; • A culture of coding prevails and is hard to overcome; • There is a lack of understanding of modeling notations and technologies; • The code-centric approach works well enough, such that the return on investment of changing is marginal, yet the risks are high.

The focus of this paper is proposing a new development paradigm that provides tight integration of modeling and coding styles. We demonstrate that this paradigm has the potential of increasing modeling adoption by presenting a model-driven programming environment called Umple, which we developed as an open source project.

Proposed solution

Umple is a fully functional and executable language with a textual syntax that allows uniform code and model development. Umple allows model abstractions from UML to be embedded into code written in Java, PHP and other programming languages.

Introduction to Umple

A key philosophy behind Umple is that modeling and coding are just different perspectives of the same development practice, with the difference being a question of abstraction. Modeling constructs such as UML associations and state machines are more abstract than traditional code elements like while loops, yet both appear together in Umple code. Complex Umple modeling constructs are typically more readily understood when rendered visually as UML diagrams, while traditional coding constructs are nowadays more commonly best understood when shown as indented text, but it need not be this way only. The Umple environment enables users to model textually and visually (with updates to one view applied instantly to the other view).

Consider the Umple sample code in Listing 1.

. The structure of the code is familiar to a Java programmer. However, many of the lines of this example represent UML elements embedded textually in the code. Line 18 is a UML association, and indicates that class Student can have an optional Supervisor, while a Supervisor can have many Students. Lines 4 and 22 are Umple's way of representing generalization (i.e. designating a superclass). Umple Online [START_REF] Lethbridge | Umple Language Online[END_REF], the Umple web-based environment, would render the above code as a UML class diagram, as shown in Figure 1. have an impact on the visual representation, since not all aspects of the code are visualized in every diagram type.

1

Code generation from Umple

The Umple philosophy is to combine code and model into one type of artifact. Hence, Umple does not have the typical process of code generation (model to editable code) nor reverse engineering (edited code to model) found in other modeling tools. An Umple program, consisting of model and code, is compiled into an executable system directly. It is not necessary to reverse engineer Umple code to create a model, since it already is a model.

Language independent modeling

The main strength of UML as a modeling language is being platform and implementation independent. This allows the model in Figure 2, for example, to be used to generate code in Java, C++, or any other programming language. This independence is also maintained in Umple. Users of Umple can chose to write a system in any language of their choice as long as its compiler is available. Umple currently provides full support for Java, PhP and Ruby, with growing support for C++. Umple can also generate XMI and Ecore [START_REF]Package Org.Eclipse.Emf.Ecore[END_REF] representations for integration with existing modeling tools.

Case Study

In this section, we assess the effectiveness of using model-driven programming languages, such as Umple, to encourage adoption of modeling in open-source projects.

Our case study is on Umple itself as an open source project, hosted in the Google Code repository [START_REF] Lethbridge | Umple Google Code Project[END_REF]. The source code of the Umple compiler is written in Umple with Java as the target language and the language of the embedded methods. Contributors need to learn the syntax of Umple before contributing. But since the syntax is very similar to Java and resembles what would appear in a UML diagram, learning Umple does not add significantly to the time needed for contribution.

As with a typical open source project, there is a little up-front effort required to set up the development environment, which includes downloading the code, installing tools such as Eclipse (with the Umple and Jet plugins) and Ant, getting the appropriate project permissions, etc.

Umple was released as open source software in 2010. However, all of the source (model/code) artifacts was stored in a Subversion repository for over 5 years; it is possible therefore to analyse the source changes, including the UML underpinnings of the Umple compiler. Because the model is represented textually in Umple, there is no additional infrastructure investment for model versioning and comparing.

Objectives and Research Methodology

The objective of this study is to investigate the applicability of model oriented programming in open source projects. This investigation is carried out by analyzing how model orientation was used in developing the Umple platform.

In previous work, we have provided empirical evidence that model oriented code has significant comprehension value over pure Java code [START_REF] Badreddin | An Empirical Experiment of Comprehension on Textual and Visual Modeling Approaches[END_REF]. The empirical evidence is a result of a controlled experiment comparing model-oriented code, traditional object-oriented code, and UML models. The experiment included both student and professional participants and proceeded by posing questions on a set of different modeling and coding artifacts. The question and answer sessions were recorded and analyzed to infer comprehensibility of the different code and modeling snippets. The experiment provides evidence that suggests that model oriented code is at least as comprehensible as UML visual models. Therefore, in this paper, we limit our focus to investigation of the applicability of using model orientation in open source environments.

The design of Umple was carried out over more than 5 years. The technology is still under extensive development and iterative improvements. Design of Umple was influenced by the following studies.

• Study of early adopters [START_REF] Badreddin | A Manifestation of Model-Code Duality: Facilitating the Representation of State Machines in the Umple Model-Oriented Programming Language[END_REF]. This is a study that was conducted during the early design phases where early adopters were interviewed and filled up questionnaire that reflects their attitudes towards model oriented code. • Experiences of applying Umple in industrial development projects [START_REF] Badreddin | A Study of Applying a Research Prototype Tool in Industrial Practice[END_REF]. By using the technology in industrial projects, we were able to refine the design and implementation of the platform. In particular, we improved scalability aspects of the technology. • User evaluations and experimentation [START_REF] Badreddin | Combining Experiments and Grounded Theory to Evaluate a Research Prototype: Lessons from the Umple Model-Oriented Programming Technology[END_REF]. Such studies provided empirical evidence to support our claims about the comprehension value of model oriented programming technology. These studies have also given us insights on how users actually go about exploring the usage of such technology.

Design is both an art and a science, making it challenging to satisfactorily evaluate design work. Recently, research on design has witnessed a significant uptake in several domains. This increased uptake has encouraged researchers to define a systematic methodology of evaluation design [START_REF] Verschuren | Evaluation in Design-Oriented Research[END_REF]. In summary, this evaluation methodology relies on iterative design evaluation cycles with key stakeholders. This methodology also adopts empirical evaluation of design by measuring to what extent a design satisfies its intended goals.

We adopted the same design evaluation methodology mentioned above in the design of Umple. We implemented a prototype of Umple that embodied many of our design objectives. We used the prototype to iteratively assess to what extent the design met its objectives and we collected feedback and evaluation from users. This case study does not discuss the intermediate designs, but rather focuses on the final design after completing the process of iterative refinement.

Development environment

Developers of Umple use a variety of development environments. For simple tasks, the Umple web-based editor [START_REF] Lethbridge | Umple Language Online[END_REF] can be used to easily write code and visualize the equivalent UML model. Figure 3 is a snapshot of the UmpleOnline system. On the left side there is the code/model textual editor. On the right side, there is the corresponding visualization editor for the model. Edits on either side are automatically reflected on the other side. If a user modifies the default layout of the visual rendering of the model, the new layout information is stored textually. This is to support preserving the layout when a user returns to the same visualization again. This layout information is committed and versioned in the repository.

Figure 3: Umple Online

Umple Online is suitable for a quick demonstration of concepts and for relatively simple development tasks. However, for larger and more elaborate tasks, the Eclipse based plug-in is preferred. The added functionality provided by the plugin includes code highlighting, context assist, outline view, error and problem reporting views, as well as compiling. Finally there is a command line version of the compiler, which is used for automatic building, and is therefore preferred by some developers.

Developer Contributions

Contributions to Umple are represented in text, as in other open source projects. The key and only difference is that Umple text represents both model and code elements. Once the Umple continuous integration server senses a commit, it automatically triggers a build. The build process first compiles all Umple source files to generate a new executable Umple compiler. Then, the build process runs Umple test cases to verify that the latest commit did not break existing functionality. The new compiler then builds itself, as yet another large test case. If the tests are all successful, the new build is completed and deployed.

Umple source versioning

Umple developers review code and model changes in the same way. Since model and code in Umple are textual; changes can be reviewed using the repository diff functionality (Figure 4). Our investigation is based on analyzing the revision history of three artifacts (the Umple associations and attributes portion of the metamodel, the state-machine portion of the metamodel, and the parser) as shown in Table 1. The period covered is from October 2008 to February 2012. We chose these artifacts because they are frequently updated, have existed for a long time, belong 'together' in the architecture (the parser populates the Metamodel), and have different distributions of model vs. Java (the metamodel files are mostly model, and the parser is mostly Java). We chose a subset of Umple to simplify the data, and we chose three components to see if the results are consistent between them. This is an exploratory case study only, so we have not attempted to analyse the entire system.

The Umple metamodel is the schema written in Umple of all Umple elements in the system being compiled and is used to define different modeling and code elements within the Umple language. Changes to the metamodel occur when a new Umple language element is defined or when a change is done to an existing element.

The number of lines of code for the associations and attributes portion of the metamodel is 1623, 19% of which are modeling elements and the rest are Java code.

The second artifact is the state machine portion of the metamodel, which is the schema of the state machine related elements. The artifact has 315 lines, 24% of which are model.

The third artifact is the parser, which is a component of the Umple compiler. The parser contains mostly Java code (690 lines), 4% of which is model. Comparison of Model vs. Java code in terms of the volume of their change relative to their size: The number of changes and the percentages affecting model only, Java only or both are given in the first four columns of Table 1. It would typically be challenging to produce these numbers automatically since Umple treats both model and code uniformly. Hence, in other systems one might have to manually inspect the changed lines or write a special-purpose parser to judge whether they are code or model related. However, we took advantage of the Umple project's coding guidelines, which advise developers to keep modeling elements at the top of the file or in separately-included files whenever possible, to quickly classify the majority of changes. We also used Fisheye [START_REF] Atlassian | FishEye[END_REF], a repository visualization tool to help verify our classification estimates. Finally, we verified our numbers by asking three experienced Umple developers to produce them on their own. No significant discrepancies were evident.

Since the Umple metamodel includes a much higher portion of modeling elements than the parser, while the parser includes a much higher portion of Java code than the metamodel, we expected that the changes to those artifacts follow similar proportions (more model changes in the metamodel; more java changes in the parser). Table 1 show that this pattern was indeed observed. In fact, it was valid across different developers. In other words, the change patterns of any particular developer are similar to what is shown in Table 1.

Comparison of Model vs. Java changes over time: Umple was initially written purely in Java. Incrementally, more modeling abstractions were added to the language, starting with attributes, then associations, and finally state machines. The more modeling support got added, the more we were able to refactor the code base to take advantage of the modeling abstractions. One would therefore expect to find an upward trend in the percentage of modeling changes and that this trend would persist over time. To our surprise, we noticed a different pattern: modeling changes exhibited a downward trend for most of the time period of our observations (Figure 5). Our explanation is as follows: As the code base was refactored to take advantage of more modeling abstractions, modeling changes were initially extensive as compared to Java changes. But as the refactoring slowed down, more changes occurred to the Java elements to add features, largely algorithms and computations that typically do not involve creating new or changing existing modeling elements. The core attributes and association metamodel was developed prior to October 2008. The spike in change activity to Attributes and association metamodel (around Q1 2010) corresponds to refactoring of the metamodel that took place as the responsible researcher was transitioning out. The state machine metamodel was developed during 2009. There was little refactoring performed on this metamodel since it was developed after many modeling abstractions were already supported by Umple. In other words, the state machine metamodel was written in a version of Umple that supported attributes and associations.

The downward trend is more evident in the case of the state machine metamodel than in the attributes and association metamodel. The number of model lines in the parser is minimal; hence, one cannot elicit a trend. With the exception of the refactoring spike in the attributes and association metamodel, the trend would have been also evident in that case too.

Techniques for mining software repositories can recover more trends about the nature and pattern of software development of Umple. The Umple repository and all its versioning history are publicly available for download. This should encourage other independent work to perform such in depth analysis of the repository and report on it.

Related work

Robbins [START_REF] Robbins | Adopting Open Source Software Engineering (OSSE) Practices by Adopting OSSE Tools[END_REF] identifies a set of tools that are absent in an open source community, including requirements and modeling tools. He attributes this absence to a number of reasons, including the fact that open source developers do not have direct paying customers and therefore do not feel the need to follow a rigorous methodology or respect deadlines. He also predicts that many of those missing tools will have a significant positive impact if and when they get adopted by the open source community. This is where the motivation for the research presented in this paper comes from.

Iivari [START_REF] Iivari | Why are CASE Tools Not used? Communications of the ACM[END_REF] explored why modeling tools are not used in general in software projects. In a study, he reports that 70% of modeling tools are never used after being available for one year, 25% are used by only a single group, and only 5% are widely used. This is despite the fact that the same study reports positive impact of modeling adoption. More than a decade later, modeling tools are still not widely adopted and a significant segment of the software engineering practices are still code centric [START_REF] Forward | Perceptions of Software Modeling: A Survey of Software Practitioners[END_REF].

Conclusion and future work

The open source community remains almost entirely code centric. Adoption of modeling practices remains extremely low. Since the open source community is known for its exploration, innovation, and willingness to quickly adopt new technologies, model-oriented programming languages like Umple offer a promising direction. We have presented Umple as a case study of an open source project that has been successfully developed using a model-based programming language (Umple itself). It effectively supports modeling by embedding model elements in code artifacts, and hence in the same repository. Besides using the Umple compiler, which can be invoked from a regular command line shell and from the Eclipse platform, Umple developers only use openly available tools..

The key concept in our approach is the view that model and code can be treated uniformly. While most models are best viewed visually and most code is best viewed textually, the underlying representation of both model and code should be textual, and capable of co-existing in the same textual artifacts. This helps bring modeling to the open source community. To the best of our knowledge, Umple remains the only open source project that is largely model-driven, and where model contributions are performed routinely.

Future work includes more in-depth analysis of the trends of comments of the Umple open source code. Approaches such as mining software repositories can be utilized to uncover trends and patterns.

Future enhancements to Umple include a tool to support incremental reverse engineering from existing systems (umplification) [START_REF] Lethbridge | Umplification: Refactoring to Incrementally Add Abstraction to a Program[END_REF]. The key advantage is that systems can be reverse-engineered while being able to instantiate a running system at all stages. Umple is also being extended to include a debugger that can work at the modeling level. This stems from our vision that whatever functionality available to traditional code developers should also be made available when modeling support is added.

Figure 1 :

 1 Figure 1: A Class Diagram in UML Lines 6 to 17 describe the behavior of the Student class as a state machine, which can be depicted as in Figure 2. When a Student object is created, it goes initially to the Applied state. Depending on the events that occur next, and whether or not the 'hold' boolean variable is true, the Student object moves from one state to another state.

Figure 2 :

 2 Figure 2: State Diagram Umple is not intended to replace the need for visual models. As illustrated in the following sections, the Umple compiler has both a textual and a visual editor. Both views are synchronized automatically, since a change in the model will always have an equivalent change in the textual representation. Of course, not all code changes

Figure 4 :

 4 Figure 4: Code and model revisions

Figure 5 :

 5 Figure 5: Model changes trend over time Figure 5 illustrates the analysis for the same three artifacts; the state machine metamodel, the attributes and association metamodel, and the parser. The figure aggregates model only changes with code and model changes, starting from October 2008 and until February 2012. The data is aggregated quarterly.The core attributes and association metamodel was developed prior to October 2008. The spike in change activity to Attributes and association metamodel (around Q1 2010) corresponds to refactoring of the metamodel that took place as the responsible researcher was transitioning out. The state machine metamodel was developed during 2009. There was little refactoring performed on this metamodel since it was developed after many modeling abstractions were already supported by Umple. In other words, the state machine metamodel was written in a version of Umple that supported attributes and associations.The downward trend is more evident in the case of the state machine metamodel than in the attributes and association metamodel. The number of model lines in the parser is minimal; hence, one cannot elicit a trend. With the exception of the refactoring spike in the attributes and association metamodel, the trend would have been also evident in that case too.Techniques for mining software repositories can recover more trends about the nature and pattern of software development of Umple. The Umple repository and all its versioning history are publicly available for download. This should encourage other independent work to perform such in depth analysis of the repository and report on it.

Table 1 :

 1 Model and code contributions

	File	changes	%	%	% Model	Number of lines (Feb. 2012)
			Model only	Java only	and Java change	Total	Model only (%)	Java only (%)
	Attributes	1414	15%	40%	45%	1623	307	1316
	and						(19%)	(81%)
	associations
	metamodel
	State	779	18%	25%	57%	315	77 (24%)	238
	machine							(76%)
	metamodel
	Parser	1242	1%	97%	2%	690	26 (4%)	664 (96%)
	Average						15.6%	84.3%

Analysis of the use of Umple to develop Umple itself

  At a bare minimum, Umple developers need to simply download a single Jar file (Umple.jar) to use the Umple compiler. This is readily available and works well with other open source infrastructure. Most developers choose to go one step further and work with the Umple Eclipse plugin. However, installing such plugin is a common task to Eclipse-developers. • Easy editing paradigm -textual models: Umple users can use whatever text editor they are familiar with to edit Umple sources. There is no need to use a separate graphical tool to view the Umple-sources in UML notation. Such visualizations can be generated using Umple Online if desired. •

	4.6 We now revisit the requirements specified in Section 2, and reflect, in their context,
	on our experiences developing Umple as an open source project written in Umple
	itself.
	• Little to no change to existing infrastructure:
	Number of commits	State machine metamodel	metamodel Attributes and associations
			Parser

Versioning, comparing and merging features that operate the same way on model and programming language text:

  All Umple sources, whether they include Java or model elements, are represented textually in Umple files and are committed to SVN just like in any other open-source system. • Tight integration with code: In Umple, both model elements and code elements are co-located in the same textual artifact and treated uniformly • Semantic completeness: The Umple compiler completely supports the subset of UML semantics, like multiplicity constraints, bidirectional association referential integrity, and state-machines, expressible in Umple.


Anne-Sophie Bonnet-Bendhia

Karim Ramdani
email: ramdani@ensta.fr

Axel Tillequin
email: tillequi@ensta.fr

Diffraction par un obstacle situé dans un réseau de plaques semi-infinies

L'objet de cette Note est de proposer une méthode pour l'étude de la diffraction par un réseau de plaques horizontales semi-infinies localement perturbé par un obstacle. La méthode proposée couple une équation variationnelle posée dans un domaine borné entourant l'obstacle et une équation pseudo-différentielle écrite sur la droite verticale située à l'extrémité des plaques. Après avoir donné une formulation variationnelle du problème, on montre que celui-ci relève de l'alternative de Fredholm, en dehors des fréquences de résonance du réseau.

Diffraction by an obstacle located in a semi-infinite plates grating

Abridged English Version

Let (O, x, y) be an orthonormal system of coordinates of the plane. Consider a grating constituted of semi-infinite and horizontal plates located in the half-plane {x < 0}. We are interested in the diffraction of an incident plane wave by a bounded obstacle located in the grating. Without the obstacle, the geometry is periodic and one can classically look for quasi-periodic solutions (see [START_REF] Abboud | Electromagnetic waves in an inhomogeneous medium[END_REF], [START_REF] Bao | Variational Approximation of Maxwell's equations in biperiodic structures[END_REF], [START_REF] Bonnet-Bendhia | Guided waves by electromagnetic gratings and non uniqueness examples for the diffraction problem[END_REF]), the problem being set in one cell of the grating. In this Note, an original method to determine the perturbation of the diffracted field due to the presence of the obstacle is presented. This method, which has been first introduced in [START_REF] Bonnet-Bendhia | A generalized mode matching method for scattering problems with unbounded obstacles[END_REF] to study the radiation of a semi-infinite guide, is based on the following idea : if the trace u on Σ = {x = 0} (cf. Figure 1) of the diffracted field ϕ is known, then ϕ can be recovered using the Fourier transform in the half-plane Ω + = {x > 0} and using a modal decomposition in the cells Ω - n of the grating that do not contain the obstacle. Matching the normal derivatives of the representation formulas obtained, we show that u solves a one dimensional problem coupled to a classical diffraction problem set in a bounded domain surrounding the obstacle (equation ( 7)). After defining a suitable functional framework to study the variational formulation of the problem, we show that when k = pπ/d, for all p ∈ Z (d being the distance separating two plates), the Fredholm alternative holds. The case k = pπ/d corresponds to the resonances of the grating and will not be considered here.

Le plan étant muni d'un système de coordonnées orthonormé (O, x, y), on considère un réseau de plaques semi-infinies horizontales, situé dans le demi-plan {x < 0}. L'objet de cette Note est de présenter une méthode pour résoudre le problème de la diffraction d'une onde incidente plane par un obstacle borné situé dans l'une des cellules du réseau. Naturellement, la difficulté majeure provient du fait que la présence de l'obstacle détruit le caractère périodique du problème. En effet, en l'absence d'obstacle, on peut classiquement rechercher des solutions quasi-périodiques et se ramener ainsi à un problème posé dans une cellule du réseau (cf. [START_REF] Abboud | Electromagnetic waves in an inhomogeneous medium[END_REF], [START_REF] Bao | Variational Approximation of Maxwell's equations in biperiodic structures[END_REF], [START_REF] Bonnet-Bendhia | Guided waves by electromagnetic gratings and non uniqueness examples for the diffraction problem[END_REF]). On s'intéresse ici à la perturbation du champ diffracté induite par la présence de l'obstacle. La méthode proposée a été introduite pour la première fois dans [START_REF] Bonnet-Bendhia | A generalized mode matching method for scattering problems with unbounded obstacles[END_REF] afin d'étudier le rayonnement d'un guide semiinfini. Elle repose sur l'observation suivante : si l'on connait la trace u du champ diffracté sur la droite Σ = {x = 0} (cf. Figure 1), celui-ci peut aisément être reconstruit par transformée de Fourier dans le demi-plan Ω + = {x > 0} à droite de Σ et par décomposition modale à gauche de Σ dans les cellules ne contenant pas l'obstacle. En écrivant le raccord des dérivées normales des représentations précédentes du champ diffracté, on montre que la trace u résout un problème mono-dimensionnel couplé à un problème de diffraction classique posé dans la cellule contenant l'obstacle. En utilisant une méthode variationnelle, on prouve qu'en dehors des fréquences de résonance du réseau, le problème relève de l'alternative de Fredholm. On note Γ n = {x < 0 , y = nd} les plaques du réseau où d désigne la distance entre deux plaques.

S G n W + S 0 G n+1 S n S 0 W 0 W - 0 W - n -
Pour tout n = 0, la cellule n du réseau est notée Ω - n = {x < 0, nd < y < (n + 1)d}, sa frontière

∂Ω - n étant constituée des plaques Γ n et Γ n+1 et de Σ n = Σ ∩ ∂Ω - n .
On suppose que l'obstacle, de frontière Γ, est contenu dans la cellule {x < 0, 0 < y < d}. Enfin, le milieu de propagation Ω est le domaine situé à l'extérieur des plaques et de l'obstacle. On note ϕ inc la solution quasi-périodique de la diffraction d'une onde plane par le réseau sans obstacle. Le champ diffracté par le réseau perturbé ϕ résout alors le problème de diffraction acoustique suivant :

∆ϕ + k 2 ϕ = 0 dans Ω , ∂ ν ϕ = 0 sur n∈Z Γ n , ∂ ν ϕ = g sur Γ , (1)
où l'on a posé g = -∂ ν ϕ inc . Bien évidemment, pour ne conserver que les solutions sortantes de (1), il faut imposer une condition de rayonnement. Celle-ci sera précisée ultérieurement.

Dans les sections 2 et 3, nous commençons par obtenir (de manière formelle) une formulation variationnelle du problème. Sa justification rigoureuse repose sur une technique d'absorption limite et ne sera pas détaillée ici. Dans la section 4, nous précisons le cadre mathématique adéquat pour l'analyse du problème avant d'en faire une étude rigoureuse.

2 Représentation dans Ω + et dans Ω - n , n = 0

Nous allons voir comment reconstruire la solution ϕ du problème (1) dans Ω + puis dans chaque cellule Ω - n , n = 0, à partir de la seule connaissance de sa trace u = ϕ |Σ sur l'interface fictive Σ. La représentation de la solution dans Ω + s'obtient aisément en appliquant la transformée de Fourier (dans la direction y) au problème [START_REF] Abboud | Electromagnetic waves in an inhomogeneous medium[END_REF]. En effet, ϕ est donné dans Ω + par l'expression:

R + u(x, y) = F -1 {Fu(ξ) e -c √ ξ 2 -k 2 x }, (2)
où F désigne la transformée de Fourier selon la direction y, et où l'on a posé pour tenir compte du caractère sortant du champ :

c ξ 2 -k 2 = ξ 2 -k 2 , si ξ 2 ≥ k 2 -i k 2 -ξ 2 , si ξ 2 ≤ k 2 .
Soulignons ici que les valeurs de ξ satisfaisant ξ 2 ≥ k 2 correspondent à des ondes évanescentes alors que si ξ 2 < k 2 , il s'agit d'ondes propagatives. Etant donné n = 0, la représentation R - n u de la solution dans chaque cellule Ω - n , est obtenue par une méthode de séparation de variables à partir du développement en série de Fourier de u dans l'intervalle I n =]nd, (n + 1)d[. En effet, le champ diffracté ϕ résout dans chaque cellule Ω - n le problème aux limites: Pour résoudre (3), il suffit donc de résoudre la famille de problèmes aux limites :

∆ϕ + k 2 ϕ = 0 dans Ω - n , ∂ ν ϕ = 0 sur Γ n ∪ Γ n+1 , ϕ = u sur Σ n . (3)
∆ϕ n p + k 2 ϕ n p = 0 dans Ω - n , ∂ ν ϕ n p = 0 sur Γ n ∪ Γ n+1 , ϕ n p = ψ n p sur Σ n , la solution de (3) s'écrivant alors simplement: ϕ = +∞ p=0 (u, ψ n p ) ϕ n p dans Ω - n .
En recherchant des solutions à variables séparées, on obtient que ϕ n p (x, y) = ψ n p (y) e βpx , où l'on a posé :

β p = p 2 π 2 /d 2 -k 2 , si p 2 π 2 /d 2 ≥ k 2 -i k 2 -p 2 π 2 /d 2 , si p 2 π 2 /d 2 ≤ k 2 .
Notons qu'il existe un nombre fini de modes propagatifs (correspondant à β p ∈ iR + ) et un nombre dénombrable de modes évanescents (correspondant à β p ∈ R + ). Ainsi, la solution ϕ de (1) est donnée dans chaque cellule Ω - n par la formule suivante:

R - n u(x, y) = +∞ p=0 (u, ψ n p ) ψ n p (y) e βpx . (4)
Nous commenons par ramener le problème posé dans la cellule {x < 0, 0 < y < d} à un problème posé en domaine borné. On introduit à cet effet la frontière fictive Σ - 0 (voir la Figure 1), située sur la verticale x = δ < 0 et on note Ω - 0 = {x < δ, 0 < y < d} le sous-domaine situé à gauche de Σ - 0 . Enfin, Ω 0 désignera le sous-domaine entourant l'obstacle limité latéralement par Σ 0 et Σ - 0 . Pour obtenir sur Σ - 0 une condition aux limites transparente, on utilise l'opérateur de Dirichlet-Neumann. Plus précisément, en procédant exactement comme on l'a fait pour les autres cellules, on voit que si ϕ |Σ - 0 est connu, la solution ϕ du problème de diffraction est donnée dans Ω - 0 par la formule: R - 0 (ϕ

|Σ - 0 ) = +∞ p=0 (ϕ |Σ - 0 , ψ n p ) ψ n p (y) e -βp|x-δ| . Si l'on définit maintenant l'opérateur de Dirichlet-Neumann T - 0 par : T - 0 (ϕ |Σ - 0 ) = ∂ x (R - 0 (ϕ |Σ - 0
)) |Σ0-, on voit que ϕ est solution dans Ω 0 du problème aux limites suivant:

           ∆ϕ + k 2 ϕ = 0 Ω 0 ∂ ν ϕ = 0 ∂Ω 0 ∩ Γ 0 et ∂Ω 0 ∩ Γ 1 ∂ ν ϕ = g Γ ϕ = u Σ 0 ∂ x ϕ = T - 0 (ϕ |Σ - 0 ) Σ 0 - (5)
Par suite, on a pour tout ψ ∈ H 1 (Ω 0 ):

∂ x ϕ, ψ Σ0 = T - 0 (ϕ |Σ - 0 ) , ψ Σ - 0 + Ω0 ∇ϕ • ∇ψ -k 2 Ω0 ϕψ + Γ gψ. (6)
Partant des représentations ( 2) et ( 4), on introduit maintenant les opérateurs de Dirichlet-Neumann

T + et T - n (n = 0) tels que : T + (u) = -∂ x (R + u) |Σ et T - n (u) = ∂ x (R - n u) |Σn .
Alors, la fonction définie par :

ϕ =    R + u dans Ω + R - n u dans Ω - n , n = 0 R - 0 u dans Ω - 0
et qui est solution de (5) dans Ω 0 résout le problème de diffraction (1) si et seulement si ses dérivées normales à travers Σ se raccordent, condition qui s'écrit au sens faible:

∂ x ϕ, v Σ0 = -T + u, v Σ - n =0 T - n u, v Σn , ∀v ∈ D(Σ). (7
T + u, v Σ + n =0 T - n u, v Σn + T - 0 (ϕ |Σ - 0 ) , ψ Σ - 0 + Ω0 ∇ϕ • ∇ψ -k 2 Ω0 ϕψ = - Γ gψ. Posons a + (u, v) = T + u, v Σ = R c ξ 2 -k 2 Fu(ξ) Fv(ξ) dξ a - n (u, v) = T - n u, v Σn = +∞ p=0 β p (u, ψ n p ) (v, ψ n p ) a - 0 (ϕ, ψ) = T - 0 (ϕ), ψ Σ - 0 = +∞ p=0 β p (ϕ, ψ 0 p ) (ψ, ψ 0 p ) ((v, ψ)) = - Γ gψ il vient alors que : a ((u, ϕ) , (v, ψ)) = ((v, ψ)), avec : a ((u, ϕ) , (v, ψ)) = a + (u, v) + n =0 a - n (u, v) + a - 0 (ϕ |Σ - 0 , ψ |Σ - 0 ) + Ω0 ∇ϕ • ∇ψ -k 2 Ω0
ϕψ.

Nous allons maintenant définir de manière rigoureuse le cadre mathématique adéquat pour étudier ce problème variationnel.

4 Cadre fonctionnel et alternative de Fredholm L'espace variationnel naturel pour la recherche de ϕ est H 1 (Ω 0 ). En ce qui concerne u, la question du cadre fonctionnel est plus délicate. Soit

V + = {v ∈ S (R), R |ξ 2 -k 2 | |Fv(ξ)| 2 dξ < +∞} l'espace naturel de définition de a + (•, •).
Cet espace a fait l'objet d'une étude détaillée dans [START_REF] Bonnet-Bendhia | A generalized mode matching method for scattering problems with unbounded obstacles[END_REF]. En particulier, il y est établi que V + est un espace de Hilbert lorsqu'il est muni de la norme :

v V + = R |ξ 2 -k 2 | |Fv(ξ)| 2 dξ 1/2
, et que l'on a les injections (strictes) :

H 1/2 (R) ⊂ V + ⊂ H 1/2 loc (R).
Dans toute la suite, on supposera que k = pπ/d pour tout p ∈ Z. Sous cette hypothèse, on a β p = 0 pour tout p ∈ Z. De plus, comme |β p | ∼ p 2 π 2 /d 2 + 1 quand p tend vers +∞, l'espace naturel de définition pour a - n (•, •) n'est autre que H 1/2 (I n ). On est donc amené à définir l'espace fonctionnel

V -= {v ∈ L 2 (R), v |In ∈ H 1/2 (I n ), n∈Z v 2 1/2,In < +∞}, où : v 2 1/2,In = +∞ p=0 p 2 π 2 /d 2 + 1 (v, ψ n p ) 2 . Muni de la norme : v V -= n∈Z v 2 1/2,In 1/2
, V -est un espace de Hilbert et on a l'injection H 1/2 (R) ⊂ V -. L'espace variationnel où l'on est donc amené à rechercher u est donc V = V + ∩ V -, muni de la norme :

v V = v 2 V -+ v 2 V +
1/2 . Il est clair que H 1/2 (R) s'injecte de manière continue dans V . Par ailleurs, les éléments de V + sont localement dans H 1/2 (R), alors que ceux de V -ne diffèrent de ceux H 1/2 (R) que par leurs -éventuelles-discontinuités aux points y n = nd, n ∈ Z. On en déduit donc que V = H 1/2 (R) et que la norme • V est équivalente à la norme usuelle • 1/2,R (ce dernier résultat découlant du théorème de l'application ouverte). La formulation variationnelle du problème est donc la suivante:

Trouver (u, ϕ) ∈ W = {(v, ψ) ∈ V × H 1 (Ω 0 ); v |Σ0 = ψ |Σ0 } tel que : a ((u, ϕ) , (v, ψ)) = (v, ψ) , ∀(v, ψ) ∈ W
On peut maintenant énoncer le résultat principal de cette Note, à savoir que le problème de diffraction (1) relève de l'alternative de Fredholm:

((u, ϕ) , (v, ψ)) = a + (u, v) + n =0 a - n (u, v) + a - 0 (ϕ |Σ - 0 , ψ |Σ - 0 ) + Ω0 ∇ϕ • ∇ψ + Ω0 ϕψ c ((u, ϕ) , (v, ψ)) = -(k 2 + 1) Ω0 ϕψ.
Alors, par compacité de l'injection de ). Remarque 1. i) La méthode dévelopée dans cette Note peut être étendue au cas où la condition aux limites imposée sur la frontière Γ de l'obstacle est de type Dirichlet. Cette fois, comme u |Σn ∈ H 1/2 00 (Σ n ), on a V -⊂ V + , de sorte que V = V -∩ V + = V -. On peut alors montrer que le Théorème 1 est encore valable. ii) Du point de vue numérique, l'approche proposée fournit par ailleurs une méthode peu coûteuse pour l'approximation numérique du champ diffracté par éléments finis.

H 1 (Ω 0 ) dans L 2 (Ω 0 ), c (

Figure 1 :

 1 Figure 1 : Le réseau de plaques.

  Posons alors pour tout p ∈ N * : ψ n p (y) = 2/d cos(pπ (y -nd)/d) et ψ n 0 (y) = 1/ √ d. La famille (ψ n p ) p∈N constitue une base orthonormale de L 2 (I n ), et u admet sur chaque intervalle I n la décomposition : u = +∞ p=0 (u, ψ n p ) ψ n p , où (•, •) désigne le produit scalaire usuel dans L 2 (I n ).

)

  Les inconnues à déterminer dans (7) sont les deux fonctions u et ϕ, respectivement définies sur Σ et Ω 0 et vérifiant u |Σ0 = ϕ |Σ0 . Pour tout couple de fonctions régulières v, ψ respectivement définies sur Σ et Ω 0 et vérifiant v |Σ0 = ψ |Σ0 , il vient en comparant (6) et (7):

Théorème 1 .

 1 On suppose que k = pπ/d pour tout p ∈ N. Alors, l'opérateur associé à la forme bilinéaire a est un opérateur de Fredholm de seconde espèce. Il s'agit de montrer que la forme bilinaire a peut s'écrire a = b + c où b(•, •) est une forme bilinéaire coercive sur W × W et c(•, •) une forme bilinéaire associée à un opérateur compact sur W . Soit : b

= ϕ 2 1 / 2 , 2

 122 •, •) est associée à un opérateur compact. La coercivité de b(•, •) repose d'une part sur le découplage entre modes évanescents et propagatifs dans les expressions des parties réelle et imaginaire de b((u, ϕ) , (u, ϕ)), et d'autre part sur le signe adéquat de ces dernières (lequel est directement lié au choix de solutions sortantes). Plus précisément, on a :|Re b ((u, ϕ) , (u, ϕ))| = |ξ|≥k |ξ 2 -k 2 | |Fu(ξ)| 2 dξ + n =0 p>kd/π |β p | (u, ψ n p ) Σ0 ≤ C ϕ 2 1,Ω0 , on a donc : |Re b ((u, ϕ), (u, ϕ))| ≥ |ξ|≥k |ξ 2 -k 2 | |Fu(ξ)| 2 dξ+ n =0 p>kd/π |β p | (u, ψ n p ) part : |Im b ((u, ϕ) , (u, ϕ))| = |ξ|≤k |ξ 2 -k 2 | |Fu(ξ)| 2 dξ + n =0 p<kd/π |β p | (u, ψ n p )Par suite, comme β p = 0, on a :n =0 a - n (u, u) + u 2 1/2,Σ0 ∼ u 2 V -, d'où: √2|b ((u, ϕ) , (u, ϕ))| ≥ |Re b ((u, ϕ) , (u, ϕ))| + |Im b ((u, ϕ) , (u, ϕ))| ≥ C( u 2 V + ϕ 2 1,Ω0