Fashion waves in information systems research and practice AbstractBuilding on neo-institutional theory and theories of innovation and diffusion Research in the field of management has suggested that management research and practice is characterized by fashions (Abrahamson 1991; Abrahamson and Fairchild 1999; Clark 2004) . A management fashion is a relatively transitory belief that a certain management technique leads rational management progress. At first sight, management fashions appear to be new and innovative, but some have suggested that they are in fact just old wine in new bottles and a repackaging of old concepts (Miller and Hartwick 2002) . These fashions have a relatively short shelf life and disappear almost as quickly as they arrived. Management fashions have been criticized for tending to offer glib and unworkable "solutions" to a complex international business environment (Currie 1999 ).. Similar comments have been made about research and practice in the field of information systems. Banville and Landry suggested that IS researchers were overly driven by new technological opportunities and research fads (Banville and Landry 1989; Landry and Banville 1992) . Larsen and Levine (2005) say that research and practice in information systems has sometimes been characterized as lacking coherence and durability with respect to core topics in the field. Gregor and Jones (2007) note that waves of "fads and fancies" tend to characterize IS/IT. Various topics in IS research and practice have been described as fashions, such as business process reengineering (Jones 1994) , enterprise resource planning (ERP) systems (Westrup 2003) , and group decision support systems (Ramiller et al. 2008) . A prevalent theme in these comments is the idea that many topics in the IS field have little, if any, enduring value.. Given the apparent similarity between the two fields of management and information systems (at least with respect to the fashionable nature of research and practice in both disciplines), we decided to apply Abrahamson's management fashion theory to information systems research and practice. Like Abrahamson, we used bibliographic research to model the relative strength and duration of selected fashion waves in IS research and practice. Hence, the purpose of the paper is to describe some of the more important fashion waves in recent years and to suggest how IS scholars might better engage with IS practitioners in the IS fashion setting process.. Research on management fashion fundamentally builds on Rogers' (1995) adoption and diffusion theory. Management fashions are not simply spontaneous diffusion of guru-driven techniques, but are shaped by culture, society, and economics (Abrahamson 1991) .. Far from being cosmetic or transient in nature (and popular because of this), management fashions will only diffuse if they claim to be fundamental in their application and timeless in their scope-if they claim to offer solutions to real or perceived efficiency gaps (Scarbrough and Swan 2001, p. 9 ).. We suggest that many IS fashions can be described in a similar way. The proponents of IS fashions claim that the particular IS technique is a fundamental improvement that offers solutions to real or perceived problems with information systems in organizations.. In the management literature, some authors regard management fashions with disdain, casting them "as something from which management scholars should remain disengaged, lest they join the ranks of 'snake oil salesman'" (Abrahamson 1991, p. 255) . In contrast, much like Abrahamson, we take a neutral position. Our purpose in conducting this research project is not to evaluate the wisdom, impact, or merit of the various fashions in information systems research and practice. Rather, our purpose is to describe some of the important fashion waves in recent years and to illuminate the degree to which the research literature reflects the practitioner literature, or vice versa (as far as IS fashion is concerned). Further, we offer an analysis of the negative impacts arising from the absence of IS scholarship from the IS fashion setting process.. The contribution of this paper is, therefore, as follows. First, it helps to open a new reflexive discourse on how we, as academic scholars in the information systems field, set and pursue our research agendas (see also Ramiller et al. 2008 ). This discourse is distinct from the more well-established discourses on relevance (or irrelevance) and subject-matter coherence (e.g., concerning the "IT artifact"). Second, it suggests new ways in which management fashion theory can be advanced in IS. As examples, we apply management fashion theory to four information systems research and practitioner discourses: office automation, computer-aided software engineering, business process reengineering, and e-commerce. Third, it contributes to the discourse on the relationship between IS research and practice by assessing the extent to which academics and practitioners have influenced each other in the fashion setting process (see Barley et al. 1988) .. With respect to this last contribution, IS researchers have lamented the supposed poor state of the relationship between IS research and practice for many years. For example, Benbasat and Zmud (1999) say that the lack of IS research relevance can be traced to the "ivory tower" nature of business research in general, which is popularly regarded as fuzzy, irrelevant, and pretentious. Lyytinen (1999) says that underlying institutional structures create pressures for IS researchers to pursue research directions that respond to academic careers rather that practical usefulness. Pearson et al. (2005) say that IS practitioners have problems finding academic research literature, and when they do, they find it dated, difficult to read, and of little value.. Our findings cast a more positive light on this long-standing debate concerning the relationship between IS research and practice. Contrary to the usual stance lamenting the poor state of the relationship between IS research and practice, our findings show that IS research closely parallels practice. In terms of topic, our research suggests that academic work is usually synchronous with practitioner interests, and indeed, in some cases, leads. By following the latest IS fashions, IS researchers show that they are not simply ivory tower researchers who ignore everything that goes on around them. On the contrary, they show that they are sensitive to trends in industry and are willing to study them. However, we believe there is room for improvement. We suggest that IS academics should be more proactively engaged in the fashion setting process and in the evaluation of IS fashions. In this paper, we have suggested that management fashion theory provides insights into the nature of IS research and practice. Both IS research and IS practice are characterized by fashion waves in certain topics. Although IS research might be seen as faddish or outdated, depending upon which perspective it taken toward IS fashions, our data also shows that IS research closely parallels practice. The more-or-less synchronous rise and fall of fashion waves in the IS research and practitioner literature shows that IS researchers are engaging with practice and with the latest developments in the field. However, much improvement is needed.. The Milan theory we have proposed suggests that IS academics should actively engage with leading IS practitioners in the IS fashion setting process. This engagement could involve advancing IS fashions or it might involve critically dampening them, depending upon the arguments and evidence provided.. In summary, this paper helps to open a new reflexive discourse on how we, as academic scholars in the information systems field, set and pursue our research agendas (see also Ramiller et al. 2008) . The concept of IS fashion waves provides a way of conceptualizing the codevelopment of IS research and practice. The bibliographic method we have used provides an empirical approach of assessing the extent to which academics and practitioners have influenced each other (Barley et al. 1988) . Our findings reveal that academic participation in IS fashion waves is not the central problem. The central problem is the absence of active academic engagement with the IS fashion setting process. We propose that IS researchers should be among the leaders, and not just the followers, of fashion. We have suggested that Abrahamson's theory of management fashion (Abrahamson 1991 (Abrahamson , 1996 Abrahamson and Fairchild 1999) can be applied to information systems research and practice. The argument of this paper is that, just as the literature on management is characterized by waves of interest in certain fashionable topics, so the IS research and practitioner literature is characterized by similar fashion waves. These waves represent a burst of interest in particular topics by IS researchers and practitioners.. One of the most notable findings of our analysis is how quickly topics in both the IS researcher and practitioner literature rise to prominence. As a general rule, the upswings of the IS fashion waves are rapid, and occur within the space of between three to five years. Of the four topics we studied, three of them peaked within five years. The only exception was the research literature on e-commerce, which peaked after eight years.. Another interesting finding is that the peak of the wave tends to be followed quickly by a noticeable downswing, although there is some variability in the speed with which the wave dissipates. Some waves decline sharply whereas others linger on for quite some time. For example, it took only eight years for the wave of scholarly interest in office automation to peter out almost entirely: scholarly articles on office automation had almost disappeared by 1992. With the case of business process reengineering, however, scholarly interest is still bubbling along, some 13 years after peaking in 1994.. As we mentioned earlier, there is a longstanding debate in the general management literature about whether academics influence practitioners or vice versa (Barley et al. 1988) . Some suggest that fashions emerge first in the practical press and later in the scholarly press (Spell 2001) , whereas others suggest that the upswing is more-or-less simultaneous. The latter group argues that any apparent delay can be explained by the longer review and publication cycle in scholarly journals (Rüling 2005 ). This debate is important because an answer one way or the other gives some indication of the potential value of academic research for practice.. Our evidence helps explain why the information systems academic literature may appear more old-fashioned than the practical literature. There is a distinct difference between the IS research and practitioner literature with regard to the speed with which the waves dissipate. As a general rule, the IS practitioner waves tend to decline much more rapidly that the IS research waves. Topics survive in the IS research literature for some time, long after IS practitioners have lost interest. For example, the scholarly literature on CASE tools continued to flourish until around 2004, whereas the practitioner literature on CASE tools virtually disappeared after 1996. The IS research literature on business process reengineering continues to flourish at a steady (albeit lower) level, despite the fact that practitioners appear to have lost interest from 2000 onward. It is perhaps too early to say what the long term trend will be for the scholarly literature on e-commerce, but we speculate that e-commerce will follow the same trajectory as BPR. The IS research literature on e-commerce reached its peak in 2004, and has declined slowly since then. The practitioner literature reached an index level of below 1 in 2005.. Abrahamson and Fairchild note a similar trend within the general management literature. For example, they found that the academic and semi-academic literature kept focusing on quality circles well after most of the popular business press had lost interest. Perhaps this lingering academic interest is a factor of the longer cycle times of academic publication, and longer term academic investments in topical research projects (such as funded research and doctoral thesis topics). These factors lengthen time commitments of scholarly research to selected topics. Unfortunately, one outcome of this long trailoff in the scholarly literature is that a sizeable segment of this literature appears to be outdated and irrelevant to practice.. Despite the unfashionable appearance (to practitioners) of some IS research, our evidence also points to a more positive alternative conclusion: much of the IS research literature closely parallels that of the IS practitioner literature. As a general rule, the peaks of the waves occur within one to five years of each other. For example, both the practical and scholarly literature on CASE tools peaked at the same time (in 1991), as did the literature on reengineering (in 1994). Such evidence indicates that IS research is responsive to IS practice. The rapid, synchronous rise of fashion waves is a positive characteristic of IS research, one that indicates that IS researchers are engaging with the latest practitioner thinking. But paradoxically, such responsiveness also leaves IS researchers open to criticism that they are being too faddish.. Our evidence can thus be interpreted to support two contradictory viewpoints: (1) that the IS research literature parallels the IS practitioner literature and hence is too faddish; (2) that IS research is outdated and irrelevant. The IS research literature may seem faddish because it participates in fashion upswings in concert with the practical literature. It will also seem obsolete because academic interest in the fashion continues long after it dies in practice. What are we to make of this apparent contradiction?. Our view is that the academic discipline of information systems is reasonably effective in tracking IS fashions. Rather than failing to address unfounded fashions for decades, the rise-and-peak timing shows that academia participates in the fashion setting process. The main problem seems to be that much of our research appears very late in the fashionsetting process.. Hence, we recommend that more IS researchers should make a determined effort to participate more directly at the start of the fashion-setting process (either as a positive or negative influence). There are several ways in which this could be done.. Research methods such as action research (Baskerville and Myers 2004) , design science (Hevner et al. 2004) , and practice research (Mathiassen 2002) bring the scholarly research directly into the hands of practitioners. These research methods are now accepted in information systems, but need to be encouraged by Ph.D. programs and editorial boards. Actually, Van de Ven (2007) argues that any research method can be driven by better engagement with the practitioners, clients, and users among other key stakeholders. Such "engaged research" is participative and benefits from differing perspectives. From our perspective, engaged research also provides an avenue for better participation by IS scholars in the fashion-setting process.. While such directly engaged research methods may enable academic researchers to participate actively in setting useful information systems fashions, more reflexive research into the fashion-setting process itself is also important. Ramiller, Swanson, and Wang (2008) have proposed an institutional ecology that better integrates the academic research community with its practical constituency. A key element of this ecology is the presence of a discourse (rather than a chasm) between information systems research and practice. Such a discourse is needed to enlighten the fashion-setting and fashion-following phenomena in both research and practice.. However, we believe their recommendations for more reflexive research into IS fashions do not go far enough. The notion of evidence-based management, together with the Milan theory we have proposed, demands a much more active engagement of IS academics with the fashion-setting process. Such active engagement encourages researchers to drop topics that have long since lost interest for practitioners, and adopt research that is more prescriptive, more normative, or more future-oriented. IS researchers could play an important role within the fashion-setting cycle, either dampening or amplifying the setting and launching processes depending upon the evidence provided by their research. If academic researchers do not participate in the fashion-setting process, then they are relegated to a role of providing reflective, post hoc critiques. Academic participation in IS fashion setting (and fashion dampening) is not just an intellectual advancement; it is an important responsibility academics owe to practitioners.. In order for IS academics to actively participate in fashion setting, greater agility is required in scholarly IS research. This agility requirement suggests that research methods such as "agile action research" or "agile design research" may need to be used. Such approaches should come somewhat naturally to information systems researchers, as the agility concept already has strong roots in our underlying subject area (Baskerville et al. 2005) . Developing agile and engaged research will advance the role of scholarly research in amplifying or dampening fashion-setting.. As well as implying the adoption of new topics and methods, the Milan theory reframes the relationship between academic researchers and knowledge dissemination media. Researchers should become more actively engaged in disseminating their discoveries to practice. Taking a more proactive stance with the news media and practitioner press would mean not only following but also contributing to the practitioner press by providing evidence-based, positive or negative critiques of fashions. Such contributions could be published in practitioner venues like Computerworld or CIO Magazine.. Similarly, reflections on current practice could be given more prominence in IS scholarly journals. Activities like these would mean that IS researchers might well be sought after for their expertise relating to the latest IS fashion.. We suggest that recent moves to provide publication outlets that put academic research into the hands of practitioners (e.g., MISQ Executive) should continue to receive encouragement. However, more needs to be done. To prevent research results from getting bogged down in the publication process, we need a publication vehicle with a more rapid response. Such vehicles already exist in other fields. In economics, for example, the highly regarded Economics Letters aims for efficiency in delivering fast, up-to-date, and concise knowledge about developments, with a very short review cycle. A similar vehicle, "Information Systems Letters," could provide researchers and practitioners with fast-track, concise commentaries and research results about the latest innovative thinking, but still subject to peer review. A publication vehicle such as this might enable IS scholars to take the lead in the IS fashion-setting process.. We acknowledge various limitations in this research. First, the content of the ABI/INFORM Complete™ database has changed over time, which may have affected some of our findings; however, there has been a steady increase in the number of journals indexed, which suggests that the database is much more complete now than in previous years. Second, citation analysis does not reveal whether a concept or idea was central or peripheral to the main topic or whether it was referred to positively or negatively. Citation analysis is limited to the counts of references to an idea-it is a relatively crude measure of the discourse life cycle. Third, the boundaries of a fashion discourse can sometimes be difficult to identify, as fashions may develop and be carried forward under new labels. This makes article searches based on two or three words (or phrases) somewhat problematic. Fourth, our data do not indicate the degree to which the ideas are adopted by organizations-the diffusion life cycle (Clark 2004 )-only the extent to which the topic is mentioned in the literature. Fifth, our analysis is limited to just four IS fashions; we acknowledge that research is needed on other fashions to see whether our findings are more generally applicable. Finally, our analysis does not reveal the paths of influence. While we show evidence that there is no significant time lag between fashion upswings in research and practice, simple counts cannot reveal the influence of research on the fashion discourse among practitioners, or vice versa.. These limitations suggest a number of opportunities for future research. Further research is needed to examine more deeply how IS academics and practitioners influence each other (see Barley et al. 1988) . Such research could dramatically improve the value of IS research to practice. Further research is also needed to examine the triggers of fashion waves and fashion succession. Our selection criteria resulted in four fashions that respectively peaked in 1982, 1990, 1995, and 1999 . Does the collapse of one fashion trigger the launch of a new fashion? Management fashion theory suggests that the collapse of one fashion may release energy that triggers the upswing of the next fashion, but our data are insufficient for us to reach any firm conclusions. An effective first treatment of fashion succession in our field will require a much bigger effort, both in theorizing and empirical study.

