Hani Abdeen
email: hani.abdeen@gmail.com

Stéphane Ducasse
email: stephane.ducasse@inria.fr

Houari Sahraoui
email: sahraoui@iro.umontreal.ca

Modularization Metrics: Assessing Package Organization in Legacy Large Object-Oriented Software

There exist many large object-oriented software systems consisting of several thousands of classes that are organized into several hundreds of packages. In such software systems, classes cannot be considered as units for software modularization. In such context, packages are not simply classes containers, but they also play the role of modules: a package should focus to provide well identified services to the rest of the software system. Therefore, understanding and assessing package organization is primordial for software maintenance tasks. Although there exist a lot of works proposing metrics for the quality of a single class and/or the quality of inter-class relationships, there exist few works dealing with some aspects for the quality of package organization and relationship. We believe that additional investigations are required for assessing package modularity aspects. The goal of this paper is to provide a complementary set of metrics that assess some modularity principles for packages in large legacy object-oriented software: Information-Hiding, Changeability and Reusability principles. Our metrics are defined with respect to object-oriented inter-package and intra-package dependencies. The dependencies that are caused by different types of inter-class dependencies, such as inheritance and method call. We validate our metrics theoretically through a careful study of the mathematical properties of each metric.

I. INTRODUCTION

Since some decades now, there exist many legacy large object-oriented software systems consisting of a large number of inter-dependent classes. In such systems, classes are at a low level of granularity to serve as a unit of software modularization. In object-oriented languages such as Java, Smalltalk and C++, package structure allows people to organize their programs into subsystems. A well modularized system enables its evolution by supporting the replacement of its parts without impacting the complete system. A good organization of classes into identifiable and collaborating packages eases the understanding, maintenance, test and evolution of software [START_REF] Deremer | Programming in the large versus programming in the small[END_REF].

However, even for well modularized software systems, code decays: as software evolves over time with the modification, addition and removal of classes and inter-class dependencies. As consequence, the modularization gradually drifts and looses quality, where some classes may not be placed in suitable packages and some packages need to be re-structured [START_REF] Eick | Does code decay? assessing the evidence from change management data[END_REF], [START_REF] Griswold | Automated assistance for program restructuring[END_REF]. To improve the quality of software modularization, assessing the package organization and relationships is required.

Although there exist a lot of works in the literature proposing metrics for object-oriented software, the majority of these previous works focused mostly on characterizing a single class [START_REF] Coppick | Software metrics for object-oriented systems[END_REF], [START_REF] Briand | A Unified Framework for Cohesion Measurement in Object-Oriented Systems[END_REF], [START_REF] Briand | A Unified Framework for Coupling Measurement in Object-Oriented Systems[END_REF], [START_REF] Briand | Defining and validating measures for object-based high-level design[END_REF], [START_REF] Abreu | Candidate metrics for object-oriented software within a taxonomy framework[END_REF], [START_REF] Li | Object-oriented metrics that predict maintainability[END_REF], [START_REF] Li | Another metric suite for object-oriented programming[END_REF], [START_REF] Chidamber | A metrics suit for object oriented design[END_REF], [START_REF] Ghassemi | Evaluation of coupling in the context of java interfaces[END_REF], [START_REF] Dallal | An object-oriented high-level design-based class cohesion metric[END_REF]. Few previous efforts measure the quality of some aspects of package organization and relationships [START_REF] Allen | Measuring coupling and cohesion of software modules: An information theory approach[END_REF], [START_REF] Fowler | Reducing coupling[END_REF], [START_REF] Martin | Agile Software Development. Principles, Patterns, and Practices[END_REF], [START_REF] Abreu | Coupling and cohesion as modularization drivers: are we being over-persuaded?[END_REF], [START_REF] Ponisio | Using context information to re-architect a system[END_REF]. Much of these efforts are focused on package cohesion and coupling from the point of view of maximizing intrapackage dependencies. But although this point of view is important for assessing an aspect of package structure, it is definitely not enough for assessing software modularization [START_REF] Abreu | Coupling and cohesion as modularization drivers: are we being over-persuaded?[END_REF], [START_REF] Martin | Agile Software Development. Principles, Patterns, and Practices[END_REF], [START_REF] Ducasse | Package surface blueprints: Visually supporting the understanding of package relationships[END_REF], [START_REF] Abdeen | Automatic package coupling and cycle minimization[END_REF], [START_REF] Abdeen | Package fingerprint: a visual summary of package interfaces and relationships[END_REF]. Fortunately, Santonu Sarkar et al. [START_REF] Sarkar | Metrics for measuring the quality of modularization of large-scale object-oriented software[END_REF], [START_REF] Sarkar | Api-based and informationtheoretic metrics for measuring the quality of software modularization[END_REF] have recently proposed a set of metrics that characterize several aspects of the quality of modularization. Their metrics are defined with respect to the APIs of the modules (i.e., packages), and with respect to object-oriented intermodule dependencies that are caused by inheritance, associations, state access violations, fragile base-class design, etc. Unfortunately, their metrics are mainly based APIs. They assume that each package explicitly declares its APIs, which is not the case for most legacy object-oriented software systems. Therefore, in the absence of declared APIs at package level, their metrics could not be applied without additional interpretations and heuristics. Although their metrics are valuable and they characterize many aspects of software modularization, we believe that some important aspects are still not characterized.

Our goal is to provide a complementary set of metrics that follow the principles of good software modularity as explained by Parnas [START_REF] Parnas | On the criteria to be used in decomposing systems into modules[END_REF] and R. Martin [START_REF] Martin | Agile Software Development. Principles, Patterns, and Practices[END_REF]. Since we address large legacy software systems, consisting of a very large number of classes and packages, we consider that packages are the units of software modularization: a package should provide well identified services to the rest of the software system, where the role of classes inside a package is implementing the package services. But unfortunately, in legacy object-oriented systems, APIs/Services are often, if any, not pre-defined explicitly at package level (i.e., systems are not API-based). Therefore, the metrics we propose in this paper are are not API-based. In this paper, we consider package and module to be synonymous concepts. On another hand, we consider the interfaces of a given package to be the package classes interacting with classes of other packages. For a given modularization, we consider classes to be at the lowest level of granularity.

In the following, Section II underlines the modularity principles that we address in this paper. In Section III we define the terminology and the notations we use to define our metrics. We define a set of coupling metrics in Section IV and a set of complementary cohesion metrics in Section V. In Section VI we show how our metrics satisfy all the mathematical properties that are defined by Briand et al. [START_REF] Briand | A Unified Framework for Cohesion Measurement in Object-Oriented Systems[END_REF], [START_REF] Briand | A Unified Framework for Coupling Measurement in Object-Oriented Systems[END_REF]. Before we conclude in Section IX, we discuss our metrics in Section VII and we compare them to previous works related to software metrics in Section VIII.

II. MODULARITY PRINCIPLES In software engineering practices, a module is a group of programs and data structures that collaborate to provide one or more expected services to the rest of the software. According to Parnas [START_REF] Parnas | On the criteria to be used in decomposing systems into modules[END_REF] and R. Martin [START_REF] Martin | Agile Software Development. Principles, Patterns, and Practices[END_REF], a module should hide its design decisions and should provide its services only through its interfaces. The main goal of modules is information hiding: only the module interfaces are accessible by other modules. Some object-oriented programming technologies support the definition of module interfaces through the declaration of APIs (Application Programming Interface) [START_REF] Strnisa | The java module system: Core design and semantic definition[END_REF], [START_REF] Microsystems | Jsr-294: Improved modularity support in the java programming language[END_REF]: an API may be a set of methods that are implemented in the module classes. Unfortunately, almost all legacy object-oriented software systems are not API-based.

In addition, it is not enough to group some programs inside a module, then declaring the module interfaces. Since a module should provide well identified services to other modules, the module programs should have a common goal: capturing the module design decisions and implementing the module services. It is widely known that a good modularization of a software supports the software changeability, maintainability and analyzability. In the rest of this section we underline the principles that a software modularization should follow, and that we address in this paper.

A. Hiding Information and Encapsulation.

As mentioned above, modules should encapsulate their implementations and provide their services via well identified interfaces.

For a legacy object-oriented systems, where the APIs are not pre-defined, the identifiable package interfaces are the package classes that interact with classes of other packages. In such a case, we assume that the principle of hiding information and of encapsulation requires the following (Principle I):

• We consider that hiding information is similar to hiding information exchange or communications. In this way, the communications (interactions) between packages should be as little as possible. • We consider that every package should encapsulate its design decisions and hide its implementation from other packages as much as possible. Thus, the number of methods/implementations/classes that a package exposes to other packages should be relatively small.

