The sisterhood of the traveling packets From a cyber-security perspective, attribution is considered to be the ability to determine the originating location for an attack. However, should such an attribution system be developed and deployed, it would provide attribution for all traffic, not just attack traffic. This has several implications for both the senders and receivers of traffic, as well as the intervening organizations, Internet service providers and nation-states. In this paper we examine the requirements for an attribution system, identifying all of the actors, their potential interests, and the resulting policies they might therefore have. We provide a general framework that represents the attribution problem, and outline the technical and policy requirements for a solution. We discuss the inevitable policy conflicts due to the social, legal and cultural issues that would surround such a system. In this paper we investigate the requirements behind an attribution system, defining first the general characteristics of "attribution" (Section 1). We then provide a more complete definition of attribution, discussing how this differs from the approaches typically used in the literature. From this, we design a framework for an attribution system (Section 2) that details three key components-the actors, the attribution vector and the policy negotiation system-and describes the system requirements. We then discuss the interesting political and social aspects of the framework. First is the feasibility of developing a full attribution system by analogy to other real-world developments (Section 3), then the economic incentives for creating such a system (Section 4) and finally we posit a likely path towards creating such a system (Section 5). We consider the limitations of attribution (Section 6) and provide some related work (Section 7). We conclude with thoughts on future directions (Section 8). Adequate attribution deals not just with identifying the source of attack packets addressed to a particular recipient. An adequate attribution system needs to address a wide range of needs held by at least nine different types of network participants. An expanded-and necessary-view raises a number of policy and technical questions not answerable under current approaches. Such an expanded view of attribution points towards major policy reforms, as well as technical needs. Even so, such a system will not meet the needs of all parties. Conflicts will emerge between the various network interests; the extent to which such conflicts can be resolved satisfactorily will shape the extent to which some groups may choose, for instance, to stay off of the Internet. Defining what the needed policy structure is, what needs it will satisfy, and equally what needs it will not satisfy, is an important step forward in creating a security structure for networked systems. This will allow us to delimit what works for attribution, and what does not.. This attribution framework cannot be imposed upon a structure with control as fragmented as that of the Internet. Such attempts will fail miserably; the United States, North Korea, Iran, and Israel would be unlikely to agree on mechanisms and policies for attribution (or anything else, for that matter). And even where the technology provides added benefits (such as Secure DNS), the Internet community is slow to adopt it. Thus, this framework will grow slowly, piece-meal, in a modular fashion, with incompatibilities between interfaces being ironed out or accepted as reality, resulting in the development of "attribution networks" as discussed above. Perhaps legal issues, such as criminal and civil liability, will drive the development of different corporate and governmental attribution policies and enforcement mechanisms, while the individualism rampant in other parts of the Internet will drive the non-attribution policies and mechanisms. Only time will tell-and the need for attribution and nonattribution ensures that, as the ancient curse claims, we shall live in interesting times.. To summarize, an adequate delineation of attribution involves:. • Multiple parties, not just the receiver attempting to identify the origin of the sender;. • Different needs and requirements for these parties, with negotiating possible; and. • Imperfect trust relationships between all parties.. Formalizing this structure requires consideration of the context of the messages sent, including content. Trustworthiness of the links is critical. There are opportunities to make improvements in the technology. However, we are still left with the situation where users are unable to use the Internet with the desired levels of attribution.. However, while the multinational policy and technical requirements for adequate attribution may appear daunting, positive historical examples of similar systems suggest that the framework outlined is feasible to create. The requirements for an attribution framework raise a number of interesting questions.. What constitutes "adequate" attribution, and who decides what is adequate? This itself is an issue of governance. Equally difficult is ensuring the governance guiding the answers reflects the changing needs of users, administrative domains, and other interested parties.. This also raises the question of theoretical assurance-how can we reason about attribution quality and types? Clearly, dualvalued logic fails, as there are gradations of attribution. A natural candidate for this type of analysis is fuzzy logic; indeed, although not specifically identified as such, much of the description above uses ideas from that field.. An interesting aspect of this governance is the issue of revocation-when can attribution be undone? In a centralized world, a central authority could direct all networks (specifically, intermediate nodes) to discard all attribution information, and not provide any of their own. But in a distributed world, as our Internet is today, this is not possible.. Another area is selective access to the attribute vectors. Mentioned earlier, this idea raises issues of negotiation. If multiple central authorities are involved in creating (or assuring) an attribution vector, will multi-jurisdictional co-operation depend upon limiting access to the vector and if so, how will that affect their actions?. Conflicts and ambiguities will undoubtedly arise. The negotiation system and supporting infrastructure must handle them appropriately. For example, attribution may be desirable for crimes and cyber attacks, and undesirable for political speech and whistleblowers. Actors may have different, conflicting goals, and hence the success of a governance system in resolving such conflicts will be a measure of its success, although the metrics to evaluate the degree of success will have to be developed. Note that this is far more than a technical problem; it delves into the political and cultural aspects of attribution, where our culture assumes that the ability to visit a dissident web site is good, but the governments of some countries would strongly disagree with this particular belief. In some cases, notably when a whistleblower reveals information his or her organization would prefer to keep secret, the organization will want full attribution whereas doing so would be inimical to the whistleblower.. Finally, recall that under some circumstances a requirement for false attribution exists. In addition to the intelligence agent example given earlier, whistleblowers and political dissidents may desire no attribution or a false one when they visit a reporting or government web site which requires attribution. Under what circumstances should this capability be provided? If not always available, who should determine when circumstances warrant its use? The technical literature contains a large body of work on some forms of attribution, focusing primarily on IP-traceback (e.g., see [1, 2, 15, 16] ) as a scheme for achieving attribution. The goal of IP traceback is to determine the originating IP address of a packet, regardless of the stated originating IP address, which is intended to address attribution in the case of spoofed-source denial of service attacks. Thus this approach addresses only a subset of the attribution problem that we present. While there are other technical approaches to attribution, as surveyed by Wheeler and Larsen [5] , these approaches also address only limited aspects of the attribution issue as a whole.. Pyun and Reeves [17] take a different approach to attack attribution-they provide a graph theoretic approach to the optimum placement of sensors on the internet. They find that monitoring only 5% of autonomous systems will provide attribution of packets with little ambiguity. They do not address, however, the policy issues surrounding attribution, nor do they acknowledge that attribution may not be desirable under certain circumstances. Thus their approach also addresses only one part of the attribution problem.. An early paper by Staniford-Chen and Heberlein [3] identified the issue of attribution in terms of accountability, and more specifically the need to hold attackers accountable. They focused on the problem of "stepping stones"-where an attacker chains his activity through multiple machines in order to obscure his origin-and developed a technique called "thumbprinting". A thumbprint is a summary of the contents of a connection, and can then be used to determine if connections between two different machines (e.g., between machines A and B, and between machines B and C) are similar or the same, thus potentially indicating stepping stone behavior. While this paper highlights the need for accountability, its solution also addresses only one part of the attribution problem. However, this paper does address determining the ultimate source of a message, regardless of any intermediate chaining, which is an identified weakness with our current framework.. Strayer et al. [18] provide an attribution architecture in their 2003 paper. More specifically, they provide an architecture that combines packet-tracing techniques (e.g., such as IP traceback approaches) with stepping stone detection (such as thumbprints) to provide integrated source attribution. Their architecture does not address any policy considerations or identify cases where nonattribution is preferable.. These papers do not address a framework that spans both the technical and non-technical realms, focusing instead on the technology required to implement their notions of attribution, and in some cases on the uses to which it may be put. Our framework expressly goes beyond this, focusing on the higher-level implications and requirements and eschewing many technical details because those depend on the precise characteristics of interest.. Daniels and Spafford [19] investigated the attribution issue, calling such systems Network Traffic Tracking Systems (NTTS). They identify several attributes for such a system-accuracy, precision, the ability to resist subversion, low overhead, low cost, scalability, real time tracking, privacy and control, and note that the attributes may be orthogonal to each other. Like us, Daniels and Spafford identify, albeit briefly, the need for discussion around the privacy issues and who controls access to the attribution information (e.g., government authorities, the final recipient, or others), and use the case of a whistle-blower to indicate the complexity of the issue. They provide three models of NTTS, the "Internet Model" being the one that most closely resembles our framework. They identify a number of practical issues-which are also applicable to our framework-in this model, and question if an NTTS is even desirable given the privacy implications.. This paper introduces many elements that our framework addresses. In particular, we assume that the desirability or undesirability (such as the level of privacy to be provided) can be determined using the policy negotiation system we introduce. Critical to our work is the observation that all parties must have a say in the attribution characteristics and assurances that they are willing to accept-even if only to say, "None!" In this way, we generalize the question that Daniels and Spafford ask, to encompass not only privacy but also other attribute characteristics of importance to the actors.. Much research has been done on negotiation systems; however, these tend to focus on negotiation strategies [20] or specific issues or environments such as network management issues [21, 22] , trust negotiation [23] , and electronic commerce [24] . Closest to our proposed system is SCENS [25] , designed to support data sharing but easily adapted to different forms of negotiation and environments such as governance. These works all focus on implementations, whereas our discussion focuses on goals and the properties needed to meet those goals. Many of these systems could be used to implement parts of our framework.