O O O O O O O O O O O O O O O B 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 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 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 B I O O O B I O O O O O B O B 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 B I 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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 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 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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 O O O O O O O O O O O O O O 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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


Genotype-phenotype mapping in dynamic environments with grammatical evolution The application of a genotype-phenotype mapping in Evolutionary Computation is not a new idea, however, how this mapping process is interpreted, and implemented varies wildly. In the majority of cases a very simple abstraction of the biological genotype-phenotype mapping is used, but as our understanding of this process increases, the deficiencies in current approaches become more evident. In this paper, an outline of what approaches have been taken in the investigation of the genotype-phenotype map in Grammatical Evolution are presented and an outline of proposed future work is introduced. The adoption of a Genotype-Phenotype Map (GPM) for Genetic Programming (GP) [11, 18] has demonstrated performance advantages over traditional tree-based GP [4, 13, 10, 2] . One of the most popular grammar-based forms of GP [12] , Grammatical Evolution (GE), adopts a genotypephenotype map which has been argued to provide a number of advantages over standard GP [16] . The GPM provides GE with the ability to search both genotypic space and solution space in a many to one relationship, unlike traditional GP which has a one to one mapping. The many-to-one mapping allows for multiple solutions to have the same performance 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. but be structured differently. This feature allows for neutral search which allows the Evolutionary Algorithm(EA) to search with zero impact on performance amongst the different variants of the same solution and has been shown to allow GPM-based variants of GP to resist getting stuck at local optimal solutions [2] . Whilst these results are encouraging it has yet to be established what effect the GPM has on an EA such as GE. How does changing the order in which the mapping is done effect the EA? Can further inspiration be taken from biology which first inspired the GPM in GP to improve the EA. Recently these topics have started to be tackled [8, 15, 6, 7, 1, 14] , but many more avenues of exploration remain as the interpretation of mapping used by GE is simplistic and lacking in some of the desired advanced features of the GPM that exist in nature [3] .. GP research in dynamic environments was recently noted as an open issue for GP [17] . Within a dynamic environment the ability to adapt to change is crucial. Fast adaptation of a GP system requires diversity to be present within the population. The degeneracy offered by a GPM provides the system with diversity within the population thus making it the ideal choice when applying GP to dynamic environments. However the current usage of GPM has been noted to lack the complexity shown in nature [3] as it is based upon an old model of what was once perceived to take place within Genotype-Phenotype Mappings in the natural world.. The remainder of this paper is as follows. An overview of the main research objective in Sections 2 and 3, followed by a summary of work done in Sections 4 and 5, and finally an outline of the future direction of the research in Section 6.

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 O B I 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 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