B. Changeability, Maintainability and Reusability.

It's well known that Maintenance activities represent a large and important part of the software life-cycle. One of the primary expected goals from modules is facilitating the software maintenance. Such a goal is usually supported by the localization of module changes impact on other modules. In other words, when changing a given module, the propagation of changing impact on other modules should be minimal (as little as possible). In the same context, modules should be reusable pieces of software. As stated earlier, a module should interact with other modules via well identified interfaces and requires identifiable services from other modules. Therefore, to support software changeability, maintainability and reusability at package level, we assume that (Principle II):

• Inter-package connectivity should be as little as possible.

C. Commonality-of-Goal vs. Similarity-of-Purpose.

As explained above, a module should provide particular (i.e., well identified) services to other modules. Therefore, the programs inside a module should have a common goal, which should be: capturing the module design decisions and implementing the module services. We refer to this principle as commonality-of-goal. In another side, if a module is expected to provide more than one service, the module services then should be as segregated as possible: each service should have a well identified purpose, and the service purpose should be different than the purpose of other provided services. To fulfill these objectives, we assume the following (Principle III):

• Ideally, a package should be as a provider of only one service to the rest of the software. • If not, the goal of each package interface should be as consistent as possible. In other words, for an interface participates with other interfaces to provide a service, it is an ideal state if that interface does not participate, aside from those other interfaces, to provide different service(s). In such a case, all the interfaces that participate to provide a service will have only one common goal, which is: implementing and providing that service.

Our Contribution. In this paper, we propose a set of metrics that measure "to which extent a given OO software modularization is well-organized", with regard to the principles we have underlined in this section. We organize our metrics into two subsets: 1) metrics characterize packages coupling with regard to the principles I and II; 2) and metrics characterize packages cohesion with regard to the principle III.

III. TERMINOLOGY AND NOTATION

We assume in this paper that the dependencies of a package to other packages are due to the dependencies of the classes inside the considered package to classes outside it. Those dependencies are either method calls or inheritance relationships. In this section we define the terminology and the notation we use in this paper.

A. Dependency Types

By definition, we say that a class c 1 extends another class c 2 if c 1 is a direct subclass of c 2 . We say that a class a is a subclass of another class b if a belongs to the subclass hierarchy of b. By definition, we say that a class x uses a class y if x is not a subclass of y, and there is a method directly implemented in x either calls a method directly implemented in y, or refers to an attribute directly defined in y.

For packages, whatever the number of classes inside a package p that have dependencies pointing to classes inside another package q, we say that p depends on q. This is regardless the number of concerned classes inside q and the number of inter-class dependencies. In this way, we say that p is client to q and q is provider to p. By definition, we say that package p extends another package q if there is a class in p that extends a class in q. Similarly, we say that p uses q if there is a class in p that uses a class in q.

B. Package Interfaces and Relationships

We assume in this paper that packages in large objectoriented software are the units of the software modularization. The role of classes inside a package is to implement and fulfill the package services. But due to the complexity of the services to provide, a package may contain a large number of classes, and it may require services from other packages.

In absence of pre-defined APIs at package level, we assume that the relationships of a package p to other packages form two sets of p classes. Those classes of p that play the role of p interfaces to the rest of the software system: p classes that have either incoming dependencies from classes outside p or outgoing dependencies pointing to classes outside p.

1) In-Interfaces: for a package p, the in-interfaces are the p classes that have incoming use or/and extend dependencies from p clients (i.e., from classes belonging to other packages). The p in-interfaces via use dependencies represent the services that p provides to the rest of the software system. The p ininterfaces via extend dependencies represent the p's services (abstract services) that other packages extend (implement).

2) Out-Interfaces: for a package p, the out-interfaces are the p classes that have dependencies pointing to p providers (i.e., pointing to classes belonging to other packages). The p out-interfaces via use dependencies represent the p classes that require services from the rest of the software system. They represent the requirements that p needs to fulfill its services. The p out-interfaces via extend dependencies represent the p's implementations of abstract services declared in other packages.

C. Modularization, Packages, Classes and Interfaces

We define a Modularization of an object-oriented software system by M =< P, D >. P is the set of all packages and D is the set of pairwise dependencies among the packages: D ⊆ P × P. Packages are the containers of classes: each package p ∈ P involves a set of classes C(p) ⊆ C: C is the set of all classes. Every class c belongs to only one package p(c).

The classes of a package p that have dependencies to classes outside p represent the interfaces of p Int(p) ⊆ C(p). Formally, I ⊆ C: I is the set of all interfaces. The interfaces of a package p are either in-interfaces InInt(p) relating p to its client packages Clients p (p) ⊂ P, or out-interfaces OutInt(p) relating p to its provider packages P roviders p (p) ⊂ P: Int(p) = InInt(p) ∪ OutInt(p). Taking liberties with the notation Clients p (p), we use Clients p (c) to denote the set of all packages containing classes that depend upon c. Similarly, we use the notation P roviders p (c) to denote the set of all packages containing classes that c depends upon them. We also use the notation Clients c (p) to denote the set of all classes outside p that depend upon classes inside p. Similarly, we use the notation P roviders c (p) to denote the set of all classes outside p that c depends upon them.

D. Dependencies Notation

In this section we define the notations of different types of dependencies that we use in this paper. We define the set of dependencies by D = {U ses ∪ Extends}. According to this, we define the notations of dependencies as follows:

Extend dependencies. For two classes c 1 and c 2 we define the predicate Ext(c 1 , c 2 ) that is true if c 1 extends c 2 . For convenience, we use the same predicate at package level:

Ext(p 1 , p 2 ) is true if p 1 extends p 2 .
We also use the oneargument version of the Ext predicate, as in Ext(c), to denote the set of all classes directly extended by the class c. Similarly we use this version at package level, as in Ext(p), to denote the set of all packages extended by the package p.

Use dependencies. For two classes c 1 and c 2 we define the predicate U ses(c 1 , c 2 ) that is true if c 1 uses c 2 . For convenience, we use the same predicate at package level: U ses(p 1 , p 2 ) is true if p 1 uses p 2 . We also use the oneargument version of the U ses predicate, as in U ses(c), to denote the set of all classes used by the class c. Similarly, we use this version at package level, as in in U ses(p), to denote the set of all packages used by the package p.

IV. COUPLING METRICS: METRICS RELATED TO INFORMATION-HIDING AND CHANGEABILITY PRINCIPLES

A. Index of Inter-Package Interaction

In this section we want to measure to which extent packages hide inter-class communication. This is by answering the following questions: to which extent classes belonging to different packages are not dependent on each other?

The goal of this section is to provide metrics that address the Hiding-Information principle explained in Section II-A. We define 2 similar metrics, IIP U (Index of Inter-Package Usage) and IIP E (Index of Inter-Package Extending): one dealing with U ses and the other with Extends.

1) Index of Inter-Package Usage: As defined in Section III, let C and P denote respectively the set of all classes and the set of all packages. Let U sesSum(C) be the sum of all use dependencies among the classes C, and let U sesSum(P) be the sum of all the use dependencies among the packages P:

U sesSum(C) = ci∈C |U ses(c i )| ExternalU ses(c) = {x ∈ C|U ses(c, x)&p(x) = p(c)} U sesSum(P) = pj ∈P ci∈C(pj ) |ExternalU ses(c i )| IIP U (M) = 1 - U sesSum(P) U sesSum(C) (1)
Interpretation. IIPU is the index of inter-package usage within a modularization M. It takes its value in the range [0,1] where 1 is the optimal value and 0 is the worst value: the greater value IIPU has, the smallest inter-package usage the modularization has. IIPU provides an index about the extent to which packages hide the actual inter-class usage. It is an indicator to the degree of collaboration among classes belonging to same packages.

2) Index of Inter-Package Extending: We define a similar metric to IIP U but from the extending interactions standpoint. Let ExtSum(C) be the sum of all inheritance dependencies among the classes C, and let ExtSum(P) be the sum of all inheritance dependencies among the packages P: i.e., the sum of all the inheritance dependencies among classes belonging to different packages.

ExtSum(C) = ci∈C |Ext(c i )| ExternalExt(c) = {x ∈ C|Ext(c, x)&p(x) = p(c)} ExtSum(P) = pj ∈P ci∈C(pj ) |ExternalExt(c i )| IIP E(M) = 1 - ExtSum(P) ExtSum(C) (2)
Interpretation. IIPE is the index of inter-package extending within a modularization M. It takes its value in the range [0,1] where 1 is the optimal value and 0 is the worst value: the greater value IIPE has, the smallest number of interpackage inheritance dependencies the modularization has. IIPE provides an index about the extent to which class hierarchies are well organized into packages. It is an indicator to the degree of concreteness of packages (i.e., concreteness of services that packages provide). As example, let the value of IIPE for a given modularization be 0.5, which mean that 50% of inheritance dependencies are among classes belonging to different packages. This could be interpreted as follows:

• The software system is mainly plugins-based, where the core software (some packages) declares abstract services that are implemented by other packages (plugins).

• The software system contains some packages that play as the root of large number of other packages. In this case some packages declare abstract services that are implemented by a large number of other packages. In this way, we can say that a large number of packages are similar from the point of view of interfaces they implement. • Finally, it may simply mean that the class hierarchies are not well organized into packages. In this case the modularization need a revision.

B. Index of Package Changing Impact

In Section IV-A we defined measurements that characterize inter-package coupling/interactions based on inter-package dependencies. In this section we want to provide other measurements that complement those defined in Section IV-A by answering the following: in the context of a given modularization M, to which extent M packages are inter-connected? to which extent modifying a package within M may impact other packages?

We want to define metrics characterize, at package level, the maintainability of M (ref. Section II-B). We believe that reducing inter-package dependencies, if it does not take into account the number of inter-dependent packages, may negatively affect the modularization maintainability. By example, Fig. 1 shows the package p has 7 dependencies coming from classes belonging to one package; while the package q has 3 incoming dependencies coming from classes belonging to 3 distinct packages. In such a case, and at package granularity, maintaining/modefying p may require an impact analysis to one package (p 1 ), while maintaining q may require an impact analysis to 3 packages (q 1 , q 2 and q 3 ). Therefore, from the point of view of impact localization, q is harder to be maintained than p.

As stated in Section III, let Clients p (p) denotes the set of all packages that depend on p; let P denotes the set of all packages in the modularization M. According to what we stated above, we define the index of package changing impact as follows:

Clients p (p) 1 -|P| (3) IP CI(M) = pi∈P IP CI(p i ) |P|
Interpretation. IPCI takes its value between 0 and 1, where 1 is the optimal value and 0 is the worst value. For a package p in a modularization M, a IP CI(p) value of 0 indicates that all packages in M are dependent on p. As a consequence, any changes on p may impact the whole modularization. In the context of the whole modularization, the IP CI(M) value indicates the extent to which M is free for changes: i.e., the index to which M packages are not inter-dependent.

C. Index of Package Communication Diversion

In this section we define metrics that measure the extent to which package communication (Section IV-A) is focused or diverted. Our vision of package communication diversion can be explained as follows: let p be a package uses 5 classes packaged into 5 different packages, and let q be a package uses 5 classes packaged in one package. In such a case we say that p communication is completely diverted, while q communication is completely focused. This is because p communication starts out with maximal number of coupling paths (5 provider cause 5 different coupling paths via 5 different provider packages), while q starts out with minimal coupling paths (one coupling path via one provider package).

1) Index of Inter-Package Usage Diversion: we define inter-package communication diversion on the usage dependencies. Let U ses(p) denotes the packages that p uses; let U ses c (p) denotes the classes that p uses; and let 1 be the minimal number of coupling paths that p may start with. Then we define index of inter-package usage diversion as follows:

P U F (p) = 1 |U ses(p)| IIP U D(p) =      P U F (p) × (1- 1-|U ses(p)| |U ses c (p)| ) 1 : |U ses c (p)| = 0 IIP U D(M) = pi∈P IIP U D(p i ) |P| (4)
Interpretation. IIPUD is the index of inter-package usage diversion and PUF is package usage factor. We used this factor to distinct packages that use a large number of packages from packages that use a small number.

The IIPUD(p) value ranges from 0 to 1. A IIPUD(p) value of 1 indicates that p communication diversion is minimal: as shown in Fig. 2, p starts out with only one coupling path, where it uses only one package p 1 . It mean that p requires services from only one package, thus it requires particular, nondispersed, functionalities. Otherwise, the smallest value the IIPUD(p) has, the largest diversion of usage communication p has. We assume by our definition of PUF(p) and IIPUD(p) the following: if a given package uses a large number of packages it will has a worst IIPUD(p) value than another package that uses a smaller number of packages, this is even if the term 1-|U ses(p)| U sesc(p) has the same value for both packages. As example, Fig. 2 shows that q uses 4 classes distributed over 3 packages, and shows that k uses 8 classes distributed over 5 packages. In such a case, 1-|U ses(q)| U sesc(q) = 1-|U ses(k)| U sesc(k) = 0.5. But the IIPUD(q) value ( 0.5

3 ) is better than the IIPUD(k) value ( 0.5 5 ) -Since q uses a smaller number of packages than k. For a given modularization M, a max IIPUD(M) value of 1 indicates an ideal focusing of package usage communication: each package in M uses, at maximum, only one package. Otherwise, as the value of IIPUD(M) decreases, the diversion of usage communication between packages increases. This can be an indicator to the following:

• A large number of packages require services that are dispersed over distinct packages. In such a case, the schema of usage communication paths is characterized as complex. Thus, a revision to M is required. • Some packages are characterized by very small value of IIPUD(p). In such a case, to minimize the schema's complexity of usage communication paths, the maintainers may start by focusing on those packages.

2) Index of Inter-Package Extending Diversion: we define the index of package extending diversion (IIPED) similarly to IIPUD defined above, but with regard to extending dependencies. Let Ext(p) denotes the packages that p extends; let Ext c (p) denote the classes that p extends; and let 1 be the minimal number of coupling paths that p may start with.

P EF (p) = 1 |Ext(p)| IIP ED(p) =      P EF (p) × (1- 1-|Ext(p)| |Ext c (p)| ) 1 : |Ext c (p)| = 0 IIP ED(M) = pi∈P IIP ED(p i ) |P| (5)
Interpretation. The interpretation of IIPED(p) is similar to what we stated above for IIPUD(p) in Section IV-C1. Note that IIPED is defined with regards to extending dependencies rather than usage dependencies. IIPED also takes its value between 1 and 0, where 1 is the optimal value and 0 is the worst value. When the value of IIPED(p) goes closer to 0 is an indicator that p extends a relatively big number of classes that are distributed over distinct packages. This could mean that p plays the role of a plugin of a big number of packages. It also indicates that p implement interfaces that are completely not similar from the point of view of their providers. As summary, p is may expected to provide complex service(s). Take as example a package p that extends 10 classes belonging to 10 different packages, thus IIPED(p) = 0.01. In such a case, p is a plugin for 10 packages and it requires a particular attention.

V. COHESION METRICS: METRICS RELATED TO COMMONALITY-OF-GOAL PRINCIPLE

A. Index of Package Goal Focus

In this section we assume that a package, in its ideal state, should focus on providing one well identified service to the rest of the software system. What do we mean by focused service? and how to characterize such an aspect?

From the point of view of the package role, we say that a package provides a focused service if it plays the same role with all its client packages. In other words, for a package p, we say that p services are focused if they are always used together by every client package to p. In such a case, for an ideal situation, the p in-interfaces are always used together, so they represent a single composite provided by p to the rest of the system. In this way, we say that p is focused (i.e., the p goal is focused). Otherwise, where the p in-interfaces are used via relatively small portion per client package, p is then not focused: p plays different roles with its clients.

Let Req(x, c) be true if x uses or extends c; let InInt(p,q) denotes the set of p in-interfaces required by q; and let Role(p, q) denotes the role that p plays with its client q. We define then the Focus of a package p as the average of p roles with respect to all p clients:

InInt(p, q) = {c ∈ InInt(p)|∃x ∈ q : Req(x, c)} Role(p, q) = InInt(p, q) InInt(p) : q ∈ Clients(p) P F (p) = pi∈Clientsp(p) Role(p, p i ) |Clients p (p)| (6)
P F (M) = pi∈P P F (p i ) |P|

Interpretation. PF(p) always takes its value between 0 and 1, where 1 is the optimal value and 0 is the worst value. The largest value PF(p) has, the highest frequency of requiring largest portion of p in-interfaces. Ideally, when the package in-interfaces are always used together by every client package to that package, as for p in Fig. 3, PF(p) takes then a max value of 1. The goal of PF(p) is to provide one answer for both following questions: (1) to which extent p services are required together? (2) to which frequency p clients require all the p services? To better understand the behavior of PF(p) we take 3 examples (the cases of q, k and y in Fig. 3):