O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


A projection method for low speed flows We propose a decomposition applicable to low speed, inviscid flows of all Mach numbers less than 1. By using the Hodge decomposition, we may write the velocity field as the sum of a divergence-free vector field and a gradient of a scalar function. Evolution equations for these parts are presented. A numerical procedure based on this decomposition is designed, using projection methods for solving the incompressible variables and a backward-Euler method for solving the potential variables. Numerical experiments are included to illustrate various aspects of our algorithm. We are interested in solving unsteady compressible flow problems where the flow speed is much less than the sound speed and the acoustical waves have large wavelengths. Such problems could be found in a variety of applications such as combustion [1] and flow noise generation [2] . These low speed flows are often difficult to simulate numerically because of the presence of low-amplitude acoustical waves.. One possible way to simulate to low speed flow is to treat such a flow as a fully compressible flow and use an explicit method. These explicit methods have a time step restriction, the CFL condition, which states that for stability, the time step size must be inversely proportional to the maximum of the sum of flow speed and the sound speed. Explicit methods are best suited for problems where the flow speed is on the same order of or larger than the sound speed. In low speed problems, however, the sound speed could be orders of magnitude larger than the flow speed, thus grossly overresolving in time features of the fluid flow.. One would then like to somehow separate out the "ill-conditioned" part of the flow and treat it implicitly, while hoping that the rest of the flow may be advanced at an acceptable time step with an economical and accurate method. Such is the approach first taken by Amsden and Harlow [3] and later expanded by many others [4] [5] [6] [7] [8] [9] [10] [11] . A common theme in all these methods is splitting: by separating the flow variables into various parts, one may identify the part of the flow that needs implicit treatment and thereby bypass the stringent CFL condition dominated by the sound speed.. In their original paper [3] , Amsden and Harlow treated the density variable implicitly; later, it was understood that the pressure variable is the problematic one. Casulli and Greenspan [4] were able to show that only pressure needs to be discretized implicitly, and the resulting difference equations are solved via an iterative procedure. Patnaik et al. [5] extended the work of Casulli and Greenspan to include an "implicitness parameter" to tune the degree of implicitness. Various other formulations have also been proposed in [6] [7] [8] . Klein [9] and co-workers [10] have also proposed a numerical method based on asymptotics, which were an extension of the low Mach number asymptotics of Klainermann and Majda [12] .. To develop a numerical method useful in the regime of our interest, we shall study a decomposition of the equations of inviscid, compressible flows. These equations will be rewritten in terms of a Hodge decomposition of the velocity field and in terms of auxiliary pressures. With the new equations, we will separate the flow into the divergence-free part, one that varies on a time scale determined by the flow speed, and a part that may contain fast sound waves. The former part may be advanced with time step determined solely by the flow speed. Since the fast sound waves are only present in the latter part, we can advance much of the flow using an explicit method, and apply an implicit method only to the compressible part.. In this paper, we will first present the evolution equations for low speed flows in Section 2. A numerical algorithm for solving these equations will be detailed in Section 3. Results of numerical experiments will be tabulated in Section 4. We derived the evolution equations for the divergence-free and the curl-free parts of the velocity field in an inviscid, compressible flow. A numerical method for simulating flows whose Mach numbers are less than one based on these equations has been devised. Convergence results show that our numerical method is second-order accurate for lowMach-number flows and first-order accurate for higher Mach numbers. Results of other numerical experiments were presented.. One area of improvement is the resolution of acoustic waves. As we have seen from our convergence tests, there can be important feedback from the acoustics into the flow even at low Mach numbers. While it may not be important that the sound waves be resolved, we do wish to minimize the polluting effects of the poor resolution of acoustics. A possible approach would be to use a higher-order time discretization in the Helmholtz solve. A desirable higher-order time discretization should contain enough damping to eliminate acoustic waves effectively at very small Mach numbers, and not as much damping for the sound waves at higher frequencies.. Another area of improvement lies in the numerical implementation of boundary conditions. We do not yet fully understand how to implement boundary conditions numerically in general; each case has to be "engineered" to obtain physically reasonable results. We would like to develop a consistent framework for the application and the implementation of boundary conditions for the decomposed velocity fields, as well as the corresponding boundary conditions for the projection operators.. Finally, we would like to extend our formulation to include viscosity and chemistry terms to study combustion applications.