A trait based re-engineering technique for Java hierarchies Traits are pure behavior components introduced in the Smalltalk community in order to integrate the traditional class inheritance with a composition mechanism: a class is composed by traits and inherits from superclasses. This offers the advantage of promoting code reuse. In this paper, we tackle the problem of re-engineering a Java hierarchy into traits, by adapting to a Java setting a methodology developed by Lienhard, Ducasse, and Arévalo for a Smalltalk setting, based on Formal Concept Analysis. We illustrate the approach by applying it to the Java input stream library. We also obtain two by-products: (i) we identify clearly some workarounds that programmers must exploit in order to overcome some of the limitations of Java single inheritance; (ii) we single out some features a Java with traits might include, as none of the proposals in the literature in this sense has taken the lead yet. It is well-known that single inheritance in object-oriented languages has some intrinsic limitations. Often the restriction of having only one direct superclass forces programmers to some design choices that are not optimal from the point of view of the domain conceptual representation, of the understandability of the code, and especially from the point of view of the code reuse, which is, in principle, one of the main goals of the object-oriented paradigm.. In the literature, there are some proposals to overcome such limitations. Notably, multiple inheritance is supported in different forms by languages such as C++ [32] and Eiffel [22] ; another interesting alternative construct is the mixin based inheritance [8, 9, 10, 2, 16] . Nevertheless, none of them is completely satisfactory, in fact none of them has ever taken the lead completely as a substitute of single inheritance (for a full account on the subject we refer to [12] ).. A new construct called trait was introduced in the Smalltalk community, in order to complement single inheritance and to solve some of the problems introduced by it. Traits [29, 12] are pure units of reuse, constituted of methods only, that can be used as building blocks to compose classes. The most important feature of traits is that the composed class has a complete control on the composition itself, which implies, in particular, that traits and their composition are orthogonal to any inheritance hierarchy; moreover, it is the programmer that must solve explicitly any conflict that may arise when composing the traits. Traits have been incorporated in Squeak [18, 3] , then in other languages such as Scala [25] and Fortress [1] , in a typed context [14] , and in the Java setting [31, 21, 7] .. When traits are introduced in a language, either to complement traditional single inheritance or as the only construct to build classes, it is of interest to tackle two (related) aspects: (i) providing techniques and tools as aids for programming fruitfully with the new construct from scratch (see, for instance, [26] , in which a tool for supporting Java traits in Eclipse is presented); (ii) supplying special code refactoring procedures and tools, to transform legacy code under the form of single-inheritance based hierarchies into trait based hierarchies, in order to improve the reuse possibilities of the legacy code itself.. In this paper, we present a semi-automatic technique for refactoring a traditional Java hierarchy into groups of traits We have chosen not to select a specific "Java with traits" target language among the proposals in the literature [31, 21, 7] , for three reasons: (i) there is still not a proposal which prevails on the others, neither in the literature, nor in the "outside world"; (ii) our goal is to suggest simply a possible set of traits (as groups of methods) that can be used to compose classes that can be integrated within other, orthogonal, programming constructs; (iii) we also want to discuss on which would be a good candidate to become the "Java with traits", that is, which would be the constructs useful to complement traits. A by-product of our work is to single out some of the workarounds programmers must apply in order to overcome some of the drawbacks of single inheritance. Nevertheless, traits and trait composition alone are not enough. In particular, in order to preserve the polymorphism present in a single-inheritance based hierarchy, we need at least to have the interface programming construct (in the sense of Java). For a discussion on other possible combinations of traits with other Java constructs, see Section 5.. Our refactoring technique is based on the approach proposed by Lienhard, Ducasse, and Arévalo [19] for Smalltalk that exploits Formal Concept Analysis [17] , a solid mathematical theory for gathering significative groupings of elements which have some properties in common. The main novelty is that we apply this technique to Java, which is a typed language (while Smalltalk is untyped). We worked on the Java library defining input streams (shown in Figure 1 ) as a case study. We also implemented a substantial part of a tool that performs the trait-based refactoring as an Eclipse plug-in.. The paper is based on the content of the master thesis of Naddeo [23] and it is organized in the following way: Section 2 illustrates, via our case study, some of the design choices forced by single inheritance, Section 3 gives a short introduction on traits, Section 4 presents our refactoring approach from single-inheritance based hierarchies to trait based ones in detail, and Section 5 draws some conclusions on the work done. In this paper, we proposed a refactoring technique to transform a single-inheritance based hierarchy into a trait based hierarchy, with the aim of improving code reuse. Our proposal is an adaptation to Java of the FCA approach of [19] , originally introduced for Smalltalk, which is untyped, and here adapted for a typed setting. The FCA approach was also exploited for identifying modules in legacy code written in C++ in [30] .. Our case study is the Java input stream library, but the same approach can be applied to all the main Java libraries, notably the collection and the networking libraries. The obtained results show that our case study may benefit from a trait based refactoring, as most of the flaws of the original version of the library, described in Section 2, were removed. In future work we will then measure how good the refactored output is, from a more quantitative point of view (for instance, the trait granularity), possibly by comparing it with results from manual techniques, as it was done in [11] for the Smalltalk stream library, that was redesigned from scratch.. We focused on the purpose of designing a trait extraction technique, without choosing any special "Java with traits" as target. The output of our procedure is a lattice of traits that can be seen as a possible refactorization of a classical Java hierarchy, equipped with a hierarchy of interfaces, which is the minimum addition in order not to lose the polymorphism of the original hierarchy. The new trait based hierarchy can be then refined further, with the aid of other techniques, and/or complemented with other programming constructs. We also considered an alternative solution to the "trait + interface" one we adopted in the end, that is, a "trait + interface + abstract class" one, that implies having both trait composition and single inheritance. By using abstract classes, some of the traits individuated in Section 4 (see Figure 8 ) may be implemented as abstract classes (and possibly refactored in traits in the second phase of the approach); for instance, the root of the hierarchy, the abstract class InputStream, would be preserved. Similar considerations to the ones we made about whether to include the methods mark and reset in the interface IInputStream must be taken in account also for the corresponding abstract class. The main advantage of having traits and interfaces only is that we gain in simplicity, while having a form of single inheritance that complements composition might be appealing to programmers used to work with implementation hierarchies.. In the original proposal [19] , trait composition is complementary to single inheritance. Note that the main difference between the untyped Smalltalk setting and the typed Java setting is that, for the latter, it is necessary to introduce a form of inheritance among classes along with trait composition in order to maintain the polymorphism. Nevertheless, it is not mandatory to reintroduce class inheritance, but it is enough to introduce an appropriate interface hierarchy. However, from the point of view of having backward compatibility of the refactored library towards old client code, for both settings it would be necessary to re-introduce all subclasssuperclass relations that were present originally. This is an important issue and it will be developed in future work.. At the moment, we do not have a clear opinion yet on which would be the best "Java with traits", but we hope that this work would help to give some ideas to reflect upon.. A complementary work is to show formally that the proposed technique produces a hierarchy which is conservative with respect to the semantics of the original one. This will be also the subject of future work, but we believe that it is a straightforward (even still interesting) adaptation of the flattening property of [12, 24] .. As mentioned earlier, we implemented a tool that performs most of the steps presented in Section 4, in particular all the ones of the first phase, but the bytecode-based detection of duplicated methods. 3 Step 1, that is, the detection of canceled methods, has been semi-automatized, since it is the programmer that has the last word on which among all the syntactically detected methods are actually to be considered as canceled. The tool is an Eclipse plug-in and it is freely available at http://fcajava.sf.net.