1) Fig. 3 shows that the package q exposes 5 in-inerfaces to 4 clients q 1 , q 2 , q 3 and q 4 ; where each of them uses only 2 classes of q in-interfaces. In this case, P F (q) = 2 3) Finally, Fig. 3 shows that the package y also exposes 5 in-interfaces to 4 clients: y 1 , y 2 , y 3 and y 4 ; where each of y 2 , k 3 , k 4 uses 3 classes of y in-interfaces, while y 1 uses only 2 classes. In this case, P F (k) < P F (y) = 11 20 As summary, when the value of PF(p) decreases, we expect that p clients frequently require relatively-small sets of p services. For a given modularization M, PF(M) also takes its value from 0 to 1, where 1 is the optimal value and 0 is the worst value. When PF(M) decreases, we say that the definition of package roles within M gets worse.

B. Index of Package Services Cohesion

Unlike what we stated above in Section V-A, in this section we assume that a package may be expected to provide several services. Therefore, we want to address the following questions: what if the purpose of a package p is to play distinct roles with regard to its clients? in this case, to which extent p services are cohesive with regard to their common use?

In absence of pre-defined APIs at package level that declare explicitly which services a package provides to the rest of the software, we assume the following: since each client package q to a package p represents a requirement to a subset of p in-interfaces, we define such a subset as a composite service CS(p, q) provided by p to q:

CS(p, q) = {int ∈ InInt(p)|int ∈ P roviderc(q)}
According to this definition, we say that two composite services of p, CS(p, q) and CS(p, k): q, k ∈ Clients p (p), are identical if both represent the same group of classes. In this way, we measure the cohesiveness for a composite service by measuring the similarity of purpose of the service classes: to which extent the service classes are required together? For example, let α be a composite service presented by 3 classes {c 1 , c 2 , c 3 }, and suppose that either these classes are always required together or there is no subset of these classes used apart. In this case we say that α is fully cohesive from similarity of purpose perspective. Another example, let β be also a composite service of p to q, CS(p, q). Suppose that each class of β classes is always required, by other client packages than q, aside from other ones. In this case we say that β is fully segregated from similarity of purpose perspective.

Let λ q,k denotes the set of classes results from the intersection of 2 composite services of a package p: λ q,k = |CS(p, q) ∩ CS(p, k)|. Let SP k (p, q) a measurement of the similarity of purpose for a composite service CS(p, q) with regard to another composite service CS(p, k):

k (p, q) =      |λ q,k | |CS(p,q)| |λ q,k | = 0 1 Else
The similarity of purpose for a composite service α with respect to another one β is given by: the relative size of the subset of in-interfaces that are shared in both services with respect to the size of the α classes set. The largest set of α classes is involved in β, the highest value of similarity that α has with regard to β. SP k (p, q) always takes its value between 0 and 1, where 1 is the optimal value and 0 is the worst value. If there is no classes shared between α and β, then we say that β does not affect the similarity of purpose of α.

According to what we stated above, we define the cohesion of a composite service by the average of its similarity of purpose with regard to all p's clients. We define then the index of package services cohesion, for a package p, by the average of cohesion for all the composite services that p provides:

CS cohesion (p, q) = ki∈Clientsp(p) SP ki (p, q) |Clients p (p)| IP SC(p) = qi∈Clientsp(p) CS cohesion (p, q i ) |Clients p (p)| (7)
IP SC(M) = pi∈P IP SC(p i ) |P|

Interpretation. CS cohesion (p, q) takes its value between 0 and 1, where a value of 1 indicates that CS(p, q) is completely cohesive, while a value of 0 indicates that CS(p, q) is completely segregated. IPSC(p) and IPSC(M) both take their value between 0 and 1, where 1 is the optimal value and 0 is the worst value. Fig. 4 shows a package p in 3 different cases from the perspective of common usage of p services. In the 3 cases, p provides 7 classes {c 1 , c 2 , c 3 , c 4 , c 5 , c 6 , c 7 } to 3 client packages {q 1 , q 2 , q 3 }. The figure also shows that p provides 3 different composite services: CS 1 , CS 2 and CS 3 .

• In Fig. 4(a), the classes of any composite service CS of p are always required together: none of the CS classes is used aside from the other classes of CS. Therefore, we say that similarity of purpose for the CS classes is very well defined: all the classes that are in a CS have the same purpose, which is providing services to the same group of client packages. Thus, CS i cohesion = 1. In this case, the value of IPSC for p is maximal: IP SC(p) = 1. • In Fig. 4(b), the difference from Fig. 4(a) is that a small subset {c 4 , c 5 } of CS 1 classes has also another purpose, which is providing services to q 2 . Therefore, the similarity of purpose for the CS 1 classes is not well defined: CS 1 cohesion = 4 5 . In this case, the IP SC(p) value is smaller than in the previous case (a): IP SC(p) = 14 15 .

• In Fig. 4(c), the difference from Fig. 4(b) is that the subset {c 5 } of CS 2 classes has also another purpose, which is providing services to q 3 . This negatively affects the similarity of purpose for both CS 3 and CS 2 , since {c 5 } is currently a subset of CS 3 also: CS 2cohesion = 2 3 and CS 3 cohesion = 2 3 . In this case, the IP SC(p) value 32 45 is smaller than in the previous case (b).

VI. VALIDATION

In this section we provide a theoretical validation of our coupling and cohesion metrics. This is by showing that our metrics satisfy all the mathematical properties that are defined by Briand et al. [START_REF] Briand | A Unified Framework for Cohesion Measurement in Object-Oriented Systems[END_REF], [START_REF] Briand | A Unified Framework for Coupling Measurement in Object-Oriented Systems[END_REF].

A. Coupling Metrics Validation

The widely known properties to be obeyed by a coupling metric are: Non Negativity, Monotonicity and Merging of Modules. The following of this section shows how our coupling metrics (IIP U , IIP E, IP CI, IIP U D and IIP ED) satisfy these properties.

Non Negativity property: according to this property, for any given software modularization M, the coupling metric value for M should be greater than 0. According to what we discussed in Section IV, all our coupling metrics take their value between 0 and 1, where 0 is the worst value.

Monotonicity property: this property assumes that adding additional interactions to a module cannot decrease its coupling. To check this property: let p be a package in a given modularization M, that has d dependencies pointing to or/and coming from n packages. Now let p ′ in M ′ be the same package than p but with one additional dependency (d + 1) pointing to one additional client/provider package (n + 1). In this case, all the following conditions are true:

IIP U (M) IIP U (M ′ ) (IIP E(M) IIP E(M ′ )) ; IP CI(M) IIP CI(M ′ ) ; IIP U D(M) IIP U D(M ′ ) (IIP ED(M)
IIP ED(M ′ )). This means that all our coupling metrics satisfy the monotonicity property.

Merging-of-Modules property: this property assumes that the sum of the couplings of two modules is not less than the coupling of the module which is composed of the data declarations of the two modules. To check this property, let p and q be two packages in M, that have respectively n and m dependencies pointing to or/and coming from x and y packages. Now, let k be the merging of p and q (i.e., k contains only the classes of both packages), and let M ′ be the resulting modularization after the merging. In this case, the sum of the dependencies that k have with other packages N cannot be greater than n + m (N n + m). Similarly, the number of the k client and provider packages R cannot be greater than x + y (R x + y). In this case, any of our coupling metrics will indicate that the coupling in M ′ is less than (or equal to) the coupling in M. As consequence, all our coupling metrics satisfy the merging-of-modules property.

B. Cohesion Metrics Validation

The widely known properties to be obeyed by a cohesion metric are: Normalization, Monotonicity and Cohesive Modules. The following of this section shows how our cohesion metrics (P F and IP SC) satisfy these properties.

Normalization property: this property assumes that the value of a cohesion metric should belongs to a specified interval [0, M ax]. As explained in Section V, our cohesion metrics are normalized and take their value in the interval [0, 1]. Therefore, our cohesion metrics satisfy this property.

Monotonicity property: this property assumes that adding cohesive interactions to a module/modularization cannot decrease its cohesion. To check this property, let p be a package in a given modularization M. Supposing that we add to p a new class c, where c is always used by other packages in M ′ together with a non-empty set of p ′ in-interfaces, and it is never used aside from that set: p ′ and M ′ are respectively the resulting package and modularization after adding c to p. In this case, the value of both P F (p ′ ) and IP SC(p ′ ) metrics cannot be smaller than their values for p. In this way, our cohesion metrics satisfy the monotonicity property.