O O O O B I I O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Fast recursive grayscale morphology operators: from the algorithm to the pipeline architecture Abstract This paper presents a new algorithm for efficient computation of morphological operations for gray images and the specific hardware. The method is based on a new recursive morphological decomposition method of 8-convex structuring elements by only causal two-pixel structuring elements (2PSE). Whatever the element size, erosion or/and dilation can then be performed during a unique raster-like image scan involving a fixed reduced analysis neighborhood. The resulting process offers low computation complexity combined with easy description of the element form. The dedicated hardware is generic and fully regular, built from elementary interconnected stages. It has been synthesized into an FPGA and achieves highfrequency performances for any shape and size of structuring element. Mathematical morphology was first introduced as a method to measure binary objects, but soon became a complete theory based on set operations [14] . Morphology relies on the use of set operators (intersection, union, inclusion, complement) to transform an image. The transformed image usually has fewer details, but its main characteristics are still present. Once the image has been simplified, measurements can be computed to give a quantitative analysis of the image. Morphological transformation is based on a structuring element (B) characterized by its shape, size and center location, also called origin. Each pixel in an image is compared with B by moving B so that its center hits the pixel. Depending on the type of morphological transformation, the pixel value is set to the minimal or maximal value of the pixels in the translated structuring element.. Performing a morphological operation directly from its formal definition would imply that all the neighbors present within the structuring element should be sought for each pixel. Of course, this process becomes time consuming for large elements. Fortunately, mathematical morphology properties led to the introduction of methods which partially solve this problem.. The main goal of the decomposition algorithms is to reduce the number of basic dilations needed to generate the desired structuring element. Different ways to decompose structuring elements have been investigated exploiting two fundamental properties: dilations [2, 19] and set unions of elements [9, 18] . More particularly, Chen has defined a decomposition method using only two non-connected pixel elements. On the other hand, Xu demonstrated how any 8-convex polygon could be constructed from a set of elements included in a 4-neighborhood.. Mathematical morphology is a tool commonly used in embedded vision systems, so a great deal of work has been done to design hardware implementation. The quality of an architecture dedicated to mathematical morphology is generally measured by its ability to describe different element shapes versus hardware efficiency, e.g., memory and computation requirements, or number of image scans. Of course, decomposition element methods can help the design of efficient dedicated hardware by limiting the number of operations.. Chien et al. [3] proposed a comparative table among existing architectures for a dilation by a 7 9 7 structuring element (see Table in one pass 1). Chien architecture relies on the principle of PRR (Partial-Result-Reuse), trying to avoid redundant computations. This concept has been used earlier by Pitas Ong and Sunwoo [11] and [12] , but their architectures were not fully optimized. Coltuc and Pitas [5] proposed an optimal solution but only for rectangular elements, and Chien architecture is an extension of some other shapes. A comparison between PRR and the proposed method will be discussed later.. Diamantaras and Kung [6] architecture provides the best flexibility, supporting both non-flat and arbitrarily shaped elements. However, it is at the expense of complexity. The architecture is built as a systolic array, and one Processor Element is defined for each pixel of the element. Ruetz and Brodersen [13] and Sheu et al. [15] both proposed pipelined implementations deduced from decomposition element techniques that are also limited to flat rectangular elements. The performance and capability of their approach will be further discussed in the Sect. 4 .. Other works concern computational efficiency for grayscale morphological operators. Van Herk [17] proposed a very efficient method called HGW for grayscale erosions and dilations, requiring only three comparisons for 1D structuring elements, whatever the element size. It relies on a recursive forward and backward ranking of pixel values inside temporary buffers. Extension to 2D rectangular structuring elements is achieved by consecutively applying the same process to rows and columns, for a total of six comparisons. 2D circular symmetric filtering can also be considered by running the process along the two diagonal directions, doubling the number of operations. Soille et al. [16] introduced an extension of this algorithm to any angle 1D structuring elements. Gil and Kimmel [8] further improved the initial algorithm to reach 1.5 comparisons for 1D erosions and dilations, thanks to a sliding window technique. The major drawback is that this algorithm induces non-regular data flow processing, as well as the generation of ordered lists, which are not compatible with efficient implementations. In Clienti et al. [4] , the authors proposed a modification of the original HGW, with a block mirroring scheme, in order to design a low-memory requirements architecture. The other drawback is that all HGW-based techniques have been designed and optimized in 1D space: 2D extension requires a second pass and is mainly restricted to rectangular elements shapes. The technique proposed in this paper performs one-pass erosion or dilation, considering more generalized 2D convex shapes.. In this paper, we address the problem of grayscale morphology with a restricted class of discrete convex polygons (2) . We then introduce a fast recursive technique for grayscale dilations, relying on this particular decomposition scheme. The process regularity also enables the design of a pipeline architecture (Sect. 3). We summarize the results in Sect. 4. In this paper, we have presented an algorithm enabling the design of fast mathematical grayscale morphology operations. We have proposed a systematic way to describe any 8-convex structuring elements through a generic decomposition process using 2-pixel structuring elements. Then these 8-convex structuring elements are recursively constructed by elementary dilations and union sets, based on a fixed and close neighborhood. This decomposition system has been used to define the efficient implementation of elementary morphological operators in both software and hardware. Computation complexity is directly correlated to the number of elementary dilations involved in the decomposition. Comparative implementation efficiency with existing architectures is summarized in Table 1 . Except for the Diamantaras solution, all the other techniques have been optimized for only rectangular elements. For memory and cycle requirements, the proposed method achieves the same performances as the best solutions. Only Chien architecture provides a better solution in terms of comparators, but as mentioned earlier, the PRR concept is essentially efficient for 1D and rectangular elements. Moreover, PRR and the proposed methods are not incompatible: additional improvements in order to reduce the number of operations, for simple shapes, can be a posteriori realized after the decomposition definition.. The proposed architecture has been synthesized into FPGAs. As the architecture requires few resources, a medium FPGA such as an APEX 20KC (Altera) used in these experiments is sufficient to support dilations by large

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