O B 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 B I O O O O O O O O B O B O O O O O O O B 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 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 B 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 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 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 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 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 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 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 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 B 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 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 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 B I 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 B 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 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 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 B 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 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 B 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Comment on "Generic Universal Switch Blocks" AbstractÐIn the paper [5] , the authors defined the well-structured symmetric switch block M N;W and showed that M N;W is universal for any pair of positive integers N and W . However, we find that this result is partially correct. Here, we show that, when N ! U, M N;W is not universal for odd W s (! Q) and it is universal for any even W .Index TermsÐField programmable gate array, universal switch block design, FPGA routing. ae 1 NONUNIVERSAL M N;W S THIS paper concerns the design of generic switch blocks, which can be used in the two or higher dimensional FPGA architectures.An N-sided switch block with W terminals on each side (denoted by (N, W)-SB) is said to be universal if every set of (2-pin) nets satisfying the dimension constraint (i.e., the number of nets routed through each side cannot exceed W ) is simultaneously routable through the switch block. Experiments show that using universal switch blocks (USB) in an FPGA architecture results in higher routing capacity. Therefore, it is desirable, in general, to design an (N, W)-USB for each pair of positive integers N ! P and W ! I. This problem was first proposed and solved for N R in [3] , then extended to k T in [2], and, finally, is claimed to be solved in [5] by showing that the proposed symmetric switch block M N;W is universal for any pair of N and W .However, we find that M N;W is not universal when N ! U and W is odd (! Q). We will show this by presenting unroutable routing requirement (counter examples) for such cases. For example, Fig. 1a shows such a routing requirement for (7, 3)-SB, with routing requirement vector (RRV) V H : n IP I; n PQ I; n PR I; n QR P; n IS I; n ST I; n SU I; n TU P and others n ij H. V H is not routable in M U;Q because M U;Q is isomorphic to the disjoint union of M U;P and M U;I (see Fig. 2 ), but V H cannot be decomposed into two RRVs that are routable in M U;P and M U;I . Moreover, we find that M N;W is universal if and only if N T or W is even.In order to give a simple proof and to employ some known graph theory results, we use graph models to represent routing requirements and switch blocks. In view of practice (practical application), it is quite useful already to have the result that M N;W is universal for an even W since we can choose to design FPGA switch boxes with an even number of tracks to gain universal routing property. However, as a problem, the generic (N, W)-USB design problem for N ! U and odd W (! Q) is still left open and it seems to be a hard problem because no efficient method is known to compute all N-way MBGRs for any given N.

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 I 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