Cohesive-Modules property: this property assumes the following: if p 1 and p 2 are cohesive packages in M, but there is no cohesive relationships between p 1 classes and p 2 classes, then merging p 1 and p 2 into one package q in M ′ should not increase the modularization cohesion. To check these property, we suppose that none of the p 1 in-interfaces is required by packages require p 2 in-interfaces. In this case, the value of P F (q) cannot be greater than P F (p 1 ) value nor than P F (p 2 ) value. Thus, P F (M ′ ) value cannot be greater than P F (M). As a consequence, P F satisfies the cohesivemodules property. In the same context, since none of the p 1 in-interfaces is required by packages require p 2 in-interfaces, the composite services CSs of q are exactly those of p 1 and p 2 and their cohesion values still the same. On another hand, the number of the q's client packages is equal to the sum of the p 1 client packages and the p 2 client packages. Thus the IP SC(q) value cannot be greater than the IP SC(p 1 ) value nor the IP SC(p 2 ) value. In this way, IP SC(M ′ ) value cannot be greater than IP SC(M). As a consequence, IP SC also satisfies the cohesive-modules property.

VII. DISCUSSION

In this section, we discuss our metrics with regard to the modularity principles we underlined in Section II.

A. Assessing Package Encapsulation

The goal of the IIP U and IIP E metrics is measuring the extent to which packages hide inter-class communication. They measure the extent to which packages encapsulate system complexity at class granularity, where this last is given by the frequency of inter-class interactions. According to Callebaut et al. [START_REF] Callebaut | Modularity: Understanding the Development and Evolution of Natural Complex Systems[END_REF], where they suppose that: "the frequencies of interaction among elements in any particular subsystem of a system should be two times greater than the frequencies of interaction between the subsystems". From this point of view, we defined our metrics to assess packages encapsulation within a given modularization by the ratio of inter-package interactions to all interactions at class granularity. From IIP U perspective, for a given modularization M, if all the method call interactions are among classes belonging to different packages, thus they all represent inter-package interactions. In this case, packages encapsulation of inter-class usage is at the worst level, where IIP U (M) = 0.

As complementary metrics to IIP U and IIP E, we defined IIP U D and IIP U E that measure to which extent the interactions of a package p are spread over other packages. It is worth to note that other aspects can also participate in assessing package encapsulation, such as: the relative number of in-interfaces that a package exposes (i.e., InInt(p) C(p) ). At method granularity, the relative number of methods used outside their classes' package can also be an indicator for package encapsulation quality.

B. Assessing Package Changeability

The goal of the IP CI metric is assessing package changeability from the standpoint of the localization of changes impact. Our standpoint is that changing a package may directly impacts other packages depending on the changed package. According to this, the IP CI(p) metric assesses p changeability with regards to the p clients packages. We defined IP CI(p) as a ratio to the number of all packages within the modularization to give a measurement relative to the context of the given software: i.e., let p and q be two packages within the modularizations M 1 and M 2 , respectively; where M 1 consists of 1000 packages and M 2 consists of 20 packages; suppose that p and q have the same number (e.g., 10) of client packages; in such a context, the impact of changing q on M 2 is greatly larger than the impact of changing p on M 1 .

C. Assessing Package Role and Reusability

To characterize the role of a given package p with within its modularization M and to assess p reusability, we defined the metrics P F and IP SC. On the first hand, the goal of P F (p) is to provide us with answers to the following questions: (1) does p provide one service to the rest of the rest of the software? (2) to which extent p classes are used together by the rest of the software? On the other hand, if p provides multiple services, the goal of IP SC(p) is to measure the cohesiveness of p services from the commonality-of-goal vs. similarity-of-purposes perspectives Section II-C. IP SC(p) provides us with answers to the following questions: (3) to which extent p is a provider of well-identified (particular) services to the software system? (4) to which extent p is a provider of utility (general) services to the software? Our standpoint is that if p services are used together in an identifiable way, then it is easier to understand the goal, the scope and the purpose of p services than if p services are used together in an non-identifiable (arbitrary) ways. In this last case, understanding the p services requires an understanding of each p in-interface aside from others.

VIII. RELEVANT RELATED WORKS VS. OUR METRICS

To cope with software system complexity, Parnas et al. [START_REF] Parnas | On the criteria to be used in decomposing systems into modules[END_REF] have introduced the idea of decomposing software systems with the intention of increasing module cohesion and minimizing inter-module coupling. Since then, many metrics have been defined to compute the cohesion and coupling of a module, where module concept is usually used to represent a composite software entity (e.g., a class or a package).

A large body of previous works on Object-Oriented software metrics is mainly focused on the issue of characterizing the class design, either looking at class internal complexity or relationships between a given class and other classes [START_REF] Chidamber | A metrics suit for object oriented design[END_REF], [START_REF] Abreu | Candidate metrics for object-oriented software within a taxonomy framework[END_REF], [START_REF] Li | Object-oriented metrics that predict maintainability[END_REF], [START_REF] Li | Another metric suite for object-oriented programming[END_REF], [START_REF] Henderson-Sellers | Object-Oriented Metrics: Measures of Complexity[END_REF], [START_REF] Bieman | Cohesion and reuse in an object-oriented system[END_REF], [START_REF] Bieman | Measuring design-level cohesion[END_REF], [START_REF] Briand | Defining and validating measures for object-based high-level design[END_REF], [START_REF] Briand | A Unified Framework for Cohesion Measurement in Object-Oriented Systems[END_REF], [START_REF] Briand | A Unified Framework for Coupling Measurement in Object-Oriented Systems[END_REF], [START_REF] Dallal | An object-oriented high-level design-based class cohesion metric[END_REF]. Some of these works characterize a class by counting its internal components, such as counting the number of methods and the number of attributes. Others characterize a class by looking at its relationships with other classes, as for the coupling between objects (CBO), or characterize the class cohesion with regard to the similarity between pairs of methods and pairs of attribute types in the given class. Few number of these previous works provide metrics that do not characterize a single class, such as metrics measure the depth of the inheritance tree in a software.

In the literature, there is also a body of work that focus on object-oriented metrics from the standpoint of their correlation with software changeability [START_REF] Kabaili | Cohesion as changeability indicator in object-oriented systems[END_REF], or from the standpoint of their ability to predicate software maintability [START_REF] Bandi | Predicting maintenance performance using object-oriented design complexity metrics[END_REF], [START_REF] Dagpinar | Predicting maintainability with objectoriented metrics -an empirical comparison[END_REF]. Other researchers argue that the measures resulted by the cohesion and coupling metrics of the previous works cited above are open to interpretation [START_REF] Kabaili | Cohesion as changeability indicator in object-oriented systems[END_REF], [START_REF] Briand | A Unified Framework for Coupling Measurement in Object-Oriented Systems[END_REF]. This is due to polymorphic method calls, where it is difficult to capture through static analysis which method is actually being called for execution.

In general, there are few metrics in the literature devoted to packages. In the following we present those metrics according to their perspectives: either Cohesion or Coupling perspective.

A. Cohesion Metrics

Emerson presents a metric to compute cohesion applicable to modules in the sense of Pascal procedures [START_REF] Emerson | A discriminant metric for module cohesion[END_REF]. His metric is based on a graph theoretic property that quantifies the relationship between control flow paths and references to variables. Patel et al. [START_REF] Patel | A measure for composite module cohesion[END_REF] compute the cohesion of Ada packages based on the similarity of their members (programs). The idea is to measure cohesion based on subprograms similarity. They use the keywords shared between subprograms. They consider only the specification of the package, not the keywords present in the body, which are invisible from outside the package. Similarly, Allen and Khoshgoftaar define information theory-based (as opposed to counting) coupling and cohesion measures for subsystems [START_REF] Allen | Measuring coupling and cohesion of software modules: An information theory approach[END_REF]. Their measures are applied to modules, which are represented as graphs. They define cohesion in terms of the similarity between the objects of the concerned modules. However these approaches do not take into account classes and the relationships they cause inter-packages and/or intrapackage.

Misic adopts a different perspective and measures the cohesion of a package as an external property [START_REF] Mišić | Cohesion is structural, coherence is functional: Different views, different measures[END_REF]. He claims that the internal organization of a package is not enough to determine its cohesion. Similarly, Ponisio et al. introduce the notion of use cohesion (or conceptual cohesion) [START_REF] Ponisio | Using context information to re-architect a system[END_REF]. They measure the cohesion of a package considering the usage of the package classes from the client packages. Their cohesion metric does not take into account the explicit dependencies among the package classes (e.g., method call).

Recently, Martin proposed the Rational Cohesion metric. It is defined as the average number of package internal dependencies per class. Martin's cohesion metric measures the connectivity among the internal classes of a given package, regardless the amount of dependencies that the package classes have with external classes.

Finally, Sarkar et al. proposes an API-based cohesion metric [START_REF] Sarkar | Metrics for measuring the quality of modularization of large-scale object-oriented software[END_REF]. They define the APIU metric that measures the extent to which a service-API is cohesive, and the extent to which it is segregated from other service-APIs. This is from the common usage point of view. However, their metric is API based and apply that each module (i.e., package) explicitly declares its service-APIs. Otherwise, the metric is not applicable.