A case study of post-deployment user feedback triage Many software requirements are identified only after a product is deployed, once users have had a chance to try the software and provide feedback. Unfortunately, addressing such feedback is not always straightforward, even when a team is fully invested in usercentered design. To investigate what constrains a teams evolution decisions, we performed a 6-month field study of a team employing iterative user-centered design methods to the design, deployment and evolution of a web application for a university community. Across interviews with the team, analyses of their bug reports, and further interviews with both users and non-adopters of the application, we found most of the constraints on addressing user feedback emerged from conflicts between users heterogeneous use of information and inflexible assumptions in the team's software architecture derived from earlier user research. These findings highlight the need for new approaches to expressing and validating assumptions from user research as software evolves. Designers rarely know everything about user needs before a product ships. Stakeholders are overlooked [16] , use cases are missed [20] and above all else, the world changes, requiring software teams to evolve applications to suit new needs. It is therefore inevitable that much of the work to serve user needs through design happens after software is deployed, in continuously changing contexts of use [24] .. But as most practitioners in the software industry know, changing software is not so simple. For example, software engineering researchers have long studied notions of coupling and cohesion [25] , modularity, and cross-cutting concerns [9] , analyzing the role of technical dependencies in both constraining and facilitating change. Moreover, there are several economic [2] and lifecycle [19] factors that can limit software change, not to mention a variety of cognitive [8] and social [18] challenges in simply understanding complex software systems in order to change them.. One aspect of software evolution that has received little attention, however, is the role of post-deployment user feedback such as support requests and bug reports. With the rise of web-based technical support and the ease with which users can contact small software teams via e-mail and the web, what constrains a software team's ability to address user feedback with software changes, even when a team is committed to user-centered, iterative design?. To investigate this question, we performed a 6-month field study of a software team employing Agile methods and staffing several user researchers and designers working directly with developers, testers, and managers. We report on the history of one of the team's products, a grade book application for a university community. We discuss the team's user research, prototyping and post-deployment iteration, analyzing the constraints they faced in addressing postdeployment user feedback. We also analyzed over 1,200 bug reports the team did and did not address and the reasons why; we also interviewed a sample of both users and non-adopters of the team's application, revealing needs the system did not serve and what constraints prevented the team from serving them.. Our findings make several contributions to knowledge about usercentered design and software evolution. In particular, we found that most of the constraints in addressing user feedback emerged from conflicts between (1) heterogeneous perspectives on how grades should be represented and (2) global assumptions in the team's software architecture and user interface design. When the team attempted to address these conflicting user needs, the resulting solutions were considered inadequate by both the team and the user community, limiting changes to incremental modifications that supported existing users. These findings highlight the need for new approaches to expressing and validating assumptions from user research as a team receives and triages user feedback.. In the rest of this paper, we discuss prior work on software evolution and then detail the methods used to study the team. We then discuss our observations and their implications on user research, user-centered design and software evolution. The goal our case study was understand what constrains a software team's ability to address post-deployment user feedback in the form of the help requests and bug reports. We found that while feedback was a significant source of knowledge about user practices, translating this knowledge into changes to GradeBook's implementation was constrained by conflicts between heterogeneous uses of grade information in the user community and global assumptions made in the team's initial implementation. Ultimately, the information architecture inherent in the team's data schema was simply not expressive enough to support the diversity of information uses. Therefore, while GradeBook was adopted by many instructional staff, the team's interests in evolving the application to serve new adopters' new needs was hampered by the risk of breaking existing use cases, the costs of migrating existing data, and the unlikelihood of changing other infrastructure and processes over which the team had little control.. These results raise several questions about the role of user feedback in the post-deployment life of software applications. For example, would it have been possible for the team to somehow design the application in a more flexible way to serve a larger subset of the user community, without simply rewriting Excel? Is it possible, for example, that there was a degree of flexibility somewhere between Excel and the data schema the team designed initially that would have been expressive enough? If so, the question then becomes whether the team's oversight of this design possibility was a failure of the user research and requirements gathering. And yet, the team had already invested six months in its user research, far more than many commercial software projects; how much prototyping and iterative evaluation would have been enough?. It is also possible that the team could have done a better of identifying the assumptions they made in their initial user research and using the stream of post-deployment user feedback to test and validate these assumptions. Earlier detection of problems with these assumptions may have made it easier for the team to have addressed them, before the user community grew too large or the code grew too complex. For example, perhaps if LST had been more explicit about the limitations of their assumptions about the number of assignments and students faculty would add to a GradeBook, they could have designed testing procedures that may have revealed the performance problems earlier, before the performance limitations reached throughout the system's implementation.. Existing research on software design suggests several theoretical framings through which software processes might be devised to account for assumptions. For example, Naur described programming as building a theory of how a solution relates to the world [22] ; design theory perspectives view software designs as value judgements [12] , projecting "ideal" users [3] and expecting users to conform to them. For example, Friedman et al. suggest that systems ought to be free of bias by identifying it [12] . Similarly, Fischer et al. argue for escaping the user/developer dichotomy and empowering users to be their own designers [11] ; but in doing so, teams may prioritize users who want to be empowered, but not those who want curated, pre-existing solutions. These perspectives may be helpful in designing new software processes that formalize and operationalize the identification of assumptions, helping software teams to think more carefully not only about the application's design, but also how assumptions are manifested in software architectures, testing plans, and triage processes.. While our case study primarily revealed evolution constraints related to modularity and heterogeneity, our results also suggest that the gathering of user feedback may itself constrain software evolution. Our findings show that by letting user feedback drive change, the GradeBook team mostly heard from existing users of the application, and even then, they mostly heard from a vocal minority which may not have been representative of the user community. Moreover, when these vocal minorities did provide feedback, change was usually denied, disincentivizing further feedback. This had the effect of hardening the original design, crystalizing it around existing uses, rather than future ones (in the same way users' workarounds can prevent software change [23] ). Our study therefore highlights the importance of treating user feedback as less of a guide for what to change and more of a signal for the need for further research. In particular, user feedback should be a sign that users at or beyond the boundary of an application's idealized user [3] are struggling to adapt the software their needs.. Such signals should drive explicit studies of non-adopters of the system. These recommendations reinforce arguments that the point of data gathering is not to drive design, but inspire it [13] . Moreover, it also reinforces arguments that in some cases, the only way to better serve user needs is to abandon software [6] , as we do with deteriorating physical systems.. One can also take a more positive view of the team's responses to user feedback: the team succeeded in anticipating many aspects of their user communities' homogeneous needs, implementing the application in a way that ensured additional grading scales and alternative workflows would either be easily added or supported by the Excel import. While the team faced tradeoffs between designing for flexibility and preserving simplicity, it may not have been possible to design an application that served everyone in their community; only serving some well, even if it means not serving others, may be an inevitable part of software design.. The implications of these observations in our case study on the larger concern of software evolution are many. For one, having a clear notion of who software is intended for is not only important in the design of software, but also in the architecting, testing, and evolution of software. Software processes should focus on ways of making the audience more explicit and finding ways of weaving the assumptions inherent in a design throughout an application's implementation and throughout a team's processes. Our study also suggests that an inherent part of triaging post-deployment feedback involves clarifying the values a team wants to uphold; without clarity, there is little to decide whether a potential change is important enough to risk the harm that changes might do through new defects and broken uses cases to the existing user community. We know of know prior work that has explicitly investigated the constraints that software teams face in addressing software change requests. There is, however, considerable prior work on the factors that can constrain software evolution in general, ranging from the inflexibility of computer code, the time required to invest in change, and the skills available to implement change, to more systemic factors such as policy, market forces, and politics. In this section, we discuss prior work on these various factors.. One major constraint on software change is complexity. For example, Buxton argues that as systems grow in complexity, the architecture, technologies and paradigms "create a straightjacket that severely affects the cost of change." [6] . Lehman provided one of the first reports on this phenomenon [19] , deriving several laws of software evolution from a study of several long-lived applications. Lehman argued that because of the ease with which code can be reused, there is an incentive to implement changes with existing code, rather than aggregate changes into new code.. These forms of reuse are captured in several concepts of code complexity, such as coupling (the degree to which program modules are mutually interdependent) [25] and cross-cutting Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ICSE '11, May 21-28, 2011, Waikiki, Honolulu, HI, USA Copyright 2011 ACM 978-1-4503-0576-1/11/05... $10.00.. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. concerns [9] (the degree to which a software feature spans modules). Measures of these concepts across successive versions of software show that all tend to increase, causing each change to span a larger subset of a program's modules [21] [7] . One way that teams mitigate increases in complexity is through change impact analysis [1] , determining which parts of a program will be affected if a proposed change is made. Recent studies have shown that when developers cannot find enough information to assess the impact of a change, the risk of the change introducing new defects, breaking an existing use, or otherwise changing user experience, is assumed to be prohibitively high [18] .. Another constraint on software change can be the user community itself. For example, Buxton argues that because users have made an investment in learning the product; any significant changes to the UI or workflow may threaten the loss of existing users and may not lead to new adopters. After all, learning is a significant investment [14] and some users may see no value in the new benefits offered by a system relative to the new cost of learning the system [2] . Moreover, people often adopt new technologies not on the actual cost, risks, and rewards, but perceived ones [5] . People are also adept at appropriating software in unexpected and idiosyncratic ways [15] , leading them to depend on code in ways a team may not have intended. Once these use dependencies are established, modifying such code may mean breaking unplanned but widespread uses, even if the code was viewed as provisional.. Teams also face infrastructural constraints. For example, Edwards et al. [10] explain how infrastructure can preclude certain user experiences, expose technical abstractions to users in undesirable ways, and force users to interact directly with infrastructure to accomplish their goals. Such infrastructural constraints can also be a significant constraint for software teams' ability to change software, forcing them to select undesirable designs because they are not free to change the infrastructure.. There may also be social and cognitive factors within a team that constrain change. For example, teams may experience loss aversion, strongly preferring avoiding losses to acquiring gains [17] ; with respect to software evolution, this may mean avoiding losing a small number of existing users over gaining a large number of new users, or avoiding an architectural change even though it may enable significant improvement in user experience. Similarly, teams may engage in irrational escalation [4] , justifying increased investment in a decision because of cumulative prior investment, despite new evidence that the decision may be ineffective. Teams may also experience confirmation bias [4] , seeking or interpreting information in a way that confirms preconceptions about how software is used or what value users derive from it. The focus of our study was on understanding the role of user feedback in addressing software change requests. In this section, we describe the team we observed and how we analyzed their efforts.. In selecting a software team for study, we sought one that had an explicit focus on user-centered design. We chose to study an inhouse software team at a university known as LST, consisting of 20 full time and 40 part time staff. While the team was local, making it easy for us to observe the team, the primarily reason we selected the team was their mission statement:. "We follow an itera.ve, user--centered design and development process that focuses on understanding the needs and experiences of our users. Whether we are crea.ng a new tool or upda.ng an older one, our design decisions are based on direct feedback, user research, and findings from usability studies.". This dedication was reflected in their many awards, with the most recent presented by the Center for Digital Government and Education, and the ACM Special Interest Group on University and College Computing Services. This was also reflected in their actual work throughout our observations. The focus of our study was on LST's most recent tool, a cloudbased web application called GradeBook, used by university instructional staff to store, organize, and publish student grades. The main screen of this application appears in Figure 1 . The major features of the application include a spreadsheet-like interface for storing scores on assignments, categories for representing groups of assignments, automatic final grade calculation, and online grade submission. The application also imports and exports Excel files. We discuss the rationale behind several of GradeBook's features later in our discussion of the team's initial user research.. The GradeBook design team included six individuals across two teams: one focused on the grade book application itself and another focused on online grade submission. Of these 6 individuals, 2 were developers (and participated on both teams), 3 were designers (one of which participated on both teams), and 1 was the program manager for both teams. One of the designers focused on client-side user interface design, writing HTML, CSS, and JavaScript for the front end. The two developers were responsible for the majority of the engineering work behind all versions of the application.. To learn about the project history, we performed two semistructured interviews with the 4 of the 6 team members. We interviewed them in pairs to help reveal conflicting and confirming memories about the project history, also asking the same questions in different ways to cross-validate responses. Our questions focused on several aspects of GradeBook's history: we asked about the rationale for the project's inception, what user research was performed to inform the design, and about the results of the user research. We asked about the rationale for the major features of the GradeBook application and their relation to the user research. We also asked what aspects of GradeBook had evolved in response to user feedback, and which aspects the team wanted to evolve, but could not and why. Interviews were recorded and transcribed.. In addition to interviewing the team, we also analyzed the team's technical support and bug report repositories. The team used Bugzilla to track issues and classified resolved bugs into FIXED, WONTFIX, LATER, DUPLICATE, NOTREPRODUCIBLE, MOVED, or REMIND. Our analyses focused on the 1,046 FIXED and 144 WONTFIX closed reports. In reading them, we focused on understanding what aspect of GradeBook was identified and why the team decided to fix or not fix the issue. It was common for reports to both indicate the rationale for closing a report, a link to the code change in the version repository (if there was one), and a link to support tickets that prompted the project, if any.. To understand the user community's use (and non-adoption) of GradeBook, we also interviewed several instructional staff in charge of teaching the large undergraduate population, particularly those teaching introductory lower-division courses. We focused on departments with more than 100 students and on courses being taught during the quarters of our observations. We contacted each of the instructors and teaching assistants of these classes through email, explaining our study and asking for participation. Of the 82 instructors and teaching assistants we contacted, 22 replied. Of these replies, we successfully arranged interviews with staff of the 12 courses in Table 1 . Of the 12 staff interviewed, 5 were the official instructors of record, 6 were teaching assistants, and 1 was a course coordinator, responsible for managing teaching assistants in collaboration with the instructor. Of the 12, all used Excel to track some form of student grades, 6 used GradeBook to store grades, and 2 used other grade management software mandated by their departments. All used GradeBook to submit grades online.. Our semi-structured interviews with these 12 instructional staff involved a walkthrough of the syllabus and rationale, the kinds of deliverables students submitted, how deliverables were submitted, how they were graded, where grades were stored, how feedback and scores were provided to students, the tools used for all of these processes and the staffs' views on these tools' inadequacies for grading. Each interview was audio-recorded and transcribed.