Single Password Authentication Users frequently reuse their passwords when authenticating to various online services. Combined with the use of weak passwords or honeypot/phishing attacks, this brings high risks to the security of the user's account information. In this paper, we propose several protocols that can allow a user to use a single password to authenticate to multiple services securely. All our constructions provably protect the user from dictionary attacks on the password, and cross-site impersonation or honeypot attacks by the online service providers.Our solutions assume the user has access to either an untrusted online cloud storage service (as per Boyen [14]), or a mobile storage device that is trusted until stolen. In the cloud storage scenario, we consider schemes that optimize for either storage server or online service performance, as well as anonymity and unlinkability of the user's actions. In the mobile storage scenario, we minimize the assumptions we make about the capabilities of the mobile device: we do not assume synchronization, tamper resistance, special or expensive hardware, or extensive cryptographic capabilities. Most importantly, the user's password remains secure even after the mobile device is stolen. Our protocols provide another layer of security against malware and phishing. To the best of our knowledge, we are the first to propose such various and provably secure password-based authentication schemes. Lastly, we argue that our constructions are relatively easy to deploy, especially if a few single sign-on services (e.g., Microsoft, Google, Facebook) adopt our proposal. A recent study [26] found that the average user logs into 25 different online services in the course of a three month period. The same study found that the average user has only 7 passwords, and reuses them for about 3 accounts on average. To make things worse, users frequently forget their passwords, and try to login via trial-and-error. This means that a malicious online service would learn not only a user's password to that service, but to many other services, possibly also through a cross-site impersonation attack. Even "trusted" services may mount such attacks. For example, in 2004, the CEO of Facebook allegedly used Facebook login data to access the private emails of some business rivals and journalists [20] .. In a honeypot attack, Bob would create an online service, Bob.com, and convince Alice to create an account on it. Bob.com might even provide some useful service, but the real goal of the honeypot would be to harvest as many usernames and passwords as possible. Bob would then try to use this information to login to other services such as bank accounts. Even if Bob.com was honest, hackers might try to break into Bob.com user database and steal user login data. Bob.com might also leak the information accidentally (e.g., lost company laptops). Analysis of a breach suggests that the user passwords then can be recovered easily via dictionary attacks by the hackers [34] .. Even if Bob.com is an honest online service with strong security precautions, Alice still has to worry about potential malware running on her computer. She can become the victim of a phishing attack (where a malicious website impersonates Bob.com), a key logger running on a public terminal, or a virus on her friend's computer.. In this work, we present several solutions to the problem of secure password authentication. Our solutions have three key features:. 1. Alice has exactly a single password that she can use with all online services (hence the name single-password authentication -SPA).. 2. No online service ever learns Alice's password, or any deterministic function of Alice's password. In particular, no online service ever learns enough information to impersonate Alice with any other service.. 3. Alice's user experience is simple and similar to the typical password login experience she is already used to.. We accomplish these three goals with the help of a storage device. We consider two scenarios. In the first scenario, the storage device is actually an online cloud service -Carol.net. Alice distrusts Carol.net as much as she distrusts Bob.com. Yet, as long as Carol and Bob do not collude, Alice's password is safe. For simplicity, we describe our protocols assuming Carol and Bob do not collude (e.g., Carol is Microsoft and Bob is Google), but in Section 6 we show how to relax this assumption. In our second scenario, where Alice has a trusted mobile device (e.g., a smart-phone), Alice's password and online accounts are safe even if an adversary (except Bob, since otherwise it means the storage and the online service are colluding) steals her mobile device. Note that such a helper storage means that Alice may use any computer to login to her accounts (in contrast to password managers that require installation on each computer Alice would like to use).. Our cloud-based solutions are based on Boyen's Hidden Credential Retrieval (HCR) protocols [14] . HCR lets a user securely store a random value on an untrusted server. Due to the properties of the HCR scheme, only the user who knows a short password can retrieve the data. An adversary who does not know the password cannot launch a dictionary attack to retrieve the secret data because the adversary has no way to test whether the data it retrieves is the correct random value via offline means. The adversary may then try to mount an online attack, but Bob.com will block his attempts after several unsuccessful tries, since by assumption they are not colluding.. proof hardware, and mainly target phishing attacks rather than dictionary attacks. Our mobile SPA protocols assume only standard hardware, and are provably secure even if the mobile device is stolen and its contents are revealed (no tamper-resistance required).. Our constructions focus on achieving authentication rather than authenticated key exchange. There exist many protocols for achieving a secure channel between two parties given an initial set of secrets; TLS, SSH, and Kerberos are pervasive examples. Instead of creating a new secure channel protocol that is unlikely to be adopted, we propose practical schemes that are easily deployable with existing infrastructure.. Finally, other attempts to provide single-password authentication fail to provide complete security against dictionary attacks by the server or hackers hacking into the server, since they lack formal definitions and proofs [53, 29] . For example, the SPP scheme [29] assumes the users can remember long and random passwords; otherwise the scheme is insecure against dictionary attacks. It is possible to use only the information known to the server to mount a dictionary attack, since the server also stores the randomness used in the hash function (see our observations below). Unfortunately Imperva analysis shows that half of the user passwords are already susceptible to dictionary attacks [34] . In the SOKE scheme, the authors admit that using the same password for multiple servers makes it even easier to mount dictionary attacks [1] . Recent industrial solutions trying to secure the server-side password databases [50] make it harder but not impossible to mount dictionary attacks. The closest formalization to our technique is the virtual soft-token idea [49] , but again without provable security against dictionary attacks. Our constructions are all provably secure against dictionary attacks, and it is possible that the single password that is used is simple, as long as it is hard to guess (i.e. secure against social attacks) (e.g., not so obvious as a birth date).. While we provide provable guarantees against many common attacks, we do not fully protect against man-in-the-middle attacks or malware. If the adversary can successfully mount a man-inthe-middle attack (e.g., via attacking SSL, secure DNS, or certificates, or by installing malware on the machine used), the the adversary may steal a single session in our mobile-based solutions. This is a problem inherent in today's world, and would require modifications in network protocols with support from browsers and operating systems. Yet, we make sure to protect the user's persistent, long-term password even under successful man-in-the-middle attacks or malware.. Our contributions may be summarized as follows:. 1. We formally define single-password authentication schemes, and security against attacks by a malicious server, or a malicious storage, or an external adversary, both in cloud-and mobilebased scenarios.. 2. We present, to the best of our knowledge, the first provably-secure single-password authentication schemes with various performance/privacy/usability considerations.. 3. Our cloud-based solutions do not require that multiple servers need to communicate with, or even know each other, and thus can be easily deployed via independent vendors.. 4. Our mobile-based solutions can work with current standard cell-phones or smart-phones, and remain secure even when the device is stolen.. 5. Overall, we propose methods to (completely or partially) protect against dictionary attacks, honeypot attacks, cross-site scripting attacks, phishing attacks, and malware. To the best of our knowledge, such a comprehensive proposal on password-based authentication have not been done before.. To enable these contributions, we make three key observations:. 1. Password-based encryption is inherently susceptible to dictionary attacks. Therefore, simply using a master password to encrypt all other passwords do not constitute a solution. The key idea we use is the fact that password-based encryption is insecure unless the encrypted input is indistinguishable from random.. 2. While offline dictionary attacks are very easy to mount and fast, online dictionary attacks are inherently slow and easy to protect against. The standard mechanism in use today (limiting the number of unsuccessful attempts) is enough to successfully thwart online dictionary attacks. Thus, in our solutions, we make sure that the only way of testing correctness of the decryption of a password-based encryption is online through trying to login to the server (i.e. in cryptographic terms, the number of queries that can be made to a distinguishing oracle is limited to some constant).. 3. Current authentication protocols, where there is no randomization by the client or the server, are doomed to be susceptible to dictionary attacks (by the server or hackers hacking into the server), since the server has a deterministic function of the client's password (see also [31, 13] ). To overcome such a limitation, the authentication protocol must be a challengeresponse type protocol where the server never learns any deterministic function of the client's password.

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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 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 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 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 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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 O O O O B I 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 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 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 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 B I 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 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 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 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 B I O O O O O O O O B 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 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 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 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 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