Our Cohesion metrics. The IP SC cohesion metric we provide is similar to certain extent to the AP IU metric provided by Sarkar et al. [START_REF] Sarkar | Metrics for measuring the quality of modularization of large-scale object-oriented software[END_REF], but it is not API-based. In addition, we provide a new cohesion metric (P F ) with the aim to measure the extent to which a package plays a consistent role with regard to its usage by its client packages. The standpoint is that, ideally, a package should focus to provide one service for other packages. Otherwise, where a package provides more than one service, we provide the IP SC metric that measures the cohesiveness of package services from the similarity-of-purpose perspective.

B. Coupling Metrics

Martin [START_REF] Martin | Agile Software Development. Principles, Patterns, and Practices[END_REF] defines two kinds of package coupling: efferent coupling (C e ) and afferent coupling (C a ). The C e is to assess the coupling degree between a package p and its provider packages. While the C a is to assess the coupling degree between p and its client packages.. He defines the C e metric for a package p as the number of p's provider classes, and defines the C a metric as the number of p's client classes. Recently, in 2005 [START_REF] Martin | The tipping point: Stability and instability in oo design, 05[END_REF], he redefines these metrics: p's C e is the number of p's provider packages, while p's C e is the number of p's client packages. However, these coupling metrics do not take in consideration the context of the package modularization. Hautus addresses cyclic package coupling [START_REF] Hautus | Improving Java software through package structure analysis[END_REF]. He proposes a tool to analyze the structure of Java programs and a metric that indicates the percentage of changes to make a package structure acyclic.

Finally, Sarkar et al. propose coupling metrics [START_REF] Sarkar | Metrics for measuring the quality of modularization of large-scale object-oriented software[END_REF]. First of all, they propose API-based coupling metric (MII) that calculates how frequently the methods listed in a module's APIs are called by the other modules. Then they assume that modules may also interact with each other by calling methods that are not listed in the APIs of the modules. Therefore, they provide another metric (NC) that measures, for a given module, the disparity between the declared API methods and the methods that are actually participating in intermodule call traffic. However, both metrics are not applicable when modules are not API-based. In the same paper, Sarkar et al. propose also the following coupling metrics: [START_REF] Abdeen | Package fingerprint: a visual summary of package interfaces and relationships[END_REF] The IC metric, to measure inheritance-based intermodule coupling;

(2) The AC metric, to measure intermodule associationinduced coupling. IC and AC, are defined in the same way, but with regard to U ses and Extends dependencies, respectively. For a package p, the value of AC (IC) is given by the smaller value among the following: the number of p's client classes, the number of p's client packages, or the number of p's out-interfaces. In this way, they do not take care about the evidence indicates that the number of p's client packages is surely not bigger than the number of p's client classes. Also, they also do not provide us with the rationale beyond their definition, nor with an interpretation of their metrics.

Our Coupling metrics. They are not API-based and characterize three different aspects of inter-package coupling within a given modularization. First of all, we provided metrics (IIP U and IIP E) that measure the extent to which packages follow the hiding-information principle, with regard to inter-package communication. Then, we provided other metrics (IIP U D and IIP U E) which measure the extent to which the package communication is focused or dispersed. Finally, we provided a metric (IP CI) measures the package changing impact: it measures the extent to which a package modification impacts the whole software modularization.

IX. CONCLUSION AND FUTURE WORKS

In this paper, we tackled the problem of assessing modularizations for not API-based object-oriented software systems. We defined a complementary set of coupling and cohesion metrics that assess packages organization in large legacy object-oriented software. While designing our metrics, we addressed some modularity principles related to packages encapsulation, changeability and reusability. In addition, we defined metrics characterizing packages role within a given modularization. We defined our metrics with regard to two different types of object-oriented inter-class dependencies: method call and inheritance relationships. We also provided our metrics with exhaustive interpretations for both types of dependencies.

We successfully showed that all our metrics satisfy the mathematical properties that cohesion and coupling metrics should follow.

We plan to investigate our metrics on real large software systems and validate their utility with independent software maintainers.

Fig. 2 .

 2 Fig. 1. Explanation for Package Changing Impact

5 2 )

 2 Fig.3shows that the package k also exposes 5 ininterfaces to 4 clients k 1 , k 2 , k 3 and k 4 ; where k 4 uses 4 classes of k in-interfaces, while each of other clients uses only 2 classes. In this case, P F (q) < P F (k) =1

2

 2

Fig. 3 .

 3 Fig. 3. Explanation for Package Focus

  CS3 is changed from (b):CS3 = {c5, c6, c7}.

Fig. 4 .

 4 Fig. 4. Explanation for Package Services Cohesion.

SP


Odile Heddebaut
email: odile.heddebaut@inrets.fr

Inrets

Brendan Finn

RABUEL Sébastien Etts
email: etts@indigo.ie

RAMBAUD François Certu

Dr Odile Heddebaut Is Certu

Sébastien Rabuel
email: sebastien.rabuel@developpement-durable.gouv.fr

François Rambaud
email: francois.rambaud@developpement-durable.gouv.fr

The European Bus with a High Level of Service (BHLS): Concept and Practice

Keywords: BRT, BHLS, BHLS Characteristics, Implementation conditions, gains in ridership

The paper discusses the respective American Bus Rapid Transit (BRT) and European Bus with a High Level of Service (BHLS) concepts comparing their approaches and implementation conditions. It describes the main BHLS characteristics and the gains in ridership findings for several case studies among European countries.

Introduction

Since the 1990's throughout Europe bus improvements are observed and are currently called "Bus with a High Level of Service" (BHLS). Sweden has developed this concept with "trunk networks" in Stockholm and Gothenburg, BHLS lines in Jönköping and bus-only-roads as a pretram solution in Lund. In England and Ireland such systems are called "Quality Bus Corridor". France expands its concept of Bus à Haut Niveau de Service -(BHNS) in many cities of different sizes. Germany and Spain have their BHLS Metrobus concept and the Netherlands apply it under the name of "Hoogwaardig Openbaar Vervoer" (HOV). These countries have followed the same "systemic" approaches that seek to both increase the bus ridership and its quality of service and to adapt the bus offer to the European urban and economic context.

In order to study European BHLS implementation, to develop a comprehensive approach to bus provision and to sort out best practices, a collaboration among 14 European countries 1 has been launched through a COST2 Action approved in April 2007 called "Buses with a High Level of Service (BHLS): Fundamental characteristics and recommendations for decision-making and research". The objectives of this COST BHLS group are mainly to share the current state of the art and know-how in this field, to find and compare the key results as well as to understand the limits and difficulties of the BHLS implementation. This paper presents firstly how the BHLS concept has emerged in Europe and the condition of its implementation. Secondly, it reports the main findings concerning the ridership gains for 10 of the specific BHLS bus lines.

From the American Bus Rapid Transit (BRT) concept to the European Bus with a High Level of Services (BHLS) concept

The North American BRT concept development North American towns have developed with diffuse and low density suburbs that do not favor mass transit. Indeed, car ownership growth has led to the construction of large highways rather than the development of rail or public transport networks. In this context, Bus Rapid Transit firstly emerged in the form of bus lanes on freeways known as "busways" to improve the bus services and ease the Central Business District (CBD) access (Los Angeles in 1973and 1979, Houston in 1979). Nevertheless, in the United States, these busways often have been turned into high occupancy vehicle (HOV) lanes. This answer to the oil crisis has decreased bus performance [START_REF] Vuchic | The Bus Transit System : its underutilized potential, Federal Transit Administration[END_REF] due to the loss of dedicated lanes.

Later, the BRT projects reappeared in the 1990's and focused on speed. BRT was then defined as "a rapid mode of transportation that can combine the quality of rail transit and the flexibility of buses" [START_REF] Levinson | Bus Rapid Transit: An Overview[END_REF]. As their implementations increased in North and South America, the studies describe a wider spectrum of characteristics to define the BRT systems (Levinson et al., 2003a[START_REF] Levinson | Transit Cooperative Research Program, Report 90 : Bus Rapid Transit[END_REF], Diaz, 2009). They are ranked from "BRT-Lite" to "Full-BRT" depending on their components [START_REF] Gray | Bus Rapid Transit, A Handbook for Partners[END_REF]. BRT-Lite is the "lower limit" of the BRT concept and must be as a minimum faster than a normal bus line (Levinson et al., 2003a). It is often achieved by greater stop spacing and priorities at junctions. These lines often have their own identity by using a brand name, logo and specific colors applied to buses and stations. BRT-Lite is the most common form of BRT in North America (the Vancouver B-line in 1996, Chicago since 1998, the MetroRapid Bus in Los Angeles since 2000, etc.).