O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O B I O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O B I O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O B I O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Transforming web pages to become standard-compliant through reverse engineering Developing Web pages following established standards can make the information more accessible, their rendering more efficient, and their processing by computer applications easier. The World Wide Web Consortium (W3C) is an organization that develops and promotes the use of standards on the Web. However, as much as 95% of existing Web pages today are "invalid" [9] in that they fail to conform to the W3C "recommendations" (commonly considered "Web standards" by the community) published since 1995 [16] . These invalid Web pages may not be rendered consistently across platforms or by different browsers, may not be accessible to some users, and may cause problems for Web-based applications. The seriousness of the problem spawned the Web Standards Project (WaSP) [10] , which was established to encourage people to design Web pages which conform to standards in order to reduce the cost and complexity of development, while increasing the accessibility and long-term viability of any site published on the Web [21] .. The basic idea of Web standards is to develop Web pages with valid HTML or XHTML code and to separate content from presentation. A Web page is composed of three parts: content, presentation and behavior. According to Web standards, the content should be written in valid HTML or XHTML code; the presentation (e.g., layout, font, color, etc.) should be specified by valid CSS code; and the behavior should be controlled by valid JavaScript (officially, the ECMAScript [2] ) through the DOM interface [17] . Figure 1 shows the "trinity" of Web standards [21] . It is necessary for a Web page to be compliant with Web standards because of the following reasons [5] [11]:. • Its accessibility is wider because the CSS-based presentation is more flexible for different devices, browsers or handicapped people.. • Its size is smaller and bandwidth for access is reduced. For example, ESPN.com is saving 2TB of traffic per day by redesigning Web pages according to Web standards [7] .. • It is friendly for machine processing. Without the misused table and font tags for layout and appearance in the code, other computers can "understand" the Web page's content better. Today, people have realized that most of existing Web pages are not compliant with Web standards, which hinders the accessibility and viability of the Web. Transforming those legacy Web pages to be standard-compliant is necessary but will require a lot of effort. Our PURE tool is developed to help Web developers to do the transformation automatically. Because some legacy Web pages are very complicated and the browser may not generate the page structures according to W3C's definition of the DOM tree, PURE may not work well automatically in some cases. But with some human interaction, PURE can be effective for most cases. Furthermore, the PURE tool will be released as an open source and free software so that the community can help improve it. We believe that PURE will evolve into a useful tool for Web developers to transform legacy Web pages. With additional work PURE may be made an option for Web page authors to pass the code through before leaving the authoring tool used for the page's creation.. Web page reverse engineering can be applied to many other applications. One possible application is to transform existing Web pages to make them compatible with mobile devices. Today, mobile Web access suffers from interoperability and usability problems that make the Web difficult to use for most mobile phone subscribers [19] . One well-known problem is that traditional Web pages do not provide a good browsing experience on mobile devices due to their small screen size. This problem may be solved by using a new presentation scheme (style sheet) with which the browsers on mobile devices will use to display the Web page nicely. Some popular websites now provide a version designed specially for mobile devices such as http://www.google.com/pda and http://wap.oa.yahoo.com/ . But it would be difficult to keep the content consistent with the original Web page unless there is a tool to generate a mobile version automatically from the traditional website.. The reverse engineering approach introduced in PURE can be adopted to help Web developers build Web pages that are compatible with mobile devices based on existing ones. That is: (1) segment the original Web page into primary boxes; (2) remove some primary boxes if necessary (e.g., large images or navigation links on the top of the page [20] ); (3) rearrange the placement of primary boxes to fit the mobile device's screen. Therefore our reverse engineering approach will become a valuable foundation for research work on Web standards and Mobile Web. The content of an HTML document is contained in the BODY element. All elements which may appear in BODY can be classified into 2 kinds: the "block-level" elements and the "inlinelevel" elements. Generally, block-level elements may contain inline-level elements and other block-level elements. Inline-level elements may contain only data and other inline-level elements. For example, the elements P, DIV, TABLE, UL and H1 are blocklevel elements and B, SPAN, FONT, A and IMG are inline-level elements. During rendering, block-level elements always begin on new lines, but inline-level elements do not [13] .. Generally, a Web browser parses the HTML document into a tree structure and then begins rendering based on the tree. The tree structure is often called the HTML DOM (Document Object Model) tree. The W3C's visual formatting model gives the idea on how a browser renders an HTML document based on its DOM tree [14] . Each node in the DOM tree generates one or more boxes on the screen if it is visible. A visible inline-level element may generate more than one box when the text within it spans several lines. A visible block-level element always generates one box because it will begin with a new line. We can see an element's box boundaries by adding the STYLE attribute of CSS to specify the border of the box. For example:.
 some text
 If we specify the border of each element in the document body, we can see that a Web page's appearance is composed of many nested boxes. Modern browsers provide a friendly programming interface for developers to access a page's DOM tree structure and each element's box information (e.g., position, size, source code, etc.). Therefore, it is possible for us to reverse engineer a Web page box by box through the browser's rendering result.

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O