Static analysis to support the evolution of exception structure in object-oriented systems Exception-handling mechanisms in modern programming languages provide a means to help software developers build robust applications by separating the normal control flow of a program from the control flow of the program under exceptional situations. Separating the exceptional structure from the code associated with normal operations bears some consequences. One consequence is that developers wishing to improve the robustness of a program must figure out which exceptions, if any, can flow to a point in the program. Unfortunately, in large programs, this exceptional control flow can be difficult, if not impossible, to determine.In this article, we present a model that encapsulates the minimal concepts necessary for a developer to determine exception flow for object-oriented languages that define exceptions as objects. Using these concepts, we describe why exception-flow information is needed to build and evolve robust programs. We then describe Jex, a static analysis tool we have developed to provide exception-flow information for Java systems based on this model. The Jex tool provides a view of the actual exception types that might arise at different program points and of the handlers that are present. Use of this tool on a collection of Java library and application source code demonstrates that the approach can be helpful to support both local and global improvements to the exception-handling structure of a system. Most modern programming languages provide an exception-handling mechanism. Syntactically, an exception-handling mechanism provides a means to raise an exceptional condition explicitly, and a means to express a block of code to handle one or more exceptional conditions [Goodenough 1975] . By enabling software developers to separate source code that deals with unusual situations from code that supports normal processing, exception-handling mechanisms are intended to make it easier for developers to conceptualize and build robust software systems.. Separating the exceptional structure from the code associated with normal operation has consequences. One consequence is that developers wishing to improve the robustness of a program must figure out which exceptions, if any, can flow to a point in the program. Some exception-handling mechanisms help a developer in this reasoning process. The mechanisms for Java [Gosling et al. 1996] and CLU [Liskov and Snyder 1979] , for instance, both support the declaration of exceptions in module interfaces; the compiler can then check that appropriate handlers are provided in a client module. However, this support is only partial because each of these languages also provides a form of unchecked exceptions. The developer of a client module is not warned of the possibility of an unchecked exception by the compiler. Object-oriented languages, which typically support the classification of exceptions into exception-type hierarchies, further complicate the reasoning about exception structure because a handler that explicitly names one exception type may implicitly catch a set of more specific exception types. Such implicit catching of exception types can complicate the development and evolution of robust classes [Miller and Tripathi 1997; Robillard and Murphy 2000] .. In this article, we present a model that encapsulates the minimal concepts necessary for a developer to reason about exception flow for the purpose of software evolution (Section 2). Using these concepts, we describe why exception-flow information is needed to build and evolve robust programs (Section 3). We then describe Jex, a static analysis tool we have developed to provide exception-flow information for Java systems (Section 4). The Jex tool extracts information about the flow of exceptions in Java programs, providing a view of the actual exception types that might arise at different program points and of the handlers that are present. In Section 5, we describe how we have used this tool on a collection of Java library and application source code to demonstrate that the approach can be helpful to support both local and global improvements to the exception handling structure of a system. In Section 6, we compare our approach to other exception-flow analysis tools and techniques. Finally, Section 7 summarizes and concludes the article. Goodenough [1975] introduced the exception-handling concepts in use today. To provide a common basis for discussion, we begin with a brief review of these concepts and the related terminology. It is not uncommon for users of software applications to become frustrated by misleading error messages or program failures. Exception-handling mechanisms present in modern programming languages provide a means to enable software developers to build applications that avoid these problems. Building and evolving applications with appropriate error-handling strategies, though, requires support above and beyond that provided by a language's compiler or linker. To implement an appropriate strategy, a developer requires knowledge about how exceptions might flow through a system. Unfortunately, exceptionhandling mechanisms introduce a different control flow that can be difficult, if not impossible, to assess. In object-oriented languages where exceptions are defined as objects, the control flow of a program under exceptional circumstances is determined by the type of the exception objects that are raised.. In this article, we have shown the need for a developer to reason about exception flow when producing robust systems, and we have presented a model that encapsulates the minimal concepts necessary for a developer to understand exception flow for object-oriented languages that define exceptions as objects. Researchers interested in the use of exception-flow information for the purpose of software engineering tasks can build on this minimal model to describe techniques and methodologies that use exception-flow information.. Using the concepts of this exception-flow model, we have described why exception flow information is necessary to build and evolve robust programs. Exception-flow information can be used both at the level of guarded scopes, to detect and correct problems such as unused handlers, and at the global level, to improve exception-handling policies based on the knowledge of how certain exceptions can propagate through the system.. We have also described Jex, a static analysis tool we have developed to provide exception-flow information for Java systems. The Jex tool extracts information about the structure of exceptions in Java programs, providing a view of the actual exception types that might arise at different program points and of the handlers that are present. Use of this tool on a collection of Java library and application source code demonstrates that the approach can be helpful to support both local and global improvements to the exception-handling structure of a system.. The model of exception flow described in this article, and the corresponding challenges a developer faces when trying to assess exception flow, are based only on the characteristics of the general exception-handling mechanism targeted by our work, and do not integrate any specific programming language semantics. For this reason, both the model presented, the problems discussed, and the functionality for the exception-flow analysis tool described in this article are in theory applicable to any object-oriented programming language that define exceptions as objects. Furthermore, even if the implementation of an exception-flow analysis tool is inevitably language-specific, many of the challenges we faced in the implementation of Jex will have to be addressed for other languages. Researchers and practitioners wishing to develop exceptionflow analysis technologies for other languages can thus build on our work to elicit the tool requirements, plan the design and implementation of the tool, and evaluate the results. Various static analysis tools and techniques have been proposed to address problems related to exception handling in different programming languages. We distinguish between two broad classes of tools and techniques for exception handling based on the underlying goal: human-oriented approaches, meant to help developers build robust programs, and machine-oriented approaches, meant to be integrated into compilers or other static analysis tools (e.g., dynamic optimization of exception handling [Ogasawara et al. 2001] , or controland data-flow analysis in the presence of exceptions [Choi et al. 1999; Sinha and Harrold 2000] ). This section presents an overview of human-oriented approaches, as machine-oriented approaches are outside the scope of our work.. Human-oriented static analysis for exception handling has been proposed for three languages with large user-bases: ML [Milner et al. 1990 ], a functional language; Ada-83 [ANSI 1983 ], an imperative language; Java, an object-oriented language.. The ML language represents exceptions as singular values that are not organized into a hierarchy and does not support exception interfaces [Lang and Stewart 1998 ]. These two characteristics make it difficult for programmers to ensure that all exceptions are caught. Pessaux and Leroy [1999] report that uncaught exceptions are the most frequent mode of failure in large ML applications. The goal of the analyses for ML is thus to help programmers identify the points in a program where different exceptions can be raised. Guzmán and Suárez [1994] have proposed an extension of the ML type system by which it is possible to estimate all uncaught exceptions that can be raised. Their type system is limited in that it does not handle exceptions carrying arguments.. A different approach has been adopted by Yi [1998] , who developed an exception analyzer based on abstract interpretation techniques [Cousot and Cousot 1977] . Since this analyzer suffered from performance problems, Yi and Ryu [1997] developed a more efficient one using control-flow analysis and a set-constraints framework [Heintze 1992] . Fähndrich et al. [1998] have built an Exception Analysis Tool (EAT) that allows the programmer to display uncaught exceptions in various scopes while browsing the corresponding source code. EAT is based on BANE, a general framework for implementing constraint-based program analyses. Yi's tool is more precise than EAT, but EAT, which uses a more conservative approach, is more scalable. The EAT tool also provides support for visualizing the declaration and handling of exceptions at different points in the program. Pessaux and Leroy [1999] propose a type-based analysis of uncaught exceptions in ML that offers different speed and precision tradeoffs than the previous constraintbased approaches. Most of the work on exception analysis for ML focuses on the technical difficulties and tradeoffs involved in the analysis, with little or no discussion of how the results can be applied in a software engineering context.. Ada exceptions share some of the characteristics of ML exceptions. In particular, they are defined according to a flat structure [Gauthier 1995] , and the language does not support exception interfaces. Tools proposed for Ada include the work of Schaefer and Bundy [1993] , and of Brennan [1993] . Similar to Jex, these tools calculate the encounters function for all scopes in a program. However, since Ada-83 is not an object-oriented language and since Ada exceptions are not organized hierarchically, their analysis does not need to consider dynamic method bindings or subsumption for handler selection. Furthermore, neither of these approaches provides complete information about the flow of predefined Ada exceptions. However, exceptions generated by language operations can play an important part in the behavior of a program under exceptional circumstance: Jex includes the propagation paths for predefined exceptions in its analysis. Additionally, the main focus of the work on Ada exception analysis was to detect specific defects in the code, such as unused handlers. Such detection relates to local reasoning in our terminology. The tool described by Brennan was originally meant to help systematically implement fault-tolerant Ada programs following a compartmenting approach proposed by Litke [1990] . We have not found any report of the application of this technique in Ada, but in earlier work, we reported on the use of Jex to evaluate the feasibility of the approach for improving the design of exception structure in Java systems [Robillard and Murphy 2000] . In comparison to the approaches for Ada, our work considers support for both local and system-wide reasoning about exceptions in object-oriented systems.. Tools and algorithms have also been developed to analyze various aspects of exception handling in Java. The first version of Jex [Robillard and Murphy 1999] was limited to version 1.0 of the Java language, and provided only a subset of the generates function for any scope. These shortcomings have been addressed in the version described in this article. Sinha and Harrold [1999] have described a framework and methodology for selecting unit and integration test cases for Java programs that contain exception-handling constructs. Ryder et al. [1999] have built the Java Exception Static Profiler (JESP), a suite of tools to extract statistical information about the frequency of the occurrence of exception-handling structures in Java programs. Ryu and Yi [2001] have proposed an algorithm for the exception analysis of an extension of the Java language that supports the propagation of exceptions across threads. Their language extension involves a new keyword for raising an exception in a different thread. The analysis involves first determining the expressions of a program that can be executed concurrently, and then analyzing the flow of exceptions between concurrent expressions. Their analysis of exception flow is based on the resolution of constraints on the type of expressions in a Java program. No implementation of this analysis was described in the work cited above, so the practical feasibility of the approach remains to be evaluated. In our work, because we support the Java language without special extensions, we do not distinguish thread-related exceptions from other asynchronous exceptions, which can theoretically be raised at any program point. For that reason, we do not consider asynchronous exceptions in our analysis. Chang et al. [2001] have proposed an interprocedural exception analysis also based on the set-constraints framework. Their exception-flow analysis offers a refinement over the one performed by the Java compiler. This analysis determines more precisely the types of exceptions that can be propagated by a method, based on an analysis of the types of expressions in throw statements. The analysis, however, does not include the flow of unchecked exceptions, including exceptions generated by the Java virtual machine at run-time. This precludes examining many of the problems we discussed in this article, such as the unanticipated handling of unexpected exceptions. In contrast, the model we propose is intended to address all synchronous exceptions that can be raised in a Java program, and, to this effect, the Jex tool supports the analysis of both checked and unchecked exceptions. Chang et al. [2002] have also reported on a visualizer they have created to show exception propagation in Java programs. Their visualizer consists of textual views in an integrated development environment that allow a developer to view, for a selected method, a list of uncaught checked exceptions for that method, and to see the propagation path of those exceptions from their origin. In contrast, our visualizer provides graphical views of the exception flow at different levels of structural detail, from methods, to packages, and user-specified components. Our intent is to allow a developer to investigate the overall exception flow in a system.