Full-BRT represent the bus systems that can achieve metro-style performances. They necessitate full grade-separated transit ways, off-board fare collection, frequent and rapid services, modern and clean vehicles. Bogotá, Brisbane and Ottawa are the most famous Full-BRT examples described (Levinson et al., 2003a, Wright andHook, 2007). This kind of BRT is not really implemented in the United States, but this model is greatly admired and represents the ultimate reference point. Its operational performance combined with its flexibility could be integrated into an environment achieving higher urban densities [START_REF] Hoffman | Advanced Network Planning for Bus Rapid Transit, The "Quickway" model as a modal alternative to "light rail lite[END_REF](Hoffman, ). al., 2006)). Flagship projects such as the Cleveland Health Line and the Eugene EMX Green line should contribute to develop the BRT-Heavy concept. Sixty three percent of American BRT projects scheduled for completion by 2017 include dedicated right of ways as an integral component [START_REF] Kantor | Bus Rapid Transit, Vehicle Demand and System Analysis Update[END_REF]. American research is now turned towards the integration of BRT projects into urban planning with a systemic vision like any other rapid transit system [START_REF] Vuchic | Métros légers et liaisons rapides par autobus, modes concurrents ou complémentaires ? Transportation Public International[END_REF]. Moreover, the creation of a specific body able to involve all the stakeholders at all planning levels is seen as a condition for success [START_REF] Arrillaga | Bus Rapid Transit Demand Analysis Update, Federal Transit Administration[END_REF][START_REF] Danaher | Bus Rapid Transit : Practitioner's guide[END_REF]. The most recent BRT studies focus on planning conditions, decision-making processes, BRT integration into existing networks, and the acceptability and image of these transportation systems (Golub et al., 2007, Wright andHook, 2007). Studies are carried out about the perception of various public transportation systems in Los Angeles [START_REF] Cain | Tangible and intangible service attributes Quantifying the importance of image and perception to Bus Rapid Transit[END_REF] and on the influence of BRT stations on property value in Pittsburgh [START_REF] Perk | Impacts of Bus Rapid Transit stations on surrounding single-family home values: study of Pittsburgh' East Busway[END_REF].

Since 2005, a French working group headed by the transport study organization CERTU3 has defined its own concept of BRT based on initial local experiences (the "new town" of Évry since the 1970s, the Trans-Val-de-Marne system of Greater Paris since 1993, TEOR in Rouen since 2001) and by adapting BRT to the French urban environment and "transportation culture" (Babilote and Rambaud, 2005). In 2007, this French group decided to share its experiences with 14 others European countries by launching a group of experts known as "Cost BHLS" (www.bhls.eu). Emerging from this group is a shared view on BHLS, albeit with some unique characteristics from one European country to the other.

European BHLS as BRT inspired by tramways performance and adapted to the European urban context

In the United States, public transportation essentially answers the needs of commuters headed downtown, from extremely scattered and often far-off starting points. The European urban models present relatively dense cities with narrow streets where most activities and residence are mixed. This has influenced the public transportation organization that takes advantage of concentrated flows. The demand for public transportation goes beyond peak hour commuting travel and covers all-day, evening and week-end use of the transit systems. In most European cities, the systems of metros, tramways and suburban trains already fulfill the needs of high capacity transit.

European tramways are light systems operating mostly via exclusive on-street right-of-ways (i.e. more like streetcars than fully-segregated light railways) and integrated into the city with atgrade junctions and accessible platform. Capacity is limited by intersection management, with maximum of 6,000 trips/hour/direction for a 45 meters (148 feet) long tram with a headway of 3 minutes. The tramway has reappeared in many cities where it had been dismantled, with a new high-performance and modern image and with a strong linkage to enhanced streets. At the same time, buses generally suffer from a negative image due to congestion, irregularity, discomfort and outdated designs.

The emergence of the BHLS concept in Europe can therefore be explained by the necessity to fill the gap between the regular bus and the tramway in terms of performance, cost and capacity. Thoroughfares not served by metros or tramways usually present a relatively low user-potential, which does not justify the higher tramway capacity associated to higher cost (€15-30 million per km, or $30-70 million per mile). The BHLS approach tries to link advantages of an economical bus-based system and performances of heavier systems. It has been inspired by American BRT with regard to methodology and design, favoring a transportation system in which the vehicle is but one of various components. Just like BRT, BHLS remains generic and can be integrated into any type of infrastructure configuration.

European BHLS: a different choice of components compared to the American approach

In general, very high-capacity configurations using grade-separated transit ways do not suit the European urban context (lack of available space, undesirable urban cuttings, low demand). Nevertheless, inspired by tramways projects, the on-street exclusive lane constitutes the fundamental component allowing greatest speed and regularity gains, and the possibility to share again the streets in favor of alternative modes (walking and cycling ) despite occasional implementation difficulties [START_REF] Heddebaut | Les difficultés de mises en oeuvre des sites propres pour les modes de transport collectifs guidés ou non : le cas des lignes de bus à haut niveau de service[END_REF]. BHLS can be implemented into congested zones, such as city centers. Moreover, the European concept of BHLS allows for a certain permeability of the exclusive lane, useful in case of a limited but heavily used route (taxis, cyclists, deliveries).