CROS: A Contingency Response multi-agent system for Oil Spills situations This paper presents CROS, a Contingency Response multi-agent system for Oil Spill situations. The system uses the Case-Based Reasoning methodology to generate predictions to determine the probability of finding oil slicks in certain areas of the ocean. CBR uses past information to generate new solutions to the current problem. The system employs a SOA-based multi-agent architecture so that the main components of the system can be remotely accessed. Therefore, all functionalities (applications and services) can communicate in a distributed way, even from mobile devices. The core of the system is a group of deliberative agents acting as controllers and administrators for all applications and services. CROS manages information such as sea salinity, sea temperature, wind speed, ocean currents and atmosphere pressure, obtained from several sources, including satellite images. The system has been trained using historical data obtained after the Prestige accident on the Galician west coast of Spain. Results have demonstrated that the system can accurately predict the presence of oil slicks in determined zones after an oil spill. The use of a distributed multi-agent architecture has been shown to enhance the overall performance of the system. The response to minimize the environmental impact when an oil spill is produced must be precise, fast and coordinated. The use of contingency response systems can facilitate the planning and task assignation when organizing resources, especially when multiple people and systems are involved. This paper presents CROS (Contingency Response multi-agent system for Oil Spill situations), a system for helping to manage these situations. This system deploys a prediction model which uses intelligent agents and Case-Based Reasoning systems to determine the possibility of finding oil slicks in a certain area of the ocean. It also applies a distributed multi-agent architecture based on Service Oriented Architectures (SOA), modeling most of the system's functionalities as independent applications and services. These functionalities are invoked by deliberative agents acting as coordinators.. Agents and multi-agent systems have been successfully applied to several scenarios, such as education, culture, entertainment, medicine and robotics [1] [2] [3] [4] [5] [6] . Agents have a set of characteristics, such as autonomy, reasoning, reactivity, social abilities, pro-activity, mobility and organization which allow them to cover several needs for developing contingency response systems [7] .. The agents' characteristics make them appropriate for developing dynamic and distributed systems, as they possess the capability of adapting themselves to the users and environmental characteristics [8] . In addition, the continuous advances in mobile computing make it possible to obtain information about the environment and also to react physically over it in more innovative ways. The agents in CROS multi-agent system are based on the deliberative (Belief, Desire, Intention -BDI) model [9] , where the agents' internal structure and capabilities are based on mental aptitudes, using beliefs, desires and intentions for solving problems. However, modern developments need higher adaptation, learning and autonomy levels than pure BDI models [9] . This can be achieved by modeling the agents' characteristics in order to provide them with mechanisms that allow them to solve complex problems and achieve autonomous learning. Some of these mechanisms are Case-Based Reasoning (CBR) systems [10] , where problems are solved using solutions applied to solve similar past problems [1] . Solutions are stored in a case memory which the system can consult in order to find better solutions for new problems. Deliberative agents can use these systems to learn from past experiences and to adapt their behavior according to each situation.. The system presented in this paper generates the probability of finding oil slicks for different geographical areas after an oil spill. Predictions are created using a Case-Based Reasoning system. The cases used by the CBR system contain information about the oil slicks (size and number) and atmospheric data (wind, ocean currents, salinity, temperature, height and pressure). CROS combines artificial intelligence techniques in order to improve the efficiency of the CBR system, thus generating better results. CROS was trained using historical data acquired during the Prestige oil spill on the Galician west coast of Spain, from November 2002 to April 2003.. Most of the data used by CROS was acquired from the ECCO (Estimating the Circulation and Climate of the Ocean) consortium [11] . The position and size of the slicks was obtained by treating SAR (Synthetic Aperture Radar) satellite images [12] . The development of agents is an essential component in the analysis of data from distributed sensors and provides those sensors with the ability to work together and analyze complex situations [13] .. The excessive centralization of services negatively affects the systems' functionalities, overcharging or limiting their capabilities. Classical functional architectures are characterized by trying to find modularity and a structure oriented to the system itself. Modern functional architectures like Service-Oriented Architecture (SOA) consider integration and performance aspects that must be taken into account when functionalities are created outside the system.. As described by [14] , "A SOA-based system is a network of independent services, machines, the people who operate, affect, use, and govern those services as well as the suppliers of equipment and personnel to these people and services". The term service can be defined as a mechanism that facilitates the access to one or more functionalities (e.g. functions and network capabilities). Services are linked by means of standard communication protocols that must be used by applications in order to share resources in the services network. A SOA approach has been chosen in CROS because such architectures are asynchronous and non-dependent on context (i.e. previous states of the system) [15] .. Agents and multi-agent systems combine classical and modern functional architectural aspects. Multi-agent systems are structured by taking into account the modularity in the system, and by reuse, integration and performance of the data and results obtained. CROS employs a SOA-based multi-agent architecture which allows different users to work together without sharing the same space. The architecture divides the main components of the system into small pieces of software which work separately but are coordinated. These components are managed through a set of deliberative BDI agents. The use of a distributed architecture can help to distribute resources and reduce the central unit tasks [16, 17] . It also provides more flexible ways of moving functions to where actions are needed, thus obtaining better responses at execution time, autonomy, services continuity, and superior levels of flexibility and scalability than centralized architectures [18] .. The following section presents the oil spill problem while highlighting the difficulties and the possibilities of finding solutions to this problem. This is followed by a brief description of the CBR methodology and the systems created from it. Afterwards, the main components of the system presented in this study, including its architecture, are described. Finally, the results obtained by applying CROS to a real oil spill situation, the final conclusions and future work are presented. CROS is a new solution for predicting the presence of oil slicks in oceanic areas after an oil spill. This system has a SOA-based distributed multi-agent architecture which allows the simultaneous interaction of multiple users. Distributing resources also allows users to interact with the system in different ways depending on their specific needs for each situation (e.g. introducing data or requesting a prediction). This distributed and multi-agent architecture is an improvement over previous tools where the information must be centralized and where local interfaces were used. With the vision introduced by CROS, all the different people that may interact with a contingency response system can collaborate in a distributed way, being physically located in different places but exchanging information in a collaborative mode.. CROS uses a Case-Based Reasoning system to create new solutions and predictions using past solutions given to past problems. It has been demonstrated that the CBR system generates consistent results. The structure of the CBR system was divided into services in order to optimize the overall performance of CROS.. In order to improve the system, it will be necessary to incorporate some generalizations. Applying the methodology explained before to diverse geographical areas will improve the results even more, being able to generate good solutions in a larger variety of situations. The current system was mainly developed using data from the accident of the Prestige off the north-west coast of Spain. With that information, CROS was able to generate solutions to new situations, based on the available cases. If the amount and variety of cases stored in the case base increases, the quality of the results will also improve.. Although the performed tests have provided us very useful data, it is necessary to continue developing and enhancing CROS. The number of possible interfaces can be augmented, including independent sensors that may send information to the system in real-time. The data received by the system must be analyzed in order to detect new spills and to generate fast and accurate solutions to existing problems without the direct intervention of the users. Then, the system will be not only a contingency response but also a kind of supervising system that can be specifically used in dangerous geographical areas. CROS uses different artificial intelligence techniques to cover and solve all the phases of the CBR cycle. Fast Iterative Kernel Principal Component Analysis is used to reduce the number of variables stored in the system, achieving about a 60% reduction in the size of the case base. This adaptation of the PCA also implies a faster recovery of cases from the case base (more than 7% faster than storing the original variables).. To obtain a prediction using the cases recovered from the case base, the Growing Radial Basis Function Networks was used. This evolution of the RBF networks implies a better adaptation to the structure of the case base, which is organized using Growing Cell Structures. The results from using Growing RBF networks instead of simple RBF networks are about 4% more accurate, which is a good improvement. Using GRBF also implies a better adaptation to the retrieved data which implies a more coherent solution generation.. Evaluations show that the system can make predictions in known conditions, showing better results than previously used techniques. The use of a combination of techniques integrated in the CBR structure makes it possible to obtain better results than using the CBR alone (17% better), and also better than using the isolated techniques (neural networks), without the integration feature produced by the CBR (11% better). A summary of all these improvements can be seen in Fig. 10 . The predicted situation was compared to the actual future situation. The future situation was known because historical data was used to develop the system and to test its correction. The proposed solution was, for the majority of the variables, close to 90% accurate. For every problem defined by an area and its variables, the system offers 9 solutions (i.e. the same area with its proposed variables and the eight closest neighbours). This type of prediction is used in order to clearly observe the direction of the slicks, which can be useful in determining the coastal areas that will be affected by the slicks generated after an oil spill. Table 2 shows a summary of the results obtained after comparing different techniques with the results obtained using CROS. The table shows the evolution of the results along with the increase in the number of cases stored in the case base. The results for all of the techniques analyzed improved while increasing the number of cases stored. Having more cases in the case base makes it easier to find cases similar to the proposed problem, which in turn enables the solution to be more accurate. The "RBF" column represents a simple Radial Basis Function Network that is trained with all the available data. The network produces an output that is considered a solution to the problem. The network is trained with the majority of the information available and, the rest of the data, which has not been previously used for training purposes, is used to check it. There is no filtering or selection of optimal data. The "CBR" column represents a pure CBR system, with no other techniques included; the cases are stored in the case base and recovered considering the Euclidean distance (according to the internal representation of the cases). The most similar cases are selected and, after applying a weighted mean according to the similarity of the selected cases with the inserted problem, a solution s proposed. The values are calculated transforming the information stored into a vector of values, which allows the system to measure the distance between two different elements. The "RBF + CBR" column corresponds to the possibility of using a RBF system combined with CBR. The recovery from the CBR is done by the Manhattan distance and the RBF network works in the reuse phase, adapting the selected cases to obtain the new solution. The RBF network is now trained with all the information used for training, but when generating solutions, a subset of the data available is introduced in the network to generate the results. The results of the "RBF + CBR" column are generally better than those from the "CBR", mainly because of the elimination of useless data to generate the solution. Finally, the "CROS" column shows the results obtained by the proposed system, obtaining better results than the three previously analyzed solutions. The laboratory environment where the different techniques were applied was the same for all of them. Three Pentium IV computers were used in the tests (3.00 GHz, 2 Gb RAM, Windows). One of them was used as a server, and the other two were used to send requests and receive the solutions. The same historical data was also used to generate all the results used for comparison. Table 3 shows a multiple comparison procedure (Mann-Whitney's test) [48] used to determine which models are significantly different from the others. This test helps to determine H 0 . That is, whether the variables are identically distributed for two analyzed techniques. In our case, the variables represent the percentage of errors for the numbers of cases shown in Table 2 . Therefore, the variables x and y represent the different pairs of techniques (i.e. RBF, CBR, RBF + CBR and CROS) selected. The values for the variables x and y are the successive rows of each column. The asterisk indicates that these pairs show statistically significant differences. We have taken the lowest significance level for H 0 (i.e. = 0.13) where CROS presents statistically significant differences with the rest of the models, while the rest are considered equal. The proposed solution does not generate a trajectory, but a series of probabilities in different areas, which is far more similar to the real behavior of the oil slicks.. Several tests have been done to compare the overall performance of CROS. The tests consisted of a set of requests delivered to the Prediction Generation Service (PGS) which in turn had to generate solutions for each problem. There were 50 different data sets, each one with 10 different parameters. The data sets were introduced into the PGS through a remote PC running multiple instances of the Prediction Agent. The data sets were divided in five test groups with 1, 5, 10, 20 and 50 data sets respectively. There was one Prediction Agent for each test group. 30 runs for each test group were performed. Several data have been obtained from these tests, notably the average time to accomplish the solutions, the number of crashed agents, and the number of crashed services. First, all tests were performed with only one Prediction Service running in the same workstation on which the system was running. Then, five Prediction Services were replicated also in the same workstation. For every new test, the case base of the PGS was deleted in order to avoid a learning capability, thus requiring the service to accomplish the entire prediction process. Fig. 11 shows the average time needed by CROS for generating all solutions (predictions) for each test group. As can be seen, the time exponentially increases when there is only one PGS running. This is because the service must finish a request to start the next one. So, for the last test group (50 data sets) the service was overcharged. On the other hand, with five replicated services, the system can distribute the requests among these services and optimize the overall performance. The system performed slightly faster when processing a single request, but the performance was constantly reduced when more requests were sent to the service. Fig. 12 shows the average number of crashed agents and services during all tests. As can be seen, with only one PGS available CROS is far more unstable. This is because the PGS had to perform all requests by itself. It is important to notice that when the PGS crashed, more agents crashed because they were always waiting for the service response. For example, when processing 50 data sets, the last agent had to wait almost 200 s to receive the response. These data demonstrate that a distributed approach provides a higher ability to recover from errors.

O O O O O O O O O O O O O O O O O O O O B I O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O