B I O O O O O B I 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 I 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 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 B 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 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 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 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 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 I 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 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 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 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 B I 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 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 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 B 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 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 B I O B I 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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 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 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


On Optimal Bilinear Quadrilateral Meshes Abstract. The novelty of this work is in presenting interest This paper presents the theoretical effectiveness of two types of 'optimal' bilinear quadrilateral meshes. The novelty of this work is in presenting interesting error properties of two types of asymptotically 'optimal' quadrilateral meshes for bilinear approximation. The first type of mesh has an error equidistributing property where the maximum interpolation error is asymptotically the same over all elements. The Government retains a nonexclusive, royalty-free license to publish or reproduce the published form of this contribution, or allow others to do so, for U.S. Government purposes.. Correspondence and offprint requests to: E. D'Azevedo, Computer Science and Mathematics Division, Oak Ridge National Laboratory, P.O. Box 2008, Oak Ridge, TN 37831-6367, USA. Email: e6dȰornl.gov second type has faster than expected 'super-convergence' property for certain nonconvex saddle-shaped data functions. The 'super-convergent' mesh may be an order of magnitude more accurate than the error equidistributing mesh. Both types of meshes are generated by a coordinate transformation of a regular mesh of squares. The coordinate transformation is derived by interpreting the Hessian matrix of a data function as a metric tensor. This work is a basic study on optimal meshes with the intention of gaining insight into the more complex meshing problem in surface approximation and finite element analysis, especially near corner or point singularities.. For simplicity, we consider the problem of interpolating a given smooth data function with continuous piecewise bilinear quadrilaterals over a domain to satisfy a given error tolerance. A mesh that achieves this error tolerance with the fewest elements is defined to be optimally efficient. Intuitively, one would expect smaller and denser elements in regions where the function has sharp peaks or large variations.. Provably optimal triangular meshes [1, 2] have been produced by anisotropic mesh transformation. Anisotropic mesh transformation is emerging as an effective technique for unstructured grid generation, where the vertex distribution is highly non-uniform. The central idea is to control the element shapes and sizes by specifying a symmetric metric tensor that measures the approximation error. The metric tensor determines the corresponding anisotropic transformation. The anisotropic mesh is then the image of a uniform mesh of optimal shape elements under the anisotropic transformation. Simpson [3] gives a survey on anisotropic meshes. Nadler [4] , D'Azevedo and Simpson [5, 2] and D'Azevedo [1] have studied local anisotropic transformation for generating optimally efficient triangular meshes. Numerous works, such as Borouchaki [6] , Peraire [7] and Shimada [8] , have used the Hessian matrix as a metric tensor for anisotropic mesh generation.. In this paper, we apply a similar analysis to bilinear approximation on quadrilateral patches.. An outline of the paper follows. In Section 2, we present a simple local quadratic model for error analysis and introduce the coordinate transformation to the 'isotropic' space. In Section 3 we show that a square over the isotropic space is the most efficient shape to minimize the ratio of Error/Area. A regular mesh of squares over the isotropic space would correspond to an optimally efficient mesh in the original space. Section 4 states a classical result in differential geometry on the conditions for finding the anisotropic transformation [x(x,y),ỹ(x,y)] for a general data function. Results of numerical experiments are presented in Section 5 to demonstrate the error equidistributing property and the effectiveness of the super-convergent meshes.

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 O O O O O O O O O O O O O O O O O O O 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 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 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 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