In comparison, in the United States, despite wider and often less congested numerous avenues, the realization of on-street exclusive lanes remains limited. BRT systems more often use discontinuous and not well-marked bus-only lanes that are mostly limited to rush hours. Outside the CBDs, BRT circulation via reserved lanes is provided by the opportunity to re-develop unused railroads (Miami's South Dade Busway in 1997, the Pittsburgh Busway in 2000, the Los Angeles Orange Line in 2005, etc.) or to use freeway shoulders. Nevertheless, attitudes are progressively evolving. With the implementation of the EMX Green Line in Eugene in 2007 and the Healthline in Cleveland in 2008, the United States now has two BRT-Heavy projects using axial on-street exclusive lanes integrated into the urban environment (use of grass-planted lanes in Eugene, building-to-building regeneration on Euclid Avenue in Cleveland).

We can find other differences between the American BRT and the European BHLS characteristics, in addition to their approach to interpreting exclusive right-of-way. In Europe, increase in stop-spacing is blocked by the resistance of users -in particular, disabled personswhile it is used by 89% of future American projects planned for 2017 or earlier [START_REF] Kantor | Bus Rapid Transit, Vehicle Demand and System Analysis Update[END_REF]. Off-board payment which is rare in Europe should develop with public awareness of this measure's effectiveness (54% of the projects in USA). Lastly, while long commute times encourage Americans to retain a high number of seats in their vehicles, capacity needs and attempts to reduce costs lead to fewer seats in European vehicles. This design results in a higher proportion of standing passengers whose comfort could only be ensured by special modifications of the bus platform, generating additional costs.

While Full-BRT is not present in Europe, numerous systems approach BRT-Lite relying on a hierarchical organization of the bus network such as the blue buses of Stockholm (Sweden) since 1999, the Lianes of Dijon (France) since 2004, and the Linea Alta Mobilita in Italy (Prato, Brescia, Pisa). But most of the new projects more or less correspond to America's BRT-Heavy. That is the case in France with 9 systems in operation and over 20 planned [START_REF] Finn | Buses with High Level of Service (BHLS) -Operational, Regulatory and Contractual Dimensions[END_REF]. It is also present in the Netherlands (Amsterdam in 2001, Eindhoven in 2005), England (Leeds in 1998, Cambridge in 2009), Sweden (Gothenburg in 2003, [START_REF] Bjerkemo | Avancerade kollektivtrafiksystem utomlands -mellanformer mellan buss och spårväg[END_REF]), and Germany (Hamburg in 2005), and is being developed in Spain (Castellón in 2008, projects planned for Madrid) and Italy (projects for Messina and Bologna).

Varying institutional frameworks and cultures that condition the emergence of BHLS in Europe

Most European countries have legislation regulating the organization of public transportation. In these countries, BHLS services are scheduled, like tramways, within planning documents similar to urban travel plans [START_REF] Finn | Buses with High Level of Service (BHLS) -Operational, Regulatory and Contractual Dimensions[END_REF].

However, this model does not apply to Great Britain. There, deregulation (outside the Greater London area) authorizes the implementation of bus routes on the initiative of the relatively numerous private operators. In this context, it is relatively difficult to establish a global, integrated approach that favors the emergence of BHLS as single routes on dedicated running ways with a very high level of speed, comfort and information. Local authorities can just improve the network's performance by setting up bus lanes or bus priorities at traffic lights without a systemic approach. The focus on right-of-way is also a characteristic of the Dublin manner to improve the bus quality but with a different reason due to the fragmented responsibilities between the infrastructure planning and the bus service planning. Quality Bus Corridors (QBC) were created in Dublin since 1997 and are based on strongly identified, multiroute bus-only lanes which can also be used by taxis and cyclists [START_REF] O'mahony | Quality Bus Corridors in Dublin[END_REF].

Contrary to Americans, Europeans have some difficulties in implementing bus lanes on freeways. That could be explained by the low co-ordination between the numerous stakeholders (urban and non urban transport authorities, freeways and roads managers, financial bodies). Nevertheless, the few and recent experimentations (HOV lane on the A6 freeway in Madrid region, shoulder bus lane in A48 freeway in Grenoble region in France ) are showing a high potential for further development in Europe.

Ridership gains achieved with BHLS

BHLS in Europe is implemented for a wide range of objectives, as described above. Nonetheless, each system anticipates gains in ridership. To be more precise, the transportation, social, environmental or economic objectives can only be achieved when ridership gains are made. Two questions arise:

• whether BHLS really is effective in achieving ridership gains,

• which are the contributory factors to ridership gains.

The experience in Europe has been that BHLS systems do achieve ridership gains, and in some cases ridership can even double. BHLS systems frequently involve significant changes in structure and volume of service, in addition to the travel time and quality improvements. While improvement in each of these attributes is well known to increase ridership, the holistic approach appears to achieve ridership gains which are "more than the sum of the parts".

To illustrate the European experiences, a set of 10 BHLS systems is presented in Tables 1 and2 below. Table 1 presents primary characteristics of the BHLS systems, including the system length, nature of the running way, daily carryings and service headway during the peak periods.

Table 2 presents changes in ridership for each of the 10 BHLS systems. This indicates growth in the range 20%-134%. Table 2 also presents likely explanatory factors for the ridership gains:

-% change in the service supply (measured in vehicle-kms) -% change in operating speed or journey time -scale of change in service headway -whether there was significant change to the network and/or route structure -whether there was significant change to the tariff structure or average tariff -whether the BHLS was given unique branding and strong marketing While we do not have full comparative data for all sites, we can make the following observations:

• BHLS system daily ridership is in the range 24,000 to 65,000 passengers/day. These data are for individual corridors, and hence matches or exceeds the ridership of many tramway and North American BRT systems. • All of the BHLS systems achieve significant ridership gains, in the range 20%-134%. It should be noted that this level of growth may be achieved over a number of years as the systems mature. • BHLS systems invariably offer improved frequency and volume of service.

• In many cases the network and lines within the BHLS corridor have been restructured.

• In many cases, BHLS offers improved operating speed and journey time, although in a few cases there has been little improvement in speed/time but big improvement in both reliability and variance in journey times. • All systems have a system identify and most have a unique brand and dedicated fleet.

Marketing, image and product repositioning are a strong feature of BHLS systems.

It is clear that BHLS has achieved ridership gains and hence achieved many of its goals. Despite this, there is an extreme shortage of structured research into the individual and linked factors that achieve the ridership gains. This is urgently required to (a) assist future projects; (b) give better understanding of where funds are best targeted; and (c) provide feedback and evidence to policymakers and transport operators about the effectiveness of investment in BHLS.

Conclusion

The following key points can be highlighted: Successful BHLS projects require lengthy dialogue; the issue of choosing the right mode remains fundamental. As a mode, the bus appears flexible and well-adapted to new or progressive expanded urban zones (e.g. Almere in the Netherlands and the Fastrack project South-East of London).

Buses allow a variety of configurations: from high-volume primary routes fed by secondary services through to trunk sections shared by several routes in order to minimise transfers. However, in Europe there are no traces of the express services that are so widely developed in high capacity projects on the other side of the Atlantic.

Some BHLS projects are designed to be upgraded in future into tramway systems once there is sufficient demand. Europe's economic context and labour costs appear to favour tramway for upwards of 30,000 to 50,000 trips/day and for volumes of over 2,000 to 2,800 passengers per hour per direction.

These projects are beginning to show signs of the same high-quality integration as tramway can do; the exclusive running lanes are easily passable in order to promote cycling and walking. It then becomes difficult to go beyond three-minute headways on individual routes in order to maintain satisfactory service consistency.

A bus market specifically for BHLS appears to be emerging: this needs to be recognisable and provide the level of comfort and information of a structuring corridor. The bi-articulated vehicle also appears to have its place in Europe (Hamburg, Utrecht, Geneva).

BHLS seems to have a highly promising market in Europe in towns, medium-sized conurbations as well as in the outlying zones of the biggest metropolitan areas. Until the expected publication of the COST Action report that will be published for the final seminar planed in Autumn 2011 to present the main findings and recommendations for decision-makers, do stay in contact through the website www.bhls.eu4 , where you will find, amongst other information, all the presentations of the plenary workshops that have been and will be organised. Notes:

1) Dublin data is for the Stillorgan Road Quality Bus Corridor, there are other QBCs.

2) Gothenburg data is for route 16, there are other TrunkBus lines.

3) Hamburg data is for the MetroBus Line 5; there are other MetroBus lines.

4) Dublin, Madrid systems operate multiple routes on their BHLS systems. Figure shows combined headway across all routes in direction of city centre.

5) The Bus-VAO system is tidal. Data shown is for inbound morning peak (0700-1000), for multiple bus routes and HOV occupants combined.

6) Passengers per day for Prato and Stockholm are averaged across multiple routes/corridors.

Illustrations:

Photo 1 : Amsterdam Zuid-Tangent (photo: Stads-regioAmsterdam, 2008)

Photo 2: Dublin -QBC Stillorgan Road (photo: Sven Allan Bjerkemo, 2008)

Table 1 : Characteristics of selected BHLS systems in Europe

 1 Case studies of the COST BHLS www.bhls.eu accessed 26 March 2010

		CITY	SYSTEM IDENTITY	SYSTEM LENGTH (KM)/	NATURE OF RUNNING WAY	PASSENGERS PER	PEAK HEADWAY	DEDICATED FLEET?
				(DEDICATED LANES)		DAY		(MINUTES)
	Amsterdam	Zuid-Tangent	41 (33)	Bus-only road, bus lanes	40,000	6	Yes
					(suburban/orbital)
	Dublin	1	Quality Bus Corridor	12 (8.4)	Bus-lanes	34,000	< 1.5 4	No
	Gothenburg 2	TrunkBus	16.5 (7.5)	Bus-lanes	24,000	3.3	Yes
	Hamburg 3	MetroBus	14.8 (4.0)	Bus-lanes	60,000	3.5	Yes
	Helsinki	Jokeri Line	28 (6)	Bus-lanes	25,000	5	Yes
					(orbital route)
	Madrid	Bus-VAO	16.1 (16.1)	Tidal segregated lanes	33,000 5	< 1 4	No
					(motorway insertion)
	Nantes	BusWay	7 (6)	Bus-lanes	24,600	3.3	Yes
	Paris		TVM	20 (19)	Bus-only road	65,800	3.5	Yes
					(suburban/orbital)
	Prato		LAM	42 (15)	Bus-lanes	n/a		7	Yes
	Stockholm	Blue Line	40 (12)	Bus-lanes	36,575	6	5	Yes
	Source:

European participating countries: Belgium, Czech Republic, France, Germany, Greece, Ireland, Italy, Netherlands, Portugal, Romania, Spain, Sweden, Switzerland and United Kingdom,.

COST Action is an intergovernmental European framework for international co-operation between nationally funded research activities. COST creates scientific networks and enables scientists to collaborate in a wide spectrum of activities in research and technology. COST activities are administered by the COST Office and is endorsed by the FP7. For further information, please visit: www.cost.esf.org

CERTU: Center for Studies on Urban planning, Transportation and public facilities.

The first leaflet can be downloaded at http://www.bhls.eu/IMG/pdf/bhls_nl1_gb_web.pdf

Photo 3: Hamburg -Metrobus XXL (photo: Thomas KNÖLLER October 2009) Photo 4 : Madrid Bus-VAO (Photo: CRTM Madrid October 2008) Photo 6: Nantes BusWay® 4 (photo: Odile HEDDEBAUT May 2008) Photo 7: Paris -TVM (photo: Odile HEDDEBAUT May 2008)

Notes:

1) Data for Dublin, Gothenburg and Hamburg are for specific BHLS lines/routes; these are the 'flagship' BHLS lines in each city.

2) The baseline for BHLS Ridership Growth is usually taken as prior to the major BHLS implementation. In some cases there had been gradual improvements in the preceding years, the baseline usually includes such improvements.

3) In some cases, the data was reported as changes in journey time