Learning from Cluster Examples Abstract. Learning from cluster examples (LCE) is a hybrid task combining features of two common grouping tasks: learning from examples and clustering. In LCE, each training example is a partition of objects. The task is then to learn from a training set, a rule for partitioning unseen object sets. A general method for learning such partitioning rules is useful in any situation where explicit algorithms for deriving partitions are hard to formalize, while individual examples of correct partitions are easy to specify. In the past, clustering techniques have been applied to such problems, despite being essentially unsuited to the task. We present a technique that has qualitative advantages over standard clustering approaches. We demonstrate these advantages by applying our method to problems in two domains; one with dot patterns and one with more realistic vector-data images. Clustering is a typical grouping task that involves partitioning a given object set into subsets, such that objects in the same subset are "similar." (We use the term objects to refer to entities that will be grouped.) Clustering is carried out based on prespecified knowledge in the form, for example, of preference potential functions or dissimilarity measures.. In this paper, we advocate the use not of prespecified knowledge, but of examples for partitioning. That is, we try to acquire a partitioning rule from an example set consisting of pairs of an object set and a true partition for the object set. The acquired rule can then be used for finding a true partition for an unseen object set (not appearing in the training example set). Since the task is similar to that of learning from examples, which acquires a classification rule from a given example set, we give the new task the composite name learning from cluster examples (LCE).. A solution technique for LCE will be useful for any problem for which users can easily identify an appropriate partition for a given object set, but cannot specify explicit knowledge for deriving these partitions in general. We know of no previous technique that has been developed for this purpose. To fill a void, clustering techniques have previously been used, but they are not particularly suited to this kind of partitioning. In this paper, we present a dedicated technique, and discuss its theoretical and practical merits.. We apply our solution to experimental tasks in two domains. One task involves an artificial domain made up of dot patterns, and the other involves a realistic domain made up of vectordata images.. Since there are no algorithms designed specifically for the tasks we consider, we pay particular attention to showing the qualitative advantages over using clustering techniques for partitioning, assessing the appropriateness of the acquired partitions, and analyzing the behavior of our method in detail.. We proceed as follows. In Section 2, we show the importance of the LCE task and formalize the problem. In Sections 3 and 4, we then present partitioning and learning methods, respectively. In Section 5 these methods are applied to experimental problems. In Section 6, we discuss LCE. Finally, Section 7 summarizes our conclusions. We introduced learning from cluster examples as a new learning task, and discussed the merits of accomplishing this task. We proposed a solution method for the task and applied this method to object sets in two types of domains. Using a set of dot patterns, we showed that our method could automatically acquire and fully represent the information required for appropriate partitioning. We then showed that these results carried over to the more realistic domain of vector-data images.. Having laid the foundations for the basic task in this paper, we now plan to continue this research by investigating additional approaches. Another topic for further research is the extension of the composite attribute vector form, and the development of a method capable of dealing with attributes assigned to clusters.. Code length for the example set S (Wallace & Patrick, 1993) : (S) = log(#S + 1) + log #S #S + We have applied our technique of learning from cluster examples in two test domains: dot patterns and vector-data images. We below describe these domains, then present and discuss our test results.

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 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 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 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 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 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 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O