| Publications sorted by title |
| 2009 |
| 2008 |
| Little is known about the specific kinds of questions programmers ask when evolving a code base and how well existing tools support those questions. To better support the activity of programming, answers are needed to three broad research questions: 1) What does a programmer need to know about a code base when evolving a software system? 2) How does a programmer go about finding that information? 3) How well do existing tools support programmers in answering those questions? We undertook two qualitative studies of programmers performing change tasks to provide answers to these questions. In this paper, we report on an analysis of the data from these two user studies. This paper makes three key contributions. The first contribution is a catalog of 44 types of questions programmers ask during software evolution tasks. The second contribution is a description of the observed behavior around answering those questions. The third contribution is a description of how existing deployed and proposed tools do, and do not, support answering programmers' questions. |
| With the advent of object-oriented systems it is contested that they are less complex, more manageable, more modular and, hence, less error prone. Predictor of error is a software quality attribute and is an important parameter of software reliability. The program complexity measure and the size measures currently seem to be the most capable measures for both quantitative and objective control of the software project. Fault proneness can be estimated based on certain directly measurable software attributes if associations between these attributes and the system fault proneness can be established. In this study, the analysis of the integrated effect of the static measures and object-oriented metrics available on the fault proneness of the software is done. Also, a model using artificial neural network (ANN) is presented and validated for detecting faulty classes. Neural network modeling methods have proved to predict software quality when predicting reliability and the number of faults. The neural network is trained on the principal components derived from the raw data collected from real-time object-oriented software systems. The model is able to classify classes with as much as 76 percent accuracy. Key words: ANN, fault prone classes, objectoriented metrics, object-oriented systems, prediction models, software engineering, static measures |
| Quality experts often need to identify in software systems design defects, which are recurring design problems, that hinder development and maintenance. Consequently, several defect detection approaches and tools have been proposed in the literature. However, we are not aware of any approach that defines and reifies the process of generating detection algorithms from the existing textual descriptions of defects. In this paper, we introduce an approach to automate the generation of detection algorithms from specifications written using a domain-specific language. The domain-specific is defined from a thorough domain analysis. We specify several design defects, generate automatically detection algorithms using templates, and validate the generated detection algorithms in terms of precision and recall on Xerces v2.7.0, an open-source object-oriented system. |
| The FreeBSD, GNU/Linux, Solaris, and Windows operating systems have kernels that provide comparable facilities. Interestingly, their code bases share almost no common parts, while their development processes vary dramatically. We analyze the source code of the four systems by collecting metrics in the areas of file organization, code structure, code style, the use of the C preprocessor, and data organization. The aggregate results indicate that across various areas and many different metrics, four systems developed using wildly different processes score comparably. This allows us to posit that the structure and internal quality attributes of a working, non-trivial software artifact will represent first and foremost the engineering requirements of its construction, with the influence of process being marginal, if any. |
| 2007 |
| The value of using static code attributes to learn defect predictors has been widely debated. Prior work has explored issues like the merits of “McCabes versus Halstead versus lines of code counts ” for generating defect predictors. We show here that such debates are irrelevant since how the attributes are used to build predictors is much more important than which particular attributes are used. Also, contrary to prior pessimism, we show that such defect predictors are demonstrably useful and, on the data studied here, yield predictors with a mean probability of detection of 71 percent and mean false alarms rates of 25 percent. These predictors would be useful for prioritizing a resource-bound exploration of code that has yet to be inspected. Index Terms—Data mining detect prediction, McCabe, Halstead, artifical intelligence, empirical, naive Bayes. |
| Many techniques for detecting duplicated source code (software clones) have been proposed in the past. However, it is not yet clear how these techniques compare in terms of recall and precision as well as space and time requirements. This paper presents an experiment that evaluates six clone detectors based on eight large C and Java programs (altogether almost 850 KLOC). Their clone candidates were evaluated by one of the authors as an independent third party. The selected techniques cover the whole spectrum of the state-of-the-art in clone detection. The techniques work on text, lexical and syntactic information, software metrics, and program dependency graphs. |
| Design patterns are generic design solutions that can be applied and composed in different applications where pattern-related information is generally implicit in the Unified Modeling Language (UML) diagrams of the applications. It is unclear in which pattern instances each modeling element, such as class, attribute, and operation, participates. It is hard for a designer to find the design patterns used in an application design. Consequently, the benefits of design patterns are compromised because designers cannot communicate with each other in terms of the design patterns they used and their design decisions and trade-offs. In this paper, we present a UML profile that defines new stereotypes, tagged values, and constraints for tracing design patterns in UML diagrams. These new stereotypes and tagged values are attached to a modeling element to explicitly represent the role the modeling element plays in a design pattern so that the user can identify the pattern in a UML diagram. Based on this profile, we also develop a Web service (tool) for explicitly visualizing design patterns in UML diagrams. With this service, users are able to visualize design patterns in their applications and compositions because pattern-related information can be dynamically displayed. A real-world case study and a comparative experiment with existing approaches are conducted to evaluate our approach. |
| Knowing which associations are compositions is important in a tool for the reverse engineering of UML class diagrams. Firstly, recovery of composition relationships bridges the gap between design and code. Secondly, since composition relationships explicitly state a requirement that certain representations cannot be exposed, it is important to determine if this requirement is met by component code. Verifying that compositions are implemented properly may prevent serious program flaws due to representation exposure. We propose an implementation-level composition model based on ownership and a novel approach for identifying compositions in Java software. Our approach is based on static ownership inference; it is parameterized by class analysis and is designed to work on incomplete programs. We present empirical results from two instantiation of our approach. For one of these instantiations, on average 40\% of the examined fields account for relationships that are identified as compositions. In addition, we present a precision evaluation which shows that the analysis achieves almost perfect precision--that is, it almost never misses composition relationships. The results indicate that precise identification of interclass relationships can be done with a simple and inexpensive analysis, and thus can be easily incorporated in reverse engineering tools that support iterative model-driven development. |
| An eye tracking experiment revealed that college student users have substantial trust in Google's ability to rank results by their true relevance to the query. When the participants selected a link to follow from Google's result pages, their decisions were strongly biased towards links higher in position even if the abstracts themselves were less relevant. While the participants reacted to artificially reduced retrieval quality by greater scrutiny, they failed to achieve the same success rate. This demonstrated trust in Google has implications for the search engine's tremendous potential influence on culture, society, and user traffic on the Web. |
| Early detection and correction of faults in the software design phase can reduce total cost and time to market of a software product. In this paper we describe an approach for testing UML design models to uncover inconsistencies. Our approach uses behavioral views such as Sequence Diagrams to simulate state change in an aggregate model. The aggregate model is the artifact of merging information from behavioral and structural UML views. OCL pre-conditions, post-conditions and invariants are used as a test oracle. |
| Design patterns are solutions to recurring design problems, conceived to increase benefits in terms of reuse, code quality and, above all, maintainability and resilience to changes. This paper presents results from an empirical study aimed at understanding the evolution of design patterns in three open source systems, namely JHotDraw, ArgoUML, and Eclipse-JDT. Specifically, the study analyzes how frequently patterns are modified, to what changes they undergo and what classes co-change with the patterns. Results show how patterns more suited to support the application purpose tend to change more frequently, and that different kind of changes have a different impact on co-changed classes and a different capability of making the system resilient to changes. |
| The Unified Modeling Language (UML) is a family of largely visual notations which has become the "lingua franca" of software engineering. In industrial settings the UML is used mainly as a means for facilitating communication between humans and so its visual qualities are decisive for its usefulness and practical value. However, it is rare to see any sort of analysis of the visual qualities and their effectiveness. Also, since the UML is continually evolving, some guidelines and criteria to help analyse any changes or additional proposed notations would be beneficial. Building on some basic frameworks and design criteria, we develop some principles for effective design, especially when considering languages with vague semantics. We use this to identify a number of problems of the UML that show up in the diagrammatic representation of models and propose improvements which overcome these difficulties. The methodology is applicable for analysing other complex languages with vague semantics in order to try to reduce human errors. |
| Since the seminal book by the Gang of Four, design patterns have proven an important tool in software development. Over time, more and more patterns have been discovered and developed. The sheer amount of patterns available makes it hard to find patterns useful for solving a specific design problem. Hence, tools supporting searching and finding design patterns appropriate to a certain problem are required. To develop such tooling, design patterns must be described formally such that they can be queryed by the problem to be solved. Current approaches to formalising design patterns focus on the solution structure of the pattern rather than on the problems solved. In this paper, we present a formalisation of the intent of the 23 patterns from the Gang-of-Four book. Based on this formalisation we have developed a Design Pattern Wizard that proposes applicable design patterns based on a description of a design problem. |
| Design patterns aim at improving reusability and variability of object-oriented software. Despite a notable success, aspect-oriented programming (AOP) has been discussed recently to improve the design pattern implementations. In another line of research it has been noticed that feature-oriented programming (FOP) is related closely to AOP and that FOP suffices in many situations where AOP is commonly used. In this paper we explore the assumed duality between AOP and FOP mechanisms. As a case study we use the aspect-oriented design pattern implementations of Hannemann and Kiczales. We observe that almost all of the 23 aspect-oriented design pattern implementations can be transformed straightforwardly into equivalent feature-oriented design patterns. For further investigations we provide a set of general rules how to transform aspect-oriented programs into feature-oriented programs. |
| UML sequence diagrams describe the interaction be- tween objects of a system. In this paper, we present four approaches to analyze the quality of sequence diagrams. First, we propose formal model checking techniques and vi- sualization to analyze the possible interaction traces and to identify ambiguities in a sequence diagram. Second, we identified patterns of common interactive behavior and we present an approach to identify these patterns. This ap- proach is useful to identify implicit patterns and make them explicit. Third, we propose a series of checks to identify syn- tactic defects in sequence diagrams. The fourth approach consists of metrics describing properties such as coverage. The proposed approaches complement each other rather than being competing alternatives. We implemented these approaches in our SquAT tool and conducted a multi case study on three industrial and five research models to vali- date them. These models showed a large number of defects which were acknowledged by their designers. |
| Programs that use multi-threaded concurrency are known to be difficult to design. Moreover, research in computer-science education suggests that concurrency and synchronization concepts are generally difficult to master. It stands to reason that comprehension tasks may be more complex for programs that employ concurrency than for sequential programs. We believe that external representations, specifically refinements to some of the popular UML modeling notations, should aid students in mastering fundamental concurrency/ synchronization concepts and should enable practitioners to better comprehend the dynamically evolving nature of the these programs. In this paper, we present our synchronization adorned UML (saUML) sequence diagram notation that highlights aspects of thread interactions and describe an empirical study of whether these diagrams, as opposed to purely textual representations, help students to better understand concurrent executions and concurrency concepts, as measured by their ability to answer questions about a particular execution of a multi-threaded system. A statistically significant benefit was found from the study. |
| Eye-tracking equipment is used to assess how well a subject comprehends UML class diagrams. The results of a study are presented in which eye movements are captured in a non-obtrusive manner as users performed various comprehension tasks on UML class diagrams. The goal of the study is to identify specific characteristics of UML class diagrams, such as layout, color, and stereotype usage that are most effective for supporting a given task. Results indicate subjects have a variation in the eye movements (i.e., how the subjects navigate the diagram) depending on their UML expertise and software-design ability to solve the given task. Layouts with additional semantic information about the design were found to be most effective and the use of class stereotypes seems to play a substantial role in comprehension of these diagrams. |
| Eye-tracking equipment is used to assess how well a subject comprehends UML class diagrams. The results of a study are presented in which eye movements are captured in a non-obtrusive manner as users performed various comprehension tasks on UML class diagrams. The goal of the study is to identify specific characteristics of UML class diagrams, such as layout, color, and stereotype usage that are most effective for supporting a given task. Results indicate subjects have a variation in the eye movements (i.e., how the subjects navigate the diagram) depending on their UML expertise and software-design ability to solve the given task. Layouts with additional semantic information about the design were found to be most effective and the use of class stereotypes seems to play a substantial role in comprehension of these diagrams. |
| 2006 |
| Intensional views and relations have been proposed as a way of actively documenting high-level structural regularities in the source code of a software system. By checking conformance of these intensional views and relations against the source code, they supposedly facilitate a variety of software maintenance and evolution tasks. In this paper, by performing a case study on three di erent versions of the SmallWiki application, we critically analyze in how far the model of intensional views and its current generation of tools provide support for co-evolving high-level design and source code of a software system. |
| This article discusses whether using warnings generated by the GNU C++ compiler can be used effectively to identify source code files that are likely to be error prone. We analyze five industrial projects written in C++ and belonging to the telecommunication domain. We find a significant positive correlation between the number of compiler warnings and the number of source files changes. We use such correlation to conclude that compiler warnings may be used as an indicator for the presence of software defects in source code. The result of this research is useful for finding defect-prone modules in newer projects, which lack change history. Keywords Compiler warnings . Revision numbers . Software defect prediction . Bootstrap . Meta-analysis |
| Numerous quality rules have been proposed in the literature. These rules define the ``best practices'' for designing and to implementing flaw-free object-oriented program. Unfortunately, due to the particular nature of these rules, there are no existent tools that can really take advantage of them to improve the quality in object-oriented development. In this paper, we propose an approach for detecting violations of quality rules in object-oriented programs. We suggest modeling these rules using fuzzy rule-based systems and apply them on source code. |
| Software architectures must frequently evolve to cope with changing requirements, and this evolution often implies integrating nwe concerns. Unfortunately, existing architecture description languages provide little or not support for this kind of evolution. The software architect must modify the architetcure manually, which risks introducing inconsistencies. In previous work, we have proposed the TranSAT framework, which provides a pattern construct for describing new concerns and their integration into an existing architecture. As the interaction between the new concern and the existing architecture may be complex, it is essential that the framework ensures the coherence of the resulting architecture. In this paper, we introduce a language for specifying patterns and verifications that ensure that the concern represented by a pattern can be safely integrated into an existing architecture. The verifications comprise static verifications that check coherence properties before the architecture is modified and dynamic verifications that focus on the parts of the architecture that are affected by the pattern. As a result of these verifications, patterns can be provided as a commodity, such that a software architect can confidently apply a pattern obtained from a third-party developer. |
| De nombreux champs applicatifs n\'ecessitent la maise en oeuvre de relations d\'ecrivant les sp\'ecificit\'es du lien entre un tout et ses parties. Nous nous appuyons sur diff\'erents travaux dans le domaine de la repr\'esentation des connaissances et de la mod\'elisation en g\'enie logiciel, pour pr\'esenter l'int\'egration de diverses s\'emantiques de la relation Tout-Partie dans le syst\`eme de repr\'esentation de connaissances par objets AROM. Nous pr\'esentons les diff\'erentes s\'emantiques retenues et leur op\'erationnalisation puis les illustrons \`a travers un exemple. |
| When analyzing the evolution history of a software project, we wish to develop results that generalize across projects. One approach is to analyze design patterns, permitting characteristics of the evolution to be associated with patterns, instead of source code. Traditional design patterns are generally not amenable to reliable automatic extraction from source code, yet automation is crucial for scalable evolution analysis. Instead, we analyze ``micro pattern" evolution; patterns whose abstraction level is closer to source code, and designed to be automatically extractable from Java source code or bytecode. We perform micro-pattern evolution analysis on three open source projects, ArgoUML, Columba, and jEdit to identify micro pattern frequencies, common kinds of pattern evolution, and bug-prone patterns. In all analyzed projects, we found that the micro patterns of Java classes do not change often. Common bug-prone pattern evolution kinds are 'Pool $\rightarrow$ Pool', 'Implementor $\rightarrow$ NONE', and 'Sampler $\rightarrow$ Sampler'. Among all pattern evolution kinds, 'Box', 'CompoundBox', 'Pool', 'CommonState', and 'Outline' micro patterns have high bug rates, but they have low frequencies and a small number of changes. The pattern evolution kinds that are bug-prone are somewhat similar across projects. The bug-prone pattern evolution kinds of two different periods of the same project are almost identical. |
| Object-oriented legacy systems are hard to maintain because they are hard to understand. One of the main understanding problems is revealed by the so-called "yo-yo effect" that appears when a developer or maintainer wants to track a polymorphic method call. At least part of this understanding problem is due to the dual nature of the inheritance relation i.e., the fact that it can be used both as a code and/or as an interface reuse mechanism. Unfortunately, in order to find out the original intention for a particular hierarchy it is not enough to look at the hierarchy itself; rather than that, an in-depth analysis of the hierarchy’s clients is required. In this paper we introduce a new metrics-based approach that helps us characterize the extent to which a base class was intended for interface reuse, by analyzing how clients use the interface of that base class. The idea of the approach is to quantify the extent to which clients treat uniformly the instances of the descendants of the base class, when invoking methods belonging to this common interface. We have evaluated our approach on two medium-sized case studies and we have found that the approach does indeed help to characterize the nature of a base class with respect to interface reuse. Additionally, the approach can be used to detect some interesting patterns in the way clients actually use the descendants through the interface of the base class. |
| Design defects are similar to design patterns, which are today largely used: design patterns propose ``good'' solutions to recurring design problems in object-oriented architectures, whereas design defects are ``bad'' solutions. However, unlike design patterns, design defects have not yet been widely studied and are based essentially on textual descriptions prone to interpretation. The lack of precise and structured representation of design defects hinders the efficient detection and correction of these defects. We propose a methodology to represent design defects based on a meta-model using a taxonomy of defects. We apply and validate this methodology on a set of design defects such as the Blob and the Swiss Army Knife. |
| Mining software repositories is an important activity during software evolution, as the extracted data is used to support a variety of software maintenance tasks. The key information extracted from these repositories gives a picture of the changes on the software system. To have a complete picture, tailored to the needs of the developer, the extracted data needs to be filtered, aggregated, and presented to the users. In this paper we propose a new visualization for such data, which relies on an existing software visualization front-end, SourceViewer3D (sv3D). The new visualization allows users to define multiple views of the change history data, each view helps answer a set of questions relevant to specific maintenance tasks. Data can be viewed at different granularity (e.g., file, line of text, method, class) and comprehensive views can be defined, which display to the user multiple data types at the same time. Complex questions and tasks can be solved with the aid of such views. |
| La maintenance s’\'el\`eve \`a 50% du co\^ut total du cycle de d\'eveloppement d’un logiciel. Lors de la maintenance les ing\'enieurs passent plus de 50% de leur temps \`a comprendre le programme avant de proc\'eder aux changements. Pour comprendre un programme orient\'e objet, les ing\'enieurs doivent utiliser des techniques de r\'etro-ing\'enierie car la documentation est souvent incompl\`ete ou obsol\`ete. Le langage cible le plus utilis\'e pour la r\'etro-ing\'enierie des programmes orient\'es objet est UML. UML (Unified Modeling Language) est un langage graphique de mod\'elisation de programmes orient\'es objet. C’est un standard de l’OMG (Object Management Group) et il est \'enorm\'ement utilis\'e dans l’industrie. Il propose de nombreuses notations diff\'erentes permettant d’observer diff\'erentes composantes d’un programme, comme sa structure statique, les interactions entre les diff\'erents objets ou encore un cas d’utilisation. Beaucoup de travaux existent sur la r\'etro-ing\'enierie de la structure statique des logiciels. Par exemple [7] permet de visualiser un syst\`eme \`a l’aide de m\'etriques, tandis que [2] compare les diagrammes de classes UML obtenus lors de la conception d’un logiciel avec les diagrammes de classes obtenus lors de la r\'etro-ing\'enierie du logiciel produit. Au contraire, il y a peu de travaux concernant la r\'etro-ing\'enierie des mod\`eles dynamiques, bien qu’UML inclut des notations pour sp\'ecifier le comportement dynamique des programmes, comme les diagrammes de s\'equence ou les diagrammes d’\'etats. Les mod\`eles dynamiques de programmes sont aussi importants que les mod\`eles statiques car ils permettent aux ing\'enieurs d’identifier des interactions complexes entre les objets et d’enlever l’ambigu\"{\i}t\'e de l’envoi de message lorsque l’h\'eritage, la d\'el\'egation, le polymorphisme, les liens dynamiques, la r\'eflexion sont utilis\'es de mani\`ere intensive. Nous proposons donc d’aller plus loin, en combinant les travaux de [1] et de [12] pour synth\'etiser des diagrammes de s\'equence et des diagrammes d’\'etats afin de proc\'eder \`a des analyses de haut niveau d’un programme. Cette \'etude \'etablit un \'etat de l’art du sujet et met en \'evidence les points peu trait\'es par la litt\'erature et ceux auxquels nous nous int\'eresserons lors du stage. La section 1 s’int\'eresse aux travaux concernant la r\'etro-ing\'enierie de mani\`ere g\'en\'erale et introduit notre approche. Puis la section 2 consid\`ere les travaux traitant de la g\'en\'eration de diagrammes de s\'equence \`a partir du code. Enfin la section 3 aborde les travaux traitant de la g\'en\'eration de diagrammes d’\'etats \`a partir de diagrammes de s\'equence. |
| CVS is a version control system, an important component of Source Configuration Management (SCM). Using it, you can record the history of sources files, and documents. It fills a similar role to the free software RCS, PRCS, and Aegis packages. |
| The goal of the Subversion project is to build a version control system that is a compelling replacement for CVS in the open source community. The software is released under an Apache/BSD-style open source license. |
| Program comprehension is a vital software engineering and maintenance activity. It is necessary to facilitate reuse, inspection, maintenance, reverse engineering, reengineering, migration, and extension of existing software systems. ICPC provides an opportunity for researchers and industry practitioners to present and discuss both the state-of-the art and the state-of-the-practice in the general area of program comprehension. |
| 2005 |
| This book captures the main scientific contributions of Victor R. Basili, who has significantly shaped the field of empirical software engineering from its very start. He was the first to claim that software engineering needed to follow the model of other physical sciences and develop an experimental paradigm. By working on this postulate, he developed concepts that today are well known and widely used, including the Goal-Question-Metric method, the Quality-Improvement paradigm, and the Experience Factory. He is one of the few software pioneers who can aver that their research results are not just scientifically acclaimed but are also used as industry standards. On the occasion of his 65{th} birthday, celebrated with a symposium in his honor at the International Conference on Software Engineering in St. Louis, MO, USA in May 2005, Barry Boehm, Hans Dieter Rombach, and Marvin V. Zelkowitz, each a long-time collaborator of Victor R. Basili, selected the 20 most important research papers of their friend, and arranged these according to subject field. They then invited renowned researchers to write topical introductions. The result is this commented collection of timeless cornerstones of software engineering, hitherto available only in scattered publications. |
| In this article, we describe a taxonomy of generic graph related tasks along with computer-based evaluation designed to assess the readability of two representations of graphs: matrix-based representations and node-link diagrams. This evaluation encompasses seven generic tasks and leads to insightful recommandations for the representation of graphs according to their size and density. Typically, we show that when graphs are bigger than twenty vertices, the matrix-based visualisation outperforms node-link diagrams on most tasks. Only path finding is consistently in favor of node-link diagrams throughout the evaluation. |
| For the maintenance of software systems, developers have to completely understand the existing system. The usage of design patterns leads to benefits for new and young developers by enabling them to reuse the knowledge of their experienced colleagues. Design patterns can support a faster and better understanding of software systems. There are different approaches for supporting pattern recognition in existing systems by tools. They are evaluated by the Information Retrieval criteria precision and recall. An automated search based on structures has a highly positive influence on the manual validation of the results by developers. This validation of graphical structures is the most intuitive technique. In this paper a new approach for automated pattern search based on minimal key structures is presented. It is able to detect all patterns described by the GOF [15]. This approach is based on positive and negative search criteria for structures and is prototypically implemented using Rational Rose and Together. |
| Graphic visuals derived from reverse engineered source code have long been recognized for their impact on improving the comprehensibility of structural and behavioral aspects of large software systems and their source code. A number of visualization techniques, primarily graph-based, do not scale. Some other proposed techniques based on 3D metaphors tend to obscure important structural relationships in the program. Multiple views displayed in overlapping windows are suggested as a possible solution, which more often than not results in problems of information overload and cognitive discontinuity. In this paper, we first present a comprehensive survey of related work in program comprehension and software visualization, and follow it up with a detailed description of our research which uses program slicing for deriving program structure-based attributes and 3D-metaball-based rendering techniques to help visualization-based analysis of source code structure. Metaballs, a 3D modeling technique, has already found extensive use for representing complex organic shapes and structural relationships in biology and chemistry. We have developed a metaball software visualization system in Java3D, named MetaViz. As proof of concept, using MetaViz, we demonstrate the creation of 3D visuals that are intuitively comprehensible and communicate information about relative component complexity and coupling among components and therefore enhance comprehension of the program structure. |
| Software systems continuously evolve. CVS record almost all of the changes the system parts undergo. Hence, CVS repositories contain a great deal of information about software artifact evolution. Software artifacts of a system can evolve following similar evolution patterns as well as very different ones. A peculiar kind of similarity in evolution is the one among two or more artifacts having changed almost at the same times for a certain number of changes. We name these co-changing artifacts. Co-changing artifacts are relevant because cochanges can be inducted by not trivial dependencies among system parts. In this paper, we propose a definition of co-changes suitable of practical application. We assess the challenges arising in detection of groups of co-changing software parts, and we present a robust approach, based on Dynamic Time Warping, to detect groups of co-changing files in CVS repositories. We also report and discuss the results of a preliminary application of the approach to the Mozilla CVS repository. |
| The usefulness of design patterns in forward engineering is already well-known and several tools provide support for their application in the development of software systems. While the role of design patterns in reverse engineering is still argued primarily due to their informal definition which leads to various possible implementations of each pattern. One of the most discussed aspects related to design patterns is about the need of their formalization according to the drawbacks this can represent. Formalization leads to the identification of the so-called sub-patterns, which are the recurring fundamental elements design patterns are composed of. In this paper we analyze the role sub-patterns play in two reverse engineering tools: FUJABA and SPQR. Attention is focused on how sub-patterns are exploited to define and to detect design patterns. To emphasize the similarities and differences between the two approaches, the Composite Design Pattern is considered as example. |
| A key difficulty in the maintenance and evolution of complex software systems is to recognize and understand the implicit dependencies that define contracts that must be respected by changes to the software. Formal Concept Analysis is a well-established technique for identifying groups of elements with common sets of properties. We have successfully applied FCA to complex software systems in order to automatically discover a variety of different kinds of implicit, recurring sets of dependencies amongst design artifacts. In this paper we describe our approach, outline three case studies, and draw various lessons from our experiences. In particular, we discuss how our approach is applied iteratively in order to draw the maximum benefit offered by FCA. |
| Design patterns are a powerful means to understand, model and implement OO micro-architecures. Their composition leads to architectures with interesting properties in terms of variability and evolutivity. However they are difficult to track, modularize and reuse as there elements tend to vanish in the code. We experiment aspect oriented programming as a modular technology to give new insights on the expression of design patterns. We first take a look at singular features of some design patterns to see how aspects deal with their representation. Then we study some cases of composition in the JHotDraw framework, where we analyze various interactions and the way aspects help to express them. |
| Representing programs as text strings makes programming harder then it has to be. The source text of a program is far removed from its behavior. Bridging this conceptual gulf is what makes programming so inhumanly difficult -- we are not compilers. Subtext is a new medium in which the representation of a program is the same thing as its execution. Like a spreadsheet, a program is visible and alive, constantly executing even as it is edited. Program edits are coherent semantic transformations. The essence of this new medium is copying. Programs are constructed by copying and executed by copy flow: the projection of changes through copies. The simple idea of copying develops into a rich theory of higher-order continual copying of trees. Notably absent are symbolic names, the workhorse of textual notation, replaced by immediately-bound explicit relationships. Subtext unifies traditionally distinct programming tools and concepts, and enables some novel ones. Ancestral structures are a new primitive data type that combines the features of lists and records, along with unproblematic multiple inheritance. Adaptive conditionals use first-class program edits to dynamically adapt behavior. A prototype implementation shows promise, but calls for much further research. Subtext suggests that we can make programming radically easier, if we are willing to be radical. |
| The wide acceptance of the “Design Patterns” has encouraged experts in other software domains to formulate their experience into pattern format hoping to make it readily reused by developers. We now have numerous pattern collections covering all aspects of software development from analysis to deployment and refactoring. But developers can be overwhelmed by this large number and the lack of coordination and in consistencies among them. These patterns have many similarities and redundancies which may contribute to misunderstanding and wrong reuse. Some research has proposed standards to writing patterns but they were rarely used because each pattern author prefers to use their own creativity which is often a good thing. We propose another approach to address this problem. In each specific software domain, we collect and pre-process existing patterns by defining, detecting and removing some kinds of redundancies between them. The result is a smaller collection of patterns from different sources that have fewer redundancies which reduces confusion and promotes the proper reuse. |
| Design patterns offer flexible solutions to common problems in software development. Recent studies have shown that several design patterns involve crosscutting concerns. Unfortunately, object-oriented (OO) abstractions are often not able to modularize those crosscutting concerns, which in turn decrease the system reusability and maintainability. Hence, it is important verifying whether aspect-oriented approaches support improved modularization of crosscutting concerns relative to design patterns. Ideally, quantitative studies should be performed to compare OO and aspect-oriented implementations of classical patterns with respect to important software engineering attributes, such as coupling and cohesion. This paper presents a quantitative study that compares aspect-based and OO solutions for the 23 Gang-of-Four patterns. We have used stringent software engineering attributes as the assessment criteria. We have found that most aspect-oriented solutions improve separation of pattern-related concerns, although only 4 aspect-oriented implementations have exhibited significant reuse. |
| In this paper, we describe the use of visualization tools in the context of constraint programming. Specifically, we focus on the visualization of dynamic graphs using adjacency matrices, and show that visualization tools can provide valuable insights into the behavior of constraint-based solvers. This contributes to better understanding solver dynamics for teaching purposes, and can enhance the analysis and the optimization of constraint-based programs in connection with known and difficult research problems. |
| Micro patterns are similar to \emph{design patterns}, except that micro patterns are stand at a lower, closer to the implementation, level of abstraction. Micro patterns are also unique in that they are mechanically recognizable, since each such pattern can be expressed as a formal condition on the structure of a class.This paper presents a catalog of 27 micro-patterns defined on Java classes and interfaces. The catalog captures a wide spectrum of common programming practices, including a particular and (intentionally restricted) use of inheritance, immutability, data management and wrapping, restricted creation, and emulation of procedural-, modular-, and even functional- programming paradigms with object oriented constructs. Together, the patterns present a set of prototypes after which a large portion of all Java classes and interfaces are modeled. We provide empirical indication that this portion is as high as 75\%. A statistical analysis of occurrences of micro patterns in a large software corpus, spanning some 70,000 Java classes drawn from a rich set of application domains, shows, with high confidence level that the use of these patterns is not random. These results indicate consciousness and discernible design decisions, which are sustained in the software evolution. With high confidence level, we can also show that the use of these patterns is tied to the specification, or the purpose, that the software realizes.The \emph{traceability}, \emph{abundance} and the \emph{statistical significance} of micro pattern occurrence raise the hope of using the classification of software into these patterns for a more founded appreciation of its design and code quality. |
| Last year at OOPSLA we presented a methodology, vertical profiling, for understanding the performance of object-oriented programs. The key insight behind this methodology is that modern programs run on top of many layers (virtual machine, middleware, etc) and thus we need to collect and combine information from all layers in order to understand system performance. Although our methodology was able to explain previously unexplained performance phenomena, it was extremely labor intensive. In this paper we describe and evaluate techniques for automating two significant activities of vertical profiling: trace alignment and correlation. Trace alignment aligns traces obtained from separate runs so that one can reason across the traces. We are not aware of any prior approach that effectively and automatically aligns traces. Correlation sifts through hundreds of metrics to find ones that have a bearing on a performance anomaly of interest. In prior work we found that statistical correlation was only sometimes effective. We have identified highly-effective approaches for both activities.For aligning traces we explore dynamic time warping, and for correlation we explore eight correlators based on statistical correlation, distance measures, and piecewise linear segmentation. Although we explore these activities in the context of vertical profiling, both activities are widely applicable in the performance analysis area. |
| In order to make frameworks easier to use we need to better understand the difficulties that programmers have with them. The questions that programmers ask give clues to the quality of design, documentation, and programmer practice. We describe the method and results of a study on the Java Swing framework. We collected and analyzed a sample of 300 newsgroup questions asked about two Swing components (JButton and JTree), and classified the questions according to the design features of the components. This process revealed key insights that can improve a framework's design, its tutorials, and programmer practice. |
| Object-oriented frameworks are a powerful form of reuse but they can be difficult to understand and reuse correctly. Over the last decade a large range of candidate documentation techniques have been proposed to address this difficulty. There is little research, however, to identify the specific problems that arise during framework reuse and to evaluate documentation techniques in terms of these problems. This paper reports on a long-term investigation that firstly identifies four fundamental problems of framework reuse: mapping, understanding functionality, understanding interactions and understanding the framework architecture. It then describes two forms of documentation specifically developed to address the mapping, interaction and functionality problems namely a pattern language and a set of micro architectures. An in-depth, qualitative analysis of these two documentation types evaluates the key strengths and weaknesses of their support for framework understanding, whilst confirming the significance of the four problem categories. |
| We propose an approach for complex software analysis based on visualization. Our work is motivated by the fact that in spite of years of research and practice, software development and maintenance are still time and resource consuming, and high-risk activities. The most important reason in our opinion is the complexity of many phenomena related to software, such as its evolution and its reliability. In fact, there is very little theory explaining them. Today, we have a unique opportunity to empirically study these phenomena, thanks to large sets of software data available through open-source programs and open repositories. Automatic analysis techniques, such as statistics and machine learning, are usually limited when studying phenomena with unknown or poorlyunderstood influence factors. We claim that hybrid techniques that combine automatic analysis with human expertise through visualization are excellent alternatives to them. In this paper, we propose a visualization framework that supports quality analysis of large-scale software systems. We circumvent the problem of size by exploiting perception capabilities of the human visual system. |
| We propose an aspect-oriented programming (AOP) language called Aspectual Caml based on a strongly-typed functional language Objective Caml with two AOP mechanisms similar to those in AspectJ language. This paper describes the design and implementation issues of those AOP mechanisms that give us insights into the interaction between AOP features and common features in strongly-typed functional languages such as type inference, polymorphic types and curried functions. We implemented a prototype compiler of the language and used the language for separating crosscutting concerns in application programs, including for separating descriptions of a type system from compiler descriptions. |
| Design defects, antipatterns, code smells are software defects at the architectural level that must be detected and corrected to improve software quality. Automatic detection and correction of these software architectural defects, which suffer of a lack of tools, are important to ease the maintenance of object-oriented architectures and thus to reduce the cost of maintenance. A clear understanding of the different types of software architectural defects and a classification of these defects is necessary before proposing any techniques related to their detection or correction. We introduce a first classification and summarise existing techniques. Then, we introduce some challenges that our community must meet. |
| Design patterns propose “good” solutions to recurring design problems in object-oriented architectures. Design patterns have been quickly adopted by the Software Engineering community and are now widely spread. We define design pattern defects as occurring errors in the design of a software that come from the absence or the bad use of design patterns. Design pattern defects are software defects at the architectural level that must be detected and corrected to improve software quality. Automatic detection and correction of these software architectural defects, which suffer of a lack of tools, are important to improve object-oriented architectures and, thus, to ease maintenance. We propose a first taxonomy of design pattern defects and presents techniques and tools to detect these defects in source code. |
| In this paper, we present a collection of aspect-oriented refactorings covering both the extraction of aspects from objectoriented legacy code and the subsequent tidying up of the resulting aspects. In some cases, this tidying up entails the replacement of the original implementation with a different, centralized design, made possible by modularization. The collection of refactorings includes the extraction of common code in various aspects into abstract superaspects. We review the traditional object-oriented code smells in the light of aspectorientation and propose some new smells for the detection of crosscutting concerns. In addition, we propose a new code smell that is specific to aspects. |
| Refactoring can have a direct influence on reducing the cost of software maintenance through changing the internal structure of the source-code to improve the overall design that helps the present and future programmers evolve and understand a system. Bad smells are a set of design problems with refactoring identified as a solution. Locating these bad smells has been described as more a human intuition than an exact science. This paper addresses the issue of identifying the characteristics of a bad smell through the use of a set of software metrics. Then by using a pre-defined set of interpretation rules to interpret the software metric results applied to Java source-code, the software engineer can be provided with significant guidance as to the location of bad smells. These issues are addressed in a number of ways. Firstly, a precise definition of bad smells is given from the informal descriptions given by the originators Fowler and Beck. The characteristics of the bad smells have been used to define a set of measurements and interpretation rules for a subset of the bad smells. A prototype tool has been implemented to enable the evaluation of the interpretation rules in two case studies. |
| Integrated development environments have been designed and engineered to display structural information about the source code of large systems. When a development task lines up with the structure of the system, the tools in these environments do a great job of supporting developers in their work. Unfortunately, many development tasks do not have this characteristic. Instead, they involve changes that are scattered across the source code and various other kinds of artifacts, including bug reports and documentation. Today's development environments provide little support for working with scattered pieces of a system, and as a result, are not adequately supporting the ways in which developers work on the system. Fortunately, many development tasks do have a structure. This structure emerges from a developer's actions when changing the system. In this paper, we describe how the structure of many tasks crosscuts system artifacts, and how by capturing that structure, we can make it as easy for developers to work on changes scattered across the system's structure as it is to work on changes that line up with the system’s structure. |
| Data warehouses are large data repositories integrating data from several sources that support decision making. Although, traditionally, data warehouses have been designed using the ‘well-known’ star schema, some design methodologies have come into existence in recent times. These new methodologies have not only focused on logical design: they also propose performing a conceptual modeling using UML. At present, it is widely accepted that modeling using packages simplifies the management and understanding of the designs.Until now, however, this statement has not been empirically proved in the data warehouse field. In this paper, we present an empirical study whose aim is to check whether using packages in designing data warehouses makes them more understandable. |
| This paper proposes a framework for describing, comparing and understanding visualization tools that provide awareness of human activities in software development. The framework has several purposes -- it can act as a formative evaluation mechanism for tool designers; as an assessment tool for potential tool users; and as a comparison tool so that tool researchers can compare and understand the differences between various tools and identify potential new research areas. We use this framework to structure a survey of visualization tools for activity awareness in software development. Based on this survey we suggest directions for future research. |
| UML class diagrams are helpful for understanding the structure of a software system. Algorithms and tools have been developed to generate UML class diagrams automatically for program understanding purposes. However, many tools often ignore perceptual factors in the layout of these diagrams. Therefore, users still have to spend much time and effort rearranging boxes and lines to make the diagram understandable. This paper presents key criteria and guidelines for the effective layout of UML class diagrams from the perspective of perceptual theories. Two UML tools have been analyzed and evaluated to illustrate how the criteria can be applied to improve the readability of class diagrams. |
| Software decay is a phenomenon that plagues all software systems in general, and object oriented systems in particular. Existing approaches fail to effectively address this problem because of their informal nature. We overcome the main deficiencies of other approaches, with the help of two innovations: encapsulation of correlated structural anomalies and machine processable patterns for restructuring. Our method allows unprecedented levels of automation in the decision making process involved in restructuring large object oriented systems. |
| Mobile devices which can capture and view pictures are becoming increasingly common in our life. The limitation of these small-form-factor devices makes the user experience of image browsing quite different from that on desktop PCs. In this paper, we first present a user study on how users interact with a mobile image browser with basic functions. We found that on small displays, users tend to use more zooming and scrolling actions in order to view interesting regions in detail. From this fact, we designed a new method to detect user interest maps and extract user attention objects from the image browsing log. This approach is more efficient than image-analysis based methods and can better represent users' actual interest. A smart image viewer was then developed based on user interest analysis. A second experiment was carried out to study how users behave with such a viewer. Experimental results demonstrate that the new smart features can improve the browsing efficiency and are a good compliment to traditional image browsers. |
| In the context of the workshop's discussion on a general framwork for empirical studies on reverse engineering, this paper stresses the need for an ontology of facotors influencing the application of reverse-engineering techniques. Through an integration of existing work, this paper proposes a tentative ontology. This work provides the first step towards an ontology facilitating communication of experimental designs and the resulting identification of relationships between experimental variables. |
| Program comprehension is a fundamental requirement for all but the most trivial maintenance activities. Previous research has demonstrated key principles for improving comprehension. Among others, these consist of the introduction of beacons as indexes into knowledge, and the chunking of low-level structures into higher-level abstractions. These principles are naturally reflected in the reverse engineering pattern Refactor to Understand, which uses incremental renaming and extracting of program elements as the means to decipher cryptic code. In this paper, we discuss a controlled experiment to explore differences in program comprehension between the application of Refactor to Understand and the traditional Read to Understand pattern. Our results support added value of Refactor to Understand regarding specific aspects of program comprehension and specific types of source code. These findings illustrate the need for further experiments to provide clear guidelines on the application of refactorings for improving program comprehension. |
| 2004 |
| Program comprehension has been researched extensively ever since software systems became complex and longer than a few hundreds code lines. At the same time, the way in which people comprehend visual models of software systems has received much less attention. This paper focuses on the comprehension of UML diagrams. During the research presented in this paper, data was gathered from the work of two groups. Group 1 consisted of 13 senior computer science students who worked in five teams. The students were asked to trace and analyze the process by which they retrieved information from UML diagrams of a given system. Group 2 consisted of 42 senior computer science students who were requested to complete a questionnaire in which they were asked to rank different types of UML diagrams according to their importance. The section on data analysis discusses strategies adopted by the novices in their attempt to reveal the meaning of a set of UML diagrams, as well as their attitudes towards the different diagrams. One of the interesting observations is that although each team had its own preferences with respect to the usefulness of each specific type of diagrams, the overall use of each diagram type is very similar across the teams. |
| Open source projects have resulted in numerous high-quality, widely used products. Understanding the defect-handling strategies such projects employ can help us use the publicly accessible defect data from these projects to provide valuable quality-improvement feedback and to better understand the defect characteristics for a wider variety of software products. We conducted a survey to understand defect handling in selected open source projects and compared the particular approaches taken in different projects. We focused on defect handling instead of the broader quality assurance activities other researchers have previously reported. Our results provided quantitative evidence about the current practice of defect handling in an important subset of open source projects. |
| Data analysis should always start by (literally) looking at the data. An efficient way to do this is to use box and whisker plots, which, for short, are called box plots. All figures in this column are box plots and Figures 2 to 4 are box plots for real data sets. In this column we will explain how to construct them and how they can help you to learn more about your data. |
| Class or object interactions form the basis of object-oriented design. However, design pattern interaction can be viewed as a higher level of abstraction for system design. The typical interactions among the patterns are a pattern uses another pattern to solve one of its sub problem, and a pattern combines with another pattern for completeness. This paper proposes a mechanism called pattern hybridization for breeding new patterns from the pattern interactions which solve more specialized problems than the original patterns do. Rules for generating hybrid patterns are also mentioned in the paper. This paper also views design pattern interactions for system design. |
| Software "design patterns?` seek to package proven solutions to design problems in a form that makes it possible to find, adapt, and reuse them. A common claim is that a design based on properly applied patterns will have fewer defects than more ad hoc solutions. This case study analyzes the weekly evolution and maintenance of a large commercial product (C++, 500,000 LOC) over three years, comparing defect rates for classes that participated in selected design patterns to the code at large. We found that there are significant differences in defect rates among the patterns, ranging from 63 percent to 154 percent of the average rate. We developed a new set of tools able to extract design pattern information at a rate of 3 imes 10^6 lines of code per hour, with relatively high precision. Based on a qualitative analysis of the code and the nature of the patterns, we conclude that the Observer and Singleton patterns are correlated with larger code structures and, so, can serve as indicators of code that requires special attention. Conversely, code designed with the Factory pattern is more compact and possibly less closely coupled and, consequently, has lower defect numbers. The Template Method pattern was used in both simple and complex situations, leading to no clear tendency. |
| Dynamic impact analysis based on whole path profiling of method calls and returns has been shown to provide more useful predictions of software change impacts than method-level static slicing and to avoid the overhead of expensive dependency analysis needed for dynamic slicing-based impact analysis. This paper presents the design, implementation, and evaluation of an online approach to dynamic impact analysis as an extension to the DynamoRIO binary code modification system and to the Jikes Research Virtual Machine. Storage and postmortem analysis of program traces, even compressed, are avoided. |
| Java 1.5 will include a type system (called JSR-14) that supports parametric polymorphism, or generic classes. This will bring many benefits to Java programmers, not least because current Java practice makes heavy use of logically-generic classes, including container classes. Translation of Java source code into semantically equivalent JSR-14 source code requires two steps: parameterization (adding type parameters to class definitions) and instantiation (adding the type arguments at each use of a parameterized class). Parameterization need be done only once for a class, whereas instantiation must be performed for each client, of which there are potentially many more. Therefore, this work focuses on the instantiation problem. We present a technique to determine sound and precise JSR-14 types at each use of a class for which a generic type specification is available. Our approach uses a precise and context-sensitive pointer analysis to determine possible types at allocation sites, and a set-constraint-based analysis (that incorporates guarded, or conditional, constraints) to choose consistent types for both allocation and declaration sites. The technique handles all features of the JSR-14 type system, notably the raw types that provide backward compatibility. We have implemented our analysis in a tool that automatically inserts type parameters into Java code, and we report its performance when applied to a number of real-world Java programs. |
| In this paper, we introduce VISEXP: a new visualization tool designed to explore relations between constraints and variables in constraint problems. This tool uses the explanation network built throughout computation. We show that VISEXP is able to provide much more information about how search is performed than classical representations. Moreover, we illustrate the animation feature of VISEXP that provides invaluable tools for visualization and therefore analysis of the dynamics of constraint solvers. |
| The main purpose of this paper is to generate discussions which may improve how we conduct empirical software engineering studies. Our position is that statistical hypothesis testing plays a too large role in empirical software engineering studies. The problems of applying statistical hypothesis testing in empirical software engineering studies is illustrated by the finding: Only 3 out of the 47 studies in Journal of Empirical Software Engineering which applied statistical hypothesis testing, were able to base their statistical testing on well-defined populations and random samples from those populations. The frequent use of statistical hypothesis testing may also have had unwanted consequences on the study designs, e.g., it may have contributed to a too low focus on theory building. We outline several steps we believe are useful for a change in focus from ``generalizing from a random sample to a larger population" to ``generalizing across populations through theory-building" |
| TOBIAS is a combinatorial testing tool, aimed at the production of large test suites. In this paper, TOBIAS is applied to conformance tests for model-based specifications (expressed with assertions, pre and post-conditions) and associated implementations. The tool takes advantage of the executable character of VDM or JML assertions which provide an oracle for the testing process. Executing large test suites may require a lot of time. This paper shows how assertions can be exploited at generation time to filter the set of test cases, and at execution time to detect inconclusive test cases. |
| In order to support the maintenance of an object-oriented software system, the quality of its design must be evaluated using adequate quantification means. In spite of the current extensive use of metrics, if used in isolation metrics are oftentimes too fine grained to quantify comprehensively an investigated design aspect (e.g., distribution of system’s intelligence among classes). To help developers and maintainers detect and localize design problems in a system, we propose a novel mechanism – called detection strategy – for formulating metrics-based rules that capture deviations from good design principles and heuristics. Using detection strategies an engineer can directly localize classes or methods affected by a particular design flaw (e.g., God Class), rather than having to infer the real design problem from a large set of abnormal metric values. We have defined such detection strategies for capturing around ten important flaws of object-oriented design found in the literature and validated the approach experimentally on multiple large-scale case-studies. |
| As systems evolve and their structure decays, maintainers need accurate and automatic identification of the design problems. Current approaches for automatic detection of design problems are not accurate enough because they analyze only a single version of a system and consequently they miss essential information as design problems appear and evolve over time. Our approach is to use the historical information of the suspected flawed structure to increase the accuracy of the automatic problem detection. Our means is to define measurements which summarize how persistent the problem was and how much maintenance effort was spent on the suspected structure. We apply our approach on a large scale case study and show how it improves the accuracy of the detection of god classes and data classes, and additionally how it adds valuable semantical information about the evolution of flawed design structures. |
| This paper presents a hierarchy of dynamic views that is constructed using tools that analyze program execution traces. At the highest-level of abstraction are the feature-interaction and implementation views, which track the inter-feature dependencies as well as the classes that implement these features. At the middle-level is the class-interaction view, which is an abstract view of the object-interactions. The object-interaction view is the base view for all the views, and captures the low-level runtime interactions between objects. Two case studies are used to demonstrate the effectiveness of our work. |
| Characterizing the location and extent of a viewer's interest, in terms of eye movement recordings, informs a range of investigations in image and scene viewing. We present an automatic data-driven method for accomplishing this, which clusters visual point-of-regard (POR) measurements into gazes and regions-of-interest using the mean shift procedure. Clusters produced using this method form a structured representation of viewer interest, and at the same time are replicable and not heavily influenced by noise or outliers. Thus, they are useful in answering fine-grained questions about where and how a viewer examined an image. |
| Software inevitably changes. As a consequence, we observe the phenomenon referred to as ``software entropy" or ``software decay": the software design continually degrades making maintenance and functional extensions overly costly if not impossible. There exist a number of approaches to identify design flaws (problem detection) and to remedy them (refactoring). There is, however, a conceptual gap between these two stages: There is no appropriate support for the automated mapping of design flaws to possible solutions. Here we propose an integrated, quality-driven and tool-supported methodology to support object-oriented software evolution. Our approach is based on the novel concept of ``correction strategies". Correction strategies serve as reference descriptions that enable a human-assisted tool to plan and perform all necessary steps for the safe removal of detected design flaws, with special concern towards the targeted quality goals of the restructuring process. We briefly sketch our tool chain and illustrate our approach with the help of a medium-sized real-world case-study. |
| Web Services promise to allow businesses to adapt rapidly to changes in the business environment and to the needs of customers. However, the rapid introduction of new services paired with the dynamicity of the business environment also leads to undesirable interactions that negatively impact service quality and user satisfaction. In this paper, we propose an approach for modeling such undesirable interactions as feature interactions. As each functional feature ultimately is motivated by non-functional requirements, we make an explicit distinction between functional and non-functional features. We then describe our approach for detecting and resolving feature interactions among Web Services. The approach is based on goal-oriented analysis and scenario modeling. It allows us to reason about feature interactions in terms of goal conflicts and feature deployment. Three case studies illustrate the approach. The paper concludes with a discussion of our findings and an outlook on future research. |
| We apply data mining to version histories in order to guide programmers along related changes: "Programmers who changed these functions also changed\ldots". Given a set of existing changes, such rules (a) suggest and predict likely further changes, (b) show up item coupling that is indetectable by program analysis, and (c) prevent errors due to incomplete changes. After an initial change, our ROSE prototype can correctly predict 26\% of further files to be changed---and 15\% of the precise functions or variables. The topmost three suggestions contain a correct location with a likelihood of 64\%. |
| This paper proposes a comprehensive methodology and instrumentation infrastructure for the reverse-engineering of UML (Unified Modeling Language) sequence diagrams from dynamic analysis. One motivation is of course to help people understand the behavior of systems with no (complete) documentation. However, such reverse-engineered dynamic models can also be used for quality assurance purposes. They can, for example, be compared with design sequence diagrams and the conformance of the implementation to the design can thus be verified. Furthermore, discrepancies can also suggest failures in meeting the specifications. We formally define our approach using metamodels and consistency rules. The instrumentation is based on Aspect-Oriented Programming in order to alleviate the overhead usually associated with source code instrumentation. A case study is discussed to demonstrate the applicability of the approach on a concrete example. |
| Dans cet article, nous pr\'esentons une m\'ethode d'am\'elioration de la qualit\'e focalis\'ee sur le contr\^ole des produits, m\'ethode dite de ``mise en qualit\'e des d\'eveloppements logiciels". Cette m\'ethode prend en compte les sp\'ecificit\'es des langages OO (Java, C++, VB.Net...) et r\'epond particuli\`erement aux besoins actuels des ma\^{\i}trises d'ouvrage. Cette m\'ethode a \'et\'e outill\'ee pour un d\'eploiement totalement automatis\'e \`a la DSIV de la SNCF. Nous pr\'esentons les fondements de cette m\'ethode, la mani\`ere dont elle a \'et\'e d\'eploy\'ee et les premiers r\'esultats concrets qui en d\'ecoulent. |
| Software maintenance and evolution is a considerably understudied area while taking into account its cost effects. This document lists some interesting figures on proportional and absolute maintenance costs, proportions of the main task types, and amount and nature of the existing legacy code. These figures are based on empirical data. Although there has not been much empirical research on this particular area, the magnitude of the maintenance cost effects is clearly identifiable. |
| This paper identifies eight keys to success in applying statistical tools for design of experiments (DOE). Quality managers who grasp these keys will be better able to support use of DOE in their organization. Ultimately this will lead to breakthrough improvements in product quality and process efficiency. |
| 2003 |
| Developers often confuse learning the technology with learning to design with the technology. In this book, senior architects from the Sun Java Center share their cumulative design experience on Java 2 Platform, Enterprise Edition (J2EE) technology. The primary focus of the book is on patterns, best practices, design strategies, and proven solutions using the key J2EE technologies including JavaServer Pages(TM) (JSP(TM)), Servlets, Enterprise JavaBeans(TM) (EJB(TM)), and Java(TM) Message Service (JMS) APIs. The J2EE Pattern Catalog with 21 patterns and numerous strategies is presented to document and promote best practices for these technologies. Core J2EE Patterns, Second Edition offers the following: \begin{itemize} \item J2EE Pattern Catalog with 21 patterns--fully revised and newly documented patterns providing proven solutions for enterprise applications \item Design strategies for the presentation tier, business tier, and integration tier \item Coverage of servlets, JSP, EJB, JMS, and Web Services \item J2EE technology bad practices \item Refactorings to improve existing designs using patterns \item Fully illustrated with UML diagrams \item Extensive sample code for patterns, strategies, and refactorings \end{itemize} |
| This handbook presents the laws that significantly impact software engineering. This book begins with requirements definitions and concludes with maintenance and withdrawl. Along the way, it identifies and discusses existing laws that significantly impact software engineering. Software engineers who wish to reacquaint (or ecquaint) themselves with the basic laws of software engineering and their applicability in an industrial setting. |
| Les \ygg@anglais{design patterns} (ou patron de conception) sont reconnus comme une des bonnes techniques du g\'enie logiciel \`a objets facilitant la conception, la documentation, la maintenance et la r\'etro-conception. Malgr\'e cela, force est de constater que dans les faits, peu d'environnements logiciels sont \`a la fois outill\'es pour inciter l'utilisateur \`a appliquer un catalogue de patterns et pour l'aider \`a am\'eliorer ses programmes en y extrayant automatiquement des micro-architectures correspondant \`a celles de patterns d\'ej\`a r\'epertori\'es. Dans ce m\'emoire nous pr\'esentons un langage de description de patterns (\PDL{}) servant de support \`a un outillage de l'environnement de d\'eveloppement \ygg@product{Visual Age pour Java}. Ce langage, bas\'e sur un m\'eta-mod\`ele, a pour particularit\'es de permettre \`a la fois de manipuler, synth\'etiser et reconna\^{\i}tre dans des programmes existants les patterns dont il a pr\'esid\'e \`a la d\'eclaration. La description du m\'eta-mod\`ele d\'efinissant la s\'emantique de ce langage et des diff\'erentes r\'ealisations logicielles venant le compl\'eter fondent le premier volet de cette th\`ese. Une partie exp\'erimentale pr\'esentant en outre la composante idiomatique et les crit\`eres de d\'etection des patterns \'etudi\'es en constitue le second volet. Ces exp\'erimentations sont l'occasion de discuter des limites de notre approche et de sugg\'erer des \'el\'ements d'am\'elioration pour notamment prendre en charge l'aspect intentionnel des patterns et supporter la reconnaissance de micro-architectures voisines de celles de patterns d\'ej\`a r\'epertori\'es. Enfin, nous g\'en\'eralisons notre exp\'erience afin de donner quelques pistes relatives \`a la faisabilit\'e et \`a l'int\'er\^et d'une automatisation ou semi-automatisation des deux activit\'es duales li\'ees \`a la synth\`ese de code et \`a la d\'etection. |
| The maintenance, reengineering, and evolution of object-oriented software systems has become a vital matter in today's software industry. Although most systems start off in a clean and well-designed state, with time they tend to graduall y decay in quality, unless the systems are reengineered and adapted to the evolving requirements. However, before such legacy software systems can be reengineered and evolved, they must be reverse engineered, i.e., their structure and inner working must b e understood. This is difficult because of several factors, such as the sheer size of the systems, their complexity, their domain specificity, and in general the bad state legacy software systems are in. In this thesis we propose a visual approach to the reverse engineering of object-oriented software systems by means of polymetric views, lightweight visualizations of software enriched with metrics and other types of semantic information about the software, e.g., its age, version, abstractness, location, structure, function, etc. We present and discuss several polymetric views which allow us to understand three different aspects of object-oriented software, namely (1) coarse-grained aspects which allow for the understanding of very large systems, (2) fine -grained aspects which allow for the understanding of classes and class hierarchies, and (3) evolutionary aspects, which enable us to recover and understand the evolution of a software system. The combination of these three types of information can greatl y reduce the time needed to gain an understanding of an object-oriented software system. Based on the application of our polymetric views, we present our reverse engineering methodology which we validated and refined on several occasions in industrial set tings. It allows us to explore and combine these three approaches into one single visual approach to understand software. |
| We present an empirical validation of object-oriented size estimation models. In previous work we proposed object oriented function points (OOFP), an adaptation of the function points approach to object-oriented systems. In a small pilot study, we used the OOFP method to estimate lines of code (LOC). In this paper we extend the empirical validation of OOFP substantially, using a larger data set and comparing OOFP with alternative predictors of LOC. The aim of the paper is to gain an understanding of which factors contribute to accurate size prediction for OO software, and to position OOFP within that knowledge. A cross validation approach was adopted to build and evaluate linear models where the independent variable was either a traditional OO entity (classes, methods, association, inheritance, or a combination of them) or an OOFP-related measure. Using the full OOFP process, the best size predictor achieved a normalized mean squared error of 38\%. By removing function point weighting tables from the OOFP process, and carefully analyzing collected data points and developer practices, we identified several factors that influence size estimation. Our empirical evidence demonstrates that by controlling these factors size estimates could be substantially improved, decreasing the normalized mean squared error to 15\%---in relative terms, a 56\% reduction. |
| Understanding the implementation of a certain feature of a system requires identification of the computational units of the system that contribute to this feature. In many cases, the mapping of features to the source code is poorly documented. In this paper, we present a semiautomatic technique that reconstructs the mapping for features that are triggered by the user and exhibit an observable behavior. The mapping is in general not injective; that is, a computational unit may contribute to several features. Our technique allows for the distinction between general and specific computational units with respect to a given set of features. For a set of features, it also identifies jointly and distinctly required computational units. The presented technique combines dynamic and static analyses to rapidly focus on the system's parts that relate to a specific set of features. Dynamic information is gathered based on a set of scenarios invoking the features. Rather than assuming a one-to-one correspondence between features and scenarios as in earlier work, we can now handle scenarios that invoke many features. Furthermore, we show how our method allows incremental exploration of features while preserving the ``mental map" the analyst has gained through the analysis. |
| This technical note presents a consistent set of information models that identify and define the foundational concepts underlying safety, security, and survivability engineering. In addition, it shows how quality requirements are related to quality factors, subfactors, criteria, and metrics, and it emphasizes the similarities between the concepts that underlie safety, security, and survivability engineering. The information models presented in this technical note provide a standard terminology and set of concepts that explain the similarities between the asset-based, risk-driven methods for identifying and analyzing safety, security, and survivability requirements as well as a rationale for the similarity in architectural mechanisms that are commonly used to fulfill these requirements. |
| Pour am\'eliorer la fiabilit\'e des syst\`emes, les informaticiens s'efforcent de r\'eduire le temps de r\'ecup\'eration des ordinateurs bloqu\'es, d'autoriser des r\'einitialisations partielles et de permettre des retours plusieurs \'etapes en amont. |
| The goal of this paper is to investigate and assess the ability of explanatory models based on design metrics to describe and predict defect counts in an object-oriented software system. Specifically, we empirically evaluate the influence of design decisions to defect behavior of the classes in two products from the commercial software domain. Information provided by these models can help in resource allocation and serve as a base for assessment and future improvements. We use innovative statistical methods to deal with the peculiarities of the software engineering data, such as non-normally distributed count data. To deal with overdispersed data and excess of zeroes in the dependent variable, we use negative binomial (NB) and zero-inflated NB regression in addition to Poisson regression. Furthermore, we form a framework for comparison of models' descriptive and predictive ability. Predictive capability of the models to identify most critical classes in the system early in the software development process can help in allocation of resources and foster software quality improvement. In addition to the correlation coefficients, we use additional statistics to assess a models' ability to explain high variability in the data and Pareto analysis to assess a models' ability to identify the most critical classes in the system. Results indicate that design aspects related to communication between classes and inheritance can be used as indicators of the most defect-prone classes, which require the majority of resources in development and testing phases. The zero-inflated negative binomial regression model, designed to explicitly model the occurrence of zero counts in the dataset, provides the best results for this purpose. |
| Pattern users are faced with difficulties in understanding when and how to use the increasing number of available design patterns due the inherent ambiguity in the existing means (textual and graphical) of describing them. Since patterns are seldom used in isolation but are usually combined to solve complex problems, the above-mentioned difficulties have even worsen. Hence, there is an appealing need to introduce formalism to accurately describe patterns and pattern combination to allow rigorous reasoning about them. The main problem of existing formal specification languages for design patterns is lack of completeness. This is mainly due either because they were not originally conceived to specify design patterns and have been adapted to do so, or they tend to focus on specifying either the structural or behavioral aspect of design patterns but not both of them. Moreover, only few of them venture in specifying design pattern combination. We propose a simple yet Balanced Pattern Specification Language (BPSL) that is aimed to achieve equilibrium by specifying the structural as well as behavioral aspects of design patterns. This is achieved by combining two subsets of logic one from First Order Logic (FOL) and one from Temporal Logic of Actions (TLA). Moreover it can be used to formally specify pattern combination. |
| The Chinese Postman Problem has many applications, including robot exploration, and analysing interactive system and web site usability. This paper reviews the wide range of applications of the problem and presents complete, executable code to solve it for the case of directed multigraphs. A variation called the ‘open Chinese Postman Problem’ is also introduced and solved. Although optimisations are possible, no substantially better algorithms are likely. |
| On se souvient mal... Pis: on ne se souvient plus... Et si en r\'ealit\'e on ne faisait que se souvenir diff\'eremment. Et si ce que l'on prend pour des insuffisances - ou m\^eme des pannes de notre m\'emoire - n'\'etait qu'une forme de r\'e\'ecriture de nos souvenirs. C'est en tout cas ce que montrent les derni\`eres recherches. Contrairement \`a ce qu'on a cru jusqu'\`a maintenant, la m\'emoire ne serait pas un disque dur qui stocke des informations fig\'ees. Si nos souvenirs changent, c'est parce que en permanence nous les r\'eactivons et les enrichissons. Une d\'ecouverte qui va changer notre fa\c con de nous servir de notre m\'emoire. Et de l'am\'eliorer. |
| Reusability is a key factor for the success of the development of low-cost applications. Component-based software engineering (CBSE) aims to address this challenge by providing flexible and easy to use software components. Composability is a key concern of CBSE because software components collaborate with difficulty in spite of the fact that they are known to be compositional. Here we propose to formalize a special kind of composability, based on high coupling in which fine-grained components are encapsulated inside high-granularity components that are deployed on the same node. We specifically study the properties of the universal whole-part relationship within a composition framework. We constrain composition design by means of rules derived from the whole-part relationship. These constraints are used to generate contracts at implementation time. Finally, we incorporate built-in test functionality into components to support runtime validation. |
| Many analyses of software systems can be formalized as relational queries, for example the detection of design patterns, of patterns of problematic design, of code clones, of dead code, and of differences between the as-built and the as-designed architecture. This paper describes the concepts of CrocoPat, a tool for querying and manipulating relations. CrocoPat is easy to use, because of its simple query and manipulation language based on predicate calculus, and its simple file format for relations. CrocoPat is efficient, because it internally represents relations as binary decision diagrams, a data structure that is well-known as a compact representation of large relations in computer-aided verification. CrocoPat is general, because it manipulates not only graphs (i.e. binary relations), but n-ary relations. |
| Design patterns are recognized, named solutions to common design problems. The use of the most commonly referenced design patterns should promote adaptable and reusable program code. When a system evolves, changes to code involving a design pattern should, in theory, consist of creating new concrete classes that are extensions or subclasses of previously existing classes. Changes should not, in theory, involve direct modifications to the classes in prior versions that play roles in a design patterns. We studied five systems, three proprietary systems and two open source systems, to identify the observable effects of the use of design patterns in early versions on changes that occur as the systems evolve. In four of the five systems, pattern classes are more rather than less change prone. Pattern classes in one of the systems were less change prone. These results held up after normalizing for the effect of class size --- larger classes are more change prone in two of the five systems. These results provide insight into how design patterns are actually used, and should help us to learn to develop software designs that are more easily adapted. |
| The Model-Driven Architecture is an initiative by the Object Management Group to automate the generation of platform-specific models from platformindependent models. While there exist some well-established standards for modeling platform models, there is currently no matured foundation for specifying transformations between such models. In this paper, we propose a possible taxonomy for the classification of several existing and proposed model transformation approaches. The taxonomy is described with a feature model that makes the different design choices for model transformations explicit. Based on our analysis, we propose a few major categories in which most model transformation approaches fit. |
| Given today's fast pace of technological evolutions and diversity of computing platforms, building applications which can work in such a wide range of systems is becoming more and more challenging. To deal with this situation, applications must be \emph{self-adaptive}, that is adapt themselves to their environment and its evolutions. The goal of our works is to enable systematic development of self-adaptive component-based applications using the Separation of Concerns principle: we consider \emph{adaptation to a specific execution context and its evolutions} as a concern which should be treated separately from the rest of an application. In this paper, we first present the general approach we propose and the corresponding development framework and tools we are developing to support it. Then, in order to validate this approach, we show how a small component-based application can be made self-adaptive using our approach. |
| The terms architecture, design, and implementation are typically used informally in partitioning software specifications into three coarse strata of abstraction. Yet these strata are not well-defined in either research or practice, causing miscommunication and needless debate. To remedy this problem we formalize the Intension and the Locality criteria, which imply that the distinction between architecture, design, and implementation is qualitative and not merely quantitative. We demonstrate that architectural styles are intensional and non-local; that design patterns are intensional and local; and that implementations are extensional and local. |
| Analysis and design of programs by using has emerged to a standard technique in object-oriented software engineering. Many of these tools claim to implement methods according to the UML{} standard and some of the tools provide automatic layout of the diagrams drawn by the user or generated automatically from source code. In this paper, we propose a set of aesthetic criteria for UML{} class diagrams and discuss the relation between these criteria, human--computer interaction (HCI) and design aspects of object oriented software. First, we describe critics from the viewpoint of HCI to the UML{} notation and restrict ourselves to changes which do not require non-standard modifications to the UML{} notation guide, then we list quality relations between class diagrams and object-oriented software models. After that our set of aesthetic criteria, that reflect the highly sophisticated structural and semantic features of UML{} class diagrams, is explained. Finally, we we show that an implementation and measurment of this proposal is realizable using a prototypical graph drawing framework. |
| In this paper, we introduce new visualization tools for explanations generated during search in a constraint program. Explanations are a very powerful tool for exhibiting dynamic interactions and relations appearing only during search. Moreover, we show that classical information that can be gathered in standard solvers does not allow retrieving this dynamic behavior thus advocating for the embedding of explanations within existing constraint solvers. |
| Data warehouse systems are nowadays a well known and widely spread approach for supporting management decisions. In several companies or even across companies the idea of integrating several data warehouses into a virtual or federated data warehouse is of growing interest. But the technical and semantic problems are very demanding. An essential part for solving this problem is a standardized, vendor independent format for describing multidimensional data. This paper introduces XCube, a family of XML based document templates to exchange data warehouse data, extit{i.e.}, data cubes, over any kind of network. XCube is organized in a modular fashion, so the multidimensional schema, the descriptions of the single dimensions and the fact data itself can be transmitted in separate steps. In addition to the describing formats XCube also offers two kinds of dynamic document types that can be used to explore the (multidimensional) content of another warehouse in a vendor independent way. They are primarily meant to reduce the amount of data transferred over the network |
| La programmation par contraintes, discipline au carrefour de l'intelligence artificielle, de la recherche op\'erationnelle et de l'analyse num\'erique a fait ses preuves pour la r\'esolution de probl\`emes combinatoires complexes dans le domaine de l'aide \`a la d\'ecision. De nouveaux champs d'applications apparaissent, en particulier dans le domaine du g\'enie logiciel. Au travers de quelques exemples (notamment l'identification et la correction de motifs de conception approch\'es et la r\'ealisation d'applications dans un contexte anytime), nous montrons les apports et les perspectives de l'utilisation de la programmation par contraintes dans le domaine du g\'enie logiciel. |
| Software visualization tools face many challenges in terms of their implementation, including scalability, usability, adaptability, and durability. Such tools, like many other research tools, tend to have a short life cycle and are vulnerble to software evolution processes because of the complex problem domain and the constantly changing requirements which are dictated by research goals. In this paper we discuss the implementation of the software visualization tool CodeCrawler according to five criteria, namely the overall architecture, the internal architecture, the visualization engine, the metamodel and the interactive facilities. This discussion generates implementation recommendations and design guidelines that hold for our tool and the class of tools its stands for. We then also extract common design guidelines and recommendations that apply for other software visualization and general reverse engineering tools as well, and hope that these insights can be used fruitfully by other researchers in this field. |
| Large industrial legacy systems are challenges of reverse-engineering activities. Reverse-engineering approaches use text-search tools based on regular expressions or work on graph representations of programs, such as abstract syntax graphs. Analyzing large legacy systems often fail because of the large search space. Our approach to handle large searchspace in pattern-based reverse engineering is to allow imprecise results in means of false positives. We use the theory of fuzzy sets to express impreciseness and present our approachon the example of recovering associations. |
| Achieving and maintaining high software quality is most dependent on how easily the software engineer least familiar with the system can understand the system's code. Understanding attributes of cognitive processes can lead to new software metrics that allow the prediction of human performance in software development and for assessing and improving the understandability of text and code. In this research we present novel metrics based on current understanding of short-term memory performance to predict the location of high frequencies of errors and to evaluate the quality of a software system. We further enhance these metrics by applying static and dynamic program slicing to provide programmers with additional guidance during software inspection and maintenance efforts. |
| Cet article s'int\'eresse au probl\`eme de mesurer la similarit\'e de graphes orient\'es \'etiquet\'es, i.e., des graphes tels que chaque arc et chaque sommet poss\`edent un ensemble d'\'etiquettes (de caract\'eristiques). Nous d\'efinissons tout d'abord le probl\`eme du calcul de la similarit\'e de deux graphes \'etiquet\'es comme la recherche d'un meilleur appariement de leurs sommets. Ce probl\`eme se distingue du probl\`eme de l'isomorphisme de graphes par le fait que ces appariements autorisent la mise en correspondance d'un sommet d'un graphe avec 0, 1 ou plusieurs autres sommets de l'autre graphe. Nous \'etudions ensuite la complexit\'e de notre probl\`eme, et nous proposons deux algorithmes : un algorithme bas\'e sur une exploration compl\`ete par ``s\'eparation et \'evaluation'', et un algorithme glouton. |
| A key desideratum for many software comprehension tools is to reduce the mental burdens of software engineers. That is, the tools should support cognition. This key benefit is difficult to directly observe and measure, so evaluating such tools has been problematic. This paper describes an investigation into the application of distributed cognition theories to analyzing and observing cognitive support. Theories of cognitive support are used to generate an analysis of potential cognitive benefits provided by the compilation-error tracking facilities of a commercial software development environment. This analysis is used to generate a scheme for coding user observations such that cognitive support related activity can be tracked. Experiences in applying the technique on data from a field study are reported. The study also serves to provide a glimpse into the ways that programmers and tools cooperate. Implications are drawn for future practices of tool evaluation and engineering. |
| For software maintenance and evolution, a common problem is to understand how each requirement is implemented in the source code. The basic solution of this problem is to find the fragment of source code that is corresponding to the implementation of each requirement. This can be viewed as a requirement-slicing problem - slicing the source code according to each individual requirement. We present an approach to find the set of functions that is corresponding to each requirement. The main idea of our method is to combine the information retrieval technology with the static analysis of source code structures. First, we retrieve the initial function sets through some information retrieval model using functional requirements as the queries and identifier information (such as function names, parameter names, variable names etc.) of functions in the source code as target documents. Then we complement each retrieved initial function set by analyzing the call graph extracted from the source code. A premise of our approach is that programmers should use meaningful names as identifiers. Furthermore, we perform an experimental study based on a GNU system. We use two basic metrics: precision and recall (which are the common practice in the information retrieval field), to evaluate our approach. We also compare the results directly acquired from information retrieval with those that are complemented through static source code structure analysis. |
| In this paper we adapt the Access Graph notation of Ardourel and Huchard for static access rights to express decoupling constraints. These constraints are pervasive in design patterns albeit in a very informal and often not very explicit way. This new formalism will be used in the RNTL LUTIN project to detect design problems and propose solutions using program or model transformations. |
| Using design patterns is a widely accepted method to improve software development. There are many benefits of the application of patterns claimed in the literature. The most cited claim is that design patterns can provide a common design vocabulary and therefore improve greatly communication between software designers. Most of the claims are supported by experiences reports of practitioners, but there is a lack of quantitative research concerning the actual application of design patterns and about the realization of the claimed benefits. In this paper we analyze the development process of over 1000 open source software projects using version control information. We explore this information to gain an insight into the differences of software development with and without design patterns. By analyzing these differences we provide evidence that design patterns are used for communication and that there is a significant difference between developers who use design patterns and who do not. |
| A new weapon in the war against subtle marketing misdirection is now available. Make the shortcomings of Shared Source absolutely clear. Help wanted, of course, to sharpen this defensive weapon even more. |
| Introduction to software development problems and to the processes and methods used to address them. Software life cycle models. Software process improvement. Goals and methods for requirements analysis and specification, software design, implementation, integration and testing of software. An introduction to one or more informal methods (focusing on object-oriented approaches) currently in widespread use. |
| Journ\'ee \`a laquelle sont invit\'es les informaticiens "professionnels", les enseignants de droit et d'informatique, les professionnels du droit et les \'etudiants, journ\'ee qui traitera de ce qu'un responsable de service informatique a \`a savoir en mati\`ere de droit dans son activit\'e professionnelle (le d\'eveloppement de logiciels). |
| Alors que l'Am\'erique, le Japon et d'autres pays europ\'eens misent r\'esolument sur la science et la technologie, la France prend un retard inqui\'etant. Cr\'edits en forte baisse, performances d\'egrad\'ees, crise des vocations scientifiques... Le syst\`eme national de recherche s'interroge sur son avenir. |
| A handy, reliable and authoritative dictionary that provides a wealth of information about the words most frequently used in English. This book is packed with features you would only expect to find in larger dictionaries, with more than 70,000 definitions and 150 illustrations. The great go-anywhere, look-it-up-fast language reference including the core vocabulary of everyday life: \begin{itemize} \item Over 70,000 clear, concise definitions. \item Authoritative pronunciations. \item Special sections and tables. \end{itemize} |
| Politicians on both sides of the argument over Iraq have been busy rummaging through the history books. The pro-war camp constantly warn against repeating the mistakes of appeasement. The antis claim we are heading for another Suez. But which is the more plausible parallel? Matt Seaton asked a dozen leading historians . |
| James Gosling talks with Bill Venners about his current research project, code-named Jackpot, which builds annotated parse trees for programs and can help you analyze, visualize, and refactor your program. |
| It's not that we believe Google is evil. What we believe is that Google, Inc. is at a fork in the road, and they have some big decisions to make. This Google Watch site is trying to articulate, publicize, and even dramatize the situation at Google, and encourage more scrutiny of their operations. By doing this, we hope to play a small part in maintaining the web as an information tool that is more useful for the masses, than it is for the elites. |
| Peut-\^etre tout se d\'eroulera-t-il selon le meilleur sc\'enario possible pour les Etats-Unis : sous la pression de l'ultimatum lanc\'e lundi 17 mars par George W. Bush, l'arm\'ee irakienne pourrait tenter un coup d'Etat qui permettrait aux forces am\'ericaines d'entrer "pacifiquement" en Irak. Rien n'est moins garanti. Et cela, en tout \'etat de cause, n'enl\`evera rien \`a la conclusion qui s'impose : l'entr\'ee en guerre de l'Am\'erique et de la Grande-Bretagne contre l'Irak, sans mandat de l'ONU, dans un geste parfaitement unilat\'eral, manifeste un formidable \'echec diplomatique pour le gouvernement Bush. |
| extit{Le grand dictionnaire terminologique} de l'Office qu\'eb\'ecois de la langue fran\c caise est une banque de donn\'ees terminologiques. On y trouve, class\'es par domaines, des termes appartenant aux langues de sp\'ecialit\'es. La fiche terminologique renseigne sur une notion, par la d\'efinition, les notes, l'illustration, et pr\'esente les termes qui d\'esignent cette notion. Le terme principal est celui que privil\'egie l'Office qu\'eb\'ecois de la langue fran\c caise dans les situations de communication \'ecrite. Les termes consign\'es en sous-entr\'ee peuvent g\'en\'eralement \^etre employ\'es, mais leur emploi doit \^etre nuanc\'e dans certains cas. |
| These notes are based on slides prepared by Chris Hankin, and to be used in the course Assured Software: Semantics (2.12) at the Department of Computing, Imperial College. The notes lean heavily on the book Semantics with Applications A Formal Introduction by Hanne Riis Nielson and Flemming Nielson, that is recommended for further reading. |
| 2002 |
| The practice of enterprise application development has benefited from the emergence of many new enabling technologies. Multi-tiered object-oriented platforms, such as Java and .NET, have become commonplace. These new tools and technologies are capable of building powerful applications, but they are not easily implemented. Common failures in enterprise applications often occur because their developers do not understand the architectural lessons that experienced object developers have learned. Patterns of Enterprise Application Architecture is written in direct response to the stiff challenges that face enterprise application developers. The author, noted object-oriented designer Martin Fowler, noticed that despite changes in technology--from Smalltalk to CORBA to Java to .NET--the same basic design ideas can be adapted and applied to solve common problems. With the help of an expert group of contributors, Martin distills over forty recurring solutions into patterns. The result is an indispensable handbook of solutions that are applicable to any enterprise application platform. This book is actually two books in one. The first section is a short tutorial on developing enterprise applications, which you can read from start to finish to understand the scope of the book's lessons. The next section, the bulk of the book, is a detailed reference to the patterns themselves. Each pattern provides usage and implementation information, as well as detailed code examples in Java or C#. The entire book is also richly illustrated with UML diagrams to further explain the concepts. Armed with this book, you will have the knowledge necessary to make important architectural decisions about building an enterprise application and the proven patterns for use when building them. |
| The gap between qualitative and quantitative statements, concerning objectoriented software design can be bridged using higher-level, goal-driven methods for measurement interpretation. The goal of this work is to develop methods and techniques that provide a relevant interpretation of measurement results applied to the investigation of object-oriented software design. In this context, the central focus of this dissertation is to support the quality assessment and improvement of existing object-oriented systems, by bridging the gap between qualitative and quantitative statements. |
| Software development remains mentally challenging despite the continual advancement of training, techniques, and tools. Because completely automating software development is currently impossible, it makes sense to seriously consider how tools can improve the mental activities of developers apart from automating them away. Such mental assistance can be called ``cognitive support". Understanding and developing cognitive support in software engineering tools is an important research issue but, unfortunately, at the moment our theoretical foundations for it are inadequately developed. Furthermore, much of the relevant research has occurred outside of the software engineering community, and is therefore not easily available to the researchers who typically develop software engineering tools. Tool evaluation, comparison, and development are consequently impaired. The present work introduces a theoretical framework intended to seed further systematic study of cognitive support in the field of software engineering tools. This theoretical framework, called RODS, imports ideas and methods from a field of cognitive science called ``distributed cognition". The crucial concept in RODS is that cognitive support can be understood and explained in terms of the computational advantages that are conferred when cognition is redistributed between software developer and their tools and environment. The name RODS, in fact, comes from the four cognitive support principles the framework describes. With RODS in hand, it is possible to interpret good design in terms of how cognition is beneficially rearranged. To make such analyses fruitful, a cognitive modeling framework called HASTI is also proposed. The main purpose of HASTI is to provide an analysis of ways of modifying developer cognition using RODS. RODS and HASTI can be used to convert previously tacit design knowledge into explicit and reusable knowledge. RODS and HASTI are evaluated analytically by using them to reconstruct rationales for two exemplar reverse engineering tools. A preliminary field study was also conducted to determine their potential for being inexpensively applied in realistic tool development settings. These studies are used to draw implications for research in software engineering and, more broadly, for the design of computer tools in cognitive work domains. |
| This paper describes an improved hierarchical model for the assessment of high-level design quality attributes in object-oriented designs. In this model, structural and behavioral design properties of classes, objects, and their relationships are evaluated using a suite of object-oriented design metrics. This model relates design properties such as encapsulation, modularity, coupling, and cohesion to high-level quality attributes such as reusability, flexibility, and complexity using empirical and anecdotal information. The relationship, or links, from design properties to quality attributes are weighted in accordance with their influence and importance. The model is validated by using empirical and expert opinion to compare with the model results on several large commercial object-oriented systems. A key attribute of the model is that it can be easily modified to include different relationships and weights, thus providing a practical quality assessment tool adaptable to a variety of demands. |
| Measuring structural design properties of a software system, such as coupling, cohesion, or complexity, is a promising approach towards early quality assessments. To use such measurement effectively, quality models are needed that quantitatively describe how these internal structural properties relate to relevant external system qualities such as reliability or maintainability. This chapter has for objective to summarize, in a structured and detailed fashion, the empirical results that have been reported so far with modeling external system quality based on structural design properties in object-oriented systems. We perform a critical review of existing work in order to identify lessons learned regarding the way these studies are performed and reported. Constructive guidelines are also provided to facilitate the work of future studies, thus facilitating the development of an empirical body of knowledge. |
| The merit of automatic graph layout algorithms is typically judged by their computational e ciency and the extent to which they conform to aesthetic criteria (for example, minimising the number of crossings, maximising orthogonality). Experiments investigating the worth of such algorithms from the point of view of human usability can take di erent forms, depending on whether the graph has meaning in the real world, the nature of the usability measurement, and the e ect being investigated (algorithms or aesthetics). Previous studies have investigated performance on abstract graphs with respect to both aesthetics and algorithms, nding support for reducing the number of crossings and bends, and increasing the display of symmetry. This paper reports on preference experiments assessing the e ect of in- dividual aesthetics in the application domain of UML diagrams. Subjects' preferences for one diagram over another were collected as quantitative data. Their stated reasons for their choice were collected as qualitative data. Analysis of this data enabled us to produce a priority listing of aesthetics for this domain. These UML preference results reveal a dif- ference in aesthetic priority from those of previous domain-independent experiments. |
| Design patterns document good solutions to recurring problems in a particular context. Composing design patterns may achieve higher level of reuse by solving a set of problems. Design patterns and their compositions are usually modeled by UML diagrams. When a design pattern is applied or composed with other patterns, the pattern-related information may be lost because traditional UML diagrams do not track this information. Thus, it is hard for a designer to identify a design pattern when it is applied or composed. In this paper, we present notations to explicitly represent each pattern in the applications and compositions of design patterns. The notations allow us to maintain pattern-related information. Thus, a design pattern is identifiable and traceable from its application and composition with others. |
| There are three interdependent factors that drive our development processes: interval, quality and cost. As market pressures continue to demand new features ever more rapidly, the challenge is to meet those demands while increasing, or at least not sacrificing, quality. One advantage of defect prevention as an upstream quality improvement practice is the beneficial effect it can have on interval: higher quality early in the process results in fewer defects to be found and repaired in the later parts of the process, thus causing an indirect interval reduction. We report a retrospective analysis of the defect modification requests (MRs) discovered while building, testing, and deploying a release of a network element as part of an optical transmission network. The study consists of three investigations: a root-cause defect analysis (RCA) study, a process metric study, and a code complexity investigation. Differing in the quantities that we anticipate to be related to found defects, they all have in common the goal of identifying early quality indicators. The core of this threefold study is the root-cause analysis. We present the experimental design of this case study in some detail and its integration into the development process. We discuss the novel approach we have taken to defect and root cause classification and the mechanisms we have used for randomly selecting the MRs, to analyze and collecting the analyses via a web interface. We present the results of our analyses of the MRs and describe the defects and root causes that we found, and delineate the countermeasures created either to prevent those defects and their root causes or to detect them at the earliest possible point in the development process. We conclude the report on the root-cause analysis with lessons learned from the case study and from our experiences during subsequent usage of this analysis methodology for in-process measurement. Beyond the root-cause analysis, we first present our findings on the correlation between defects detected and the adherence to our development process. Second, we report on our experience with analyzing static code properties and their relation to observed defect numbers and defect densities. |
| In current-day software development, programmers often use programming patterns to clarify their intents and to increase the understandability of their programs. Unfortunately, most software development environments do not adequately support the declaration and use of such patterns. To explicitly codify these patterns, we adopt a declarative meta programming approach. In this approach, we reify the structure of a (object-oriented) program in terms of logic clauses. We declare programming patterns as logic rules on top of these clauses. By querying the logic system, these rules allow us to check, enforce and search for occurrences of certain patterns in the software. As such, the programming patterns become an active part of the software development and maintenance environment. |
| Reverse engineering has always been a lawful way to acquire trade secrets embodied in mass-marketed products. This longstanding principle---on which software engineers as well as engineers in other fields so frequently rely---could be significantly undermined depending on what happens in a case now pending before the California Supreme Court. The precedent set in this case could, in turn, influence courts in other jurisdictions. A key issue in the case---one that legal scholars and intellectual property lawyers have debated for many years---is whether an anti-reverse engineering clause in a mass-market license should be enforceable. |
| Design patterns and frameworks have become important concepts in object development. As well important is UML as the standard modeling language. But there is not sufficient support to model design patterns and frameworks in design class diagrams (DCDs) without using the extension mechanisms, that is, stereotypes, constraints, and tagged values. Some approaches have been developed to improve the representation by extending UML. But they are either not comprehensive, or not well-defined, or don't consider the granularity or complexity of DCDs. In this paper we present a more comprehensive and well-defined approach by using an example, distinguish between DCDs, detailed DCDs, and design pattern CDs, define UML profiles for the extensions, and outline how an UML tool can support the approach. |
| Reflective Programming has long been viewed as an elegant but academic subject that is of interest only to educators and researchers. The seminal work on Procedural Reflection by Brian Smith clearly articulated the benefits of allowing an executing program to have access to the underlying data structures and algorithms that govern its own computation [1]. The first implementation of the reflective tower was in 3Lisp. This was followed by work in the Lisp [2, 3]) and Smalltalk communities [4]. The research work on reflection has most frequently appeared in OOPSLA [5,6] and ECOOP conference proceedings as well as Reflection conferences dedicated to the subject [7] To many outsiders, the phrase ``going meta" conjures up visions of taking a trip to Nepal as opposed to a way of thinking about software development. However, those who have experienced the ``engine room" via a Scheme meta-circular interpreter (see www-mitpress.mit.edu/sicp), or Smalltalk or CLOS meta-class programming, have a fundamentally deeper perspective on computation. |
| The cost of maintaining a software system over a long period of time far exceeds its initial development cost. Much of the maintenance cost is attributed to the time required by new developers to understand legacy systems. High-level structural information helps maintainers navigate through the numerous low-level components and relations present in the source code. Modularization tools can be used to produce subsystem decompositions from the source code but do not typically produce high-level architectural relations between the newly found subsystems. Controlling subsystem interactions is one important way in which the overall complexity of software maintenance can be reduced. We have developed a tool, called ARIS (Architecture Relation Inference System), that enables software engineers to define rules and relations for regulating subsystem interactions. These rules and relations are called Interconnection Styles and are defined using a visual notation. The style definition is used by our tool to infer subsystem-level relations in designs being reverse engineered from source code. In this paper we describe our tool and its underlying techniques and algorithms. Using a case study, we describe how ARIS is used to reverse engineer high-level structural information from a real application. |
| A transferable quality model must be general. This implies that only the high level characteristics can be transferred into different settings and that the refinement of the characteristics into metrics must be operated according to the context peculiarities. In spite of the amount of quality models and approaches to quality models definition presented in literature, there are no experiences reported showing the same quality model reused in different environments. This statement needs further investigation. The aim of this work is to present an experience on the field that involves two industrial projects in which the same quality model was used. The study confirms the need to modify the quality model, not only in the metrics but also in the measurement processes and in the interpretation of the resulting measures as side effects. |
| Most comparisons among OO languages focus on structural or philosophical features but rarely on dynamic ones. Beyond all these structural properties, late-binding is, to our opinion, the key property of OO paradigm; the operational consequence of inheritance use. All OO languages use late-binding, but do they all have the same interpretation? We show that the answer is no, not very surprisingly, but that almost each language has its own interpretation. We propose a simple procedure to compare late-binding interpretation of OO languages and introduce a late-binding signature of OO programming languages. This procedure can be used to study language interactions as we will show it for the Microsoft .NET framework. |
| Maintenant que les techniques de programmation objet sont largement diss\'emin\'ees dans la communaut\'e scientifique informatique, il est int\'eressant de faire une pause et d'observer les langages de programmation commun\'ement utilis\'es. Si les m\'ecanismes comme l'encapsulation et l'h\'eritage sont biens connus et compris, leur cons\'equence op\'erationnelle -- la liaison dynamique -- a encore beaucoup d'interpr\'etations, faisant des langages objet une solution toujours immature ou, du moins, une juxtaposition de nombreuses th\'eories. Puisque nous pensons que la notion d'objet a un sens et apporte une r\'eelle am\'elioration par rapport aux langages classiques -- sans liaison dynamique, nous avons compar\'e sept langages objet et \'etudi\'e leurs diff\'erences vis-\`a-vis de la liaison dynamique. Nous proposons une s\'emantique ``raisonnable" \`a la liaison dynamique qui autorise tout \`a la fois des red\'efinitions de m\'ethodes covariantes, contravariantes et invariantes pour ce qui est consid\'er\'e, m\^eme par des experts, comme un probl\`eme d\'elicat. |
| Research into the cognitive aspects of programming originated in the study of professional programmers (whether experts or students). Even "end-user" programmers in previous studies have often worked in organizations where programming is recognized to be demanding professional work -- the term "power-user" recognizes this technical kudos. But as personal computers become widespread, and most new domestic appliances incorporate microprocessors, many people are engaging in programming-like activities in domestic or non-professional contexts. Such users often have less motivation and more obstacles to programming, meaning that they may be unlikely even to take the first steps. This paper analyses the generic nature of those first steps, and identifies the cognitive demands that characterize them. On the basis of this analysis we propose the Attention Investment model, a cognitive model of programming that offers a consistent account of all programming behaviour, from professionals to end-users. |
| Good information design depends on clarifying the meaningful structure in an image. We describe a computational approach to stylizing and abstracting photographs that explicitly responds to this design goal. Our system transforms images into a line-drawing style using bold edges and large regions of constant color. To do this, it represents images as a hierarchical structure of parts and boundaries computed using state-of-the-art computer vision. Our system identifies the meaningful elements of this structure using a model of human perception and a record of a user's eye movements in looking at the photo; the system renders a new image using transformations that preserve and highlight these visual elements. Our method thus represents a new alternative for non-photorealistic rendering both in its visual style, in its approach to visual form, and in its techniques for interaction. |
| A functionality to support dynamic class evolution in running applications has been recently implemented in the Sun's {Java{}} HotSpot Virtual Machine. This functionality was initially considered useful for “fix-and-continue” feature of debuggers and for updating running server programs. Despite looking potentially attractive, the second option so far have not gained enough attention of major customers of the {Java{}} platform, the main reason being that dynamic application fixing or upgrading looks too risky. However, it appears that evolution technology in the form of dynamic bytecode instrumentation may become extermely useful in the areas of application profiling and monitoring. A JVM supporting dynamic bytecode instrumentation would allow developers to profile dynamically selected parts of the target application, turn emission of various kinds of pro- filing events on and off, and thus dramatically minimise the overhead presently associated with instrumentation-based pro filing. However, a special API different from the one currently implemented for class evolution, is required to support fast and scalable dynamic bytecode instrumentation. |
| Cette article d\'ecrit l'utilisation de matrices d'adjacence pour la visualisation de graphes de co-activit\'e tels que les graphes d'interaction au sein de communaut\'es. Nous d\'ecrivons leur utilisation pour la compr\'ehension et l'analyse de programmes par contraintes. Nous montrons que l'usage de matrices d'adjacence pour visualiser le graphe variables--contraintes de probl\`eme \'etudi\'e permet de voir la mod\'elisation du probl\`eme et de comparer l'activit\'e dans diverses parties du graphe au fil de la r\'esolution. |
| Dynamic analysis consists of analyzing the behavior of a software system to extract its proprieties. There have been many studies that use dynamic information to extract high-level views of a software system or simply help software engineers to perform their daily maintenance activities more effectively. One of the biggest challenges that such tools face is to deal with very large execution traces. By analyzing the execution traces of the software systems we are working on, we noticed that they contain many redundancies that can beremoved. This led us to create a comprehension-driven compression framework that compresses the traces to make them more understandable. In this paper, we present and explain its components. The compression framework is reversible that is the original trace can be reconstructed from its compressed version. In addition to that, we conducted an experiment with the execution traces of two software systems to measure the gain attained by such compression. |
| AspectJ implementations of the GoF design patterns show modularity improvements in 17 of 23 cases. These improvements are manifested in terms of better code locality, reusability, composability, and (un)pluggability. The degree of improvement in implementation modularity varies, with the greatest improvement coming when the pattern solution structure involves crosscutting of some form, including one object playing multiple roles, many objects playing one role, or an object playing roles in multiple pattern instances. |
| We detect interaction patterns in legacy code combining static and dynamic analyses. The analyses do not depend on coding or naming conventins. We classified potential pattern instances according to the evidence our analyses provide. We discuss our approach with the \ygg@pattern{Observer} pattern as an example. Our {Java{}} implementation analyzes {Java{}} programs. We evaluated our approach by self applying the tool looking for observers in its code. We do not miss a pattern instance. The class of pattern instances, our analyses provided a high evidence for, contained 80\% of all actual pattern instances but no false positive. |
| Separation of concern is a basic engineering principle that is also at the core of object-oriented analysis and design methods in the context of the Unified Modelling Language (UML). The UML gives the designer a rich, but somehow disorganized, set of views on her model as well as many features, such as design pattern occurrences, stereotypes or tag values, allowing her to add non-functional information to a model. Aspect-oriented concepts are applied to manage multitude of design constraints. However, it can then be an overwhelming task to reconcile the various aspects of a model into a working implementation. In this paper, we present our UMLAUT framework as a toolkit for ``weaving" aspects when modelling with UML. This is accompanied with an example of a distributed multimedia application with a weaving generating an implementation model. |
| Quality is a fundamental concept in software and information system development. It is also a complex and elusive concept. A large number of quality models have been developed for understanding, measuring and predicting qualities of software and information systems. It has been recognised that quality models should be constructed in accordance to the specific features of the application domain. This paper proposes a systematic method for constructing quality models of information systems. A diagrammatic notation is devised to represent quality models that enclose application specific features. Techniques of hazard analysis for the development and deployment of safety related systems are adapted for deriving quality models from system architectural designs. The method is illustrated by a part of web-based information systems. |
| As programs become more complex and larger, the sheer volume of information to be comprehended by developers becomes daunting. Software development is fraught with complexity that is difficult to identify a priori. Complexity is relative to the task, the developer's experience and the resources available. In this research, we identify comprehension processes applied in software development, and the cognitive loads associated with these processes. We present an abstraction of the cognitive environment of the software developer, and introduce techniques to minimize the cognitive effort in the short-term and the long-term. |
| Today, software-engineering research and industry alike recognize the need for practical tools to support reverse-engineering activities. Most of the well-known CASE tools support reverse engineering in some way. The Uni-fied Modeling Language (UML) has emerged as the de facto standard for graphically representing the design of object-oriented software systems. However, there does not yet exist a standard scheme for representing the reverse-engineered models of these systems. The various CASE tools usually adopt proprietary extensions to UML and, as a result, it is difficult, or even impossible, to ensure that model semantics remains unambiguous when working with different tools at the same time. In this paper, we examine the capabilities of the two most successful industrial-strength CASE-tools in reverse engineering the static structure of software systems and compare them to the results produced by two academic prototypes. The comparisons are carried out both manually and automatically using a research prototype for manipulating and comparing UML models. |
| Maintaining the source code of large software systems is hard. One underlying cause is that existing modularisation mechanisms are inadequate to handle crosscutting concerns. We propose in-tentional source-code views as an intuitive and lightweight means of modelling such concerns. They increase our ability to under-stand, modularise and browse the source code by grouping together source-code entities that address the same concern. They facilitate software development and evolution, because alternative descrip-tions of the same intentional view can be checked for consistency and relations among intentional views can be defined and verified. Finally, they enable us to specify knowledge developers have about source code that is not captured by traditional program documenta-tion mechanisms. Our intentional view model is implemented in a logic metaprog-ramming language that can reason about and manipulate object-ori-ented source code directly. The proposed model has been validated on the evolution of a medium-sized object-oriented application in Smalltalk, and a prototype tool has been implemented. |
| This paper describes a software-based system for offline tracking of eye and head movements using stored video images, designed for use in the study of air-traffic displays. These displays are typically dense with information; to address the research questions, we wish to be able to localize gaze within a single word within a line of text (a few minutes of arc), while at the same time allowing some freedom of movement to the subject. Accurate gaze tracking in the presence of head movements requires high precision head tracking, and this was accomplished by registration of images from a forward-looking scene camera with a narrow field of view. |
| A method and a corresponding tool is described which assist design recovery and program understanding by recognising instances of design patterns semi-automatically. The approach taken is specifically designed to overcome the existing scalability problems caused by many design and implementation variants of design pattern instances. Our approach is based on a new recognition algorithm which works incrementally rather than trying to analyse a possibly large software system in one pass without any human intervention. The new algorithm exploits domain and context knowledge given by a reverse engineer and by a special underlying data structure, namely a special form of an annotated abstract syntax graph. A comparative and quantitative evaluation of applying the approach to the Java AWT and JGL libraries is also given. |
| The paper describes the process of program comprehension from the point of view of constructivist theory of learning. According to this view, program comprehension starts with the pre-existing knowledge and continues through processes of assimilation and adaptation. The assimilation means that the facts encountered in the program are either added to the knowledge or rejected. Adaptation means that the existing knowledge is reorganized in order to absorb new facts. These processes are illustrated by a case study where the knowledge of the program is represented by UML class diagrams. |
| Design patterns have been widely adopted and well investigated by the software engineering community over the past decade. However, their primary use is still associated with forward engineering and the design phase of the software life-cycle. In this paper, we examine design patterns from a different perspective namely, their classification and usage for software re-engineering and restructuring. Specifically, twenty three design patterns originally presented in the "Gang of Four" book are reclassified for re-engineering purposes into two major categories, primitive and complex. Moreover, their relationships and impacts to specific re-engineering objectives are presented in terms of a layered model that is denoted by six different relations namely: uses, refines, conflicts, is-similar-to, combines-with, and requires. The paper also discusses how the classification scheme can be applied for the re-engineering and restructuring of object-oriented systems |
| Evaluation of Code Coverage is the problem of identifying the parts of a program that did not execute in one or more runs of a program. The traditional approach for code coverage tools is to use static code instrumentation. In this paper we present a new approach to dynamically insert and remove instrumentation code to reduce the runtime overhead of code coverage. We also explore the use of dominator tree information to reduce the number of instrumentation points needed. Our experiments show that our approach reduces runtime overhead by 38-90% compared with purecov, a commercial code coverage tool. Our tool is fully automated and available for download from the Internet. |
| Program and system comprehension are vital parts of the software maintenance process. We discuss the need for both perspectives and describe two methods that may be integrated to provide a smooth transition in understanding from the system level to the program level. Results from a qualitative survey of expert industrial software maintainers, their information needs and requirements when comprehending software are initially presented. We then review existing software tools which facilitate system level and program comprehension. Two successful methods from the fields of data mining and concept assignment are discussed, each addressing some of these requirements. We also describe how these methods can be coupled to produce a broader software comprehension method which partly satisfies all the requirements. Future directions including the closer integration of the techniques are also identified. |
| Computer tools for cognitively challenging activities are considered useful, to a great extent, because of the support that they provide for human thinking and problem solving. To analyze, specify, and design cognitive support, a suitable analytic framework is required. Theories of ``distributed cognition" have been offered as potentially suitable frameworks, but they have generally failed to plainly articulate comprehensive theories of cognitive support. This paper seeks to clarify the intellectual foundations for studying and designing cognitive support, and aims to put them in a form suitable for design. A framework called RODS is described as a type of minimal, lightweight intellectual toolkit. Its main aim is to allow analysts to think in high-level cognition-support terms rather than be overwhelmed by task- and technology-specific implementation details. Framing usefulness in terms of cognitive support makes it possible to define abstract patterns of what makes tools ``good". Implications are drawn for how the framework may be used for the design of tools in cognitively challenging work domains. |
| The analysis of eye-movement traces (i.e., the patterns of fixations in a search) is a powerful but often neglected area of eye-movement research. This is largely because it requires a more complex analysis than parameters such as mean fixation duration and as a result, previous attempts have focused on qualitative appraisal of the form of an eye-movement trace. In this paper, we introduce the concept of the ``fixation map". We discuss its application to the quantification of similarity of traces, and the degree of "coverage" by fixations of a visual stimulus. The use of fixation maps in the understanding and communication of large numbers of eye-movement traces is also examined. |
| Software inspection is a known technique for improving software quality. It involves carefully examining the code, the design, and the documentation of software and checking these for aspects that are known to be potentially problematic based on past experience. Code smells are a metaphor to describe patterns that are generally associated with bad design and bad programming practices. Originally, code smells are used to find the places in software that could benefit from refactoring. In this paper, we investigate how the quality of code can be automatically assessed by checking for the presence of code smells and how this approach can contribute to automatic code inspection. We present an approach for the automatic detection and visualization of code smells and discuss how this approach can be used in the design of a software inspection tool. We illustrate the feasibility of our approach with the development of jCOSMO, a prototype code smell browser that detects and visualizes code smells in JAVA source code. Finally, we show how this tool was applied in a case study. |
| A Design Pattern presents a proven solution to a common design problem using a combination of informal text, diagrams, and examples. Often, to suitably described an issue, the author of a Design Pattern must spread and repeat information throughout the Pattern description. Unfortunately, spreading the information can make it difficult for a reader to grasp subtelties in the design, leading to possible misuses of the Pattern. In this paper, we introduce the Design Rationale Graph (DRG) representation that connects and visualizes related concepts described in a Design Pattern. The localization of concept information is intended to help improve a reader's understanding of a Design Pattern. Improved comprehension of a Pattern could aid the use of a Pattern during implementation, and the reading of code built upon the Pattern. In addition to describing the DRG representation, we present a tool we have built to support the semi-automatic creation of a DRG from Design Pattern text, and we report on a small study conducted to explore the utility of DRGs. The study showed that readers with access to a DRG wer eable to answer questions about the Pattern more completely and with more confidence than those given the Design Pattern alone. |
| Constraint solvers rely on two simple mechanisms: enumeration and propagation. However, modern solvers integrate many optimizations and their actual implementations can be quite complex. In this paper, we advocate for non-intrusive constraint solver enhance-ments. First, a minimal solver is implemented. Second, different enhance-ments (here explanation and dynamic backtracking [7] capabilities) of this minimal solver are implemented with the help of a new programming paradigm: aspect oriented programming. This new approach allow us to non-intrusively enhance the minimal solver: it remains unchanged. |
| These notes have the status of letters written to ourselves: we wrote them down because, without doing so, we found ourselves making up new arguments over and over again. When reading what we had written, we were always too satisfied. For one thing, we felt they suffered from a marked silence as to what postmoderism actually is. Yet, we will not try to define postmodernism, first because a complete description of postmodernism in general would be too large for the paper, but secondly (and more importantly) because an understanding of postmodern programming is precisely what we are working towards. Very few programmers tend to see their (sometimes rather general) difficulties as the core of the subject and as a result there is a widely held consensus as to what programming is really about. If these notes prove to be a source of recognition or to give you the appreciation that we have simply written down what you already know about the programmer's trade, some of our goals will have been reached. |
| Design patterns are an important concept in the field of software engineering, providing a language and application independent method for expressing and conveying lessons learned by experienced designers. There is a large gap, however, between the aesthetic and elegance of the patterns as intended and the reality of working with an ultimately mathematically expressible system such as code. In this paper we describe a step towards meaningful formal analysis of code within the language of patterns, and discuss potential uses. The major contributions include: a compendium of Elemental Design Patterns (EDPs), a layer of seemingly simplistic relationships between objects that, on closer inspection, provide a critical link between the world of formal analysis and the realm of pattern design and implementation without reducing the patterns to merely syntactic constructs; an extension to the \&-calculus, termed -calculus, a formal notation for expressing relationships between the elements of object oriented languages, and its use in expressing the EDPs directly. We discuss their use in composition and decomposition of existing patterns, identification of pattern use in existing code to aid comprehension, support for refactoring of designs, integration with traditional code analysis techniques, and the education of students of software architecture. |
| Un design pattern peut \^etre vu comme un couple . La plupart des descriptions formelles des design patterns se concentrent sur la solution et n\'eglige le probl\`eme ainsi que les liens qui les unissent. Dans ce papier nous proposons d'exprimer ces probl\`emes en utilisant des m\'eta-variables qui encapsulent un fragment de code exprimant (maladroitement) l'intention du d\'eveloppeur. Une g\'en\'eralisation d'une classique transformation dite de pliage permet de corriger le terme intentionnel en le d\'epla\c cant vers une nouvelle abstraction fonctionnelle ou de donn\'ees. Ce pliage g\'en\'eralis\'e semble en mesure de repr\'esenter des m\'ecanismes constamment utilis\'es dans les design patterns et de reproduire leurs solutions. Ceci permet d'esp\'erer que les design patterns pourront \`a l'avenir \^etre beaucoup mieux outill\'es. |
| Given the large number of tasks available with Ant, it may be difficult to get an overall view of what each task can do. The following tables provide a short description of each task and a link to the complete documentation. |
| This document describes the syntax of the current version (1.11) of the language \ygg@pl{UMLscript}. The syntax diagrams displayed below are generated from the attributed grammar which was used to implement the scanner and the parser of UMLscript. The generation of scanner and parser is done by the {COCO} version which generates {Java{}} source code. |
| \ygg@product{Dot} draws directed graphs as hierarchies. It runs as a command line program, web visualization service, or with a compatible graphical interface. Its features include well-tuned layout algorithms for placing nodes and edge splines, edge labels, ``record" shapes with ``ports" for drawing data structures; cluster layouts; and an underlying file language for stream-oriented graph tools. Below is a reduced module dependency graph of an SML-NJ compiler that took 0.98 seconds of user time on a 1.4 Ghz AMD Athlon. |
| Le concept de relation est \`a la base de toute la math\'ematique dont le but est d'\'etudier -- par observation et d\'eduction (raisonnement), calcul et comparaison -- des configurations abstraites ou concr\`etes de ses objets (nombres, formes, structures) en cherchant \`a \'etablir les liens logiques, num\'eriques ou conceptuels entre ces objets. |
| TCPA stands for the Trusted Computing Platform Alliance, an initiative led by Intel. Their stated goal is `a new computing platform for the next century that will provide for improved trust in the PC platform.' Palladium is software that Microsoft says it plans to incorporate in future versions of Windows; it will build on the TCPA hardware, and will add some extra features. |
| I have received numerous emails privately and seen a number of postings complaining about the difficulty of getting the CVSNT system up and running. So to help out I have actually stepped through the process on a "naked" NT4 WorkStation and noted the different steps needed. Apart from minor operating system details (like where the path variable is set), these steps work the same way on Win NT4, Win 2000 and Win XP-Pro (I have tested all). Notice: This guide is rewritten on Dec 23rd 2002 to describe the new way of installing CVSNT that has been introduced recently. The reason I have done this is that many users have had problems getting it up and running. The guide is substantially the same as before, but it contains new screenshots from the setup sequence and tips on how to set it up correctly. |
| The many conflicting uses of terms like reverse engineering, reengineering, restructuring, and design recovery in conference papers and vendor presentations used to contribute to confusion. To straighten out the definition of these terms, the Taxonomy Project of the IEEE-CS Technical Council on Software Engineering (TCSE) - Committee on Reverse Engineering has developed a unified taxonomy of the field. |
| La conf\'erence se tenait du lundi 4 au vendredi 8 novembre 2002, au extit{Washington State Convention and Trade Center}, dans la ville de Seattle. Le programme \'etait tr\`es charg\'e : les ateliers \'etaient concentr\'es sur les deux premiers jours, le programme technique (trois sessions en parall\`ele) les trois derniers. Des tutoriaux avaient lieu toute la semaine, et des d\'emos les trois derniers jours, dans le hall d'exposition o\`u se trouvaient aussi des stands d'industriels (Microsoft, \'evidemment, IBM, Amazon, un stand minuscule pour Sun). |
| The word "ontology" seems to generate a lot of controversy in discussions about AI. It has a long history in philosophy, in which it refers to the subject of existence. It is also often confused with epistemology, which is about knowledge and knowing. |
| This FAQ provides answers to commonly asked questions related to the CPL. It is provided for informational purposes only. It is not part of, nor does it modify, amend, or supplement the terms of the CPL. The CPL is a legal agreement that governs the rights granted to material licensed under it, so please read it carefully. If there is any conflict between this FAQ and the CPL, the terms of the CPL shall govern. |
| You have a right to know. You have a right to all the information you need to make an informed choice about any product you buy. The author wrote this article because of the need to give his customers fundamental information about the direction Microsoft wants to take them. Few people have the technical background to understand fully the advantages and disadvantages of software as complex as an operating system. Without fundamental information, it is difficult for non-professionals to understand the advice of professionals. The author is not anti-Microsoft in any way. There appear to be management problems at Microsoft, but the author would like any problems to be fixed, rather than have the entire world suffer through Microsoft doing poorly. Because he has spent considerable time trying to understand the problems, and because he cares deeply about fixing the problems, the author is, in that sense, "more pro-Microsoft than Bill Gates". |
| Enable or disable finalization on exit; doing so specifies that the finalizers of all objects that have finalizers that have not yet been automatically invoked are to be run before the {Java{}} runtime exits. By default, finalization on exit is disabled. If there is a security manager, its checkExit method is first called with 0 as its argument to ensure the exit is allowed. This could result in a SecurityException. |
| Le Bandit-en-chef George W. Bush, dit « George II », et son gang, Dick Cheney, Donald Rumsfeld \& Co, gouvernent l'Am\'erique. Ultraconservateurs et richissimes (leur fortune est li\'ee au big business du p\'etrole, de l'informatique ou des biotechnologies), ils ont fait main basse sur le pays, et partent maintenant en guerre contre l'« Axe du Mal ». Provocateur, corrosif, inqui\'etant, narcissique, subversif, Mike l'Agitateur-en-chef refuse de leur abandonner le pays et supplie le secr\'etaire g\'en\'eral de l'ONU de d\'eployer ses casques bleus et de r\'etablir la d\'emocratie ! Le temps est venu, explique-t-il, de lancer la contre-attaque en d\'enon\c cant les maux cach\'es de l'Am\'erique : l'illettrisme et l'alcoolisme (le pr\'esident conna\^{\i}t bien les deux probl\`emes), le racisme (Mike propose aux Noirs un kit de survie !), la libre circulation des armes, la peine de mort, la pauvret\'e massive, mais aussi l'arrogance et l'irresponsabilit\'e de la politique \'etrang\`ere de son pays. Pas de doute, Mike est de retour ! Et le moins que l'on puisse dire, c'est que son humour ravageur d\'etonne dans le consensus patriotique qui domine aux \'Etats-Unis depuis les attentats du 11 septembre 2001. |
| This abstract presents an approach to semi-automatically detect pattern instances and their implementation in a software system. Design patterns are currently best practice in software development and provide solutions for nearly all granularity of software design and makes them suitable for representing design knowledge. The proposed approach overcomes a numer of scalability problems as they exist in other approaches by using fuzzy logic, user interaction and a learning component. |
| 2001 |
| For over 20 years, extit{Software Engineering -- A Practitioner's Approach} has been the best selling guide to software engineering for students and industry professionals alike. In its fifth edition, the book has undergone major design changes, substantial content updates, and expension to 32 chapters that address every important topic in what many have called "the engineering discipline of the 21{st} century." The format and style of the book have been completely revised to make it even more reader-friendly. In addition, a major new web site provides comprehensive software engineering resources for students, instructors, and industry professionals. The content of the fifth edition has been compartmentalized to make the book easier to use in the classroom and as a self-study guide. Part One, The Product and The Process, presents an introduction to software engineering milieu. Part Two, Managing Software Projects, covers topics that are relevant to those who plan, manage, and control software projects. Part Three, Conventional Methods for Software Engineering, considers the traditional analysis, design, and testing methods that are still widely used throughout the industry. Part Four, Advanced Software Engineering Topics, includes dedicated chapters that address formal methods, cleanroom software engineering, component-based development, client server software engineering, Web engineering, reengineering, and CASE. |
| Design Patterns Explained: A New Perspective on Object-Oriented Design draws together the principles of object-oriented programming with the power of design patterns to create an environment for robust and reliable software development. Packed with practical and applicable examples, this book teaches you to solve common programming problems with patterns--and explains the advantages of patterns for modern software design. Beginning with a complete overview of the fundamentals of patterns, Design Patterns Explained stresses the importance of analysis and design. The authors clearly demonstrate how patterns can facilitate the overall development process. Throughout the book, key object-oriented design principles are explained, along with the concepts and benefits behind specific patterns. With illustrative examples in C++ and Java, the book demystifies the ``whys," ``why nots," and ``hows" of patterns and explains pattern implementation. |
| It is possible to cost-effectively design performance into new software systems. Software performance engineering (SPE) provides a systematic, quantitative approach to managing performance throughout the development process. |
| Traceability ensures that software artifacts of subsequent phases of the development cycle are consistent. Few works have so far addressed the problem of automatically recovering traceability links between object-oriented (OO) design and code entities. Such a recovery process is required whenever there is no explicit support of traceability from the development process. The recovered information can drive the evolution of the available design so that it corresponds to the code, thus providing a still useful and updated high-level view of the system. Automatic recovery of traceability links can be achieved by determining the similarity of paired elements from design and code. The choice of the properties involved in the similarity computation is crucial for the success of the recovery process. In fact, design and code objects are complex artifacts with several properties attached. The basic anchors of the recovered traceability links should be chosen as those properties (or property combinations) which are expected to be maintained during the transformation of design into code. This may depend on specific practices and/or the development environment, which should therefore be properly accounted for. In this paper different categories of basic properties of design and code entities will be analyzed with respect to the contribution they give to traceability recovery. Several industrial software components will be employed as a benchmark on which the performances of the alternatives are measured. |
| Software's complexity and accelerated development schedules make avoiding defects difficult. These 10 techniques can help reduce the flaws in your code. |
| The Object Management Group is rapidly moving from its previous Object Management Architecture vision (OMA) to the newest Model-Driven Architecture (MDA). At the center of this framework, the so-called four-level meta-modeling architecture provides the foundations for building a variety of automatic and semi-automatic model-transformation and code-generation tools. The most important will be platform targeted code-generation tools but there are plenty of other possibilities that we can expect to become available in the near future. As an example, this paper shows how modern meta-modeling and meta-programming techniques may be combined to implement a new generation of software maintenance tools. The proposal deals with the future maintenance of software written in the C\# programming language, supported by the DotNet platform and uses all support available in the MDA framework (UML, MOF, XMI). In addition to this, we take advantage of the introspection properties of C\#. A similar approach could also be used with other modern programming languages like Smalltalk or, to a lesser extent, {Java{}}. |
| This work presents an approach to circumvent one of the major problems with techniques to build and apply software quality estimation models, namely the use of precise metric thresholds values. We used a fuzzy logic based approach to investigate the stability of a reusable class library interface, using structural metrics as stability indicators. To evaluate this new approach, we conducted a study on three versions of a commercial C++ class library. The obtained results are very promising when compared to those of two classical machine learning (ML) approaches, Top Down Induction of Decision Trees and Bayesian classifiers. |
| Design patterns and frameworks have a mutually beneficial relationship. A well-known example of this is JHotDraw, a highly customizable GUI framework that simplifies developing drawing applications. This article explains the JHotDraw framework and general framework principles in terms of several important design patterns. You'll develop a class diagram editor that demonstrates JHotDraw's usage and capabilities. |
| This paper proposes a system named {Addistant}, which enables the distributed execution of ``legacy" {Java{}} bytecode. Here ``legacy" bytecode means the regular bytecode of application software originally developed as non-distributed software running on a single {Java{}} virtual machine (JVM). For adapting legacy software to distributed execution, the users only have to specify whether the instances of each class are allocated on a local JVM or a remote JVM. {Addistant} transforms the bytecode according to that specification so that part of the software runs on the remote JVM and communicates through a network with the rest of the software running on the local JVM. This paper also presents that {Addistant} can transform legacy applications using the {Java{}} Swing class library so that the application objects are executed on a remote JVM and the GUI objects are on the local JVM. |
| Frustrated by having to deal with multiple operating systems, middleware and programming languages? The OMG MDA and UML gang have some solutions in mind that will make you want to think a lot differently about software development and deployment. While most everyone was happy that there was finally some agreement notation for case tools, few have ever thought of using UML as their development language. |
| Recently, many software visualization (SV) techniques and tools have become available. There is ample anecdotal evidence that appropriate visualization can significantly reduce the effort spent on system comprehension and maintenance, yet we are not aware of any quantitative investigation and survey of SV tools. This paper reports on a survey on SV tools which was conducted in spring 2000 with more than 100 participants. It addresses various functional, practical, cognitive as well as code analysis aspects that users may be looking for in SV tools. The participants of the survey rated the usefulness and importance of these aspects, and came up with aspects of their own. The participants were in general quite pleased with the SV tool they were using and mentioned various benefits. Nevertheless, a big gap between desired aspects and the features of current SV tools was identified. In addition, a list of improvements that should be done to current tools was assembled. Finally, the collected data tends to suggest that in general, code analysis aspects were not highly supported by the tools. |
| Les m\'ethodes d'analyse et de conception ainsi que les notations normalis\'ees comme UML, n'ont pas suivi la mont\'ee en puissance du d\'eveloppement de logiciels bas\'es sur les composants. L'assemblage de composants logiciels reste un probl\`eme complexe et d\'elicat pour les concepteurs. Dans ce cadre, nous travaillons sur une \'etude fondamentale de la composition/combinaison, au travers notamment, de l'\'etude exhaustive du concept plus g\'en\'eral de relation Tout-Partie. Via ce type de relation, nous souhaitons \'elaborer une m\'ethode de combinaison de composants logiciels. Nous cherchons \`a aboutir \`a un environnement supportant le d\'eveloppement d'applications \`a base de composants et ce, de la phase d'analyse \`a la phase de test. Cet article pr\'esente un panorama relatif sur l'assemblage de composants, synth\'etise le travail formel sur lequel d'autres efforts de recherche portent actuellement, et trace les grandes lignes de nos travaux futurs. |
| Many software development texts.. references.. tools.. and au thorities provide advise on good software design and pro gramming styles Unfortunately.. most of the evidence to support the value of this advise consists of intuition and anecdotes We are working to objectively determine the value of recommended style guides on large scale real world software systems we are studying both proprietary commer cial and open source systems Our work involves determin ing whether or not style recommendations are followed.. and how these styles a ect external quality factors such as fault and change proneness.. and maintainability Early results in dicate that style guidelines are often violated In addition.. we have found that.. in contrast with common claims.. one design recommendation the use of design patterns can lead to more change prone .. rather than less change prone classes |
| A primary expected benefit of object-oriented (OO) methods is the creation of software systems that are easier to adapt and maintain. OO design patterns are especially geared to improve adaptability, since patterns generally increase the complexity of an initial design in order to ease future enhancements. For design patterns to really provide benefit, they must reduce the cost of future adaptation. The evidence of improvements in adaptability through the use of design patterns and other design structures consists primarily of intuitive arguments and examples. There is little empirical evidence to support claims of improved flexibility of these preferred structures. In this case study, we analyze 39 versions of an evolving industrial OO software system to see if there is a relationship between patterns, other design attributes, and the number of changes. We found a strong relationship between class size and the number of changes-larger classes were changed more frequently. We also found two relationships that we did not expect: (1) classes that participate in design patterns are not less change prone-these pattern classes are among the most change prone in the system, and (2) classes that are reused the most through inheritance tend to be more change prone. These unexpected results hold up after accounting for class size, which had the strongest relationship with changes |
| In objectoriented technology, some concepts are so often used that people have no doubt about their meaning (e.g. class, object, method). This is not the case when abstraction concerns lead to the use of some conceptual representations such as an object being part of an other one. Even the standardized notation UML (Unified Modeling Language -- version 1.3) is confusing in some of its definitions. In this paper 1 , we use the benefits from a formal definition for the semantics of the WholePart relationship to improve the metamodel used in the UML. The aim of the proposed specification is for it to be incorporated into version 2.0 of UML. Thus it consists of an incremental improvement to the current metamodel, as well as the introduction of axioms. |
| The morning I sat down to start writing this paper, my contractor called (we’re in the middle of building an addition to our house). He told me the painter would apply one coat of paint to the primed siding. If I wanted a second coat of paint, it would cost $275 extra. Higher quality often costs extra. It struck me how often we make decisions and compromises about quality in our daily lives. Shall I buy a Yugo or a Volvo? Eat at McDonald’s or go home and cook? It all depends on what I need most money, safety, time, nutrition. In eXtreme Programming Explained Kent Beck describes the four variables of software development: Cost, Time, Quality and Scope. As he says, “quality is a strange variable”. If you try to save time or money, or increase scope, by sacrificing quality, you will pay a price in human, business and technical costs. XP teams have the right to do their best work. On the other hand, customers have the right to specify and pay for the only the quality they need. How does one reconcile two potentially conflicting points of view? Is quality negotiable? If so, how do we go about negotiating it? This paper will explore the following questions: • Is quality negotiable? • How can we negotiate quality? • What are internal and external quality, and are either or both negotiable? • What’s the XP tester’s quality assurance role? • How far should testers go in helping the customer define acceptance criteria? |
| Class diagrams (such as those of UML) constitute one of the major benefits of object-oriented programming and design. However, their construction and their evolution pose multiple problems. We think that a good way to approach them consists in proposing to the designers and to the programmers tools able to assist them in this task. The idea that we defend is that a good construction must be systematic, even if it is necessary to improve the results afterwards. In other words, our long-term goal is to automate as much as possible the optimal construction and evolution of class diagrams. Our main practical objective is to integrate our results in UML CASE tools. We describre here the strong ideas of the project and its current state. |
| Fault proneness detection in object-oriented systems is an interesting area for software companies and researchers. Several hundreds of metrics have been defined with the aim of measuring the different aspects of object-oriented systems. Only a few of them have been validated for fault detection, several interesting works with this view have been considered. This paper reports a research study started from the analysis of more than 200 different object-oriented metrics extracted from the literature with the aim of identifying suitable models for the detection of fault-proneness of classes. Such a large number of metrics allows extracting a subset of them in order to obtain models that can be adopted for fault proneness detection. To this end, the whole set of metrics has been classified on the basis of the measured aspect in order to reduce their number to a manageable one; then statistical techniques have been employed to produce a hybrid model comprised of 12 metrics. The work has been focussed on identifying models that can detect as many faulty classes as possible and, at the same time, models that are based on a manageable small set of metrics. A compromise between these aspects and the classification correctness of faulty and non-faulty classes was the main challenge of the research. As a result, two models for fault-proneness classes detection have been obtained and validated. |
| Knowledge management, in particular corporate knowledge management, is a challenge companies and researchers have to meet. The conceptual graph formalism is a good candidate for the representation of corporate knowledge, and for the development of knowledge management systems. But many of the issues concerning the use of conceptual graphs as a metalanguage have not been worked out in detail. By introducing a function that maps higher level to lower level, this paper clarifies the metalevel semantics, notation and manipulation of concepts in the conceptual graph formalism. In addition, this function allows metamodeling activities to take place using the CG notation. |
| A popular trend in current software technology is to gain program portability by compiling programs to an intermediate form based on an abstract machine definition. Such approaches date back at least to the 1970s, but have achieved new impetus based on the current popularity of the programming language {Java{}}. Implementations of language {Java{}} compile programs to bytecodes understood by the {Java{}} Virtual Machine (JVM). More recently Microsoft have released preliminary details of their ".NET" platform, which is based on an abstract machine superficially similar to the JVM. In each case program execution is normally mediated by a just in time compiler (JIT), although in principle interpretative execution is also possible. Although these two competing technologies share some common aims the objectives of the virtual machine designs are significantly different. In particular, the ease with which embedded systems might use small-footprint versions of these virtual machines depends on detailed properties of the machine definitions. In this study, a compiler was implemented which can produce output code that may be run on either the JVM or .NET platforms. The compiler is available in the public domain, and facilitates comparisons to be made both at compile time and at runtime. |
| Nous pr{\'e}sentons dans cet article notre experience dans le domaine de l'utilisation des explications dans le cadre de la programmation par contraintes. Nous pr{\'e}sentons aussi bien l'implementation d'un syst{\`e}me d'explications que les diverses utilisations que l'on peut en faire. Nous pr{\'e}sentons en particulier, outre des utilisations classiques pour le d{\'e}bogage ou la prise en compte de la dynamicit{\'e}, une utilisation plus enfouie qui nous conduit a proposer une nouvelle forme de programmation : programmation par contraintes avec explications. |
| In this paper, we present our experience in using explanations within constraint programming: how to implement an explanation system, what to use explanations for, how to use explanations to develop new algorithms. More precisely, beside classical uses (for debugging and/or solving dynamic problems), we introduce a more in-depth use of explanations that leads to a new kind of constraint programming that we call explanation-based constraint programming (e-constraints). This paper summarizes and extends previous works from the same author. |
| Software patterns such as Gang-of-Four (GOF) design pattern [4], Fowler's analysis pattern [3] and architectural patterns [1] are one of the promising techniques to develop software of high quality efficiently. They are general and abstract structures that frequently appear in past experiences in developing well-structured and maintainable artifacts and can be efficiently re-used for new software development projects. Although many researchers and practitioners jointly have much efforts on collecting and cataloguing patterns [5], it may be difficult for software developers to select suitable patterns and use efficiently them, when we only provide informal descriptions of the patterns like textbooks. To support software development based on patterns, we should model the patterns and its using process as formally or semi-formally as computers can manage, so that a computerized tool like [2] can support software development processes based on software patterns. |
| Many CASE tools support reverse engineering and the UML. However, it can be observed that usually, only a subset of the UML notation is supported, namely those parts with a more or less direct code representation. Although a lot of research is done in this field, the more advanced features of UML notations are not commonly supported in reverse engineering.In this paper, we show approaches to discover patterns in program code that can be represented by means of advanced notational features of UML class diagrams. We obtain the necessary information by reverse engineering {Java{}} programs with different methods. These have been implemented in a prototypical implementation. |
| Recently, there have emerged more sophisticated applications, which have to represent complex objects related with complex relationships, such as aggregations and compositions. New object-relational databases are more appropriated than relational databases to support complex objects. Besides, the most common way of designing databases is using the E/R model, without taking in account the program design. However, new object-oriented design techniques, such as UML (Universal Modelling Language), permit modelling the full system, including the database schema, in a uniform way. Besides, as UML is an extensible language, it allows introducing new stereotypes for specific applications if it is needed. So, new stereotypes for database design can be also defined. The framework of this paper is an Object-Relational Database Design Methodology. The methodology specifies new UML stereotypes for Object-Relational Database Design as well as it proposes some guidelines to translate an UML schema into an object-relational one. The guidelines are based on the SQL:1999 object-relational model and in Oracle8i as an example of product. In this paper we focus on the design of two UML constructors: aggregation and composition. We propose its implementation in Oracle8i, because unlike SQL:1999, Oracle8i supports a data type, the nested table, that is specially appropriated to represent the UML aggregation and composition. |
| Object-oriented (OO) design patterns define collections of interconnected classes that serve a particular purpose. A design pattern is a structural unit in a system built out of patterns, not unlike the way a function is a structural unit in a procedural program or a class is a structural unit in an OO system designed without patterns. When designers treat patterns as structural units, they become concerned with issues such as coupling and cohesion at a new level of abstraction. We examine the notion of pattern coupling to classify how designs may include coupled patterns. We find many examples of coupled patterns; this coupling may be "tight" or "loose", and provides both benefits and costs. We qualitatively assess the goodness of pattern coupling in terms of effects on maintainability, factorability, and reusability when patterns are coupled in various ways |
| Recovering the static structure of legacy source code e.g. as an UML class diagram is quite well understood. In contrast, recovering high-level behaviour diagrams from source code is still an open issue. This paper proposes to use fuzzy pattern detection techniques for the recovery of UML collaboration diagrams from source code. The approach is based on a knowledge base of basic datatypes and of generic collection classes and of code clich\'es for {Java{}} beans and of fuzzy patterns for object structure look-up and modification clich\'es. We handle the diversity of existing code clich\'es by organizing them in an object-oriented hierarchy factorizing important common properties and by relaxing exactness requirements for clich\'e detection with the help of fuzzy theory. We handle the runtime efforts for clich\'e detection using a sophisticated inference mechanism based on generic fuzzy reasoning nets (GFRN's). The work is part of the \ygg@product{Fujaba} case tool aiming to support round-trip engineering for UML and {Java{}}. |
| Object-oriented languages come with pre-defined composition mechanisms, such as inheritance, object composition, or delegation, each characterized by a certain set of composition properties, which do not themselves individually exist as abstractions at the language level. However, often non-standard composition semantics is needed, with a mixture of composition properties, which is not provided as such by any of the standard composition mechanisms. Such non-standard semantics are simulated by complicated architectures that are sensitive to requirement changes and cannot easily be adapted without invalidating existing clients. In this paper, we propose compound references, a new abstraction for object references, that allows us to provide explicit linguistic means for expressing and combining individual composition properties on-demand. The model is statically typed and allows the programmer to express a seamless spectrum of composition semantics in the interval between object composition and inheritance. The resulting programs are better understandable, due to explicitly expressed design decisions, and less sensitive to requirement changes. |
| Dans le cycle de vie d'une librairie ou d'un framework, les \'evolutions sont tr\`es fr\'e-quentes, et aussi bien les utilisateurs que les d\'eveloppeurs sont confront\'es \`a des probl\`emes de recompilation, modification du code, compatibilit\'e ascendante,livraison des nouvelles versions. Devant ces probl\`emes d\'erivant du ``Fragile Base Class problem" , nous pensons que le sous-classement n'est pas la solution la plus adapt\'ee, et proposons une extension de la hi\'erarchie par insertion de super-classes au lieu de sous-classes. Nous appelons cette insertion interclas-sement. Nous d\'ecrivons l'interclassement en montrant comment il peut \^etre impl\'ement\'e et les avantages qui peuvent en \^etre retir\'es. |
| Dynamic analysis is based on collecting data as the program runs. However, raw traces tend to be too voluminous and too unstructured to be used directly for visualization and understanding. We address this problem in two phases: the first phase selects subsets of the data and then compacts it, while the second phase encodes the data in an attempt to infer its structure. Our major compaction/selection techniques include gprof-style N-depth call sequences, selection based on class, compaction based on time intervals, and encoding the whole execution as a directed acyclic graph. Our structure inference techniques include run-length encoding, context-free grammar encoding, and the building of finite state automata. |
| Object-oriented design plays a pivotal role in software development because it determines the structure of the software solution. Once the design has been implemented, it is difficult and expensive to change. Therefore high design quality is vital for reducing software cost, and quality assurance in the design stage has a high return on investment. Unfortunately, it is mostly unclear what design quality really is. This thesis wants to clarify the general notion of design quality and to make design quality measurable. The approach is as follows: The criteria for design quality and their relationships are identified. Then objective and subjective metrics for each criteria are introduced. Together the criteria and the metrics form a quality model for object-oriented design. This model can be used for design assessment both in comparing design alternatives and in design improvement. |
| Object-oriented design plays a pivotal role in software development because it determines the structure of the software solution. Once the design has been implemented, it is difficult and expensive to change. Therefore the design should be good from the start. Metrics can help to evaluate and improve the quality of a design. Many metrics of object-oriented design have been proposed. Unfortunately, most of these metrics lack a precise and unambiguous definition. However, in order to automate design evaluation a precise definition of metrics is needed. Therefore the definitions should be based on a formal model of design. In this paper a formal model for object-oriented design called ODEM (Object-oriented DEsign Model) is presented. This model can serve as a foundation for the formal definition of object-oriented design metrics. ODEM is based on the UML meta-model, that provides a formal model of object-oriented designs expressed in UML, the most widespread design notation. Examples of the use of ODEM for defining object-oriented metrics are given. Two case studies on existing metrics suites for object-oriented design show the benefits of applying ODEM to established object-oriented design metrics. |
| This paper presents a new method of using statistical models to estimate the reading difficulty of Web pages. Language Models are used to represent the content typically associated with different readability levels. Reading level classifiers are created as linear combinations of a language model and surface linguistic features. Experiments show that this new method is more accurate than the widely used Flesch-Kincaid readability formula |
| UML diagrams, and in particular the most frequently used one, the class diagram, represent a valuable source of information even after the delivery of the system, when it enters the maintenance phase. Several tools provide a reverse engineering engine to recover it from the code.In this paper, an algorithm is proposed for the improvement of the accuracy of the UML class diagram extracted from the code. Specifically, important information about inter-class relations may be missed in a reverse engineered class diagram, when weakly typed containers, i.e., containers collecting objects whose type is the top of the inheritance hierarchy, are employed. In fact, the class of the contained objects is not directly known, and therefore no relation with it is apparent from the container declaration.The proposed approach was applied to several software components developed at CERN. Experimental results highlight that a substantial improvement is achieved when the container type information is refined with the inferred data. The number of relations otherwise missed is relevant and the connectivity of the associated class diagrams is radically different when containers are considered. |
| Many authors have proposed using byte code rewriting as a way of adapting or extending the behaviour of {Java{}} classes. There are toolkits available that simplify this process and raise the level of abstraction above byte code. However, to the best of our knowledge, none of these toolkits provide a complete model of behavioural reflection for {Java{}}. In this paper, we describe how we have used load-time byte code rewriting techniques to construct a run-time metaobject protocol for {Java{}} that can be used to adapt and customise the behaviour of {Java{}} classes in a more flexible and abstract way. Apart from providing a better semantic basis for byte code rewriting techniques, our ap-proach also has the advantage over other reflective {Java{}} implementations that it doesn't require a modified com-piler or JVM, can operate on byte code rather than source code and cannot be bypassed. In this paper we describe the implementation of Kava, our reflective implementation of {Java{}}, and discuss some of the linguistic issues and technical challenges involved in implementing such a tool on top of a standard JVM. Kava is available from http://www.cs.ncl.ac.uk/research/dependability/reflection. |
| Design patterns have been eagerly adopted by software developers in recent years. There is ample evidence that patterns can have a beneficial impact on software quality, but in some case patterns have been inappropriately applied due to a lack of experience. This paper reports on a large commercial project where the uncontrolled use of patterns has contributed to severe maintenance problems. As a result a substantial reengineering effort was undertaken, that led to the identification of a number of inappropriately applied patterns. At first glance the elminination of these patterns appears to be desirable, but often they are tighly coupled to other software artefacts, so that their removal is economically not viable. |
| The exception systems of C++ and Java use catch clauses for exception treatment. These clauses are statically attached to try blocks and cannot be reused. We propose an idiom that encapsulates catch clauses into methods of special classes thus giving the benefits of object oriented programming to exception treatment. The result is an easy to use idiom that allows for code reuse and helps to enforce consistence among all exception treatments throughout the program. |
| One of the most commonly recurring (and most complained about) bugs in {Java{}} programming is the null-pointer exception. Tracking down the cause of one of these bugs can truly make you question your career decision. In this installment of Diagnosing {Java{}} Code, we'll continue with our examination of bug patterns by cataloging one of the most common patterns associated with null-pointer exceptions and step through an example of a class that contains it. We will then review several programming techniques that can help you minimize the pattern's occurrence. |
| C++ programmers have long struggled with manual resource management ; resorting to special debugging tools, disciplined use of idioms like smart pointers, and special debug builds of compiler-provided libraries. An entire industry was created to specifically deal with detecting and diagnosing resource management problems in C++ applications. Conversely, VB and {Java{}} programmers have long known the benefit of having a runtime track resource usage on their behalf. As a result, VB and {Java{}} programmers historically keep normal working hours thant do their C++ co-workers. After completing this module, you should be able to: Understand how memory is managed by the CLR; Understand how allocation works in the CLR; Understand how garbage-collection works in the CLR; And, Understand how and why to use finalization. |
| Developing and maintaining Constraint Logic Programs (CLP) requires performance debugging tools based on visualization and explanation. However, existing tools are built in an ad hoc way and porting them from one platform to another is very difficult and experimentation of new tools remains limited. It has been shown in previous work that, from a fine-grained execution trace, a number of interesting views about logic program executions could be generated by trace analysis. In this report, we propose a generic trace model for constraint resolution by narrowing and a methodology to study and improve it. The trace model is the first one proposed for and does not pretend to be the ultimate one. The methodology is based on the following steps: definition of a formal model of trace, extraction of relevant informations by a trace analyzer, utilization of the extracted informations in several debugging tools. We present the trace model and an implementation which includes a tracer, based on a meta-interpreter written in ISO-Prolog, and an opium-like analyzer. The efficiency of the tracer is tested and some elementary debugging tools based on trace analysis are experimented. This work sets the basis for generic analysis of behavior of programs. is a short version of this report. |
| Aspect Oriented Programming (AOP) is an important technique to express modular and orthogonal adaptations of existing software components. Woven into a program, an aspect may change several units of functionality. Existing approaches to AOP require that the programmer deals with two languages: the source language of the application and the aspect language (which describes the aspects to be woven into the system). During program evolution, a developer must understand what program units are actually changed by weaving, check how the changed application behaves, and possibly correct the aspect de nitions. However, rapid AOP prototyping and debugging is di\AE cult with existing platforms because current aspect weaving tools do not supported dynamic changes and a two-language setup creates a barrier between the application code and the aspect code. This paper describes PROSE (PROgrammable extenSions of sErvices), a platform for AOP based on {Java{}} which addresses both problems. Aspects are expressed in the same source language as the application (Java). And PROSE allows aspects to be woven, unwoven, or replaced at run-time. PROSE can also be used as a high-level debugging tool for any program. To illustrate its features, the paper describes an application in which key functionality has been replaced at run-time using the PROSE system. |
| An {eCommerce} site without a profit plan is like a car without gas. It may look nice. It may impress people. It may have cost you an arm and a leg. But in the end, it ain't goin' nowhere. Today, there are two technical visions for {eBusiness} and {eBusiness} collaboration. One of these is the Microsoft vision and goes by the overall name of the .NET platform. The other is the Sun vision and goes by the overall name of {Java 2 Enterprise} Edition (J2EE). In this paper, I will compare and contrast the .NET platform and J2EE. I will focus on the main issues that I believe will drive {eBusinesses} over the next half decade: collaboration and profitability. I will discuss technical details of these two platform, but only where they impact collaboration and profitability. |
| This manual describes the core functional system of COMPOST v0.6. Potential users should read this manual in order to understand the architecture of the system. The COMPOST libraries provide you with a powerful platform for all kinds of {Java{}} source-to-source transformations. However, the use of such a complex system requires quite some knowledge in the fields of programming languages and compiler technology. You have been warned... |
| As source code travels the software lifecycle, the reasoning behind certain design decisions is lost, often leading to violations of high-level constraints and requirements during program maintenance. We present a model called a Design Rationale to Source Graph (DR-SG) that is a graph formed from Design Pattern documentation and linked to a source code base. The DR-SG allows developers to trace design concepts through design documentation down to code. The thesis of this proposed research is that software engineers would could completely and confidently satisfy high-level design goals when performing software change tasks if provided with a semi-automatic technique for tracing from the high level design goals, through design documentation, to source. We will test software engineers' confidence and completeness in satisfying high-level design goals while performing software change tasks by conducting two studies: a controlled experiment, and a set of industrial case studies. |
| The landscape for coding {Palm} OS applications with {Java{}} is far from uniform or level. There are several different APIs currently available, each of which gives a different degree of access to the underlying {Palm} OS API. Perhaps the most well known of these is the one from Sun Microsystems; it is not the only one. This article is not a tutorial on {Palm} programming with {Java{}}~-- each solution discussed has its own challenges and quirks~-- but, rather, an overview of what tools are available for developers. We will survey the landscape to discover what you can expect when developing {Palm} OS applications with {Java{}}. |
| The Eclipse Platform is designed and built to meet the following requirements: \begin{itemize} \item Support the construction of a variety of tools for application development. \item Support an unrestricted set of tool providers, including independent software vendors (ISVs). \item Support tools to manipulate arbitrary content types (e.g., HTML, {Java{}}, C, JSP, EJB, XML, and GIF). \item Facilitate seamless integration of tools within and across different content types and tool providers. \item Support both GUI and non-GUI-based application development environments. \item Run on a wide range of operating systems, including Windows and Linux. \item Capitalize on the popularity of the {Java{}} programming language for writing tools. \end{itemize} The Eclipse Platform's principal role is to provide tool providers with mechanisms to use, and rules to follow, that lead to seamlessly-integrated tools. These mechanisms are exposed via well-defined API interfaces, classes, and methods. The Platform also provides useful building blocks and frameworks that facilitate developing new tools. |
| Scientific study designed to increase our knowledge of natural phenomena can follow at least three different intellectual methods. These can be called the method of the ruling theory, the method of the working hypothesis, and the method of multiple working hypotheses. The first two are the most popular but they can, and often do, lead to ineffective research that overlooks relevant data. Instead, the method of multiple working hypotheses offers a more effective way of organizing one's research. |
| Le projet Lutin vise \`a permettre l'int\'egration forte des patrons de conception et d'architecture dans les ateliers UML, et en particulier dans l'atelier de d\'eveloppement de logiciel Objecteering de la soci\'et\'e Softeam. Les objectifs sont : (1) d'apporter un gain significatif de productivit\'e dans l'utilisation des patrons ; (2) d'encourager l'int\'egration de nouveaux patrons dans l'atelier Objecteering en fournissant un cadre formel, une m\'ethodologie et un outil gratuit pour les d\'ecrire et les y int\'egrer. |
| A unified theory of software patterns is presented through the unification of other existing pattern theories. The resulting new theory resolves two issues that practitioners often find with software patterns and pattern languages: 1) Lack of specificity of software patterns, 2) Lack of specificity in the joint-points in pattern languages. The theories unified in this paper are: 1) the General Pattern Theory from Grenander, 2) the Lepus software patterns theory by Eden and co-workers, and 3) the Alexanderian pattern theory. This unified theory defines commonalities for 1) pattern structure, 2) invariance of relationships on compositions of pattern instances, 3) comparative measurements on candidate patterns, and 4) pattern composition to form functionally and morphologically complete wholes. |
| This article investigates the security issues raised by the use of meta-programming systems in {Java{}}. For each possible type of MOP (compile-time, load-time, etc.), we study what are the permissions required for both the base and the meta-level protection domains, taking into account the flow of control between the different parts of the application. We show that the choice of a particular MOP architecture has a strong impact on the security issues. Another important outcome of this article is the following: in a component-based architecture with code from various origins and trusts, we provide a set of rules for combining the permissions associated with each protection domain (integration, base-level, meta-level, etc.). |
| The paper presents a viewer/editor for object oriented class specifications and hierarchies. The class specifications are represented as a table that hides the extraneous syntactic tokens. The tbale view is customizable in a variety of ways (e.g. column organization, and row ordering) to support the difffering needs of specific types of user roles. That is, the developer of a class is interested in much more information than a client who is just using a class to solve another problem. |
| The implementation of a design pattern typically cannot be reused. Consequently implementing design patterns is a tedious, repetitive and error-prone activity with ample opportunities to make the same mistakes over and over again. We address this issue by automating design-pattern implementation by means of code generators which are defined as declarative logic meta programs generating {Java{}} code and are therefore called declarative code generators. While a reusable code-generator is typically somewhat harder to implement than a single instance of a design pattern, it is worth the effort because: 1.It avoids tedious and error prone copy-paste-edit implementation. 2.The extra effort is not prohibitive because declarative code generation allows the code-generators to be implemented relatively easily. 3.Declarative code generators combine naturally and thus allow for generation of combinations of design patterns. |
| 2000 |
| Written by the inventors of the technology, extit{The Java Language Specification, Second Edition} is the definitive technical reference for the Java programming language. If you want to know the precise meaning of the language's constructs, this is the source for you. The book provides complete, accurate, and detailed coverage of the syntax and semantics of the Java programming language. It describes all aspects of the language, including the semantics of all types, statements, and expressions, as well as threads and binary compatibility. |
| I anatomize a successful open-source project, fetchmail, that was run as a deliberate test of the surprising theories about software engineering suggested by the history of Linux. I discuss these theories in terms of two fundamentally different development styles, the ``cathedral'' model of most of the commercial world versus the ``bazaar'' model of the Linux world. I show that these models derive from opposing assumptions about the nature of the software-debugging task. I then make a sustained argument from the Linux experience for the proposition that ``Given enough eyeballs, all bugs are shallow'', suggest productive analogies with other self-correcting systems of selfish agents, and conclude with some exploration of the implications of this insight for the future of software. |
| Cette th\`ese a \'et\'e r\'ealis\'ee dans le cadre d'une convention CIFRE au sein d'une soci\'et\'e de services en informatique sp\'ecialis\'ee dans la ma\^{\i}trise et l'\'evolution des syst\`emes d'information. La capacit\'e \`a proposer des outils pour appr\'ehender rapidement les syst\`emes d'information existants et de les faire \'evoluer est alors indispensable. |
| La repr\'esentation formelle et symbolique des connaissances repose sur des langages formels compos\'es d'une part de r\`egles syntaxiques g\'en\'eratives pour la construction de formules et d'autre part de r\`egles de composition s\'emantique associant aux formules construites une signification. La construction syntaxique assemble les formules \`a partir de primitives dont le sens se compose pour donner la signification des formules. La t\^ache des ontologies est d\'efinir quelles primitives munies de leur signification sont n\'ecessaires pour la repr\'esentation des connaissances dans un contexte donn\'e. D\'efinir une ontologie est une t\^ache de mod\'elisation men\'ee \`a partir de l'expression linguistique des connaissances. La mod\'elisation s'effectue en trois \'etapes, correspondant \`a trois engagements : un engagement s\'emantique, fixant le sens linguistique des concepts, un engagement ontologique fixant leur sens formel et enfin un engagement computationnel d\'eterminant leur exploitation effective. Nous pr\'esentons ici ces trois types d'engagement et explicitons les \'etapes de l'\'elaboration d'une ontologie. |
| Mature information systems grow old disgracefully as successive waves of hacking result in accidental architectures which resist the reflection of on-going business process change. Such petrified systems are termed legacy systems. Legacy systems are simultaneously business assets and business liabilities. Their hard-won dependability and accurate reflection of tacit business knowledge prevents us from undertaking green-field development of replacement systems. Their resistance to the reflection of business process change prevents us from retaining them. Consequently, we are drawn in this paper to a controlled pattern-oriented legacy system migration strategy. Legacy systems exhibit six undesirable anti-patterns. A legacy system migration strategy must focus upon the controlled elimination of these anti-patterns by the step-wise application of six corresponding desirable patterns. Adherence to this migration strategy results in adaptive systems reflecting purposeful architectures open to the on-going reflection of business process change. Without such a strategy there is a very real danger that legacy system migration will occur all too literally. That is, the old legacy system will be migrated to a new legacy system albeit it one using the latest buzzword-compliant technology. |
| There has been much interest in refactoring recently, but little work has been done on tool support for refactoring or on demonstrating that a refactoring does indeed preserve program behavior. We pro-pose a method for developing composite refactorings for {Java{}} programs in such a way that a rigorous demonstration of behavior preservation is possible. |
| Computational reflection is gaining interest in practical applications as witnessed by the use of reflection in the {Java{}} programming language environment and recent work on reflective middleware. Reflective systems offer many different reflection programming interfaces, the so-called Meta Object Protocols (MOPs). Their design is subject to a number of constraints relating to expressive power, efficiency and security properties. Since these constraints are different from one application to another, we should be able to easily provide specially-tailored MOPs for particular sets of constraints. In this paper, we present a generic reification technique based on program transformation. It enables the selective reification of arbitrary parts of object-oriented language interpreters. The program transformation can be applied to different interpreter definitions. Each resulting reflective implementation provides a different MOP derived from the original interpreter definition. |
| Computational reflection is gaining interest in practical applications: modern software frequently requires strong adaptability conditions to be met in order to fit heterogenous and evolving computing environment. Most of these applications only need limited but flexible reflective capabilities rather than sophisticated reflective languages and reflective runtime systems. However, there is no notion of a reflective application which is independent from an underlying reflective system. Our paper aims at filling this gap by means of a constructive definition: we introduce a reification technique that allows the transformation of non-reflective applications into reflective ones. |
| How to improve the performance of design patterns when they are involved in intensive algorithms? |
| Your team has been assigned to built an end-to-end Web application. As a {Java{}} programmer, you need to focus on the code, to ensure that it can successfully call the required data. Your graphic and Web designers need to focus on the actual presentation to the user, to determine how best to display the information. |
| The SPEC consortium's mission is to develop technically credible and objective benchmarks so that both computer designers and purchasers can make decisions on the basis of realistic workloads. |
| One method suggested for improving software quality has been that of collecting metric scores for a given design, and refactoring in response to what are deemed to be unsatisfactory metric values. More recently, the usage of design patterns has been recommended to promote adaptable designs, so reducing maintenance effort. These two approaches are therefore observed to effectively have the same general aim. The question then arises as to whether design metrics and design patterns are always compatible, and where this is not found to be the case whether the metric, the pattern or both are anomalous. Methods of analysis are presented which demonstrate the effects of applying various patterns on certain metric scores, the initial conclusion being that the two approaches are indeed mainly congruent. |
| Many distributed systems must be scalable, meaning that they must be economically deployable in a wide range of sizes and configurations. This paper presents a scalability metric based on cost effectiveness, where the effectiveness is a function of the system's throughput and its quality of service. It is part of a framework which also includes a scaling strategy for introducing changes as a function of a scale factor, and an automated virtual design optimization at each scale factor. |
| The movement in favor of free and open-source software has recently reached a highly visible status, not only in the computer profession but in the popular media, with mass-circulation magazines as widely available as Time and Newsweek giving prominent coverage to such heroes of the movement as Richard Stallman, Eric Raymond and Linus Torvalds. Although comments on free software in its various form have been overwhelmingly laudatory, little attention has been made to justify this positive assessment and, more generally, to explore seriously the associated ethical issues. |
| Software technology is undergoing a transition from monolithic systems, constructed according to a single overall design, into conglomerates of semi-autonomous, heterogeneous and independently designed subsystems, constructed and managed by di erent organizations, with little, if any, knowledge of each other. Among the problems inherent in such conglomerates none is more serious than the di culty to control the activities of the disparate agents operating in it, and the di culty for such agents to coordinate their activities with each other. We argue that the nature of coordination and control required for such systems calls for the following principles to be satis ed: (1) coordination policies need to be enforced; (2) the enforcement needs to be decentralized; and (3) coordination policies need to be formulated explicitly|rather than being implicit in the code of the agents involved|and they should be enforced by means of a generic, broad spectrum mechanism; and (4) it should be possible to deploy and enforce a policy incrementally, without exacting any cost from agents and activities not subject to it. We describe a mechanism called law-governed interaction (LGI), currently implemented by the Moses toolkit, which has been designed to satisfy these principles. We show that LGI is at least as general as a conventional centralized coordinationmechanism (CCM), and that it is more scalable, and generally more e cient than CCM. |
| In a recent article in Software Development Magazine, Professor Bertrand Meyer critically explores the lack of an ethical or moral grounding for Free / Open software. This rebuttal responds to the deep flaws in Professor Meyer's essay as well as building a moderate's case for the ethical basis of Open and Free software. |
| Software design patterns package proven solutions to recurring design problems in a form that simplifies reuse. We are seeking empirical evidence whether using design patterns is beneficial. In particular, one may prefer using a design pattern even if the actual design problem is simpler than that solved by the pattern, i.e., if not all of the functionality ordered by the pattern is actually required. Our experiment investigates software maintenance scenarios that employ various design patterns and compares designs with patterns to simpler alternatives. The subjects were professional software engineers. In most of our nine maintenance tasks we found positive effects from using a design pattern: either its inherent additional flexibility was achieved without requiring more maintenance time or maintenance time was reduced compared to the simpler alternative. In a few cases we found negative effects: the alternative solution was less error-prone or required less maintenance time. Although most of these effects were expected, a few were surprising: a negative effect occurs although a certain application of the Observer pattern appears to be well justified and a positive effect occurs de- spite superfluous flexibility (and hence complexity) introduced by a certain application of the {Decorator} pattern. Overall, we conclude that unless there is a clear reason to prefer the simpler solution, it is probably wise to choose the flexibility provided by the design pattern, because unexpected new requirements often appear. We identify several questions for future empirical research. |
| Component Models define standards for describing components and mechanisms to build applications out of components. Standard specification are given in natural language and embedded into composition tools. We address the problem of describing protocols for composing components in such a way that they are explicit and become independent from the composition tool. This allows to build generic tools capable of handling different kinds of composition protocols. We propose the use of logic meta-programming to describe the components, describe the protocols for composition and the code that realizes them, specify an application built up from connected components and generate the code for the application. Experiments based on a prototype tool show that these descriptions make the protocols and the tool independent. |
| Iguana/J is a current research project to implement the Iguana reflective architecture for the {Java{}} language. Iguana/J extends the structural reflection provided by the {Java{}} core reflection API to include behavioral reflection, and supports selective reification of behavior for any class, interface or object. It supports a high degree of separation of concerns between base-level and meta-level, allowing separate development and reuse of Iguana/J protocols. The implementation of Iguana/J eliminates of minimises performance degradation for behavior which is not reified. |
| A new method is presented for analyzing and reengineering class hierarchies. In our approach, a class hierarchy is processed along with a set of applications that use it, and a fine--grained analysis of the access and subtype relationship between objects, variables, and class members is performed. The result of this analysis is again a class hierarchy, which is guaranteed to be behaviorally equivalent to the original hierarchy, but in which each object only contains the members that are required. Our method is semantically well-founded in concept analysis: the new class hierarchy is a minimal and maximally factorized concept lattice that reflects the access and subtype relationships between variables, objects and class members. The method is primarily intended as a tool for finding imperfections in the design of class hierarchies, and can be used as the basis for tools that largely automate the process or reengineering such hierarchies. The method can also be used as a space-optimizing source-to-source transformation that removes redundant fields from objects. A prototype implementation for {Java{}} has been constructed, and used to conduct several case studies. Our results demonstrate that the method can provide valuable insights into the usage of a class hierarchy in a specific context, and lead to useful restructuring proposals. |
| Building large systems requires the difficult and time consuming activities of elicitation and representation of software requirements. During these analysis activities, particular analysis abstractions emerge. These abstractions, called analysis patterns, represent reusable patterns for subsequent analysis effort in various domains. As an example, software developers use an analysis abstraction called Person to represent a person from different application domains, such as a student person, employer person or customer person. Martin Fowler, in his book Analysis Patterns, has defined a higher abstraction to represent either a person or an organization labelled the Party pattern. |
| Constrained objects are objects whose state is regulated by constraints. They are applicable in many domains, e.g., engineering and organizational modeling. Our proposed language (Cob) supports class hierarchies, constraints, and preferences; and our computational model supports constraint satisfaction, optimization and relaxation. Constrained objects are thus declarative approach to object-oriented programming. |
| Many class libraries are designed with an emphasis on generality and extensibility. Applications often exercise only part of a library's functionality. As a result, objects created by the application may contain unused (user-specified or compiler-generated) members. Redundant members in objects are undesirable because they increase an application's memory usage. We present an algorithm for specializing a class hierarchy with respect to its usage in a program P. That is, the algorithm analyzes the member access patterns for P's variables, and creates distinct classes for variables that access different members. The algorithm addresses the inheritance mechanisms of {C++} in their full generality, including multiple inheritance and virtual (shared) inheritance. Class hierarchy specialization reduces object size, and can be viewed as a space optimization. However, execution time may also be reduced through reduced object creation or destruction time, and caching and paging effects. Class hierarchy specialization may also create new opportunities for existing optimizations such as call devirtualization and inlining. In addition, specialization may be useful in tools for software maintenance and program understanding. |
| An adaptable software system includes the description of adaptation strategies to be able to change its behavior during run time. This paper analyses the major reflective adaptable systems and proposes a reflective software architecture for object oriented systems which allows objects to change their behavior and interactions during run time. Clear separation among description of functional concerns, adaptation strategies and objects interactions is provided to facilitate reconfiguration of objects and enhance evolution. |
| We propose a software metric to evaluate understandability of OOPs. This metric is composed of a cost formula for understanding based on cognitive science and a model of the understanding process. Unlike Chidamber's metrics, our metric considers instances as well as classes. We have also evaluated understandability of structured programs using this metric. |
| We survey the literature available on the topic of domain-specific languages as used for the construction and maintenance of software systems. We list a selection of 75 key publications in the area, and provide a summary for each of the papers. Moreover, we discuss terminology, risks and benefits, example domain-specific languages, design methodologies, and implementation techniques. |
| This paper describes \ygg@product{IDEA}, an interactive design assistant capable of providing critiques about the design patterns found in a UML{} design model. \ygg@product{IDEA} analyses the UML{} model that the engineer is producing and proposes critiques directed to improve the patter realisations found in the model. The engineer is not required to adopt a modified UML{} notation because \ygg@product{IDEA} automatically detects all possible pattern realisations in a standard UML{} model. The core of \ygg@product{IDEA} is the model that automatically performs this detection. This module analyses class and collaboration diagrams trying to match part of these diagrams with pattern-specific structures. When the pattern-detection module finds a possible pattern realisation, a set of design rules are verified to test if the design can be improved. Any violation of these rules fires a critique that is proposed to the software engineer as a possible design improvement. Currently, \ygg@product{IDEA} is integrated with the user interfaces of two popular CASE tools. |
| Design Patterns have earned a place in the developer's arsenal of tools and techniques for software development. They have proved so useful, in fact, that some have called for their promoting to programming language features. In turn this has rekindled the age-old debate over mechanisms that belong in programming languages versus those that are better served by tools. The debate comes full circle when one contemplates code generation and methodological tool support for patterns. The authors compare and contrast programming languages, tools and patterns to assess their relative merits and to clarify their roles in the development process. |
| The assessment of the changeability of software systems is of major concern for buyers of the large systems found in fast-moving domains such as telecommunications. One way of approaching this problem is to investigate the dependency between the changeability of the software and its design, with the goal of finding design properties that can be used as changeability indicators. In our research, we defined a model of software changes and change impacts and implemented it for the C++ language. Furthermore, we identified a set of nine object-oriented (OO) design metrics, four of which are specifically geared towards changeability detection. The model and the metrics were applied to three test systems of industrial size. The experiment showed a high correlation, across systems and across changes, between changeability and the access to a class by other classes through method invocation or variable access. On the other hand, no result could support the hypothesis that the depth of the inheritance tree has some influence on changeability. Furthermore, our results confirm the observation of others that the use of inheritance is rather limited in industrial systems. |
| The standard reflection API of {Java{}} provides the ability to introspect a program but not to alter program behavior. This paper presents an extension to the reflection API for addressing this limitation. Unlike other extensions enabling behavioral reflection, our extension called \ygg@product{Javassist} enables structural reflection in {Java{}}. For using a standard {Java{}} virtual machine (JVM) and avoiding a performance problem, \ygg@product{Javassist} allows structural reflection only before a class is loaded into the JVM. However, \ygg@product{Javassist} still covers various applications including a language extension emulating behavioral reflection. This paper also presents the design principles of \ygg@product{Javassist}, which distinguish \ygg@product{Javassist} from related work. |
| Software systems ha e to be flexible in order to cope with evolving requirements. However,since it is impossible to predict with certainty what future requirements will emerge, it is also impossible to know exactly what flexibility to build into a system. Design patterns are often used to provide this flexibility, so this question frequently reduces to whether or not to apply a given design pattern. We address this problem by developing a methodology for the construction of automated transformations that introduce design patterns. This enables a programmer to safely postpone the application of a design pattern until the flexibility it provides becomes necessary. Our approach deals with the issues of reuse of existing transformations, preservation of program behaviour and the application of the transformations to existing program code. |
| Object identity combines the distinct notions of reference and comparison. Both notions impose restrictions on the identity concept, resulting in it meeting some lowest common denominator of requirements and limiting its expressive power. By clearly separating the two notions, we can find solutions for yet unresolved problems, for example the problems concerning object identity in the wellknown Decorator Pattern. |
| Designing an object-oriented framework requires an iterative development process, which leads all too easily to missing or incorrect documentation. Iterative framework design involves so-called refactorings: rearrangements of the object-oriented constructs that represent the design. This paper shows that by measuring the changes between different releases of the framework, it is possible to identify which refactorings have been applied and as such reverse engineer the framework design. We expect that our work will result in better documented and consequently more reusable frameworks. |
| The construction of a large class of distributed systems can be simplified by leveraging middleware, which is layered between network operating systems and application components. Middleware resolves heterogeneity, and facilitates communication and coordination of distributed components. Existing middleware products enable software engineers to build systems that are distributed across a local-area net- work. State-of-the-art middleware research aims to push this boundary towards Internet-scale distribution, adaptive and reconfigurable middleware and middleware for dependable and wireless systems. The challenge for software engineering research is to devise notations, techniques, methods and tools for distributed system construction that systematically build and exploit the capabilities that middleware deliver. |
| Software metrics as a subject area is over 30 years old, but it has barely penetrated into mainstream software engineering. A key reason for this is that most software metrics activities have not addressed their most important requirement: to provide information to support quantitative managerial decision-making during the software lifecycle. Good support for decision-making implies support for risk assessment and reduction. Yet traditional metrics approaches, often driven by regression-based models for cost estimation and defects prediction, provide little support for managers wishing to use measurement to analyse and minimise risk. The future for software metrics lies in using relatively simple existing metrics to build management decision-support tools that combine different aspects of software development and testing and enable managers to make many kinds of predictions, assessments and trade-offs during the software life-cycle. Our recommended approach is to handle the key factors largely missing from the usual metrics approaches, namely: causality, uncertainty, and combining different (often subjective) evidence. Thus the way forward for software metrics research lies in causal modelling (we propose using Bayesian nets), empirical software engineering, and multi-criteria decision aids. |
| Tools for the generation of code from model descriptions are valuable in helping developers maintain consistency between a model and its implementation. In this paper, we describe a new method for generating {Java{}} implementation code from UML diagrams. Our method accepts UML diagrams specified at a higher-level than current tools, and places fewer constraints on the supported UML constructs, like multiple generalizations and association classes. Unlike current tools, it generates implementation code that shields system implementers from the low-level details of how associations and other UML constructs are mapped to {Java{}}. Furthermore, it supports the modular design of systems according to concerns [2, 10] by being able to generate code from a set of related UML diagrams. While our discussion is focused on the special problem of generating {Java{}} implementation code, the issues discussed in this paper are applicable more generally to object-oriented implementation languages. |
| Testing is an important process that is performed to support quality assurance. Testing activities support quality assurance by gathering information about the nature of the software being studied. These activities consist of designing test cases, executing the software with those test cases, and examining the results produced by those executions. Studies indicate that more than fifty percent of the cost of software development is devoted to testing, with the percentage for testing critical software being even higher. As software becomes more pervasive and is used more often to perform critical tasks, it will be required to be of higher quality. Unless we can find efficient ways to perform effective testing, the percentage of development costs devoted to testing will increase significantly. This report briefly assesses the state of the art in software testing, outlines some future directions in software testing, and gives some pointers to software testing resources. |
| We describe the challenges of software analysis by presenting a series of dichotomies. Each gives a spectrum on which any partic-ular analysis can be placed; together, they give some structure to the space of possible analyses. Our intent is not, however, to pro-vide a survey of existing analyses within this space, but to argue that some regions are more likely to be important in the future than others. Recognizing that our opinions do not represent the consensus of the community, we have tried, for each dichotomy, to make a case for both extremes (or at least identifying the contexts in which one makes more sense) while arguing primarily for one over the other. We argue that in the future analyses will be model-driven, namely centered on abstract models of behaviour; modular and incremental, to enable analysis of components, and of systems before completion; and focused and partial, rather than uniform, paying closer attention to properties that matter most and to the parts of the software that affect those properties. In support of such analyses, we expect modelling languages to be global,with a focus on structural relationships across the system, and declara-tive, and we expect the analyses themselves to make more use of induction than has been fashionable recently. Finally, although we believe that unsound analyses have a bright future, we expect the increasing importance of infrastructural software to bring a renewed credibility to sound, precise and resource-intensive analyses. |
| Emerging key technologies like the World Wide Web, object-orientation, and distributed computing enable new applications, e.g., in the area of electronic commerce, management information systems, and decision support systems. Today, many companies face the problem that they have to reengineer existing database (DB) applications to take advantage of these technologies. Various computeraided reengineering tools have been developed to reduce the complexity of the reengineering task. However, most of these approaches presume complete structural and semantical information about the DB schema and provide only little support for earlier analysis activities that aim to obtain this information. Such activities are mainly performed manually with the aid of very simple, looselycoupled tools for textual search or data analysis. The reengineer has to judge and combine many different semantic indicators from various sources of information to recover a complete DB schema. In this paper, we present a flexible tool that aims to support the reengineer in these reverse engineering activities. Unlike other tools, our approach does not force the reengineer to follow a strict process or to enter only consistent information. On the contrary, our tool adopts the mental model of its user and deals with imperfect information (uncertainty and contradiction) explicitly. |
| Explanation-based constraint programming is a new way of solving constraint problems: it allows to propagate constraints of the problem, learning from failure and from the solver (thanks to recording explanations) and finally allows to get rid of backtrack-based complete searches by allowing more free moves in the search space (while remaining complete). This paper presents the {PaLM} system, an implementation of an explanation-based constraint programming system in {CHOCO} a constraint programming layer on top of {CLAIRE}. |
| In this paper, we introduce a new solving algorithm for Constraint Satisfaction Problems (CSP). It performs an overall local search together with a domain filtering technique to prune the search space. Conflicts detected during filtering are used to guide the search. First experiments with a tabu version of the algorithm have shown good results on hard instances of open shop scheduling problems. It competes well with the best highly specialized algorithms. |
| Object-oriented programming is about the creation of reusable classes that are to be extended to capture the specific requirements of the application at hand. However, instead of extending the methods of these classes, programmers often introduce subclasses in which they replace methods with new implementations that are completely detached from the superclass; that is, the subclass method does not invoke, directly or indirectly, its counterpart in the superclass.In this paper, we apply the SPOOL environment to the reverse-engineered C++ source code of the ET++ application framework to investigate the occurrences and causes for method replacements. To this end, we define a method replacement indicator (MRI) that quantifies the extent of method replacements. Based on the data obtained in our case study, we identify and discuss the ten causes why programmers replace non-primitive method implementations of reusable classes. |
| Cet article pr\'esente CHOCO, une biblioth\`eque de programmation par contraintes (PPC). D\'evelopp\'ee dans le cadre du projet OCRE. CHOCO est le noyau d'une plate-forme plus large pour la recherche en PPC et en optimisation combinatoire. CHOCO rassemble, dans une architecture orient\'ee-objets, les principaux utilitaires des syst\`emes de PPC, comme les structures de donn\'ees impl\'ementant des domaines de valeurs, les \'ev\'enements de propagation, des algorithmes de filtrage ou encore la recherche arborescente. L'impl\'ementation a \'et\'e faite avec deux objectifs : d'une part offrir une architecture logicielle modulaire qui accepte ais\'ement des extensions, et d'autre part, mettre en \oe uvre une gestion optimis\'ee des \'ev\'enements de propagation. Cet article d\'etaille certains choix de conception, pr\'esente l'architecture logicielle et discute les politiques de gestion et ordonnancement des \'ev\'enements de propagation : nous montrons comment le cadre g\'en\'eral des algorithmes d'arc coh\'erence peut \^etre sp\'ecialis\'e dans quelques cas comme les contraintes arithm\'etiques ou les contraintes globales. |
| Software measurement plays a key role in software engineering and, to improve its performance, an organisation needs to measure software at each stage of the development life cycle. Recently, the COSMIC-FFP measurement method has been developed to improve the measurement of the functional size of a large array of software types. By quantifying software's functional user requirements, the method makes it possible to measure software from the user's viewpoint. The COSMIC-FFP measurement method has been designed based on a software functional model that can represent the functional user requirements at many levels of functional abstraction, such as software layers, functional processes and data movement sub-processes. Developers in general, however, need to know the size of the software early in the development process to support the estimation and project planning process. While the measurement rules of the COSMIIC-FFP method have been designed to be applied when the details of the software functions are known, the method has the required flexibility to capture an estimate of the functional size of software early in the life cycle and to offer added value to the software engineers preparing the development plans. This paper investigates the applicability of COSMIC-FFP for measuring the size of software at early stages of the development life cycle. |
| Correctness constraints provide a foundation for automated debugging within object-oriented systems. This paper discusses a new approach to incorporating correctness constraints into {Java{}} development environments. Our approach uses the Object Constraint Language (``OCL") as a specification language and the {Java{}} Debug Interface (``JDI") as a verification API. OCL provides a standard language for expressing object-oriented constraints that can integrate with Unified Modeling Language (``UML") software models. JDI provides a standard {Java{}} API capable of supporting type-safe and side effect free runtime constraint evaluation. The resulting correctness constraint mechanism: (1) entails no programming language modifications; (2) requires neither access nor changes to existing source code; and (3) works with standard off-the-shelf {Java{}} virtual machines (``VMs"). A prototype correctness constraint auditor is presented to demonstrate the utility of this mechanism for purposes of automated debugging. |
| The main goal with this paper is to motivate and coin a variation of literate programming which we call elucidative programming. Elucidative programming is oriented towards program explanation with the purpose of throwing lights on important and complex program relationships. Since proposed by Knuth i 1984, literate programming has been the most viable approach to a radical improvement of internal program documentation. Unfortunately, most programmers find the ideas of literate programming, as supported by WEB-like tools, for impractical, academic, and far-fetched in relation to present-day programming practices. With elucidative programming, we intend to focus on the best ideas of literate programming. We disregards the aspects of program publication as technical literature, and we provide for mechanisms with which documentation can be added to a program without affecting or disturbing the source program. Our ideas about elucidative programming are presented as a number of requirements, and in a discussion of programming environment issues in relation to the new ideas. |
| Since design patterns emergence, many works have been done to formalize them. Most of these attempts propose a specific model, depending on the goal to reach : pattern instantiation, code documentation with patterns. Because instantiating a pattern or verifying the correctness of a pattern implementation are the most tedious and error prone things to do, we propose to reify design patterns in a meta pattern definition protocol to help the user in these tasks. A tool based on this protocol and using UML modelling has been realized and is explained in this article. |
| We describe a system for gathering and analyzing Java trace data. The system provides relatively complete data collection from large Java systems. It also provides a variety of different analyses of that data for use with a software visualization system. |
| During the evolution of object-oriented (OO) systems, the preservation of a correct design should be a permanent quest. However, for systems involving a large number of classes and that are subject to frequent modifications, the detection and correction of design flaws may be a complex and resource-consuming task. The use of automatic detection and correction tools can be helpful for this task. Various works have proposed transformations that improve the quality of an OO system while preserving its behavior. In this paper, we investigate whether some OO metrics can be used as indicators for automatically detecting situations where a particular transformation can be applied to improve the quality of a system. The detection process is based on analyzing the impact of various transformations on these OO metrics using quality estimation models |
| This paper presents a technique for recovering the high level design of legacy software systems according to user defined architectural plans. Architectural plans are represented using a description language and specify system components and their interfaces. Such descriptions are viewed as queries that are applied on a large data base which stores information extracted from the source code of the subject legacy system. Data mining techniques and a modified branch and bound search algorithm are used to control the matching process, by which the query is satisfied and query variables are instantiated. The matching process allows the alternative results to be ranked according to data mining associations and clustering techniques and, finally, be presented to the user. |
| This paper describes a structured tool demonstration, a hybrid evaluation technique that combines elements from experiments, case studies, and technology demonstrations. Developers of program understanding tools were invited to bring their tools to a common location to participate in a scenario with a common subject system. Working simultaneously, the tool teams were given reverse engineering tasks and maintenance tasks to complete on an unfamiliar subject system. Observers were assigned to each team to find out how useful the observed program comprehension tool would be in an industrial setting. A workshop panel followed the demonstration where the development teams and the observers presented their results and findings from this experience. |
| The Unified Modeling Language (UML) currently proposes a mechanism to model recurrent design structures: the parameterized collaborations. The main goal of this mechanism is to model the structure of Design Patterns. This is an interesting feature because it can help designers to point out pattern application without spending time with intricate design details. Moreover, it can also help designers to better document their systems and to manage their own design pattern library, which could be used in different systems or projects. However, from a tool perspective, the semantics associated to parameterized collaborations is still vague. To put it more precisely, the underlying representation of a design pattern and of its application, and the binding between these two levels is not exactly defined, and therefore, can be interpreted in different ways. This article has two purposes. First, we point out ambiguities and clarify some misunderstanding points concerning parameterized collaborations in the ``official'' UML literature. We also show the limits of this mechanism when effectively modelling design patterns. Second, we propose some work-around for these limits and describe how a tool integrating this mechanism could help with the semi-automatic application of design patterns. |
| The Unix programming environment provides a rich and fairly standard set of generic tools for the development and maintenance of software. In an age of advanced software tools and environments, it is useful to see how new tools compare against an old baseline. The exercise involved performing three tasks: (1) producing summary documentation; (2) evaluating program structure; and (3) reconnoitering future maintenance tasks. Our experiences from one small exercise in maintenance suggest that simple Unix tools seem to raise the bar of excellence deceptively high. |
| This article describes the use of logic programming to represent meta information. The use of logic programming language makes it possible to describe transformations from the extended to the unextended base language. |
| This report discusses architectures for safety-critical sysems. The report summarises the existing literature in the area as well as the guidance provided by existing safety-critical system development standards. We discuss the three constituent functions of fault tolerant architectures: error detection, damage assessment and confinement and error recovery. We also consider methods for fault prevention. |
| A thread is a path of execution through code; in other words, a thread is a single sequential flow of control within a program. What does that mean? In {Java{}}, objects are not ``alive", rather threads are ``alive". Threads run through your code (ie, the methods in your objects). When you invoke the main() method in your class, the {Java{}} Virtual Machine (JVM) creates a thread for you that actually runs the code in this method. Another thread that is always running in the JVM is the garbage collector thread (which makes sure to reclaim memory for objects that are no longer referenced by any other objects). For example, let's say you have a class, called MyClass.java, that has a main() and print() method, shown in Figure 1. When you run this class, by typing \ygg@code{java MyClass} at the command prompt, the JVM creates a thread to run through the \ygg@code{main()} method. At the same time during which the thread is running through your object, the JVM has a garbage collection thread running, ie, they are running concurrently. |
| This row includes information on the object models used in various object analysis and design methods (hence this row itself contains entries for multiple models). The descriptions of these models are based on the descriptions of the methods as published in books. It is important to realize that the object model described here is not necessarily the object model of the author(s); it is the result of an attempt to capture the object model described in the book. The book may have been misinterpreted; the book may have used only a part of the author(s) complete object model; that model may have changed since the publication of the book. |
| A dynamic proxy class is a class that implements a list of interfaces specified at runtime such that a method invocation through one of the interfaces on an instance of the class will be encoded and dispatched to another object through a uniform interface. Thus, a dynamic proxy class can be used to create a type-safe proxy object for a list of interfaces without requiring pre-generation of the proxy class, such as with compile-time tools. Method invocations on an instance of a dynamic proxy class are dispatched to a single method in the instance's invocation handler, and they are encoded with a {Java{}}.lang.reflect.Method object identifying the method that was invoked and an array of type Object containing the arguments. Dynamic proxy classes are useful to an application or library that needs to provide type-safe reflective dispatch of invocations on objects that present interface APIs. For example, an application can use a dynamic proxy class to create an object that implements multiple arbitrary event listener interfaces-- interfaces that extend {Java{}}.util.EventListener-- to process a variety of events of different types in a uniform fashion, such as by logging all such events to a file. |
| qflib is composed of various packages addressing different needs of application development. |
| In refactoring, you make small steps in changing code, to preserve semantics but improve other properties. This paper looks at how you might evolve software to use the Composite pattern, starting from nothing. (See Design Patterns by Gamma et al. for a description of the Composite pattern.) |
| ``Refactoring" is the process of improving the design of code, without affecting its external behavior. (See Martin Fowler's book Refactoring for a full discussion of this subject.) In this article, we'll start with some realistic code, and work our way through several refactorings. We'll see our code become more clear, better designed, and higher quality. What do we need for refactoring? Our original code Unit tests (to assure us we haven't unwittingly changed its external behavior); An environment that lets us change and run code; A way to identify things to improve; A catalog of refactorings to apply; A process to guide us |
| Jon Bentley wasn't using the term ``refactoring" in his books like Writing Efficient Programming, but many of his optimization guidelines can be looked at that way. This paper describes several of those rules, and points out a few subtleties concerning them. The refactoring rules in Writing Efficient Programs tend to be at a lower level than the refactorings described in M. Fowler's Refactoring book: they're focused more on performance issues, sometimes even at the expense of code readability. (If you use these rules for performance tuning, measure your program to ensure that performance is actually improving: some rules work better ``forward" on some machines and ``backwards" on others, and some can interfere with what your compiler does.) Not all the rules are strictly performance-based: some will enhance your understanding of what the program does. |
| {CFParse} is a low-level API that allows you to read, write and create class files. While this distribution is primarily a set of APIs, it also comes with some example applications that are built on top of {CFParse}. In addition, a set of tutorials is included. |
| Factory An interface for creating related Factory Method objects without specifying the concrete class. Builder Separates the construction process Indirect Create, of an object from the representation. Indirect Read, Indirect Write Factory Method An interface for creating an object Indirect Create without knowing its concrete class. Prototype New instances are created by Indirect Create copying a prototype. Singleton Ensures that only a single instance - of a class exists at a time. |
| This document provides task-oriented information on using the XMI Toolkit. The XMI Toolkit utilizes XML for Metadata Interchange technology to perform conversion between object-oriented analysis models developed in Rational Rose and {Java{}}. |
| This document describes the interface of the CHOCO kernel. This interface describes the objects and methods of CHOCO that may be used by applications. Therefore, you should keep this document as a reference manual if you write applications with the OCRE platform. This interface is a reference document stating what CHOCO can do; for a description of how it does so, or how it can be extended, the reader should refer the other document: ``Inside CHOCO". |
| The {Java{}} virtual machine is designed to support the {Java{}} programming language. Sun's JDK releases and {Java{}} 2 SDK contain both a compiler from source code written in the {Java{}} programming language to the instruction set of the {Java{}} virtual machine, and a runtime system that implements the {Java{}} virtual machine itself. Understanding how one compiler utilizes the {Java{}} virtual machine is useful to the prospective compiler writer, as well as to one trying to understand the {Java{}} virtual machine itself. Although this chapter concentrates on compiling source code written in the {Java{}} programming language, the {Java{}} virtual machine does not assume that the instructions it executes were generated from such code. While there have been a number of efforts aimed at compiling other languages to the {Java{}} virtual machine, the current version of the {Java{}} virtual machine was not designed to support a wide range of languages. Some languages may be hosted fairly directly by the {Java{}} virtual machine. Other languages may be implemented only inefficiently. Note that the term ``compiler" is sometimes used when referring to a translator from the instruction set of a {Java{}} virtual machine to the instruction set of a specific CPU. One example of such a translator is a just-in-time (JIT) code generator, which generates platform-specific instructions only after {Java{}} virtual machine code has been loaded. This chapter does not address issues associated with code generation, only those associated with compiling source code written in the {Java{}} programming language to {Java{}} virtual machine instructions. |
| The Abstract Window Toolkit (AWT) supports Graphical User Interface (GUI) programming. AWT features include: A rich set of user interface components; A robust event-handling model; Graphics and imaging tools, including shape, color, and font classes; Layout managers, for flexible window layouts that do not depend on a particular window size or screen resolution; Data transfer classes, for cut-and-paste through the native platform clipboard. |
| The idea of software quality is a very broad subject. Much has been written about quality in general and software quality in particular (for example see the Bibliography). This is very informative body of work and there is no desire to repeat it all here. The subject of software quality covers the customer viewpoint, of satisfaction with the software supplier s processes and of the perceived product quality, performance, fitness for purpose , etc. It covers, among other topics, the developers view of whether the software is easy and cheap to build and maintain, the ease with which software defects may be prevented, detected and corrected, etc. Some of the most commonly quoted measures of software quality are those incorporating measures of software defects and these measures are of common interest to both customers and to software developers. However, although there is much concern with software failures and their various causes, there seems to be little consensus regarding the definition of their measurable characteristics. Therefore, the UKSMA Metrics Practices Committee has set out to present a set of standards that will describe UKSMA s view of the subject. This document is intended to provide members with useful definitions around the subject of measuring defects and using those measures to facilitate measurement, comparison and discussion. |
| And here we go again, with a small overview of what the MOOSE code model with its search for a language independent representation of source code achieves, and where it fails (or at least his rough edges) and some polishing might come handy. |
| Design patterns are considered one of the most valuable tools to produce quality designs and a general-purpose technique to improve design is to identify all pattern realization and to apply well-known rules to improve them. This technique requires finding all pattern realizations used in a design and it is a rather tedious task. This paper shows the work in the literature an assistants for programmers and software architects and presents a system called IDEA (Interactive DEsign Assistant). IDEA is an interactive design assistant for software architects meant for automating the task of finding and improving the realizations of design patterns. Basically, IDEA is capable of automatically ( extit{i}) finding the patterns employed in a UML{} diagram and ( extit{ii}) producing critiques about these patterns. The core IDEA is the module that automatically detects the pattern realizations found in the model that the architect is producing. When this module finds a pattern realization, a set of design rules are verified to test if the design could be improved. Any violation to these rules fires a critique that is proposed to the engineer as a possible design improvement. Currently, a prototypal implementation of IDEA is integrated with two popular CASE tools. |
| Current programming environments for user interface development provide visual programming techniques to aid in using object-oriented and component technology concepts. We suggest a clear separation of visualizations for component assembly on the one hand and object-oriented programming on the other hand, and present metaphors and a programming environment. |
| Vous d\'ecouvrirez lors de ce s\'eminaire comment utiliser les nouvelles possibilit\'es offertes par Windows 2000, COM et COM+ pour le d\'evelopement d'une application multi-niveaux \`a base de composants. |
| What is the difference between aggregation and composition and how they are represented in \ygg@product{Rose}? |
| A code smell is a hint that something has gone wrong somewhere in your code. Use the smell to track down the problem. Kent Beck seems to have coined the phrase in {OnceAndOnlyOnce}. Highly experienced and knowledgeable developers have a ``feel" for good design. Having reached a state of {``UnconsciousCompetence"}, where they routinely practice good design without thinking about it too much, they find that they can look at a design or the code and immediately get a ``feel" for its quality, without getting bogged down in extensive ``logically detailed arguments". |
| Les techniques mises en avant dans les d\'eveloppements \`a objets, et permettant d'en assurer r\'eutilisabilit\'e, \'evolutivit\'e et facilit\'e de maintenance, sont d\'ej\`a fort bien connues mais trop peu souvent bien ma\^{\i}tris\'ees. Dans certains cas par exemple la seule technique de r\'eutilisation appliqu\'ee est l'h\'eritage alors que ce n'est ni la seule, ni la plus souple. Les principes de base `` d'isolations " ne sont g\'en\'eralement pas respect\'es. La distinction entre interface et impl\'ementation, lorsqu'elle est pr\'esente, n'est que trop rarement suffisamment explicite… Il appara\^{\i}t clairement que ce genre de consid\'erations n'est couvert ni par les m\'ethodes, ni par les langages, et le fait de les utiliser ne donne en rien l'assurance de produire du logiciel de qualit\'e b\'en\'eficiant de toutes les propri\'et\'es et qualit\'es li\'ees \`a la technologie des objets . C'est \`a ce niveau que l'utilisation d'un catalogue de `` patterns " contenant tout le savoir-faire capitalis\'e en interne et / ou en externe par la soci\'et\'e prend tout son sens. En revanche, et contrairement aux autres concepts objets, il n'existe pas \`a ce jour d'outil support vraiment efficace et souple pour en g\'en\'eraliser ou syst\'ematiser l'utilisation. |
| 1999 |
| Software development projects can be fun, productive, and even daring. Yet they can consistently deliver value to a business and remain under control. Extreme Programming (XP) was conceived and developed to address the specific needs of software development conducted by small teams in the face of vague and changing requirements. This new lightweight methodology challenges many conventional tenets, including the long-held assumption that the cost of changing a piece of software necessarily rises dramatically over the course of time. XP recognizes that projects have to work to achieve this reduction in cost and exploit the savings once they have been earned. You may love XP or you may hate it, but extit{Extreme Programming Explained} will force you to take a fresh look at how you develop software. |
| Introduced in 1997, the Unified Modeling Language (UML) has rapidly been accepted throughout the software industry as the standard graphical language for specifying, constructing, visualizing and documenting software-intensive systems. The UML provides anyone involved in the production, deployment, and maintenance of software with a standard notation for expressing a system's blueprint. The UML covers conceptual things, such as business processes and system functions, as well as concrete things, such as programming-language classes, database schemas, and reusable software components. In extit{The Unified Modeling Language User Guide}, the original developers of the UML---Grady Booch, James Rumbaugh, and Ivar Jacobson---provide a tutorial to the core aspects of the language in a two-color format designed to facilitate learning. Starting with a conceptual model of the UML, the book progressively applies the UML to a series of increasingly complex modeling problems across a variety of application domains. This example-driven approach helps readers quickly understand and apply the UML. For more advanced developers, the book includes a learning track focused on applying the UML to advanced modeling problems. With extit{The Unified Modeling Language User Guide}, readers will: \begin{itemize} \item Understand what the UML is, what it is not, and why it is relevant to the development of software-intensive systems. \item Master the vocabulary, rules, and idioms of the UML in order to ``speak" the language effectively. \item Learn how to apply the UML to a number of common modeling problems. \item See illustrations of the UML's use interspersed with use cases for specific UML features. \item Gain insight into the UML from the original creators of the UML. \end{itemize} |
| The nucleus of the Java 2 platform, the Java virtual machine is the technology that enables the Java 2 platform to host applications on any computer or operating system without rewriting or recompiling. The Java virtual machine is also responsible for the compactness of applications targeting the Java 2 platform, and is the basis for its security capabilities. This book was written by those directly responsible for the design and implementation of the Java virtual machine, and is the complete and definitive specification for the technology. It is an essential reference for writers of compilers for the Java programming language and implementors of the Java virtual machine. This second edition specifies the newest version of the Java virtual machine and provides a fascinating view into the inner workings of the Java 2 platform. In this book you will find comprehensive coverage of the class file format, the hardware, operating system, and implementation-independent binary format for compiled code. The authors fully describe the instruction set of the Java virtual machine. You will find an entire chapter of examples that demonstrate how to compile code written in the Java programming language into the instruction set of the Java virtual machine. In addition, the book presents a discussion on the vital topic of Java virtual machine threads and their interaction with memory. All in all, this comprehensive, detailed, and methodical presentation provides the information necessary to implement your own fully compatible Java virtual machine. |
| This book revolutionizes how vision can be taught to undergraduate and graduate students in cognitive science, psychology, and optometry. It is the first comprehensive textbook on vision to reflect the integrated computational approach of modern research scientists. This new interdisciplinary approach, called ``vision science," integrates psychological, computational, and neuroscientific perspectives. The book covers all major topics related to vision, from early neural processing of image structure in the retina to high-level visual attention, memory, imagery, and awareness. The presentation throughout is theoretically sophisticated yet requires minimal knowledge of mathematics. There is also an extensive glossary, as well as appendices on psychophysical methods, connectionist modeling, and color technology. The book will serve not only as a comprehensive textbook on vision, but also as a valuable reference for researchers in cognitive science, psychology, neuroscience, computer science, optometry, and philosophy. |
| The Unified Modeling Language (UML) has rapidly become the standard notation for modeling software-intensive systems. This book provides the definitive description of UML from its original developers--James Rumbaugh, Ivar Jacobson, and Grady Booch. Whether you are capturing requirements, developing a software architecture, designing the implementation, or trying to understand an existing system, this is the book for you. The majority of the book is a unique alphabetical list of articles covering every aspect of UML in a form convenient for quick reference and detailed study. This format permits full coverage of UML details as well as high-level articles without confusing the reader by constant shifts in level. The first part of the book--a complete summary of UML concepts organized by subject area--provides an introduction to UML for the newcomer as well as entry points into the detailed articles. Highlights of the book include: \begin{itemize} \item Two-color diagrams, extensively annotated. \item Thorough coverage of both semantics and notation, separated in each article for easy reference. \item Further explanations of concepts whose meaning or purpose is obscure in the original specifications. \item Discussion sections offering usage advice and additional insight into tricky concepts. \item A hyperlinked version of the book in Adobe Reader format on CD-ROM, an excellent resource for browsing or searching the text for specific information. \item Full text of the UML{} specification documents on CD-ROM, courtesy of the Object Management Group. \item Notation summary, with hyperlinks to individual articles on CD-ROM. \end{itemize} |
| The purpose of Experimentation in Software Engineering: An Introduction is to introduce students, teachers, researchers, and practitioners to experimentation and experimental evaluation with a focus on software engineering. The objective is, in particular, to provide guidelines for performing experiments evaluating methods, techniques and tools in software engineering. The introduction is provided through a process perspective. The focus is on the steps that we go through to perform experiments and quasi-experiments. The process also includes other types of empirical studies. The motivation for the book emerged from the need for support we experienced when turning our software engineering research more experimental. Several books are available which either treat the subject in very general terms or focus on some specific part of experimentation; most focus on the statistical methods in experimentation. These are important, but there were few books elaborating on experimentation from a process perspective, none addressing experimentation in software engineering in particular. The scope of Experimentation in Software Engineering: An Introduction is primarily experiments in software engineering as a means for evaluating methods, techniques and tools. The book provides some information regarding empirical studies in general, including both case studies and surveys. The intention is to provide a brief understanding of these strategies and in particular to relate them to experimentation. Experimentation in Software Engineering: An Introduction is suitable for use as a textbook or a secondary text for graduate courses, and for researchers and practitioners interested in an empirical approach to software engineering. |
| Les patterns de conception repr\'esentent des connaissances des concepteurs de logiciels relatives \`a la description de probl\`emes r\'ecurrents de conception et de leurs solutions. Toutefois, ces connaissances sont insuffisantes pour \^etre directement mises en oeuvre. En effet, il reste \`a effectuer un certain nombre de choix d'impl\'ementation, fortement li\'es \`a la sp\'ecificit\'e de l'environnement retenu pour la r\'ealisation du logiciel. De plus, suivant le contexte applicatif dans lequel la mise en oeuvre du pattern doit \^etre int\'egr\'ee, un certain nombre de contraintes doivent \^etre respect\'ees. La combinaison de ces choix d'impl\'ementation et de ces contraintes entra\^{\i}ne la possibilit\'e d'un grand nombre d'impl\'ementations diff\'erentes pour un m\^eme pattern. D'autre part, chacune de ces impl\'ementations est trop sp\'ecifique pour \^etre r\'eutilis\'ee dans des situations similaires. Cette th\`ese offre un aper\c cu des fonctionnalit\'es d'un outil de g\'en\'eration automatique de code utilisant les patterns de conception. Cet outil permettra d'expliciter les instances de patterns utilisables durant la conception. Chaque instance sp\'ecifique d'un pattern int\`egre les compromis d'impl\'ementation li\'es aux classes qui le composent. Gr\^ace \`a des bases de r\`egles de production, l'outil peut sugg\'erer des changements de conception et g\'en\'erer le code source de la variante d'impl\'ementation la plus indiqu\'ee pour chaque cas. |
| The authors offer a catalogue of problems experienced by developers, using various object modelling techniques brought into prominence by the widespread adoption of UML standard notations. The catalogue is revised to reflect changes made between UML versions 1.1 and 1.3, in which a number of semantic inconsistencies in the notation were fixed. Notwithstanding this, developers still seem to create inordinate problems for themselves by pursuing unproductive development strategies that are apparently fostered by UML. This article shows how the biggest problem by far is cognitive misdirection, or the apparent ease with which the rush to build UML models may distract the developer from important perspectives on a system. This problem is more serious than the outstanding inconsistencies and ambiguities which still exist in UML 1.3. A number of inadequacies are also highlighted, where UML somehow fails to express what we believe are important semantic issues. While UML itself is mostly neutral with respect to good or bad designs, the consequences allowing UML to drive the development process include: inadequate object conceptualization, poor control structures and poorly-coupled subsystems. |
| In this almost-verbatim transcript of his keynote talk at OOPSLA 1996, Alexander discusses the history and significance of patterns and pattern languages, his more recent work on the nature of wholeness and aesthetics, and the ongoing relationship between his field and that of software development. Jim Coplien sets the stage in his introduction. |
| There is an increasing demand for software that matches real user needs in a working environment. The paper describes the new framework for software product quality developed for ISO/IEC 9126-1: internal quality (static properties of the code), external quality (behavior of the software when it is executed) and quality in use (the extent to which the software meets the needs of the user). Quality in use is a broader view of the ergonomic concept of usability in ISO 9241-11. Achieving quality in use requires a user-centered design process which has cultural, strategic and technical implications. |
| Avec l'\'emergence des patterns de conception, plusieurs outils ont \'et\'e propos\'es pour supporter une utilisation et une application automatis\'ee des patterns dans des cas concrets. Cet article pr\'esente une revue d'un ensemble repr\'esentatif de ces outils, d\'etaillant, en plus de leur objectif et de leurs fonctionnalit\'es, les types de repr\'esentation adopt\'es pour les patterns et les choix li\'es \`a leur impl\'ementation. |
| The increasing importance being placed on software measurement has lead to an increased amount of research developing new software measures. Given the importance of object-oriented development techniques, one specific area where this has occurred is coupling measurement in object-oriented systems. However, despite a very interesting and rich body of work, there is little understanding of the motivation and empirical hypotheses behind many of these new measures. It is often difficult to determine how such measures relate to one another and for which application they can be used. As a consequence, it is very difficult for practitioners and researchers to obtain a clear picture of the state-of-the-art in order to select or define measures for object-oriented systems. This situation is addressed and clarified through several different activities. First, a standardized terminology and formalism for expressing measures is provided which ensures that all measures using it are expressed in a f... |
| This work presents the geometrical and statistical foundations of a three-dimensional model of a software project performance model called (Quality factor + Economic, Social and Technical dimensions). In this model, the three dimensions taken into consideration are combined through the use of a regular tetrahedron geometrical representation of a pyramid, the sides of which represent the normalised values of each of the project dimensions being measured and the apex represents the normalised... |
| In 1961 or 1962, Fred Brooks approached Jerry Weinberg at the IBM Systems Research Institute in New York and asked him whether he thought the term architect was suitable for software system people. At the time, Weinberg had already been incorporating ideas from architecture in his course on system development. Brooks was concerned about the fidelity of the analogy, but it seemed to hold in their ensuing discussions as they fleshed it out. From then on, the term became a fixture of the discourse on software design. |
| The representation and management of meta-information is an important issue in reflective architectures. In the case of complex base-level systems, such as middleware plat-forms, this issue becomes even more crucial, given the large number of entities of different kinds that must be dealt will and, especially, given the fact that such entities are normally distributed, which makes difficult to maintain their consistency. In this paper we present our approach to represent and maintain middleware meta-information and show how it is integrated with our reflective architecture for middleware, which is based on the idea of multi-model reflection. The result is a principled way to control the use and evolution of meta-information in the platform, also offering a means to harness the power of reflection. The paper also outlines our implementation of the approach. |
| "I wasn't a very good designer, but then I read some books on patters--and now I am a real good designer." This quote from one of the participants of the Patterns Fish Bowl discussion at last year's OOPSLA made me cringe. Here is the sad confession of a cool fool with a tool--Pat Terna Buser. |
| Code duplication is one of the factors that severely complicates the maintenance and evolution of large software systems. Good tools for detecting duplicated code are scarce because of the large amount of data to be checked, because duplicated code is not known a priori and because especially it requires parsing technology. In this paper we show that is possible to circumvent these complicating factors by applying a language independent and lightweight approach, i.e. a tool that requires no parsing and a little learning and configuration time, yet is able to detect a significant amount of code duplication. We validate our approach on a number of case studies, involving five different implementation languages and ranging from 256K up until 26Mb of source code. |
| Traces of program executions are a helpful source of information for automated debugging. They, however, usually give a too low level picture of the executed program. Opium, our extendable trace analyser for Prolog, is connected to a «standard» tracer. Opium is programmable and extendable. It provides a trace query language and abstract views of executions which solve the problems of low-level traces. Opium has shown its capabilities to build abstract tracers and automated debugging facilities. This article describes the trace query mechanism, from the model to its implementation. Characteristic examples are detailed. Extensions written so far on top of the trace query mechanism are listed. Two recent extensions are presented: the abstract tracers for the LO (Linear Objects) and the CHR (Constraint Handling Rules) languages. These two extensions were specified and implemented within a few days. They show how to use Opium for real applications. |
| Eye movement-based analysis can enhance traditional performance, protocol, and walk-through evaluations of computer interfaces. Despite a substantial history of eye movement data collection in tasks, there is still a great need for an organized de"nition and evaluation of appropriate measures. Several measures based upon eye movement locations and scanpaths were evaluated here, to assess their validity for assessment of interface quality. Good and poor interfaces for a drawing tool selection program were developed by manipulating the grouping of tool icons. These were subsequently evaluated by a collection of 50 interface designers and typical users. Twelve subjects used the interfaces while their eye movements were collected. Compared with a randomly organized set of component buttons, well organized functional grouping resulted in shorter scanpaths, covering smaller areas. The poorer interface resulted in more, but similar duration, fixations than the better interface. Whereas the poor interface produced less efficient search behavior, the layout of component representations did not influence their interpretability. Overall, data obtained from eye movements can signi"cantly enhance the observation of users' strategies while using computer interfaces, which can subsequently improve the precision of computer interface evaluations. |
| Based on previous detailed analyses of the semantics of aggregation in object modelling which indentify primary axioms which all forms of aggregation must possess together with secondary characteristics which define various ``flavours'' of aggregation, we study the semantics of UML's composition and shared aggregation. We conclude that both kinds of UML's Aggregation do not possess the full complement of primary characteristics and that their secondary characteristics are overlapping and incomplete. We recommend revisions to UML's two kinds of aggregation: completion of the primary set of axiomatic characteristics and then careful selection of secondary characteristics. |
| Software architectures play a critical role in coordinating software projects by creating workable divisions of labor. The authors describe the various means used to coordinate project work; how unanticipated events limit effectiveness; and how geographic, cultural, and organizational separation disrupt multisite communication. |
| When do you need to follow good software practice? Should a software system always have a fully designed architecture at the beginning? This article discusses the issues that software developers tackle in today's rapidly evolving software environment. To meet these needs, the authors introduce models and tools for a new methodology: inferred designs. |
| {Java{}} class files are often distributed as jar files, which are collections of individually compressed class files (and possibly other files). Jar files are typically about 1/2 the size of original class files due to compression. I have developed a wire-code format for collections of {Java{}} class files. This format is typically 1/2 to 1/5 of the siwe of the corresponding compressed jar file (1/4 to 1/10 the size of the original class files). |
| The scope of software visualization tools which exist for the navigation, analysis and presentation of software information varies widely. One class of tools, which we refer to as Software exploration tools, provides graphical representations of static software structures linked to textual views of the program source code and documentation. This paper describes a hierarchy of cognitive issues which should be considered during the design of a software exploration tool. The hierarchy of cognitive design elements is derived through the examination of program comprehension cognitive models. Examples of how existing tools address each of these issues are provided. In addition, this paper demonstrates how these cognitive design elements may be applied to the design of an effective interface for software exploration. |
| KABA is a prototype implementation of the Snelting/Tip analysis for {Java{}}. KABA combines dataflow analysis, type inference and concept lattices in order to perform a fine-grained analysis of member-access patterns in a class hierarchy together with a given set of applications. KABA computes a transformed hierarchy which is guaranteed to be 1. operationally equivalent, 2. maximally factorized, 3. minimal. The new hierarchy in particular makes obvious which classes can be split and which cannot; which inheritance relations must be retained and which can be discarded. The paper presents several case studies on medium-sized {Java{}} programs. |
| Our experience of using {Java{}} is disappointing: as a programming language (irrespective of its implementations and libraries) {Java{}} itself leaves much to be desired. This paper discusses a few serious problems with {Java{}}'s design, which leads us to suggest that the language definition should have been an integral part of the design process rather than, as appears, a retrospective commentary. |
| {Java{}} programs are routinely transmitted over low-bandwidth network connections as compressed class file archives (i.e. zip files and jar files). Since archive size is directly proportional to download time, it is desirable for applications to be as small as possible. This paper is concerned with the use of program transformation such as removal of dead methods and fields, inlining of method calls, and simplification of the class hierarchy for reducing application size. Such ``extraction" techniques are generally believed to be especially useful for applications that use class libraries, since typically only a small fraction of a library's functionality is used. By ``pruning away" unused library functionality, application size can be reduced dramatically. We implemented a number of application extraction technique in {Jax}, an application extractor for {Java{}}, and evaluate their effectiveness on a set of realistic benchmarks ranging from 27 to 2,332 classes (with archives ranging from 56,796 to 3,810,120 bytes). We report archive size reductions ranging from 13.4\% to 90.2\% (48.7\% on average). |
| This article investigates the security problems that may ap- pear with the use of meta-programming extensions to the {Java{}} language and also how meta-programming may help in expressing and implementing security policies. Depending on the moment when the shift from the base-level to the meta-level is performed, we present different security problems and their consequences. We also raise a number of issues related to security and meta-programming that we hope will result in fruitful discussions within the meta- programming community. |
| Growing maintenance costs have become a major concern for developers and users of software systems. Changeability is an important aspect of maintainability, especially in environments where software changes are frequently required. In this work, the assumption that high-level design has an influence on maintainability is carried over to changeability and investigated for that quality characteristics. The approach taken to assess the changeability of an object-oriented (OO) system is to compute the impact of changes made to classes of the system. A change impact model is defined at the conceptual level and mapped on the {C++} language. In order to assess the practicality of the model on large industrial software systems, an experiment involving the impact of one change is carried out on a telecommunications system. The results suggest that the software can easily absorb that kind of change and that well chosen conventional OO design metrics can be used as indicators of changeability. |
| In reengineering legacy code it is frequently useful to introduce a design pattern in order to add clarity to the system and thus facilitate further program evolution. We show that this type of transformation can be automated in a pragmatic manner and propose a methodology for the development of design pattern transformations. We address the issues of the definition of a starting point for the transformation, the decomposition of a pattern into minipatterns and the development of corresponding minitransformations that can introduce these minipatterns to a program. The architecture of an existing software prototype is also discussed and the results of applying this methodology to develop a transformation for the Factory Method pattern are presented. |
| The evolution of software systems over many years often leads to unnecessarily complex and in inextensible designs which in turn lead to a huge amount of effort for enhancements and maintenance. Thus, the reengineering of object-oriented software becomes more and more important as the number, age and size of such legacy systems grow. A key issue during reengineering is the identification and location of design problems which prevent the efficient further development of a system. Up to now this problem area has not been sufficiently supported, either by methods, or by tools. In this paper, we present a technique for analyzing legacy code, specifying frequent design problems as queries and locating the occurrences of these problems in a model derived from source code. We present our experiences with a tool set which we implemented to support this task by automatically analyzing a given system and detecting the specified problems. We applied our tools to check violations of a number of well-known design rules in existing source code taken from several case studies, both from industrial and academic fields. These experiments showed that the task of problem detection in reengineering can be automated to a large degree, and that the technique presented can be efficiently applied to real-world code. |
| UML{} is currently embraced as ``the" standard in object-oriented modeling languages, the recent work of \ygg@company{OMG} on the \ygg@product{Meta Object Facility} (\ygg@product{MOF}) being the most noteworthy example. We welcome these standardisation efforts, yet warn against the tendency to use UML{} as the panacea for all exchange standards. In particular, we argue that UML{} is not sufficient to serve as a tool-interoperability standard for integrating round-trip engineering tools, because one is forced to rely on UML{}'s built-in extension mechanisms to adequately model the reality in source-code. Consequently, we propose an alternative meta-model (named FAMIX), which serves as the tool interoperability standard within the FAMOOS project and which includes a number of constructive suggestions that we hope will influence future releases of the UML{} and \ygg@product{MOF} standards. |
| We present Coca, an automated debugger for C, where the breakpoint mechanism is based on events related to language constructs. Events have semantics whereas source lines used by most debuggers do not have any. A trace is a sequence of events. It can be seen as an ordered relation in a database. Users can specify precisely which events they want to see by specifying values for event attributes. At each event, visible variables can be queried. The trace query language is Prolog with a handful of primitives. The trace query mechanism searches through the execution traces using both control flow and data whereas debuggers usually search according to either control flow or data. As opposed to fully «relational» debuggers which use plain database querying mechanisms, Coca trace querying mechanism does not require any storage. The analysis is done on the fly, synchronously with the traced execution. Coca is therefore more powerful than «source line» debuggers and more efficient than relational debuggers. |
| The Unifed Modeling Language (UML) is a standard modeling language in which some of the best object-oriented (OO) modeling experiences are embedded. In this paper we illustrate the role formal specification techniques can play in developing a precise semantics for the UML. We present a precise characterization of requirements-level (problem-oriented) Class Diagrams and outline how the characterization can be used to semantically analyze requirements Class Diagrams. |
| Several techniques have been suggested for supporting reverse engineering and design recovery activities. While many of these techniques have been cataloged in various collections and surveys, the evaluation of the corresponding support tools has focused primarily on their usability and supported source languages, mostly ignoring evaluation of the appropriateness of the by-products of a tool for facilitating particular types of maintenance tasks. In this paper, we describe criteria that can be used to evaluate tool by-products based on semantic quality, where the semantic quality measures the ability of a by-product to convey certain behavioral information. We use these criteria to review, compare, and contrast several representative tools and approaches. |
| A program's object model captures the essence of its design. For some programs, no object model was developed during design; for others, an object model exists but may be out-of-sync with the code. This paper describes a tool that automatically extracts an object model from the classfiles of a {Java{}} program. Unlike existing tools, it handles container classes by inferring the types of elements stored in a container and eliding the container itself. This feature is crucial for obtaining models that show the structure of the abstract state and bear some relation to conceptual models. Although the tool performs only a simple, heuristic analysis that is almost entirely local, the resulting object model is surprisingly accurate. The paper explains what object models are and why they are useful; describes the analysis, its assumptions, and limitations; evaluates the tool for accuracy, and illustrates its use on a suite of sample programs. |
| Monitoring requires to gather data about executions. The monitoring functionalities currently available are built on top of ad hoc instrumentations. Most of them are implemented at low-level; in any case they require an in-depth knowledge of the system to instrument. The best people to implement these instrumentations are generally the implementors of the compiler. They, however, cannot decide which data to gather. Indeed, hundreds of variants can be useful and only end-users know what they want. In this article, we propose a primitive which enables users to easily specify what to monitor. It is built on top of the tracer of the Mercury compiler. We illustrate how to use this primitive on two different kinds of monitoring. Firstly, we implement monitors that collect various kinds of statistics; each of them is well-known, the novelty is that users can get exactly the variants they need. Secondly, we define two notions of test coverage for logic programs and show how to measure coverage rates with our primitive. To our knowledge no definition of test coverage exist for logic programming so far. Each example is only a few lines of Mercury. Measurements show that the performance of the primitive on the above examples is acceptable for an execution of several millions of trace events. Our primitive, although simple, lays the foundation for a generic and powerful monitoring environment. |
| Many reverse-engineering tools have been developed to derive abstract representations from source code. Yet, most of these tools completely ignore recovery of the all-important rationale behind the design decisions that have led to its physical shape. Design patterns capture the rationale behind proven design solutions and discuss the trade-offs among their alternatives. We argue that it is these patterns of thought that are at the root of many of the key elements of large-scale software systems, and that, in order to comprehend these systems, we need to recover and understand the patterns on which they were built. In this paper, we present our environment for the reverse engineering of design components based on the structural descriptions of design patterns. We give an overview of the environment, explain three case studies, and discuss how pattern-based reverse-engineering helped gain insight into the design rationale of some of the pieces of three large-scale C++ software systems. |
| This paper reports the results of a workshop held at ECOOP'99. The workshop was set up to find answers to questions fundamental to the definition of a semantics for the Unified Modelling Language. Questions examined the meaning of the term semantics in the context of UML; approaches to defining the semantics, including the feasibility of the meta-modelling approach; whether a single semantics is desirable and, if not, how to set up a framework for defining multiple, interlinked semantics; and some of the outstanding problems for defining a semantics for all of UML. |
| Java applets have been used increasingly on web sites to perform client-side processing and provide dynamic content. While many web site analysis tools are available, their focus has been on static HTML content and most ignore applet code completely. This paper presents Chava, a system that analyzes and tracks changes in {Java{}} applets. The tool extracts information from applet code about classes, methods, fields and their relationships into a relational database. Supplementary checksum... |
| In this paper it is argued that different kinds of reengineering technologies can be based on querying. Several reengineering technologies are presented as being integrated into a technically oriented reengineering taxonomy. The usefulness of querying is pointed out with respect to these reengineering technologies. To impose querying as a base technology in reengineering examples are given with respect to the EER/GRAL approach to conceptual modelling and implementation. This approach is presented together with {GReQL} as its query part. The different reengineering technologies are finally reviewed in the context of the {GReQL} query facility. |
| Since applying design patterns provides a foresight of the exibility and future extensibility of software, their application is expected to constructing evolutionable software. However, there have been few research on quantitative evaluation of the e ectiveness of applying design patterns to software development. In this paper, we aim to evaluate the e ectiveness of applying design patterns. The C\&K metrics suite is used for the evaluation. We collected C\&K metrics values for two kinds of applications designed and implemented by our research group. Each application had two releases. One was a prototype release designed without using design patterns while the other was designed using design patterns. We conducted the Mann-Whitny U-test, one of the nonparametric statistics for testing hypotheses about whether two sample values di er. As a result, we found no signi cant di erences between the C\&K metrics values of the two releases. Further examination of the relationship between the design patterns and the C\&K metrics suite showed that speci c design patterns tend to make a particular metric value worse. The result suggests that new metrics should be devised for the evaluation of the e ectiveness of applying design patterns. |
| A suitable software architecture---for example in the area of distributed application---can be composed of known-to-work solutions. These are also known as design patterns. However, there is little tool support for the construction of an application that conforms to design patterns. In most cases, the patterns are captured informally as descriptions in natural language. Our approach uses graph queries and graph rewriting rules to specify the patterns. A prototype that is able to execute these rules can be generated from the graph grammar specification by means of the PROGRES environment. The advantages of this approach are twofold: (1) patterns are specified on a high level of abstraction and (2) the resulting tools can be easily adapted to new patterns. |
| Recovering architectural documentation from code is crucial to maintaining and reengineering software systems. Reverse engineering and program understanding approaches are often limited by the fact that (1) they propose a fixed set of predefined views and (2) they consider either purely static or purely dynamic views of the application. In this paper we present an environment supporting the generation of tailorable views of object-oriented systems from both static and dynamic information. Our approach is based on the combination of user-defined queries which allow an engineer to create high-level abstractions and to produce views using these abstractions. |
| Why do we size software? For many reasons. To estimate development effort. To estimate memory requirements. To estimate processing or execution speed. To estimate the value of software assets. This paper considers size measures that help us predict the effort needed to design, build and test computer software using object-oriented methods. We estimate the size by combining estimates for the three aspects of software: data, control behavior, and function, as identified by [DeMarco, 1982]. The Unified Modeling Language (UML) is emerging as an industry standard for recording the results of object-oriented analysis and design. We focus specifically on the use of the products of the UML as early reliable measures of software size. We identified a subset suitable for early estimation of effort by examining the development process. We examined the elements of UML notation, and the activities of the Object-Oriented Systems Analysis (OOSA) method. This method is similar to Object Management Technique (OMT) which has been absorbed into UML. The Class Diagram (essentially an Entity Relationship Diagram) and the Event List or, better, the Statechart (a State Transition Diagram) seem to suffice to determine most of the development effort. The only activity we think is not covered is the development of complex operations (algorithms, methods). We recommend an approach to help the estimator identify these and estimate the additional effort. We propose a way to use these UML elements to estimate the size in Unadjusted Feature Points. We conclude by identifying some questions that need to be addressed in the future. |
| Refactorings are behavior-preserving program transformations that automate design level changes in object-oriented applications. Our previous research established that many schema transformations, design patterns, and hot-spot meta-patterns are automatable. This research evaluates whether refactoring technology can be transferred to the mainstream by restructuring non-trivial C++ applications. The applications that we examine were evolved manually by software engineers. We show that an equivalent evolution could be reproduced significantly faster and cheaper by applying a handful of general-purpose refactorings. In one application, over 14K lines of code were transformed automatically that otherwise would have been coded by hand. Our experiments identify benefits, limitations, and topics of further research related to the transfer of refactoring technology to a production environment. |
| When designing a new application, experienced software engineers usually try to employ solutions that proved successful in previous projects. Such reuse of code organizations is seldom made explicit. Nevertheless it represents important information about the system, that can be extremely valuable in the maintenance phase by documenting the design choices underlying the implementation. In addition, having it available, it can be reused whenever a similar problem is encountered. In this paper an approach is proposed to the inference of recurrent design patterns directly from the code or the design. No assumption is made on the availability of any pattern library and the concept analysis algorithm, adapted for this purpose, is able to infer the presence of class groups which instantiate a common, repeated pattern. In fact, concept analysis provides sets of objects sharing attributes, which, in the case of object oriented design patterns, become class members or inter-class relations. The approach was applied to a C++ application, for which the structural relations among classes led to the extraction of a set of structural design patterns, which could be enriched with non structural information about class members and method invocations. The resulting patterns could be interpreted as meaningful organizations aimed at solving general problems which have several instances in the analyzed application. |
| Inspections can be used to identify defects in software artifacts. In this way, inspection methods help to improve software quality, especially when used early in software development. Inspections of software design may be especially crucial since design defects (problems of correctness and completeness with respect to the requirements, internal consistency, or other quality attributes) can directly affect the quality of, and effort required for, the implementation.We have created a set of “reading techniques” (so called because they help a reviewer to “read” a design artifact for the purpose of finding relevant information) that gives specific and practical guidance for identifying defects in Object-Oriented designs. Each reading technique in the family focuses the reviewer on some aspect of the design, with the goal that an inspection team applying the entire family should achieve a high degree of coverage of the design defects.In this paper, we present an overview of this new set of reading techniques. We discuss how some elements of these techniques are based on empirical results concerning an analogous set of reading techniques that supports defect detection in requirements documents. We present an initial empirical study that was run to assess the feasibility of these new techniques, and discuss the changes made to the latest version of the techniques based on the results of this study. |
| Peu de travaux se sont int\'eress\'es aux probl\`emes sp\'ecifiques de la mod\'elisation du comportement des objets composites, li\'es \`a la nature dynamique et agr\'eg\'ee de leurs structures. Ainsi, les m\'ethodes de conception orient\'ees objet classiques ne proposent pas de solutions adapt\'ees \`a la conception du comportement global des objets composites. En cons\'equence, elles ne permettent pas d'obtenir des sp\'ecifications qui offrent tous les b\'en\'efices attendus de l'utilisation des objets composites (r\'eutilisation de composants, distribution de l'information, dynamique des structures et du comportement). Aussi nous proposons COBALT, une m\'ethode de conception d\'edi\'ee aux objets composites. Bas\'ee sur une taxonomie du comportement global des objets composites, COBALT propose de nouveaux concepts qui permettent une expression plus abstraite et d\'eclarative de leurs comportements. Ces concepts sont appliqu\'es \`a l'extension d'UML pour y am\'eliorer la mod\'elisation des objets composites. |
| UML provides modeling support for static software components through hierarchical packages. We describe a small extension of UML for modeling dynamic software components which can be instantiated at runtime, customized, made persistent, migrated and be aggregated to larger components. For example, this extension can be used to describe systems built with \ygg@product{JavaBeans}, ActiveX-Controls, Voyager Agents or CORBA Objects by Value. With our extension, the lifecycle of a dynamic software component can be expressed in terms of UML. We can not only describe a system at design time, but also monitor its runtime behaviour. A re-engineering tool is presented that exploits our UML extension for a high-level visualization of the interaction between dynamic components in an object-oriented system. |
| UML is currently embraced as 'the' standard in object-oriented modelling languages, the recent work of OMG on the Meta Object Facility (MOF) being the most noteworthy example. We welcome these standardisation efforts, yet warn against the tendency to use UML as the panacea for all exchange standards. In particular, we argue that UML is not sufficient to serve as a tool-interoperability standard for integrating round-trip engineering tools, because one is forced to rely on UML's built-in extension mechanisms to adequately model the reality in source-code. Consequently, we propose an alternative meta-model (named FAMIX), which serves as the tool interoperability standard within the FAMOOS project and which includes a number of constructive suggestions that we hope will influence future releases of the UML and MOF standards. |
| The intent section of a pattern description is written in easily understood, natural language, which unfortunately has the drawback of being too imprecise and unstructured for certain applications of the intent section. We will in this essay try to formalize the intent section of a pattern description. Our aim will be to find a structure within the intent description that will reduce ambiguities and at the same time make the classification of patterns easier. The classifications of patterns addresses the problem of ``labeling'' patterns into one of the following categories: Creational, Structural or Behavioural. Succeeding in classifying patterns by the intent does require that enough information for doing so is contained in the one to two sentences that make up the intent. Whether this is the case or not will be discussed in the essay. A formalized intent section of a pattern description can not replace the understandability of the natural language description but can be thought of as a complement to the standard structure to patterns today. |
| The {Java{}} 2 Platform is increasingly used for large server applications such as web services. These applications demand scalability, and directly benefit from large numbers of threads, processors, sockets and memory. Yet 'big iron' performance has a reputation as an art form, requiring special expertise beyond what is needed for performance on smaller systems. Fortunately, the {Java{}} Virtual Machine (JVM)* and Solaris operating environment provide effective implementations of threads, I/O and memory management. This document addresses a common speed bump on the road to scalable high performance: poorly tuned garbage collection (GC). |
| Throughout its entire life cycle software development is subject to many rules constraining and guiding construction of software systems. Examples are best-practice patterns, idioms, coding conventions, design guidelines, architectural patterns, etc. Although such regulations are widely used, their usage is currently implicit or ad-hoc, and most software development environments do not explicitly support them. We present an approach to declare explicitly software development styles in an open declarative system that allows querying, conformance checking and enforcement of these declarations on the source code. We validate the approach by expressing and supporting several software development styles in a real-world case. |
| The Unified Modeling Language (UML) provides system architects working on object analysis and design with one consistent language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling. This specification represents the convergence of best practices in the object-technology industry. UML is the proper successor to the object modeling languages of three previously leading object-oriented methods (Booch, OMT, and OOSE). The UML is the union of these modeling languages and more, since it includes additional expressiveness to handle modeling problems that these methods did not fully address. One of the primary goals of UML is to advance the state of the industry by enabling object visual modeling tool interoperability. However, in order to enable meaningful exchange of model information between tools, agreement on semantics and notation is required. UML meets the following requirements: \begin{itemize} \item Formal definition of a common object analysis and design (OA\&D) metamodel to represent the semantics of OA\&D models, which include static models, behavioral models, usage models, and architectural models. \item IDL specifications for mechanisms for model interchange between OA\&D tools. This document includes a set of IDL interfaces that support dynamic construction and traversal of a user model. \item A human-readable notation for representing OA\&D models. This document defines the UML notation, an elegant graphic syntax for consistently expressing the UML's rich semantics. Notation is an essential part of OA\&D modeling and the UML. \end{itemize} |
| Design patterns are very useful and important tools for improving software design, but they have a complexity cost. Considering that, design patterns shuold be applied only when it is really necessary. When plan in this thesis to develop an intelligent tutoring system that helps the object-oriented software designers to learning the use of design patterns and to apply them in a right way. The system will sugest the use of design patterns not only as limitedreusable pieces of design but mainly as a design style proposal which should help the designer without limiting his creativity. This project require to work on design patterns as abstraction mechanism, on intelligent teaching techniques and on contextual helps. |
| This thesis presents the design and implementation of an extensible dialect of the {Java{}} language, named Open{Java{}}. Although the {Java{}} language is well polished and dedicated to cover applications of a wide range of computational domain, it still lacks some mechanisms necessary for typical kinds of applications. Our Open{Java{}} enables programmers to extend the {Java{}} language and implement such mechanisms on demand. It is an advanced macro processor based on the technique called compiletime reflection. In this thesis, first, the problems of traditional compiletime reflection systems are pointed out; with those systems, it is difficult to write metalevel programs. Those reflective systems are not suitable for macro processing which are nonlocal, scattered, and spread in source programs, although such macro processing are typical in objectoriented languages. Also, those reflective systems do not provide sufficient supports of using different extensions together. Then this thesis proposes a new compiletime reflection system for Open {Java{}}. With Open{Java{}}, translation of source code is indirectly performed through an abstract data structure called meta-objects. This data structure gives meta programmers an intuitive view in object orientation. Meta programmers in Open{Java{}} can describe extensions of the base {Java{}} language more intuitively and safely than in traditional reflective systems. Finally, several examples are presented to show the good usability of Open{Java{}}. |
| Refactoring is an important part of the evolution of reusable software and frameworks. Its uses range from the seemingly trivial, such as renaming program elements, to the profound, such as retrofitting design patterns into an existing system. Despite its importance, lack of tool support forces programmers to refactor programs by hand, which can be tedious and error-prone. The {Smalltalk} Refactoring Browser is a tool that carries out many refactorings automatically, and provides an environment for improving the structure of {Smalltalk} programs. It makes refactoring safe and simple, and so reduces the cost of making reusable software. |
| An association is used to describe a relationship between two or more classes. |
| This report is the result of a Capita Selecta project. The aim of this Capita Selecta was to start from the book ``Constraint-Based Design Recovery for Software Reengineering", written by Steven G. Woods, Alexander E. Quilici and Quiang Yang to make a survey of recovering techniques for software reengineering. |
| 1998 |
| Are you headed into software development mine field? Follow someone if you can, but if you're on your own --- better get the map! extit{AntiPatterns} is the map. This book helps you navigate through today's dangerous software development projects. Just look at the statistics: \begin{itemize}\item Nearly one-third of all software projects are cancelled. \item Two-thirds of all software projects encounter cost overruns in excess of 200\%. \item Over 80\% of all software projects are deemed failures. \end{itemize} While patterns help you to identify and implement procedures, designs, and codes that work, anti-patterns do the exact opposite: They let you zero-in on the development detonators, architectural tripwires, and personality booby traps that can spell doom for your project. Written by an all-star team of object-oriented system developers, extit{AntiPatterns} identifies 40 of the most common anti-patterns in the areas of software development, architecture, and project management. The authors then show you how to detect and defuse anti-patterns as well as supply refactored solutions for each anti-pattern presented. |
| Reinforcement learning, one of the most active research areas in artificial intelligence, is a computational approach to learning whereby an agent tries to maximize the total amount of reward it receives when interacting with a complex, uncertain environment. In Reinforcement Learning, Richard Sutton and Andrew Barto provide a clear and simple account of the key ideas and algorithms of reinforcement learning. Their discussion ranges from the history of the field's intellectual foundations to the most recent developments and applications. The only necessary mathematical background is familiarity with elementary concepts of probability. The book is divided into three parts. Part I defines the reinforcement learning problem in terms of Markov decision processes. Part II provides basic solution methods: dynamic programming, Monte Carlo methods, and temporal-difference learning. Part III presents a unified view of the solution methods and incorporates artificial neural networks, eligibility traces, and planning; the two final chapters present case studies and consider the future of reinforcement learning. |
| Software design patterns are an emerging tool for guiding and documenting system design. This paper is a beginner's guide to patterns, answering common questions about patterns, pattern languages, generativity, and Alexandrian form. The paper describes patterns in terms of objects, rules, idioms, and paradigms in general. The paper also provides sources for patterns, and provides a short bibliography of patterns papers that have appeared in recent literature. |
| This paper provides computationally tractable conditions to determine whether a composite spline curve or patch selfintersects, according to a definition that includes the important limiting cases of cusps, singularities, and tangential intersections of adjacent components. These results follow upon our exposition of necessary and sufficient conditions to preclude such selfintersections. The paper includes a numerical example illustrating the results, and discusses an important application, namely, guaranteeing that a finite curvilinear simplicial complex in \mathcal{R}{3}, made up of properly-joined parametric patches, will retain its original topological form when its control points are perturbed. |
| For maintenance, reuse, reverse engineering, and re-implementation, software developers frequently need to examine source code to understand object-oriented software systems. The ability to learn and understand software systems from source code is greatly enhanced by visualizing the software systems at higher levels of abstraction, rather than seeing them as nebulous collections of classes and method implementations. Design patterns provide this medium-grained abstraction and can be an effective tool for understanding object-oriented systems. Visualizing object-oriented programs as a system of interacting patterns requires detecting, identifying, and classifying groups of related classes (clusters) in program code. These visualizations represent either known (design and code) patterns, or clusters that perform an abstract task and are not necessarily a known pattern solution. In this article, I present {DP++}, a tool that automates design-pattern detection, identification, and classification in {C++} programs. {DP++} currently identifies most of the structural and a few of the behavioral patterns described in {Design Patterns: Elements of Reusable Object-Oriented Software} (Addison-Wesley, 1995), by {Erich Gamma}, {Richard Helm}, {John Vlissides}, and {Ralph Johnson} (the {Gang of Four}, or {GoF}). An executable version of {DP++}, which runs on {Windows 95/NT}, is available electronically from DDJ (see {``Resource Center"}, page 3) and at indus.cs.uah.edu/. |
| Cohesion was first introduced as a software attribute that, when measured, could be used to predict properties of implementations that would be created from a given design. Unfortunately, cohesion, as originally defined, could not be objectively assessed, while more recently developed objective cohesion measures depend on code-level information. We show that association-based and slice-based approaches can be used to measure cohesion using only design-level information. An analytical and empirical analysis shows that the design-level measures correspond closely with code-level cohesion measures. They can be used as predictors of or surrogates for the code-level measures. The design-level cohesion measures are formally defined, have been implemented, and can support software design, maintenance, and restructuring. |
| Design patterns have proven to be very useful for the design of object-oriented systems. The power of design patterns stems from their ability to provide generic solutions to reappearing problems that can be specialized for particular situations. The implementation of design patterns, however, has received only little attention and we have identified four problems associated with the implementation of design patterns using conventional object-oriented languages. First, the traceability of a design pattern in the implementation is often insufficient; often the design pattern is `lost'. Second, since several patterns require an object to forward messages to other objects to increase flexibility, the self problem often occurs. Thirdly, since the pattern implementation is mixed with the domain class, the reusability of pattern implementations is often limited. Finally, implementing design patterns may present significant implementation overhead for the software engineer. Often, a, potentially large, number of simple methods has to be implemented with trivial behavior, e.g. forwarding a message to another object. In this paper, a solution to these problems is presented in the context of the layered object model ({LayOM}). {LayOM} provides language support for the explicit representation of design patterns in the programming language. {LayOM} is an extended object-oriented language in that it contains several components that are not part of the conventional object model, such as states, categories and layers. Layers are used to represent design patterns at the level of the programming language and example layers for eight design patterns are presented, i.e. Adapter, Bridge, Composite, Facade, State, Observer, Strategy and Mediator. Since {LayOM} is an extensible language, the software engineer may extend the language model with abstractions for other design patterns. |
| Pour expliquer les m\'ecanismes de la pens\'ee, deux courants th\'eoriques s'affrontent, le symbolisme et le connexionnisme. Le premier les d\'ecrit comme un embo\^{\i}tement de modules, \`a l'image des poup\'ees russes, le second comme un immense r\'eseau de connexions, semblable \`a un filet de p\^eche. Depuis peu, certains chercheurs nuancent cette opposition. |
| This paper proposes an extended version of {Java{}}.lang.Class, which enables more comprehensive language customization than other similar systems. To avoid performance degradation, we employ a technique called compile-time reflection. Most of customizations are statically applied to a {Java{}} program at compile time and the compiled code is executed by the regular {Java{}} virtual machine (JVM) with almost no performance overheads. In the rest of this paper, we first mention requirements for the ability for language customization. Then we overview the proposed extension to {Java{}}'s reflection mechanism. |
| Cr\'e\'ee en 1990 par le minist\`ere de l'industrie, l'\'Ecole des mines de Nantes est, apr\`es celles de Paris, Saint-{\'E}tienne, Al\`es et Douais, la cinqui\`eme de la l ign\'ee. Pour les premiers enseignants-chercheurs informaticiens venus rejoindre Nantes pour constituer l'ossature du futur d\'epartement informatique, l'int\'er\^et principal r\'esidait dans l'aventure et le challenge intellectuel qu'implique la cr\'eation d'une nouvelle \'ecole. Il s'agissait en fait de tirer le meilleur parti de cette opportunit\'e rare qui consiste \`a d\'ecliner un nouveau programme p\'edagogique, \`a mettre en oeuvre de nouvelles \'equipes de recherche, et finalement \`a \'elaborer une politique de valorisation industrielle en phase avec la demande et les besoins du march\'e. Il se trouve que l'approche objet en g\'en\'eral et la culture {Smalltalk} en particulier, ``dop\'es" par l'implication d'OTI Inc, ont jou\'e un r\^ole central dans la mise en place du triptyque enseignement, recherche, transfert de technologie \`a l'EMN, mais \'egalement dans la r\'egion des Pays de la Loire. |
| Testing is not closely integrated with development. This prevents you from measuring the progress of development- you can't tell when something starts working or when something stops working. Using JUnit you can cheaply and incrementally build a test suite that will help you measure your progress, spot unintended side effects, and focus your development efforts. |
| In this paper, we describe how meta-modelling techniques can be used to define rules for model transformation. A meta-model describes the ontology (the semantics) of a model, and the transformation rules between models can be described using the terms defined in both meta-models of these models. The example presented in this paper is a transformation from an object model, described using the UML semantics [UML1997], to a new one described using a relational paradigm. Both models are represented in a formalism based on semantic nets and called sNets[B\'ezivin1995]. This work can be compared to graph rewriting techniques as used in PROGRES (Programmed Graph Replacement Systems[Sch\"urr1997]) and hyper-genericity as presented in [Desfray1998]. |
| Class loaders are a powerful mechanism for dynamically loading software components on the {Java{}} platform. They are unusual in supporting all of the following features: laziness, type-safe, user-defined extensibility and multiple communicating namespaces. We present the notion of class loaders and demonstrate some of their interesting uses. In addition, we discuss how to maintain type safety in the presence of user-defined dynamic class loading. |
| In the last decade the object-oriented paradigm has decisively influenced the world of software engineering. On the other hand, in spite of the large acceptance of this paradigm, at the beginning, the design principles and the intimate mechanisms of object-orientation were not yet precisely known, and this fact conducted to a lot of poor designed large scale OO systems. In other words, these applications mostly proved to be critical exactly in those aspects where object-oriented design should have offered its most expected benefits e.g. high degree of code reuse, higher maintainability or flexibility, etc. The general tendency manifested in the last time is to redesign these older industrial object-oriented systems, so that they may take full advantage of the today's knowledge in object-orientation, and thus improve the quality of their design. In the first stage of a redesign process it is needful to detect what are the design-flaws contained in the application and where are this flaws located. This diagnose task is usually called problem detection. The detection of design problems for large or very large systems is impossible to be fulfilled manually and must therefore be accomplished by automated methods. This paper presents the possibility of using object-oriented software metrics for the automatic detection of a set of design problems. We will illustrate the efficiency of this approach by discussing the conclusions of an experimental study that uses a set of three metrics for problem detection and applies them to three projects. These three metrics are touching three main aspects of object-oriented design, aspects that have an important impact on the quality of the systems i.e. maintenance effort, class hierarchy layout and cohesion. For each of these metrics we will present the design flaw that it may detect together with some of our experimental observations and a possible redesign solution for that problem. The importance of this paper is increased by the fact that it contributes to the study of object-oriented metrics in a point where this is specially needed: the addition of new practical experience and the practical knowledge that derives from it, as the great lack of practical experience is well-known among the specialists. |
| The object-oriented design community has recently begun to collect so-called software design patterns: descriptions of proven solutions common software design problems, packaged in a description that includes a problem, a context, a solution, and its properties. Design pattern information can improve the maintainability of software, but is often absent in program documentation. We present a system called Pat for localizing instances of structural design patterns in existing C ++ software. It relies extensively on a commercial CASE tool and a {Prolog} interpreter, resulting in a simple and robust architecture that cannot solve the problem completely, but is industrial-strength; it avoids much of the brittleness that many reverse engineering tools exhibit when applied to realistic software. It relies extensively on a commercial CASE tool and a {Prolog} interpreter, resulting in a simple and robust architecture that cannot solve the problem completely, but is industrial-strength; it avoids much of the brittleness that many reverse engineering tools exhibit when applied to realistic software. The contribution of our work is not so much in the engineering value represented by this concrete system, but in its methodological approach. To evaluate Pat, we quantify its performance in terms of precision and recall. We examine four applications, including the popular class libraries {zApp} and LEDA. Within Pat's restrictions all pattern instances are found, the precision is about 40 percent, and manual filtering of the false positives is relatively easy. Therefore, we consider Pat a good compromise: modest functionality, but high practical stability for recovering design information. |
| Recent studies of eye movements in reading and other information processing tasks, such as music reading, typing, visual search, and scene perception, are reviewed. The major emphasis of the review is on reading as a specific example of cognitive processing. Basic topics discussed with respect to reading are (a) the characteristics of eye movements, (b) the perceptual span, (c) integration of information across saccades, (d) eye movement control, and (e) individual differences (including dyslexia). Similar topics are discussed with respect to the other tasks examined. The basic theme of the review is that eye movement data reflect moment-to-moment cognitive processes in the various tasks examined. Theoretical and practical considerations concerning the use of eye movement data are also discussed. |
| Developing software in wab time can be an immense undertaking. Here is some advice on making it a smooth process for everyone involved. |
| The rapid evolution of Design Patterns has hampered the benefits gained from using Design Patterns. The increase in the number of Design Patterns makes a common vocabulary unmanageable and the tracing problem obscures the documentation that should be enhanced by using Design Patterns. We present an analysis of the Design Patterns that will strongly reduce the number of Design Patterns and show how strong language abstractions can solve the tracing problem and thereby enhance the documentation. |
| Decomposing complex software systems into conceptually independent subsystems is a significant software engineering activity which received considerable research attention. Most of the research in this domain considers the body of the source code; trying to cluster together files which are conceptually related. This paper discusses techniques for extracting concepts (we call them ``abbreviations") from a more informal source of information: file names. The task is difficult because nothing indicates where to split the file names into substrings. In general, finding abbreviations would require domain knowledge to identify the concepts that are referred to in a name and intuition to recognize such concepts in abbreviated forms. We show by experiment that the techniques we propose allow about 90\% of the abbreviations to be found automatically. |
| An approach to recover object oriented design patterns from {C++} code is presented. The pattern recovery process is based on a multi-stage filtering strategy to avoid combinatorial explosion on large software systems. To maintain independence from the language and the case tools adopted in developing software, both design and code are mapped into an intermediate representation. The multi-stage searching strategy allows to safely determine pattern candidates. To assess the effectiveness of the pattern recovery process a portable environment written in {Java{}} has been developed. Based on this environment, experimental results on public domain and industrial software were obtained and are discussed in the paper. Evidence is shown that, by exploiting information about method calls as a further constraint beyond the structural ones, the number of false alarm is reduced. |
| This paper presents the {Javassist} system, which is a programming tool for assisting {Java{}} programmers. It enables programmers to write a meta-level program automating some kinds of class definitions. Moreover, a number of applications of runtime reflection can be implemented with this system. |
| A software architecture is typically drawn as a nested set of box and arrow diagrams. The boxes represent components of the software system and the edges represent interactions. These diagrams correspond to typed graphs, in which there are a number of ``types'' or ``colors'' of edges, and in which there is a distinguished “contain” relation that represents the system hierarchy (the nesting of boxes). During reverse engineering, one often transforms such diagrams in various ways to make them easier to understand. These transformations include edge aggregation, box abstraction (closing a box to hide its contents), and box separation (separating a box from its surrounding system). Such transformations are essential in helping make software architecture diagrams useful in practice. Paper shows how structural manipulations such as these can be specified and automatically carried out in a notation based on Tarski's relational algebra. The operators in this algebra include relational composition, union, subtraction, etc. These operators are supported in a language called Grok. Grok scripts have been used in manipulating the graphs for large scale software systems, such as Linux, to help in program visualization and understanding |
| There has been substantial recent interest in captured design expertise expressed as design patterns. Prevalent descriptions of these design patterns suffer from two demerits. Firstly, they capture specific instances of pattern deployment, rather than the essential pattern itself, thus the spirit of the pattern is often lost in the superfluous details of the specific instances described. Secondly, existing pattern descriptions rely upon relatively informal diagrammatic notations supplemented with natural language annotations. This can result in imprecision and ambiguity. This paper addresses these problems by separating the specification of patterns into three models (role, type, and class). The most abstract (role-centric) model presents patterns in their purest form, capturing their essential spirit without deleterious detail. A role-model is refined by a type-model (adding usually-domain- specific constraints), which is further refined by a class-model (forming a concrete deployment). We utilise recent advances in visual modelling notation to achieve greater precision without resorting to obtuse mathematical symbols. A set-oriented view of state, operations, and instances is adopted, permitting their abstract presentation in models via this visual notation. This paper utilises these ideas in the unambiguous specification of a selection of prominent design patterns. The expectation is that precise visual pattern specification will firstly enable clear communication between domain experts and pattern writers (and ultimately pattern users), and secondly enable CASE tool support for design patterns, permitting the designer (pattern user) to operate at a higher level of abstraction without ambiguity. |
| In the existing catalogues of either design patterns or architectural styles, numerous are very analogous. They show little differences because they have been developed and used by different people and for different applications. Therefore it is really very difficult, for practical use, to select the right pattern or style for a specific design problem. In general, the criteria given for selection are based on examples or case studies. The formalization of these patterns provides a criteria of comparison. In this paper, a context for style formalization that takes into account characteristic properties, is described first. Two styles, Mediator and Broker, are formalized. Then the relation of specialization is defined and applied to show that Broker is a particular case of Mediator. As an example, taking advantage of the distribution characterized by Broker, it is shown that in the PAC (Presentation-Abstraction-Control) architectural pattern, the usage of Broker as the control of the application, instead of Mediator, allows to de-fine a distributed architecture for interactive applications, a distributed PAC style. |
| Software systems are typically modified in order to extend or change their functionality, improve their performance, port them to different platforms, and so on. For developers, it is crucial to understand the structure of a system before attempting to modify it. The structure of a system, however, may not be apparent to new developers, because the design documentation is non-existent or, worse, inconsistent with the implementation. This problem could be alleviated if developers were somehow able to produce high-level system decomposition descriptions from the low-level structures present in the source code. We have developed a clustering tool called Bunch that creates a system decomposition automatically by treating clustering as an optimization problem. This paper describes the extensions made to Bunch in response to feedback we received from users. The most important extension, in terms of the quality of results and execution efficiency, is a feature that enables the integration of designer knowledge about the system structure into an otherwise fully automatic clustering process. We use a case study to show how our new features simplified the task of extracting the subsystem structure of a medium size program, while exposing an interesting design flaw in the process. |
| Design patterns facilitate reuse of good design practices. They are typically given by using conventional notations that lack well-defined semantics and, therefore reasoning about their behaviors requires formalization. Even when formalized, conventional communication abstractions may lead to too laborious formalizations when addressing the temporal behavior of a pattern as a whole instead of behaviors local to its components. We show that rigorous reasoning can be eased by formalizing temporal behaviors of patterns in terms of high-level abstractions of communication, and that by using property-preserving refinements, specifications can be naturally composed by using patterns as building blocks. |
| Early elimination of poor design architecture allows software to be constructed that is more extendible, flexible, maintainable, and thus less expensive. Currently, there exist few object-oriented design architecture measures to aid in this task. Many contemporary object-oriented software measures fail to address the intrinsic components of the object-oriented paradigm: hierarchy, inheritance, identity, polymorphism, and encapsulation. By focusing upon the intrinsic components of the object-oriented paradigm, it is hoped a better set of measurements can be created which help to distinguish between those architectures that follow object-oriented principles and those that do not. This research proposes four new software measures that attempt to measure the strength of these intrinsic concepts in an object-oriented design. These measurements are derived from available principles of object-oriented design which are relatively new to research. |
| In reengineering legacy code it is frequently useful to introduce a design pattern in order to add clarity to the system and thus facilitate further program evolution. We show that this type of transformation can be automated in a pragmatic manner and present a methodology for the development of design pattern transformations. We address the issues of the definition of a starting point for the transformation, the decomposition of a pattern into mini-patterns and the development of corresponding mini-transformations that can introduce these mini-patterns to a program. We argue that behavior preservation is a key issue and develop a rigorous argument of this for each mini-transformation we discover. The architecture of an existing software prototype is also discussed and the results of applying this methodology to develop a transformation for the Factory Method pattern are presented. |
| A rich body of data exists showing that recollection of specific information contributes to recognition memory. We present a model, based largely on known features of hippocampal anatomy and physiology, that accounts for both the {\em high-threshold} nature of this recollection process (i.e., the fact that only studied items are recollected, although nonstudied items sometimes trigger recollection of similar studied items), and the fact that increasing interference leads to less recollection but apparently does not compromise the {\em quality} of recollection (i.e., the extent to which recollection veridically reflects events that occurred at study). |
| Most popular object-oriented modeling techniques (OOMTs) provide good support for the creation of structured conceptual models of system behavior and structure. A serious drawback of these techniques is that the concepts and notations used are loosely defined. This can lead to the creation of ambiguous models, and to disagreements over the proper use and interpretation of modeling constructs. An important modeling construct that is often loosely defined is aggregation. In this paper we present a characterization of aggregation that can help developers identify appropriate applications of the concept. |
| Cognitive science emphasizes the strength of visual formalisms for human learning and problem solving. In software engineering, a clear, visual presentation of a system's architecture can significantly reduce the effort of comprehension. Yet, all too often the documentation of complex software systems lacks clear identification of the architectural constituents and insufficiently relates them to the source code. It is our contention that visualization of the architectural constituents within the source code model is an indispensable aid for the guided evolution of large-scale software systems. We present a prototype tool for visualizing both published, generic design patterns as well as well-thought, ad-hoc design solutions, given the reverse-engineered source code of a system. We discuss the architecture and core functionality of this tool, addressing source code reverse engineering, design repository, design representation, and design clustering. Then, we present our visualization objectives and detail our techniques for pattern visualization. A case study example helps explicate and illustrate our work. |
| In this paper we show to recover design information from {Java{}} source code. We take a pattern-based approach and proceed in a step by step manner deriving several layers of increasing abstraction. A compiler collects information about inheritance hierarchies and method call relations. It also looks for particular source text patterns coming from naming conventions or programming guidelines. The result of the compile phase is a graph acting as the starting graph of a graph grammar describes our design recovery process. We define criteria for the automatic detection of associations and aggregations between classes, as well as for some of the popular design patterns such as composite or strategy. |
| This paper presents that compile-time MOPs can provide a general framework resolving implementation problems of design patterns. The problems come from the fact that some programs written according to design patterns are too complicated and error-prone and that their overall structure is not easy to understand. This problem can be resolved by syntax extensions and extended language constructs that simplify description of the patterns and improve the readability of the programs. In our approach, programmers can use a MOP to write a library which implements syntax extensions and extended language constructs for supporting each design pattern. We illustrate this approach with examples written in Open{Java{}}, which is our self extensible version of the {Java{}} language with a compile-time MOP. The Adapter pattern and the Visitor pattern are used as examples. |
| Cognitive models of software comprehension are potential sources of theoretical knowledge for tool designers. Although their use in analysis of existing tools is fairly well-established, the literature has shown only limited use of such models for directly developing design ideas. This paper suggests a way of utilizing existing cognitive models of software comprehension to generate design goals and suggest design strategies early in the development cycle. A crucial part of our method is a scheme for explaining the value of tool features by describing the mechanisms that are presumed to underly the expected improvements in task performance. |
| The structure of object-oriented systems typically forms a complicated, tangled web of interdependent classes. Understanding this implicit and hidden structure poses severe problems to developers and maintainers who want to use, extend or adapt those systems. This paper advocates the use of a logic meta-language to express and extract structural relationships in class-based object-oriented systems. As validation the logic meta-language SOUL was implemented and used to construct a declarative framework that allows reasoning about the structure of {Smalltalk} programs. The declarative framework's usefulness is illustrated by expressing different high-level structural relationships such as those described by design patterns. |
| This paper discusses the development and implementation of a customizable editor for OMT/UML style object-models and behavior-models. A number of well known design patterns are used to obtain a flexible architecture that allows to build tool support for our software engineering research requiring variants or add-ons to the basic editors. We report on the difficulties we encountered in applying the Model-View-Control, Observer, Visitor, Iterator, Bridge, Facade and Chain of Responsibility patterns and we evaluate the claims of improved flexibility, modularity, reusability, and understandability as stated in the design pattern literature in general. |
| We present Coca, an automated debugger for C, where the breakpoint mechanism is based on events related to language constructs. Events have semantics whereas source lines used by most debuggers do not have any. A trace is a sequence of events. It can be seen as an ordered relation in a database. Users can specify precisely which events they want to see by specifying values for event attributes. At each event, visible variables can be queried. The trace query language is Prolog with a handful of primitives. The trace query mechanism searches through the execution traces using both control flow and data whereas debuggers usually search according to either control flow or data. As opposed to fully «relational» debuggers which use plain database querying mechanisms, Coca trace querying mechanism does not require any storage. The analysis is done on the fly, synchronously with the traced execution. Coca is therefore more powerful than «source line» debuggers and more efficient than relational debuggers. |
| of a class to an interface is by name. We propose to allow structural conformance to interfaces: Any class or interface that declares or implements each method in a target interface conforms structurally to the interface, and any expression of the source class or interface type can be used where a value of the target interface type is expected. We argue that structural conformance results in a major gain in flexibility in situations that require retroactive abstraction over types. Structural conformance requires no additional syntax and only small modifications to the {Java{}} compiler and optionally, for performance reasons, the virtual machine, resulting in a minor performance penalty. Our extension is type-safe: A cast-free program that compiles without errors will not have any type errors at run time. Our extension is conservative: Existing {Java{}} programs still compile and run in the same manner as under the original language definition. Finally, structural conformance works well with recent extensions such as {Java{}} remote method invocation. We have implemented our extension of {Java{}} with structural interface conformance by modifying the {Java Developers Kit 1.1.5} source release for {Solaris} and {Windows 95/NT}. We have also created a test suite for the extension. |
| Allocating objects on the stack rather than the heap reduces the overhead of garbage collection and permits further optimizations. This paper presents a simple and fast algorithm for stack allocating a significant fraction of objects for Java programs. Our implementation in an optimizing batch Java compiler demonstrates the benefit of stack allocation by achieving speed improvements of up to 11\% for medium-size programs. |
| Function Point Analysis has matured sufficiently nowadays that it is routinely used for performance measurement and estimating, not just within in-house Information Systems departments, but in contractual situations between businesses and their third-party IS suppliers. It goes without saying therefore that standards for FPA are vital, and any publication which helps broaden the understanding of this field, such as this Counting Practices Manual for Mk II FPA is to be welcomed. The evidence from our consulting activities is that there is in practice still a lot of misunderstanding of FPA and how to apply it, and of course many large IS organisations still have not seen the benefits of adopting these techniques. As a community, those interested in improving the professionalism of the IS function, so that it can justifiably use the term ‘system engineer’, still have a lot to do. We hope this manual will help. |
| Design patterns work very well in practice for communicating design ideas in an informal way. The common knowledge of a body of design patterns, such as the {GoF} book, within a design team, allows design discussions to be held at a higher level than when only using the concepts of individual classes and objects. However, when actually recording a design, it is usually done at the more primitive level of individual classes and objects, either in the form of (UML) class diagrams or in actual code. An explicit way of recording the pattern applications in the code would have many benefits: A tool could be used to present different design pattern views of the program in order for a developer to better understand the code when doing maintenance. Also, rules for the applied patterns could be checked by a tool so that patterns are not broken when doing maintenance. A design pattern as described in for example the {GoF} book, is informal and can have many different realizations. For example, there are several principle variations on how to implement the Observer pattern, and depending on the programming language used, there will be even more variations. Another example is associations in UML: At an informal level, they are simply drawn as lines between boxes, but closer to the implementation level they may be implemented in many different ways. The association may be represented by an object, or simply by a reference, or it may be stored in a separate data structure, e.g. a table. Tools must be open ended to support the design pattern implementations chosen by the developers. Design patterns record common design experience, and often, a pattern emerges because several independent developers have come up with the same solution to a general problem. It is therefore likely that code developed without the explicit focus on design patterns will nevertheless contain applications of design patterns. It might therefore seem possible to re-engineer legacy code to find out which patterns were applied. However, we think that this would probably be very difficult because there are so many variations on how patterns can be implemented. Also, different patterns can have the same syntactic structure, but should be identified as different patterns because their intent is different. As for other re-engineering tools, the result of trying to identify and extract pattern applications can give a starting point for further manual re-engineering, but will most likely not capture the intended patterns in a precise way. In the discussion, we focused on tools making use of explicit pattern annotations of the code. |
| UML has several relations (association, aggregation, and composition) that seem to all mean the same thing: ``has a". So, what is the difference among them? |
| 1997 |
| This is an essential guide to understanding object orientation using the new Unified Modeling Language (UML). James Odell and James Martin build a foundation that can be used to communicate with others using the new UML{} standard. Furthermore, they explain precisely how to build UML{} models based on ideas that are fundamental to human thinking---not just program-language specification. Finally, they show how their object-oriented foundation can be used to generate fully executable programs as well as to model and reengineer business processes and to integrate virtually any new technology. extit{Object-Oriented Methods: A Foundation, UML Edition} brings together all the basic ideas needed to specify any system, presenting a formally based foundation that can be understood by both ``real-world" developers and formalists. It includes extensive examples and review questions and reflects recent work by the OMG's Object Analysis and Design Task Force. Based on the UML meta-model and notation, Odell and Martin: \begin{itemize} \item Present the fundamental concepts of object orientation using the UML model and notation. \item Provide a sound approach to modeling systems that is completely independent of programming considerations. \item Clarify how to conceptualize system requirements using an OO approach that leads to sound design and programming efforts. \item Show how an OO approach encourages serial, concurrent, and synchronized processing specification and incorporates event-driven and component-based technology. \item Demonstrate how to develop systems that evolve with future changes in technology. \item Identify powerful ways to reflect---and extend---OO concepts in the enterprise repository and data warehouse. \item Shows how OO can organize and interconnect many other systems approaches, including business rules, logic, functions, neural nets, SQL, and client-server. \end{itemize} With exceptional insight and clarity, extit{Object-Oriented Methods: A Foundation, UML Edition} presents the best available approach to developing systems today---and planning for tomorrow. |
| The great challenge of reverse engineering is recovering design information from legacy code: the `concept recovery' problem. This monograph describes up-to-date research dealing with this problem. It discusses a theory of how a constraint-based approach to program plan recognition can efficiently extract design concepts from source code, and it details experiments in concept recovery that support the authors' claims of scalability. Constraint-Based Design Recovery for Software Reengineering: Theory and Experiments presents models and experiments in sufficient detail so that they can be easily replicated. This book is intended for researchers or software developers concerned with reverse engineering or reengineering legacy systems. However, it may also interest those researchers who are interested in using plan recognition techniques or constraint-based reasoning. The reader is expected to have a reasonable computer science background (i.e., familiarity with the basics of programming and algorithm analysis), but is not required to have a familiarity with the fields of reverse engineering or artificial intelligence (AI). This book is designed as a reference for advanced undergraduate or graduate seminar courses in software engineering, reverse engineering, or reengineering. It can also serve as a supplementary textbook for software engineering-related courses, such as those on program understanding or design recovery, for AI-related courses, such as those on plan recognition or constraint satisfaction, and for courses that cover both topics, such as those on AI applications to software engineering. |
| Dans un syst\`eme \`a base d'objets, des groupes d'objets coop\`erent dans le but d'assurer diff\'erentes t\^aches ou de maintenir des invariants entre eux. Nous appelons de tels comportements collectifs des extit{d\'ependances} entre objets. Or les langages \`a classes traditionnels n'offrent pas la possibilit\'e d'exprimer facilement de telles d\'ependances. En r\'eponse \`a ce probl\`eme, nous proposons un mod\`ele objet extensible qui int\`egre l'expression et le maintien des d\'ependances entre objets. Il propose : une r\'eification du concept de d\'ependance, une expression locale du maintien de la coh\'erence, des propri\'et\'es li\'ees aux d\'ependances et la r\'esolution des probl\`emes li\'es \`a une expression locale des d\'ependances par un maintien global en terme de contr\^oleur de d\'ependances. Le langage \ygg@pl{FLO} est une impl\'ementation de ce mod\`ele dans un langage \`a classes. Dans \ygg@pl{FLO}, les d\'ependances ont un statut \'egal \`a celui des classes (abstraction de la s\'emantique d'une d\'ependance, d\'efinition incr\'ementale et ind\'ependance vis-\`a-vis des classes). \ygg@pl{FLO} utilise les caract\'eristiques r\'eflexives de langages tels que \ygg@pl{CLOS}, comme le contr\^ole de l'envoi de message, afin d'assurer le maintien de la coh\'erence des d\'ependances. Dans le but d'offrir un langage conforme au mod\`ele propos\'e, nous avons choisi de d\'efinir un langage adaptable dans lequel peuvent \^etre projet\'ees des d\'ependances de diff\'erentes sortes. L'adaptabilit\'e d'un langage pose deux questions essentielles : d'une part, quelles sont les fonctions du langage qui peuvent \^etre sujettes \`a une adaptation sans mettre en p\'eril la coh\'erence ? D'autre part, quelles sont les fonctions du langage qu'il faut rendre adaptable afin de g\'en\'erer toutes les fonctionnalit\'es souhait\'ees ? Une part importante de notre travail peut \^etre per\c cue comme l'\'elaboration d'un ``jeu de \ygg@product{Lego} pour la gestion des d\'ependances" permet au programmeur de se construire son propre environnement de travail. |
| La programmation par contraintes, carrefour de diverses disciplines, a montr\'e son int\'er\^et dans de nombreux domaines d'application. De nombreux probl\`emes r\'eels sont dynamiques~: le syst\`eme de contraintes les d\'efinissant n'est donc pas fig\'e. Pour r\'esoudre un probl\`eme dynamique, il faut assurer une certaine incr\'ementalit\'e et \^etre capable de traiter les syst\`emes de contraintes contradictoires. En effet, il est souvent indispensable de fournir une solution quitte \`a ne pas respecter certaines contraintes. On parle alors de relaxation de contraintes. Durant cette th\`ese, nous nous sommes int\'eress\'es \`a la d\'efinition d'un syst\`eme de relaxation de contraintes permettant de maintenir une propri\'et\'e donn\'ee dans un environnement dynamique. Nous avons men\'e ces travaux depuis une pr\'esentation abstraite d'un tel syst\`eme jusqu'\`a son impl\'ementation. Nous pr\'esentons un sch\'ema algorithmique g\'en\'eral abstrait de la recherche d'une solution \`a un probl\`eme sur-contraint bas\'ee sur l'exploration en meilleur d'abord d'un espace de configurations. Nous en donnons trois instances pour traiter les contraintes lin\'eaires sur les rationnels, les {\em Constraint Satisfaction Problems} et les CSP num\'eriques. Les deux derni\`eres sont d\'efinies \`a l'aide d'un syst\`eme de maintien de d\'eduction dont la ma\^{\i}trise raisonn\'ee nous a permis de donner une impl\'ementation de ces instances ayant une \emph{bonne} complexit\'e~: le syst\`eme DECORUM. Nous montrons, par le biais d'un certain nombre d'exp\'erimentations, que l'utilisation de DECORUM permet de retrouver les r\'esultats classiques sur la transition de phase, de r\'esoudre raisonnablement des probl\`emes de grande taille et d'utiliser la structure du probl\`eme r\'esolu pour am\'eliorer la recherche. Enfin, nous proposons la contrainte one-of permettant de mod\'eliser et de r\'esoudre une disjonction de contraintes en tirant profit du m\'ecanisme d'exploration de DECORUM. Nous validons l'int\'er\^et de la contrainte one-of sur des probl\`emes d'ordonnancement : les Open-Shop. |
| Dr. Turkle calls attention to the fact that today's children are growing up with games like SimLife, SimCity, and SimEarth. As a result, they inherently understand the power of a simulation to explore options in problem solving. Though many engineers and managers today lack this appreciation, in the future, it may become much more prevalent in all business and scientific disciplines. |
| Some people assume that software patterns are primarily about objects or component interconnection schemes, and thereby fail to reap their benefits. To understand the potential of patterns and how to apply them, it is helpful to understand the history of patterns, their relationship to objects and language-specific idioms of object-oriented programming, and to the broader stage of software architecture. Patterns not only support object-oriented design and architecture, they are reaching out into areas far beyond the structure of software, such as the software development organization, markets, and software usability. But a true understanding of software architecture must include these facets as well, so patterns truly support the whole of sotware architecture. |
| Designer's productivity has become the key-factor of the development of electronic systems. An increasing application of design data reuse is widely recognized as a promising technique to master future design complexities. Since the intellectual property of a design is more and more kept in software-like hardware description languages (HDL), successful reuse depends on the availability of suitable HDL reverse engineering tools. This paper introduces new concepts for an integrated HDL reverse engineering tool-set and presents an implemented evaluation prototype for VHDL designs. Starting from an arbitrary collection of HDL source code files, several graphical and textual views on the design description are automatically generated. The tool-set provides novel hypertext techniques, expressive graphical code representations, a user-defined level of abstraction, and interactive configuration mechanisms in order to facilitate the analysis, adoption and upgrade of existing HDL designs. |
| Design patterns can be considered as elements of complex software systems. Crafting these software systems using design patterns calls for a suitable design methodology or technique. Existing design methodologies do not serve this purpose well. This paper proposes a technique which helps in developing software systems usign design patterns. |
| {Smalltalk} has grown and prospered in the shadow of {C++} for several years. As {Java{}} takes over the {C++} market, we expect {Smalltalk} to continue this pattern of coexistence. The worldwide shift of development toward objects and components will continue for some time to come. {Smalltalk} plays well in this domain. Recognizing this situation - and especially the loyalty of the user base reflected in our survey - we predict a continued steady increase in the number of {Smalltalk} users. After all is said and done, the fate of {Smalltalk} probably resides with its two major vendors, {ObjectShare} (formerly {ParcPlace-Digitalk}) and IBM. Both vendors are now positioned to support both {Smalltalk} and {Java{}}. |
| In this paper, we present a technique to analyze and measure the reusability of objectoriented (OO) designs. The metrics can be incorporated into a design/development environment, so that reusability measurements, analysis, and improvements can be part of ``business as usual'' for an organization. Design reusability measurements also enable early identification of poor reuse potential, when it is still possible to modify/refine the design. The essential components of our approach are two reusespecific characterizations of classes and hierarchies, and a set of metrics which objectively measures the dependencies among design components based on those reusespecific characterizations. |
| Program understanding is often viewed as the task of extracting plans and design goals from program source. As such, it is natural to try to apply standard AI plan recognition techniques to the program understanding problem. Yet program understanding researchers have quietly, but consistently, avoided the use of these plan recognition algorithms. This paper shows that treating program understanding as plan recognition is too simplistic and that traditional AI search algorithms for plan recognition are not suitable, as is, for program understanding. In particular, we show (1) that the program understanding task differs significantly from the typical general plan recognition task along several key dimensions, (2) that the program understanding task has particular properties that make it particularly amendable to constraint satisfaction techniques, and (3) that augmenting AI plan recognition algorithms with these techniques can lead to effective solutions for the program understanding problem. |
| This article offers a structure for understanding how kits, frameworks, and systems fit in with patterns, architectural styles, and domain analysis. The article applies the structure to show what information-specifically, patterns and architectural styles-are required to develop kits, frameworks, and systems, and how that information fits into a systems development life cycle. The topology also identifies potential products and research areas. |
| Reverse engineering tools support software engineers in the process of analyzing and understanding complex software systems during maintenance activities. The functionality of such tools varies from editing and browsing capabilities to the generation of textual and graphical reports. There are several commercial reverse engineering tools on the market providing different capabilities and supporting specific source code languages. We evaluated four reverse engineering tools that analyze C source code: Refine/C, Imagix4D, Sniff+, and Rigi. We investigated the capabilities of these tools by applying them to a commercial embedded software system as a case study. We identified benefits and shortcomings of these four tools and assessed their applicability for embedded software systems, their usability, and their extensibility. |
| This position paper suggests that quality is subjective. Quality is dependent upon its context. In our case the context is client needs and implementation restrictions. The author can not find a reoccurring context derived from client needs. However, the largest implementation restriction is human restrictions to overcome system complexity rather than technical restrictions. Hence, the paper suggests that design quality is software is mostly measured by its symplicity, intuitiveness, and understandability to humans. |
| We describe a compositional approach to the formal inter pretation of type view diagrams and statecharts. We define theories for object instances and classes, and theories for associations between them. These theories are combined with categorical constructions to yield a formalisation of the entire system. We observe that some notations require the identification of theories intermediate between the theories of the constituent classes and associ ations and that of the entire system. This leads us to propose a notion of subsystem which generalises the concept of object and yields an ap proach to system specification employing objectlike encapsulation in a nested hierarchy of components. |
| The Unified Modeling Language UML is a language for specifying, visualizing and documenting object-oriented systems. UML combines the concepts of OOA/OOD, OMT and OOSE and is intended as a standard in the domain of object-oriented analysis and design. Due to the missing formal, mathematical foundation of UML the syntax and the semantics of a number of UML constructs are not precisely defined. This paper outlines a proposal for the formal foundation of UML that is based on a mathematical system model. |
| In this paper, we take the position that good object oriented designs accrue from attention to both the design of objects and classes and to the architectural framework which defines how instances of those classes interact. We argue that an architecture should be assessed for conceptual integrity, and describe tool support for making such an assessment. |
| Despite vast interest in design patterns, the specification and application of patterns is generally assumed to rely on manual implementation. We describe a precise method of specifying how a design pattern is applied: by phrasing it as an algorithm in a meta-programming language. We present a prototype of a tool that supports the specification of design patterns and their realization in a given program. Our prototype allows automatic application of design patterns without obstructing the source code test from the programmer, who may edit it at will. We demonstrate pattern specification in meta-programming techniques and a sample outcome of its application. |
| A software (design) pattern describes a general solution for a recurring design problem. The solution is mostly described in terms of an abstract design structure expressed in design elements such as classes, methods and relationships (inheritance, associations). This paper describes a prototype tool that supports working with design patterns when developing or maintaining object-oriented programs. The tool provides three integrated views on a program: the code (classes, methods, etc.), a design view (abstraction of the code plus additional information not in the code) and occurrences of design patterns in the program. The tool assists developers using patterns in three ways: Generating program elements (e.g. classes, hierarchies) for a new instance of a pattern, taken from an extensible collection of template patterns Integrating pattern occurrences with the rest of the program by binding program elements to a role in a pattern (e.g. indicating that an existing class plays a particular role in a pattern instance). Checking whether occurrences of patterns still meet the invariants governing the patterns and repairing the program in case of problems. Through the use of an existing refactoring package, the tool supports the use of patterns both in forward engineering and in backwards engineering, i.e. documenting occurrences of patterns in existing programs and modifying the program to better reflect the pattern's structure. The tool is implemented in {Smalltalk} and has been applied to identify pattern occurrences in several non-trivial ({Smalltalk}) applications and to reorganize these subsequently. |
| We present a technique for formalizing design patterns using a technique based on attribute grammars. The technique allows design pattern applications to be identified in the source code, and supports automatic checking that the pattern is applied correctly. We expect the technique to be particularly useful when specializing frameworks built using design patterns. |
| Object-oriented technology has become mature enough to satisfy many new requirements coming from areas like computer-aided design (CAD), computer-integrated manufacturing (CIM), or software engineering (SE). However, a competitive information management infrastructure often demands to merge data from CAD-, CIM-, or SE-systems with business data stored in a relational system. One approach for seamless integration of object-oriented and relational systems is to migrate from a relational to an object-oriented system. The first step in this migration process is reverse engineering of the legacy database. In this paper we propose a new graphical and executable language called Generic Fuzzy Reasoning Nets for modelling and applying reverse engineering knowledge. In particular, this language enables to define and analyse fuzzy knowledge which is usually all what is available when an existing database schema has to be reverse engineered into an object-oriented one. The analysis process is based on executing a fuzzy petri net which is parameterized with the fuzzy knowledge about a concrete data-base application. |
| [GHJV94] proposed a number of design patterns that offer good solutions for recurring design situations. Along with the good solutions they also discuss naive solutions to these design situations and argue why such naive solutions should be replaced by a sound design pattern. Our position is that this exactly describes the task of OO reengineering: find patterns within a legacy OO program that show a poor solution for a (recurring) problem and replace this poor solution by a sound solution offered by the corresponding design pattern. By replacing a poor solution with a good design pattern one gains all the advantages offered by design patterns like a well structured and well documented and easy to understand (sub)design that is flexible, extensible and easy to maintain. To yield this one has to solve two main problems: 1. detecting occurrences of (poor) implementation/design patterns in legacy programs 2. replacing the poor code/design by a good implementation/design pattern. |
| Despite the burst in the availability of OO analysis and design methodologies, languages, database management systems, and tools, relatively little work has been done in the area of OO design quality assurance, assessment, and improvement. We badly need a better understanding of the properties of OO system design, in the small and in the large, and their effect on quality factors such as maintainability, evolvability, and reusability. The understanding of desirable and non-desirable properties may contribute to improvement of risk assessment and product selection, better planning, more accurate assessment of maintenance efforts, improved productivity evaluation, a better foundation of design methods, improved system evolvability, and eventually to better design practices. |
| Little assistance, if any, is given to personnel who design software. This has caused the production of software which is less evolvable and of low quality. A case study was carried out to investigate the implications of design patterns during software building. The results suggest that design patterns can facilitate our understanding of software systems and reusing software designs in our future software building. |
| Quality is not an absolute intrinsic measure neither for tangible goods nor for intangible ones such as object-oriented design. Quality can only be measured relatively to a particular point of reference and depends on the assessor's view of the objects to measure as well as the reference point. The view defines the various aspects to be considered regarding measuring quality such as reliability, performance, or security. These aspects span a multi-dimensional space in which no universal linear ordering relationship can be defined regarding quality. We refer to the view and its related multi-dimensional space as viewpoint. If we change the viewpoint then that what we consider good quality changes as well; if we change the point of reference then the degree of the quality changes. |
| Evaluation of Information Technology is mostly considered as decision making on Information Technology investment proposals. However a selected investment proposal still has to be implemented. Actual realisation of such proposals is not as straightforward as it seems. Therefore activities must be started to manage conformance to the initial proposal. One of such activities is 'Software Product Evaluation'. Software Product Evaluation is defined as the assessment of software product characteristics according to specified procedures. During a Software Product Evaluation the fit between the software product and the users' needs of that product are determined. This fit concerns both explicit and implicit needs about the product. This is often referred to as 'software product quality'. Software Product Evaluation becomes more popular both in industry and academics. Several evaluation techniques are already available, and others are being developed. This paper presents the current status of software product evaluation and points out the future needs. We conclude that three main areas can be distinguished on which more progress is necessary: building a quality profile, selecting appropriate actions during software implementation to address the quality profile, and designing and executing the evaluation activities. |
| The automatic layout of software diagrams is a very attractive graph drawing application for use in software tools. Object-oriented software may be modelled using a visual language called the Unified Modeling Language (UML). In this paper we present an algorithm for the automatic layout of UML class diagrams using an extension of the Sugiyama algorithm together with orthogonal drawing. These diagrams visualize the static structure of object-oriented software systems and are characterised by... |
| This report describes an empirical study comparing three defect detection techniques: a) code reading by stepwise abstraction, b) functional testing using equivalence partitioning and boundary value analysis, and c) structural testing using branch coverage. It is a replication of a study that has been carried out at least four times previously over the last 20 years. This study used 47 student subjects to apply the techniques to small C programs in a fractional factorial experimental design. The major findings of the study are: a) that the individual techniques are of broadly similar effectiveness in terms of observing failures and finding faults, b) that the relative effectiveness of the techniques depends on the nature of the program and its faults, c) these techniques are consistently much more effective when used in combination with each other. These results contribute to a growing body of empirical evidence that supports generally held beliefs about the effectiveness of defect detection techniques in software engineering. |
| Traces of program executions are a helpful source of information for automated debugging. They, however, usually give a too low level picture of the executed program. Opium, our extendable trace analyser for Prolog, is connected to a «standard» tracer. Opium is programmable and extendable. It provides a trace query language and abstract views of executions which solve the problems of low-level traces. Opium has shown its capabilities to build abstract tracers and automated debugging facilities. This article describes the trace query mechanism, from the model to its implementation. Characteristic examples are detailed. Extensions written so far on top of the trace query mechanism are listed. Two recent extensions are presented: the abstract tracers for the LO (Linear Objects) and the CHR (Constraint Handling Rules) languages. These two extensions were specified and implemented within a few days. They show how to use Opium for real applications. |
| This is a catalog of micro-patterns, as defined in [Eden, Gil \& Yehudai 97b; Eden \& Yehudai 97c]. A detailed description of the trick [ibid.] that implements the lattice [ibid.] of the CACHE-PROXY design pattern [GoF 95] by a {Smalltalk} routine is included, and also the source code of a sample Eiffel program whose elements served as arguments to the CACHE-PROXY trick. |
| Over recent years patterns have been drawing attention in the software community. Patterns capture knowledge from various parts of software developing. As the number of patterns increases the need to organize the patterns becomes more important. A classification scheme should organize patterns in a library and assist users in finding and storing patterns. This thesis concerns a classification of object-oriented design patterns. Developing a classification scheme involves finding useful criteria that should reflect natural properties of patterns. The thesis also contains a thorough survey of patterns and related topics. |
| At last year's OOPSLA workshop on teaching OO, I got around to deciding that talking about OO design quality is a matter of talking about the futures the design supports. I have not changed my opinion recently, but added these five tests to walk through on an OO design. |
| Every programming system is prone to certain kinds of bugs. A good programmer learns these bugs, and how to avoid them. {Smalltalk} is no different. {Smalltalk} eliminates lots of bugs that are common in other languages, such as bugs in linear search algorithms. (Just use do:) However, it has its own set of classic bugs, which every new {Smalltalk} programmer runs into. There are several reasons to collect classic bugs. The first is that it will help experienced programmers test and debug programs, and can help us design better programs in the first place. Second, if we teach these bugs up front then people should learn to be good programmers faster. Third, perhaps we can redesign the system to eliminate some of these bugs, or we can write checking tools to spot them automatically. |
| 1996 |
| Pattern-Oriented Software Architecture is a new approach to software development. This book represents the progression and evolution of the pattern approach into a system of patterns capable of describing and documenting large-scale applications. A pattern system provides, on one level, a pool of proven solutions to many recurring design problems. On another it shows how to combine individual patterns into heterogenous structures and as such it can be used to facilitate a constructive development of software systems. Uniquely, the patterns that are presented in this book span several levels of abstractions from high-level architectural patterns and medium-level design patterns to low-level idioms. This shifts the focus from what was conceived as an object-oriented design technique for reuse to a powerful and documentable method for designing large and complex software systems. The intention of, and motivation for, this book is to support both novices and experts in software development. Novices will gain from the experience inherent in pattern descriptions and experts will hopefully make use of, add to, extend and modify patterns to tailor them to their own needs. None of the pattern descriptions are cast in stone and just as they are borne from experience, it is expected that further use will feed in and refine individual patterns and produce an evolving system of patterns. |
| Interest in patterns has fostered one of the fastestgrowing communities in contemporary software design. Like many emergent software techniques in recent history---structured programming, data abstraction, and objects---they have captured the imagination of many in the industry. Most of these techniques fail to fulfill the expectations that propel them to such prominence, partly because immature ideas are exposed to the market prematurely, partly because of opportunism, and partly because a hopeful (or desperate) market yearns for the one key solution to all problems. This is a recipe not only for mismatched expectations but for misinformation, which in turn fuels expectations and so on. |
| This innovative book recognizes the need within the object-oriented community for a book that goes beyond the tools and techniques of the typical methodology book. In Analysis Patterns- Reusable Object Models , Martin Fowler focuses on the end result of object-oriented analysis and design - the models themselves. He shares with you his wealth of object modeling experience and his keen eye for identifying repeating problems and transforming them into reusable models. Analysis Patterns provides a catalogue of patterns that have emerged in a wide range of domains including trading, measurement, accounting and organizational relationships. Recognizing that conceptual patterns cannot exist in isolation, the author also presents a series of "support patterns" that discuss how to turn conceptual models into software that in turn fits into an architecture for a large information system. Included in each pattern is the reasoning behind their design, rules for when they should and should not be used, and tips for implementation. The examples presented in this book comprise a cookbook of useful models and insight into the skill of reuse that will improve analysis, modeling and implementation. |
| In our homes, our schools, and our our businesses, computers play an ever-increasing role. But while most of us today can work a computer---albeit with the help of the ever-present computer software manual---we know little about what goes on inside the box and virtually nothing about software design or the world of computer programming. In extit{Patterns of Software}, the respected software pioneer and computer scientist, Richard P. Gabriel, gives us an informative inside look at the world of software design and computer programming and the businesses that surround them. In this wide-ranging volume, Gabriel discusses such topics as what makes a successful programming languages, how the rest of the world looks at and responds to the work of computer scientists, how he first became involved in computer programming and software development, what makes a successful software business, and why his own company, Lucid, failed in 1994, then years after its inception. Perhaps the most interesting and enlightening section of the book is Gabriel's detailed look at what he believes are the lessons that can be learned from architect Christopher Alexander, whose books---including the seminal extit{A Pattern Language}--- have had a profound influence on the computer programming community. Gabriel illuminates some of Alexander's key insights---the quality without a name, pattern languages, habitability, piecemeal growth---and reveals how these influential architectural ideas apply equally well to the construction of a computer program. Gabriel explains the concept of habitability, for example, by comparing a program to a New England farmhouse and the surrounding structures which slowly grow and are modified according to the needs and desires of the people who live and work on the farm. ``Programs live and grow, and their inhabitants---the programmers---need to work with that program the way the farmer works with the homestead." Although computer scientists and software entrepreneurs will get much out of this book, the essays are accessible to everyone and will intrigue anyone curious about Silicon Valley, computer programming, and the world of high technology. |
| Object-Oriented Design Heuristics offers insight into object-oriented design improvement. The more than sixty guidelines presented in this book are language-independent and allow you to rate the integrity of a software design. The heuristics are not written as hard and fast rules; they are meant to serve as warning mechanisms which allow the flexibility of ignoring the heuristic as necessary. This tutorial-based approach, born out of the author's extensive experience developing software, teaching thousands of students, and critiquing designs in a variety of domains, allows you to apply the guidelines in a personalized manner. The heuristics cover important topics ranging from classes and objects (with emphasis on their relationships including association, uses, containment, and both single and multiple inheritance) to physical object-oriented design. You will gain an understanding of the synergy that exists between design heuristics and the popular concept of design patterns; heuristics can highlight a problem in one facet of a design while patterns can provide the solution. Programmers of all levels will find value in this book. The newcomer will discover a fast track to understanding the concepts of object-oriented programming. At the same time, experienced programmers seeking to strengthen their object-oriented development efforts will appreciate the insightful analysis. In short, with Object-Oriented Design Heuristics as your guide, you have the tools to become a better software developer. |
| The last few decades have witnessed a proliferation of software systems in a wide range of working environments. Changes to such systems are often required in order to improve performance and enhance functionality and it is the management and control of these changes that is known as software maintenance. Studies have indicated that software maintenance consumes a least 50\% of resources allocated to many software life cycles and thus is an important area for software engineers to master. This book sets out to provide a comprehensive intrudcuction to software maintenance concepts, showing how these concepts can be used to offer practical solutions to problems encountered by software engineers. Providing a framework for understanding the concepts, the authors outline how this can be applied using the wide variety of software maintenance techniques available. These include coverage of reverse engineering, reengineering, program comprehension, code restructuring and maintainability measures. extit{Software Maintenance: Concepts and Practice} begins by explaining software maintenance and examines and analyses the various methods which have been used in industry to date. Rather than the traditional view of software as static artefact, with maintenance either costly or impossible, this book presents the view of an evolutionary development of software. extit{Software Maintenance: Concepts and Practice} is the ideal for computing and engineering students studying a course in software maintenance and software engineering. It will also be an invaluable resource for practising software engineers, software designers and programmers. |
| Dans le cadre d'une mod\'elisation objet, des liens de natures diff\'erentes relient les objets de l'application. Certains expriment des relations durables et structurelles, d'autres au contraire, sont \'eph\'em\`eres. L'objectif de ce papier est d'\'etudier, d'une part, les diff\'erents types de liens inter-objets et d'en proposer, d'autre part, une d\'efinition formelle et des r\`egles pour les identifier tout en s'appuyant sur le comportement des objets li\'es. Nous avons identifi\'e plusieurs crit\`eres pour caract\'eriser les diff\'erents types de liens en examinant la dynamique li\'ee \`a l'\'ev\`enement de mort des objets li\'es. Les crit\`eres les plus discriminants sont la d\'ependance ou l'ind\'ependance des objets unis par le lien et le caract\`ere obligatoire ou optionel. Nous montrons \'egalement comment le partage et la multivaluation du lien viennent pond\'erer les r\'eactions objets reli\'es. La dynamique des objets nous a permis non seulement de donner une s\'emantique pr\'ecise pour chacun des liens, mais \'egalement d'utiliser le comportement des objets comme des r\`egles m\'ethodologiques pour inf\'erer des liens au niveau des classes et offrir ainsi une assistance au concepteur lors du processus de mod\'elisation d'une application. |
| Design patterns raise the abstraction level at which people design and communicate design of object-oriented software. However, the mechanics of implementing design patterns is left to the programmer. This paper describes the architecture and implementation of a tool that automates the implementation of design patterns. The user of the tool supplies application-specific information for a given pattern, from which the tool generates all the pattern-prescribed code automatically. The tool has a distributed architecture that lends itself to implementation with off-the-shelf components. |
| Over the past decade, the term "software quality" has been widely used. In many instances the term has been loosely used in relation to process and product. This has created considerable confusion and diverted the industry from its primary goal - improving the quality of the products of the various phases of software development. While some attention has been paid to high-level quality attributes, little has been devoted to the systematic study of tangible product properties and their influence on high-level quality attributes. Today the dominant modus operandi for software development is heavily process-oriented. This rests on the widely held belief that you need a quality process to produce a quality product. The flaw in this approach is that the emphasis on process usually comes at the expense of constructing, refining, and using adequate product quality models. The fundamental axiom of software product quality is: a product's tangible internal characteristics or properties determine its external quality attributes. Developers must build these internal properties into a product in order for it to exhibit the desired external quality attributes. A product quality model, therefore, must comprehensively identify the tangible (measurable and/or assessable) internal product characteristics that have the most significant effect on external quality attributes. I suggest a framework for the construction and use of practical, testable quality models for requirements, design, and implementation. Such information may be used directly to build, compare, and assess better quality software products. |
| This paper defines a Software Quality Model and associated attributes and then uses the model as a basis for a discussion of risk. Specific quality goals and attributes are selected based on their importance to a software development project and their ability to be quantified. Risks that can be determined by the model's metrics are identified. A core set of metrics relating to the software development process and its products is defined. Measurements for each metric and their usability and applicability discussed. |
| Cohesion was first developed to predict properties of implementations created from a given design. Unfortunately, cohesion, as originally defined, could not be objectively assessed, while more recently developed objective cohesion measures depend on code-level information. We show that association-based and slicebased approaches can be used to measure cohesion using only design-level information. Our design-level cohesion measures are formally defined, can be readily implemented, and can support software design, maintenance, and restructuring |
| Most object-oriented programs have imperfectly designed inheritance hierarchies and imperfectly factored methods, and these imperfections tend to increase with maintenance. Hence, even object-oriented programs are more expensive to maintain, harder to understand and larger than necessary. Automatic restructuring of inheritance hierarchies and refactoring method can improve the design of inheritance hierarchies, and the factoring of methods. This results in programs being smaller, having better code re-use and being more consistent. This paper describes Guru, a prototype tool for automatic inheritance hierarchy restructuring and method refactoring of Self programs. Results from realistic applications of the tool are presented. |
| In the absence of an agreed measure of software quality the density of defects has been a very commonly used surrogate measure. As a result there have been numerous attempts to build models for predicting the number of residual software defects. Typically, the key variables in these models are either size and complexity metrics or measures arising from testing information. There are, however, serious statistical and theoretical difficulties with these approaches. Using Bayesian Belief Networks we can overcome some of the more serious problems by taking account of all the diverse factors implicit in defect prevention, detection and complexity. |
| A collection of design patterns was described by {Gamma}, {Helm}, {Johnson}, and {Vlissides} in 1994. Each pattern ensures that a certain system aspect can vary over time, for example the operations that can be applied to an object or the algorithm of a method. The patterns are described by constructs such as the inheritance and reference relations, attempting to emulate more dynamic relationships. As a result, the design patterns demonstrate how awkward it is to program natural concepts of evolution when using a traditional object-oriented language. In this paper, we present a new relation between classes: the context relation. It directly models dynamic evolution, and it is meaningful at both the design and implementation level. At the design level we extend the Unified Modelling Language (UML) to include the context relation as a new form of arrow between classes. At the implementation level we present a small extension of {Java{}}. The context relation introduces a new form of dynamic binding that serves as a replacement to delegation. We demonstrate how the context relation can be used to easily model and program numerous design patterns. |
| Mastering the complexity of programs and systems, particularly distributed systems, should lead to significant improvements in program and system understanding. In this paper we present a formal approach for (distributed) software understanding based on abstraction hierarchies represented by architectural design patterns. This approach allows us to model the distributed software applications through a formal model representing the underlying structure. The representation uses instances of architectural design patterns which can hide details that may be irrelevant in specific situations. The formal models which are produced could be used as a basis for reasoning, code generation, and measuring the "goodness" of a design. |
| This paper describes a new approach towards code reuse through a highlevel programming language. This work has been developed in the context of combinatorial optimization for industrial problems, where performance is critical and where a large number of fairly complex algorithms are used, that often share similar structures (such as branch \& bound). The result is the CLAIRE programming language, which provides high levels of abstraction and parametrization. Consequently, it may be used as an executable pseudocode to describe concise and reusable problem solving algorithms. |
| For a substantial improvement of the re- engineering task, identifying the general and recurring high level concepts buried in the source code is essential. However, revealing such soft- ware patterns cannot be performed by automatic means only, it requires the management of various uncertainty issues. This paper introduces these patterns and discusses how the uncertainty issues arising during re-engineering can be handled. Furthermore, the paper shows the potential of high-level application patterns for improving the COREM re-engineering methodology. |
| The object-oriented design community has recently begun to collect so-called design patterns: cliches plus hints to their recommended use in software construction. The structural design patterns Adapter, Bridge, Composite, Decorator, and Proxy represent packaged problem/context/solution/properties descriptions to common problems in object-oriented design. Localizing instances of these patterns in existing soft- ware produced without explicit use of patterns can improve the maintainability of software. In our approach, called the Pat system, design information is extracted directly from {C++} header files and stored in a repository. The patterns are expressed as {Prolog} rules and the design information is translated into facts. A single {Prolog} query is then used to search for all patterns. We examined four applications, including the popular class libraries {zApp} and LEDA, with {Pat}. With some restrictions all pattern instances are found; the precision is about 40 percent. Since manual altering of the output is relatively easy, we consider Pat a useful tool for discovering or recovering design information. |
| Design patterns are one of the hot topics in the software community. Assuming that patterns will play an outstanding role in future software designs we dare to take a look beyond today`s pattern definition activities and give some ideas on how every stage of the software development process might substantially profit from a systematic and controlled use of patterns. Anyway, an appropriate tool support is needed to maintain patterns. As a first step towards such tools, we present the {Hook \& Template} meta-pattern which can be regarded as an unified description of all patterns known so far. Based on this meta-pattern we show how the meta-model of a CASE-tool might be extended according to patterns. Finally, we propose a formalism for pattern instantiation, the process of assigning roles defined in an abstract pattern to classes and methods of the concrete design. |
| The {Law of Demeter} [4] is accepted as a useful design principle that promotes tightly encapsulated classes and reduced coupling. Principles like this are routinely adopted in real-life projects, however neither the programming languages nor the existing environments provide enough support for effective realization of these principles. It is our thesis that broad structural principles should be formally specified, strictly enforced, and relaxed whenever relaxation is in order. In this paper we show how this can be done under our {darwin-E} environment using, the {Law of Demeter} as an illustration. |
| As a complex software system evolves, its implementation tends to diverge from the intended or documented design models. Such undesirable deviation makes the system hard to understand, modify, and maintain. This paper presents a hybrid computer-assisted approach for confirming that the implementation of a system maintains its expected design models and rules. Our approach closely integrates logic-based static analysis and dynamic visualization, providing multiple code views and perspectives. We show that the hybrid technique helps determine design-implementation congruence at various levels of abstraction: concrete rules like coding guidelines, architectural models like design patterns[7] or connectors[26], and subjective design principles like low coupling and high cohesion. The utility of our approach has been demonstrated in the development of {mChoices}, a new multimedia operating system which inherits many design decisions and guidelines learned from experience in the construction and maintenance of its predecessor, Choices |
| Design patterns are distilled from many real systems to catalog common programming practice. However, some object-oriented design patterns are distorted or overly complicated because of the lack of supporting programming language constructs or mechanisms. For this paper, we have analyzed several published design patterns looking for idiomatic ways of working around constraints of the implementation language. From this analysis, we lay a groundwork of general-purpose language constructs and mechanisms that, if provided by a statically typed, object-oriented language, would better support the implementation of design patterns and, transitively, benefit the construction of many real systems. In particular, our catalog of language constructs includes sub-typing separate from inheritance, lexically scoped closure objects independent of classes, and multi-method dispatch. The proposed constructs and mechanisms are not radically new, but rather are adopted from a variety of languages and combined in a new, orthogonal manner. We argue that by describing design patterns in terms of the proposed constructs and mechanisms, patterns descriptions become simpler and, therefore, accessible to a larger number of language communities. Constructs and mechanisms lacking in a particular language can be implemented using the paradigmatic idioms. |
| The purpose of this research has been to demonstrate the feasibility of building programs to detect the use of software design patterns in {Smalltalk} programs. To this end this thesis examines the structure of design patterns, determines the nature of what makes a design pattern detectable by automated means, and outlines algorithms by which a small set of design patterns can be detected. This thesis also documents the development of a software tool, KT, which can reverse-engineer design diagrams from {Smalltalk} code, and use this information to detect the aforementioned patterns. Finally, this thesis demonstrates the use of this tool on a small sample of commercial-scale {Smalltalk} programs and forms the basis for further work investigating the prevalence of different design patterns in existing {Smalltalk} software. |
| Object-Oriented Design Patterns (OODPs) have been proposed as a technique to encapsulate design experience and aid in design reuse. However, so far, there is very little empirical evidence about what we can expect from this emergent technology. For instance, to date little research has focused on the development of techniques for discovering workable patterns that can be captured, formalized, packaged, and quantitatively evaluated. Our work is a step in this direction. In this paper we present an inductive method aimed at helping us discover OODPs in existing OO software systems. It encompasses a set of procedures rigorously defined in order to be repeatable and usable by practitioners who are not acquainted with reverse architecting processes. Guidelines are provided and a case study is shown that demonstrates the usefulness of the approach. |
| This paper presents the results of a study conducted at the University of Maryland in which we experimentally investigated the suite of Object-Oriented (OO) design metrics introduced by [Chidamber\&Kemerer, 1994]. In order to do this, we assessed these metrics as predictors of fault-prone classes. This study is complementary to [Li\&Henry, 1993] where the same suite of metrics had been used to assess frequencies of maintenance changes to classes. To perform our validation accurately, we collected data on the development of eight medium-sized information management systems based on identical requirements. All eight projects were developed using a sequential life cycle model, a well-known OO analysis/design method and the C++ programming language. Based on experimental results, the advantages and drawbacks of these OO metrics are discussed. Several of Chidamber\&Kemerer’s OO metrics appear to be useful to predict class fault-proneness during the early phases of the life-cycle. We also showed that they are, on our data set, better predictors than “traditional” code metrics, which can only be collected at a later phase of the software development processes. |
| When designing an object oriented application design patterns can be useful. These design patterns give a general solution to a design problem, and are used again and again to solve certain design problems. An object oriented design pattern its solution is described in terms of collaborating objects. One reason to use patterns is that design patterns lets some of the collaborating objects vary independently of others, thereby making an application more robust to change and thus to reuse. Another reason to use design patterns is to describe and communicate existing patterns among designers. So, design patterns are said to make reuse of an application more feasible. But, when reusing an application it might be needed to restructure the application first. This is because not all applications were made with design patterns in mind. If this was the case, design patterns might appear in an unstructured way which makes them difficult to detect and thereby to understand the application. Automated re-structurings of an application will make reuse even further approachable. When re-structurings are behavior preserving a design can easily modify an application to make parts of it fit in a new application. Low level re-structurings can be used to define high level re-structurings. For exemple, a restructuring such as abstracting a class from two given classes will use a low level restructuring to create a class. This thesis describes a tool to restructure an object-oriented application with design patterns in mind. During the process of restructuring the user is informed about the structure of te application which can be used to base restructuring on. Design patterns are mode visible in the tool and behavior preserving restructuring can be applied on the application. Besides restructuring an application the tool can also be used to semi-automatically develop applications with the aid of design patterns. In short, the tool discussed eases the process of restructuring for reuse, implementing and maintaining an application. |
| During the last decade, object orientation has been advanced as a promising paradigm for software construction. In addition several authors have advocated the use of formal specification techniques during software development. Formal methods enable reasoning (in a mathematical sense) about properties of programs and systems. It is clear that also object oriented software development can benefit from the use of formal techniques. But although the object oriented analysis (OOA) methods claim to provide the necessary concepts and tools to improve the quality of software development,they are in general informal. This is surprising as the modeling techniques used in OOA have a high potential for formalization. The purpose of this study is to compare the specification techniquesused in current OOA-methods. In particular, the degree of formality provided by most of the methods is discussed and evaluated from a quality control perspective. |
| 1995 |
| Reviews recent research on object-oriented complexity metrics, offering theoretical and empirical guidelines and tips for technical managers and programmers. Discusses object-oriented concepts, measurement theory, available metrics, and industrial application of a metrics program. Topics include traditional product metrics for structural complexity, object-oriented product metrics, and a cognitive complexity model. Contains chapter summaries, case studies, a glossary, and a list of acronyms. Annotation copyright Book News, Inc. Portland, Or. |
| Depuis 1906, le extit{Petit Larousse} fait partie int\'egrante du patrimoine culturel et sentimental de tous les Fran\c cais et de tous les amoureux de la langue fran\c caise. Cette ann\'ee encore, plus d'un million de lecteurs, en France, en Belgique, en Suisse, au Qu\'ebec, en Afrique..., ach\`eteront un nouveau extit{Petit Larousse}. Symbole de savoir-faire et d'exp\'erience en mati\`ere de dictionnaire, le extit{Petit Larousse} est traduit et adapt\'e en espagnol, finnois, italiens, n\'eerlandais, portugais, serbo-croate et turc, devenant ainsi une r\'ef\'erence internationale. Une version en langue anglaise est actuellement en pr\'eparation. Si le extit{Petit Larousse} est une v\'eritable institution, c'est parce que son objectif est double : offrir \`a ses lecteurs ce qui constitue leur patrimoine linguistique et culturel, tout en refl\'etant l'\'evolution du monde contemporain. Ainsi, chaque ann\'ee et toujours avec discernement, il enregistre des mots nouveaux, accueille des personnalit\'es et, sans cesse mis \`a jour dans ses d\'eveloppements encyclop\'ediques, il rend compte des \'ev\`enements les plus actuels. Le succ\`es du extit{Petit Larousse} tient aussi \`a l'importance capitale qu'il a, le premier, accord\'ee \`a l'illustration. Les dessins, les photographies, les cartes et les sch\'emas \'eclairent les mots, prolongent les d\'efinitions ; les planches mettent en relation les \'el\'ements dispers\'es par l'odre alphab\'etique. L'exp\'erience prouve que l'illustration, en plus de son r\^ole didactique, est aussi un extraordinaire vecteur d'\'emotion qui attise la curiosit\'e et s'inscrit dans la m\'emoire de chacun. Aujourd'hui, toutes en couleurs, les illustrations~-- 3 600 dessins, sch\'emas et photographies, 285 cartes~-- offrent une documentation visuelle encore plus actuelle, riche et attrayante. |
| After covering the basic concepts and terms of OOD, pitfalls of Object-Oriented Development provides over eighty concise summaries describing how to detect and avoid the many potential problems that lurk at every step of the software development process: (1) Conceptual, separating OOD fact and hype, (2) Political: the organizational dangers of adopting new technology, (3) Management: how to guide a development team through OOD, (4) Analysis and Design: coming up with the right solution to the right problem, (5) Environment, Languages, and Tools: concerns and considerations, (6) Implementation: OOD temptations faced by new developers, (7) Classes and Objects: warning signs of poor design and implementation, (8) Coding: nasty OOD bugs and how to avoid them, (9) Quality Insurance: OOD testing challenges, (10) Reuse: the roadblocks to achieving the most oft-cited benefit of OOD. |
| Until now, activity related to design patterns has focused primarily on collecting new patterns, describing them as precisely as possible, and cataloging and organizing them. Having a good catalog of patterns is important, ut is only the first step. The ultimate goal is to use these patterns to design software in a new and better way. Even though all the ground work has not yet been finished, this paper looks ahead at the problems and possibilities of pattern implementation. There are three basic problems: With the present implementation style, patterns get lost during program coding. This leads to debugging and maintenance problems later. Good documentation certainly helps here, but a safer and cleaner solution would be for the final code to record the patterns. Multiple patterns can lead to large clusters of mutually dependent classes, which is one of the prime reasons why object-oriented systems can be difficult to manage. Any method that would break at least so of these dependency cycles would greatly improve the program. Until now it has been quietly assumed that the programmer will implement patterns in code by designing the classes as prescribed by the pattern. As I know, nobody has described a library of concrete reusable patterns. This paper shows that problems 1 and 2 above can be solved by representing each pattern with a special class called a Pattern class. This class encapsulates all the behavior and logic of the pattern. The classes that form the pattern contain no pattern-related methods, only pointers and the other data required for the pattern. The result is a major decoupling of the application classes, and separation of application classes from patterns. This paper a shows how you can build a reusable library of many common patterns. |
| The catalogue of design patterns from [Gamm94] contains about twenty design patterns and their mutual relationships. In this paper, we organize these relationships into different categories and revise the design patterns and their relationships. We are then able to arrange the design patterns in different layers. The results simplify the understanding of the overall structure of the catalogue, thereby making it easier to classify other design patterns, and to apply these design patterns to classify other design patterns, and to apply these design patterns to software development. |
| Techniques of machine learning have been successfully applied to various problems [1, 12]. Most of these applications rely on attribute-based learning, exemplified by the induction of decision trees as in the program C4.5 [20]. Broadly speaking, attribute-based learning also includes such approaches to learning as neural networks and nearest neighbor techniques. The advantages of attribute-based learning are: relative simplicity, efficiency, and existence of effective techniques for handling noisy data. However, attribute-based learning is limited to non-relational descriptions of objects in the sense that the learned descriptions do not specify relations among the objects' parts. Attribute-based learning thus has two strong limitations: the background knowledge can be expressed in rather limited form, and the lack of relations makes the concept description language inappropriate for some domains. |
| There lies a behavior between rigid regularity and randomness based on pure chance. It's called a chaotic system, or chaos for short [5]. Chaos is all around us. Our notions of physical motion or dynamic systems have encompassed the precise clock-like ticking of periodic systems and the vagaries of dice-throwing chance, but have often been overlooked as a way to account for the more commonly observed chaotic behavior between these two extremes. When we see irregularity we cling to randomness and disorder for explanations. Why should this be so? Why is it that when the ubiquitous irregularity of engineering, physical, biological, and other systems are studied, it is assumed to be random and the whole vast machinery of probability and statistics is applied? Rather recently, however, we have begun to realize that the tools of chaos theory can be applied toward the understanding, manipulation, and control of a variety of systems, with many of the practical applications coming after 1990. To understand why this is true, one must start with a working knowledge of how chaotic systems behave---profoundly, but sometimes subtly different, from the behavior of random systems. the behavioral elements of chaos introduces a wide array of commercial applications to enhance, manipulate, or better control many current technical functions. |
| A model for software product quality is defined. It has been formulated by associating a set of quality-carrying properties with each of the structural forms that are used to define the statements and statement components of a programming language. These quality-carrying properties are in turn linked to the high-level quality attributes of the International Standard for Software Product Evaluation ISO-9126. The model supports building quality into software, definition of language-specific coding standards, systematically classifying quality defects, and the development of automated code auditors for detecting defects in software. |
| ``Percevoir, c'est reconna\^{\i}tre une forme". Telle est la d\'ecouverte fondamentale de la Gestalt theorie n\'ee au d\'ebut du si\`ecle. En d'autres termes, c'est parce que nous projetons sur le monde des ``formes" connues qu'il nous est possible de le comprendre. |
| AI as a field has undergone rapid growth in diversification and practicality. For the past 10 years, the repertoire of AI techniques has evolved and expanded. Scores of newer fields have recently been added to the traditional domains of practical AI. Although much practical AI is still best characterized as advanced computing rather than intelligence, applications in everyday commercial and industrial settings have certainly increased, especially since 1990. Additionally, AI has shown a growing influence on other computer science areas, such as databases, software engineering, distributed computing, computer graphics, user interfaces, and simulation. This month's Communications presents the second of two special issues on practical applications of artificial intelligence (AI). The first issue published in March 1994 primarily focused on the most practical areas of AI. This issue presents more futuristic areas. I believe these two issues serve as milestones in presenting the current state and future perspective of everyday commercial and industrial applications of AI. |
| The KBSE community is actively engaged in finding ways to represent software and the activities that relate to various stages in its life-cycle. While the wealth of modelling activities have, necessarily, been founded on first order logic based representations, this paper reports on research into Software Information System that has found the domain of software to be inherently second order. A facility for accurately representing second order constructs such as are found in the software domain is also presented. |
| Code cognition models examine how programmers understand program code. The authors survey the current knowledge in this area by comparing six program comprehension models: the Letovsky (1986) model; the Shneiderman and Mayer (1979) model; the Brooks (1983) model; Soloway, Adelson and Ehrlich's (1988) top-down model; Pennington's (1987) bottom-up model; and the integrated metamodel of von Mayrhauser and Vans (1994). While these general models can foster a complete understanding of a piece of code, they may not always apply to specialized tasks that more efficiently employ strategies geared toward partial understanding. We identify open questions, particularly considering the maintenance and evolution of large-scale code. These questions relate to the scalability of existing experimental results with small programs, the validity and credibility of results based on experimental procedures, and the challenges of data availability |
| This paper presents a metaobject protocol MOP for C++. This MOP was designed to bring the power of meta programming to C++ programmers. It avoids penalties on runtime performance by adopting a new meta architecture in which the metaobjects control the compilation of programs instead of being active during program execution. This allows the MOP to be used to implement libraries of effcient transparent language extensions. |
| We propose a reflective model to express and to automatically manage dependencies between objects. This model describes reflective facilities which enable the changing of language semantics. Although the importance of inter-object dependencies is well accepted, there is only limited object- oriented language support for their specification and implementation. In response to this lack of expressiveness of object models, the FLO language integrates dependency management into the object oriented paradigm. Dependencies are described as first class objects and FLO automatically maintains the consistency of the dependency graph. In this paper, we first show how a user can declare dependencies and how the system maintains the consistency of the graph of expressed dependencies. In a second part, we focus on the implementation of this management by controlling the messages sent to linked objects. In order to make dependency management orthogonal to other application concerns, we propose an abstraction of message handling, implemented with meta-objects. We illustrate the extensibility of our language with different control behavior implementations, in particular we study different implementations of the global control of message propagation flow. |
| A central aspect of architectural design is the use of recurring organizational patterns and idioms- or architectural styles. Examples include generic system organizations such as those based on dataflow or layers, as well as specific organizational structures such as the classical decomposition of a compiler, the OSI communication stack, and the MVC user interface paradigm. The principled use of architectural styles has a number of practical benefits. First, it promotes design reuse: routine solutions with well-understood properties can be reapplied to new problems with confidence. Second, it can lead to significant code reuse: often the invariant aspects of an architectural style lend themselves to shared implementations. Third, it is easier for others to understand a system's organization if conventionalized structures are used. For example, even without giving details, characterization of a system as a ``client-server" organization immediately conveys a strong image of the kinds of pieces and how they fit together. Fourth,use of standardized styles supports interoperability. Examples include CORBA object-oriented architecture, and event-based tool integration. Fifth, by constraining the design space, an architectural style often permits specialized,style-specific analyses. For example, it is possible to analyze pipe-filter systems for schedulability, throughput, latency, and deadlock-freedom. Such analyses might not be meaningful for an arbitrary, ad hoc architecture - or even one constructed in a different style. Sixth, it is usually possible to provide style-specific visualizations: this makes it possible to provide graphical and textual renderings that match engineers' domain-specific intuitions about how their designs should be depicted. |
| A temporal event analysis approach to program understanding is described. Program understanding is viewed as a sequence of episodes in which the programmer concludes that an informal event occurs that corresponds to some part of the code. This can be viewed as accepting that the code is an adequate definition of the meaning of the informal event. Often, such a definition is contingent upon working hypotheses that describe other informal program properties that should be verified in order to confirm the validity of the understanding process. Verification of working hypotheses may depend on the formulation of additional definitions or working hypotheses. The understanding process can be assisted through the use of a documentation language for describing events and hypotheses, and an hypothesis verification tool. This paper describes a temporal event language in which hypotheses are formulated in terms of expected event sequences. An hypothesis verification tool was built, and experimentation was carried out on a set of programs. The tool was found to be very useful in understanding the detailed, control oriented aspects of a program. Program faults were discovered in every program that was analyzed, indicating that it facilitates a deep level of understanding. |
| This paper describes an effort to provide automated support for the interactive inquiry and explanation process that is at the heart software understanding. A hypermedia tool called {I-Doc} allows software engineers to post queries about a software system, and generates focused explanations in response. These explanations are extit{task oriented}, i.e., they are sensitive to the software engineering task being performed bu the user that led to the query. Task orientation leads to more effective explanations, ans is particulartly helpful for understanding large software systems. Empirical studies of inquiry episodes were conducted which support this claim. The {I-Doc} tool is being developed to embody these principles, employing knowledge-based techniques. The presentation mechanism employs World Wide Web technology, making it suitable for widespread use. |
| Framework programming is regarded as one the main advantages of object-oriented software engineering, and is expected to increase software reuse. In exploiting frameworks, however, programmers often face difficulties caused by the complexity of the hidden architecture and the multiplicity of the design decisions that are embedded in a framework. Interactive visualization of design patterns occurring in a framework shows how the framework is operating, in a flexible yet structured way that contributes to the programmer's understanding of the underlying software architecture. In this way, programmers can explore and use frameworks efficiently even when they are distributed without vast amounts of documentation and source code. |
| Program debugging can be an expensive, complex and frustrating process. Conventional programming environments provide little explicit support for the cognitive tasks of diagnosis and visualization faced by the programmer. ZStep 94 is a program debugging environment designed to help the programmer understand the correspondence between static program code and dynamic program execution. Some of ZStep 94's innovations include: An animated view of program execution, using the very same display used to edit the source code; A window that displays values which follows the stepper's focus; An incrementally-generated complete history of program execution and output; ``Video recorder" controls to run the program in forward and reverse directions and control the level of detail displayed; One-click access from graphical objects to the code that drew them; One-click access from expressions in the code to their values and graphical output . |
| Software engineers often use high-level models (for instance, box and arrow sketches) to reason and communicate about an existing software system. One problem with high-level models is that they are almost always inaccurate with respect to the system's source code. We have developed an approach that helps an engineer use a high-level model of the structure of an existing software system as a lens through which to see a model of that system's source code. In particular, an engineer defines a high-level model and specifies how the model maps to the source. A tool then computes a software reflexion model that shows where the engineer's high-level model agrees with and where it differs from a model of the source. The paper provides a formal characterization of reflexion models, discusses practical aspects of the approach, and relates experiences of applying the approach and tools to a number of different systems. The illustrative example used in the paper describes the application of reflexion models to NetBSD, an implementation of Unix comprised of 250,000 lines of C code. In only a few hours, an engineer computed several reflexion models that provided him with a useful, global overview of the structure of the NetBSD virtual memory subsystem. The approach has also been applied to aid in the understanding and experimental reengineering of the Microsoft Excel spreadsheet product. |
| Traditional object oriented analysis methodologies are based not only upon objects, but also upon relationships between objects. Object oriented programming languages do not provide support for relationships, and so analysis relationships must be expressed indirectly within a program's design, and then incorporated into implementations of other objects in a program's code. By using explicit relationships in design and implementation, analysis relationships can be expressed directly within a program's code. Programs which use explicit relationships are often smaller and easier to comprehend than traditional OO programs, and are generally quicker to write and easier to maintain. |
| In this paper we present a formal approach to define and apply design patterns that is both process- and reuse-oriented. Initially we use a process program based on design pattern primitive tasks or constructors to describe how to instantiate a pattern. As we develop the patterns we introduce a formal model for the interconnected objects that constitute the instantiation. The formal model which is based on Abstract Data Views divides designs into both objects and views in order to maintain a separation of concerns. We have chosen a formal model for pattern definition and application since it allows us to specify the steps in pattern instantiation unambiguously and to reason about the completed design. Furthermore, a formal statement of the application of a design pattern can provide the foundation on which to build tools to assist the programmer in code generation. |
| Object-Oriented methodologies like OMT provide abstractions that are not directly supported by Object-Oriented Languages. We have designed a mapping to embed these abstractions into Object-Oriented Languages, such as C++. This mapping relies upon a meta object model of the entities of the OO methodology. For each one of the meta objects we have defined operators which are being implemented as a C++ library and a prototype is being tested. We report on the result of applying this development to a realistic application. |
| 1994 |
| Capturing a wealth of experience about the design of object-oriented software, four top-notch designers present a catalogue of simple and succinct solutions to commonly occurring design problems. Previously undocumented, these 23 patterns allow designers to create more flexible, elegant, and ultimately reusable designs without having to rediscover the design solutions themselves. The authors begin by describing what patterns are and how they can help you design object-oriented software. They then go on to systematically name, explain, evaluate, and catalogue recurring designs in object-oriented systems. With Design Patterns as your guide, you will learn how these important patterns fit into the software development process, and how you can leverage them to solve your own design problems most efficiently. Each pattern describes the circumstances in which it is applicable, when it can be applied in view of other design constraints, and the consequences and trade-offs of using the pattern within a larger design. All patterns are compiled from real systems and are based on real-world examples. Each pattern also includes code that demonstrates how it may be implemented in object-oriented programming languages like C++ or Smalltalk. |
| This book provides a number of specific metrics that apply to object-oriented software projects. The metrics are based on measurements and derived advice drawn from a number of actual projects that have successfully used object technology to deliver products. Covers both project completion metrics and design metrics --- common, Smalltalk only, and C++ only. For programmers interested in object-oriented technology. |
| {C++} uses inheritance as a substitute for subtype polymorphism. We give examples where this makes the type system too inflexible. We then describe a conservative language extension that allows us to define an abstract type hierarchy independent of any implementation hierarchies, to retroactively abstract over an implementation, and to decouple sub-typing from inheritance. This extension gives the user more of the flexibility of dynamic typing while retaining the efficiency and security of static typing. With default implementations and views we provide flexible mechanism for implementing an abstract type by different concrete class types. We first show how our language extension can be implemented in a preprocessor to a {C++} compiler, and then detail and analyze the efficiency of an implementation we directly incorporated in the {GNU C++} compiler. |
| Software development can be characterized in terms of prototype (or initial design) phases, expansion phases and consolidation phases. During a consolidation phase, some relationships, initially modelled using inheritance, may be evolved to aggregations. Also, during consolidation, abstract classes are sometimes defined to capture behavior common to two or more existing classes. In this paper, we define high-level patterns for the prototype, expansion and consolidating programs. We also define supporting patterns for evolving aggregations from inheritance hierarchies and for creating abstract classes. |
| We describe an approach to text classification that represents a compromise between traditional word-based techniques and in-depth natural language processing. Our approach uses a natural language processing task called “information extraction” as a basis for high-precision text classification. We present three algorithms that use varying amounts of extracted information to classify texts. The relevancy signatures algorithm uses linguistic phrases; the augmented relevancy signatures algorithm uses phrases and local context; and the case-based text classification algorithm uses larger pieces of context. Relevant phrases and contexts are acquired automatically using a training corpus. We evaluate the algorithms on the basis of two test sets from the MUC-4 corpus. All three algorithms achieved high precision on both test sets, with the augmented relevancy signatures algorithm and the case-based algorithm reaching 100% precision with over 60% recall on one set. Additionally, we compare the algorithms on a larger collection of 1700 texts and describe an automated method for empirically deriving appropriate threshold values. The results suggest that information extraction techniques can support high-precision text classification and, in general, that using more extracted information improves performance. As a practical matter, we also explain how the text classification system can be easily ported across domains. |
| Program understanding can be enhanced using reverse engineering technologies. The understanding process is heavily dependent on both individuals and their specific cognitive abilities, and on the set of facilities provided by the program understanding environment. Unfortunately, most reverse engineering tools provide a fixed palette of extraction, selection, and organization techniques. This paper describes a programmable approach to reverse engineering. The approach uses a scripting language that enables users to write their own routines for common reverse engineering activities such as graph layout, metrics, and subsystem decomposition, thereby extending the capabilities of the reverse engineering toolset to better suit their needs. A programmable environment supported by this approach subsumes existing reverse engineering systems by being able to simulate facets of each one. |
| We need ways to describe designs that communicate the reasons for our design decisions, not just the results. Design patterns have been proposed as ways of communicating design information. This paper shows that patterns can be used to derive an architecture from its problem statement. The resulting description makes it easier to understand the purpose of the various architectural features. |
| Objects model phenomena and a phenomenon is usually a component. Information characterizing a component is encapsulated and accessible only by its methods. The relations between components are modeled explicitely by means of associations or references. A relation is also a phenomenon and objects can model this type of phenomena too. Components are usually related conceptually in diverse and subtle ways: Some relations are implicitly given and some are local to other more basic relations. Such kinds of relations are important for understanding the organization and cooperation of objects and may be supported in object-oriented analysis, design, and programming: An implicit association describes a relation between an object and objects local to its enclosing object, and a complex association describes an explicit relation between local objects in different enclosing objects. Such associations are described by classes and the objects have the usual properties including methods and attributes. |
| This report identifies a set of quality characteristics of software and provides a summary of software metrics that are useful in measuring these quality characteristics for software products. The metrics are useful in assessing the reusability of software products. This report is preliminary. Additional research is needed to ensure the completeness of the quality characteristics and supporting metrics, and to provide guidance on using the metrics. |
| 1993 |
| The first edition of extit{Object-Oriented Design with Applications} was instrumental in making object-oriented technology a practical reality--hundreds of projects applied Booch's notation and process to complex problems in diverse domains. In this eagerly-awaited new edition, Grady Booch draws upon the rich and varied results of these projects to offer improved methods for object development and a new, extit{unified notation}. With numerous examples, all of which are now implemented in C++, Booch illustrates essential concepts, explains the method, and shows successful applications in a variety of fields. You'll also find pragmatic advice on a host of issues including classification, implementation strategies, and cost-effective project management. |
| Constraint satisfaction is a general problem in which the goal is to find values for a set of variables that will satisfy a given set of constraints. It is the core of many applications in artificial intelligence, and has found its application in many areas, such as planning and scheduling. Because of its generality, most AI researchers should be able to benefit from having good knowledge of techniques in this field. This book is the most comprehensive book on the field of constraint satisfaction so far. It covers both the theoretical and the implemenatation aspects of the subject. It provides a framework for studying this field, relates different research, and resolves ambiguity in a number of concepts and algorithms in the literature. This book provides a solid foundation for researchers in this field. It is also an invaluable text for graduate and research level students in cognitive science and artificial intelligence. |
| Reverse engineering involves a great deal of effort in comprehension of the current implementation of a software system and the ways in which it differs from the original design. Automated support tools are critical to the success of such efforts. We show how program slicing techniques can be employed to assist in the comprehension of large software systems, through traditional slicing techniques at the statement level, and through a new technique, interface slicing, at the module level. |
| Numerous classes, complex inheritance and containment hierarchies, and diverse patterns of dynamic interaction all contribute to difficulties in understanding, reusing, debugging, and tuning large object-oriented systems. To help overcome these difficulties, we introduce novel views of the behavior of object-systems and an architecture for creating and animating these views. We describe platform-independent techniques for instrumenting object-oriented programs, a language-independent protocol for monitoring their execution, and a structure for decoupling the execution of a subject program from its visualization. Case studies involving tuning and debugging of real systems are presented to demonstrate the benefits of visualization. We believe that visualization will prove to be a valuable tool for object-oriented software development. |
| Maintenance tends to degrade the structure of software, ultimately making maintenance more costly. At times, then, it is worthwhile to manipulate the structure of a system to make changes easier. However, manual restructuring is an error-prone and expensive activity. By separating structural manipulations from other maintenance activities, the semantics of a system can be held constant by a tool, assuring that no errors are introduced by restructuring. To allow the maintenance team to focus on the aspects of restructuring and maintenance requiring human judgment, a transformation-based tool can be provided--based on a model that exploits preserving data flow dependence and control flow dependence--to automate the repetitive, error-prone, and computationally demanding aspects of restructuring. A set of automatable transformations is introduced; their impact on structure is described, and their usefulness is demonstrated in examples. A model to aid building meaning-preserving restructuring transformations is described, and its realization in a functioning prototype tool for restructuring Scheme programs is discussed. |
| A person understands a program because they are able to relate the structures of the program and its environment to their human oriented conceptual knowledge about the world. The problem of discovering individud human oriented concepts and assigning them to their implementation oriented counterparts for a given a program is the concept assignment problem. We will argue that the solution to this problem requires methods that have a strong plausible reasoning component. We will illustrate these ideas through example scenarios using an existing design recovery system called DESIRE. Finally, we will evaluate DESIRE based on its usage on real-world problems over the years. |
| A method is presented for using composite objects which separates their role and meaning as models of relations between problem-domain concepts from their role and meaning as models of hierarchical software structures. The meaning of composite objects is analysed in terms of connections between real-world concepts in object-oriented analysis and between software objects in object-oriented design. By capturing the designer's rationale for model transformation, the resulting models are easier to understand and maintain. An embedded systems example illustrates the approach. |
| Object-oriented programs evolve by means other than just the addition of new classes. The changes to object-oriented programs that have been most studied are those based on inheritance, on reorganizing a class hierarchy. However, aggregation is a relationship between classes that is just as important as inheritance, and many changes to an object-oriented design involve the aggregate/component relationship. This paper describes some common refactorings based on aggregation, including how to convert from inheritance to an aggregation, and how to reorganize an aggregate/component hierarchy just as one might reorganize a class inheritance hierarchy. |
| Distributed systems are conveniently described, constructed and managed in terms of their software structure or architecture. However few current platforms exploit the architectural view. This paper outlines current work on the provision of an architectural methodology and graphical support tool, the System Architect's Assistant, for the design and engineering of distributed systems. The tool supports both initial informal design decomposition and subsequent rigorously checked composition when a set of specified, designed and/or implemented components are integrated to analyse and/or construct the desired distributed system. The effectiveness of the methodology and prototype tool will be assessed by applying it to case studies supplied by an industrial associate and by conducting controlled productivity experiements. |
| Describes six OO design metrics. Authors are among most frequently cited for OO software metrics. Contains reasons why these metrics are needed, presents the theory behind mapping empirical system to formal system, and introduces the OO concepts that need to be taken into account. |
| In this paper a dynamic approach to measure the coupling of software systems is proposed. The conventionally used static measures are only limited suitable for the evaluation and characterization of such systems. We extend the static methodology with a dynamic component and define new measures based on this approach. A model for system characterization based on varying execution profiles is given. The layout of an automated monitor system is presented, which can be directly integrated into a software development system. |
| v Many problems can be formulated as Constraint Satisfaction Problems (CSPs), although researchers who are untrained in this field sometimes fail to recognize them, and consequently, fail to make use of specialized techniques for solving them. In recent years, constraint satisfaction has come to be seen as the core problem in many applications, for example temporal reasoning, resource allocation, scheduling. Its role in logic programming has also been recognized. The importance of constraint satisfaction is reflected by the abundance of publications made at recent conferences such as IJCAI-89, AAAI-90, ECAI-92 and AAAI-92. A special volume of Artificial Intelligence was also dedicated to constraint reasoning in 1992 (Vol 58, Nos 1-3). The scattering and lack of organization of material in the field of constraint satisfaction, and the diversity of terminologies being used in different parts of the literature, make this important topic more difficult to study than is necessary. One of the objectives of this book is to consolidate the results of CSP research so far, and to enable newcomers to the field to study this problem more easily. The aim here is to organize and explain existing work in CSP, and to provide pointers to frontier research in this field. This book is mainly about algorithms for solving CSPs. The volume can be used as a reference by artificial intelligence researchers, or as a textbook by students on advanced artificial intelligence courses. It should also help knowledge engineers apply existing techniques to solve CSPs or problems which embed CSPs. Most algorithms described in this book have been explained in pseudo code, and sometimes illustrated with Prolog codes (to illustrate how the algorithms could be implemented). Prolog has been chosen because, compared with other languages, one can show the logic of the algorithms more clearly. I have tried as much as possible to stick to pure Prolog here, and avoid using non-logical constructs such as assert and retract. The Edinburgh syntax has been adopted. CSP is a growing research area, thus it has been hard to decide what material to include in this book. I have decided to include work which I believe to be either fundamental or promising. Judgement has to be made, and it is inevitably subjective. It is quite possible that important work, especially current research which I have not been able to fully evaluate, have been mentioned too briefly, or completely missed out. An attempt has been made to make this book self-contained so that readers should need to refer to as few other sources as possible. However, material which is too lengthy to explain here, but which has been well documented elsewhere, has been left out. Formal logic (mainly first order predicate calculus) is used in definitions to avoid ambiguity. However, doing so leaves less room for error, therefore errors are inevitable. For them, I take full responsibility. |
| 1992 |
| Pour les d\'eveloppeurs de logiciel, les langages de programmation sont l'outil fondamental et quotidien. Trop peu pourtant connaissent les bases th\'eoriques qui permettent de ma\^{\i}triser les langages et de mieux les employer. Par une d\'emarche progressive, claire et bien structur\'ee, l'auteur pr\'esente successivement les notions de syntaxe abstraite et de s\'emantique formelle. Puis il d\'eveloppe la s\'emantique d\'enotationnelle et la s\'emantique axiomatique. Pour illustrer son discours, il expose et approfondit des concepts importants, comme le lambda-calcul et les d\'efinitions r\'ecursives. Ce livre fournit, de surcro\^{\i}t, une excellente \'etude comparative des caract\'eristiques de diff\'erents langages de programmation. Algol, Ada, Lisp, Pascal, C... et les langages \`a objets, notamment Eiffel, sont tour \`a tour \'evoqu\'es. Il en ressort une vue synth\'etique tr\`es riche de leurs diff\'erences et--ou de leurs parent\'es ainsi que des choix qui ont pr\'esid\'e \`a leur impl\'ementation. La pr\'esentation a \'et\'e con\c cue pour des praticiens de la programmation : l'auteur utilise en permanence des exemples de programmes concrets et des analogies emprunt\'ees aux situations les plus courantes de la construction de logiciel. Tous les concepts math\'ematiques n\'ecessaires sont emprunt\'es \`a la th\'eorie \'el\'ementaire des ensembles et d\'efinis clairement dans un bref chapitre d'introduction. Enfin, le lecteur appr\'eciera de pouvoir \'evaluer ses acquis gr\^ace aux exercices propos\'es \`a la fin de chaque chapitre. Les concepteurs de langage puiseront dans cet ouvrage les bases fondamentales de leur travail. Les \'etudiants et les ing\'enieurs y trouveront un expos\'e didactique leur permettant d'approfondir leurs connaissances th\'eoriques. |
| This thesis defines a set of program restructuring operations (refactorings) that support the design, evolution and reuse of object-oriented application frameworks. The focus of this thesis is on automating the refactorings in a way that preserves the behavior of a program. The refactorings are defined to se behavior preserving, provided that their preconditions are met. Most of the refactorings are simple to implement and it is almost trivial to show that they are behavior preserving. However, for a few refactorings, one or more of their preconditions are in general undecidable. Fortunately, for some cases it can be determined wether these refactorings can be applied safely. Three of the most complex refactorings are defined in details: generalizing the inheritance hierarchy, specializing the inheritance hierarchy and using aggregation to model the relation-ships among classes. These operations are decomposed into more primitives parts, and the power of these operations is discussed from the perspective of automatibility and usefulness in supporting design. Two design constraints needed in refactoring are class invariants and exclusive components. These constraints are needed to ensure the that behavior is preserved across some refactorings. This thesis gives some conservative algorithms for determining wether a program satisfies these constraints, and describe how to use this design information to refactor a program. |
| An approach that embeds human-computer cooperative problem-solving tools into knowledge-based design environments that work in conjunction with human software designers in specific application domains is described. This human-centered approach takes advantage of peoples' ability to understand and incrementally reformulate their problems, while allowing them to contribute to the gradual improvement of the underlying knowledge base. The notion of evolution circumvents the inability of the original builders of a design environment to anticipate all future needs and knowledge for complete coverage of a domain. The access and development of knowledge is supported in a cycle of location, comprehension, and modification. Modification includes the evolution of the knowledge base and tools. A framework for building such tools and mechanisms is described and illustrated in terms of three systems: \ygg@product{CatalogExplorer}, \ygg@product{Explainer}, and \ygg@product{Modifier}. User studies of these systems demonstrate the promise and the limitations of the design environment approach. |
| For the reuse of software to become routine, it is essential that all modules have well-defined interfaces, and that all users of these modules respect these interfaces. This paper examines the interfaces in object-oriented programs. It uses the notion of delegation, which can be thought of as underlying all inheritance mechanisms, to provide a framework for the examination of encapsulation mechanisms in object-oriented languages. Using delegation, the encapsulation mechanisms in class-based languages are reviewed, and suggestions are made as to how they might be improved. |
| Multiple dispatching provides increased expressive power over single dispatching by guiding method lookup using the values of all arguments instead of only the receiver. However, existing languages with multiple dispatching do not encourage the data- abstraction-oriented programming style that is encouraged by traditional single-dispatching languages; instead existing multiple-dispatching languages tend to foster a function- oriented programming style organized around generic functions. We propose an alternative view of multiple dispatching that is intended to promote a data-abstraction-oriented programming style. Instead of viewing a multi-method as 'outside' of all objects, we view a multi-method as 'inside' the objects for which the multi-method applies (on which it dispatches). Because objects are closely connected to the multi-methods implementing their operations, the internals of an object can be encapsulated by being accessible only to the closely-connected multi-methods. We are exploring this object-oriented view of multi-methods in the context of a new programming language named Cecil. |
| Troll is a language to specify information systems with dynamic behavior. Here, we elaborate on the specification of object aggregation in Troll . We distinguish between two kinds of aggregation, static and dynamic aggregation. Static aggregation means that the composition of objects is described using predicates over constant properties. Dynamic aggregation means that we may alter the composition of objects by invoking special operations (events) that are implicitly defined for each dynamic complex object. Additionally, we describe the specification of disjoint complex as a means for structuring a specification. We introduce language features to describe object aggregation and give some hints torwards their semantics. |
| To support the sharing and reuse of formally represented knowledge among AI systems, it is useful to define the common vocabulary in which shared knowledge is represented. A specification of a representational vocabulary for a shared domain of discourse -- definitions of classes, relations, functions, and other objects -- is called an ontology. This paper describes a mechanism for defining ontologies that are portable over representation systems. Definitions written in a standard format for predicate calculus are translated by a system called Ontolingua into specialized representations, including frame-based systems as well as relational languages. This allows researchers to share and reuse ontologies, while retaining the computational benefits of specialized implementations. We discuss how the translation approach to portability addresses several technical problems. One problem is how to accommodate the stylistic and organizational differences among representations while preserving declarative content. Another is how to translate from a very expressive language into restricted languages, remaining system-independent while preserving the computational efficiency of implemented systems. We describe how these problems are addressed by basing Ontolingua itself on an ontology of domain-independent, representational idioms. |
| We have designed and implemented in C an interprocedural data flow analysis that will estimate the memory object lifetime and its temporal locality. The analysis is an abstract interpretation. The target language is a multilingual intermediate language called MIL. Since we have ANSI C, Fortran, and Scheme front-ends for the target language, the analysis works for programs written in these high-level languages. The analysis information can be used for many kinds of compile-time memory, which include boosting the generational garbage collection, explicity garbage deallocation, hierarchical memory performance improvement, and static memory performance evaluation. We present an analysis example our our implementation. |
| 1991 |
| Assuming a background in C++ basics, this book helps programmers to develop their programming expertise by giving a feel for the styles and idioms of the language. The approach is organized around the abstractions that C++ supports: Abstract data types, combining types in inheritance structures, object-oriented programming, and multiple inheritance. The book also explors idioms that the core of the C++ language does not support directly, such as virtual constructors, prototype objects, and advanced garbage collection techniques. |
| This book presents a new approach to programming language design, which resolves fundamental tensions between elegance and efficiency. Metaobject protocols are interfaces to the lanaguage that gives users the ability to incrementally modify the language's behavior and implementation, as well as the ability to write programs within the language. In this way, a metaobject protocol allows users to adjust the lanaguage to better suit their needs. |
| Notable mainly for its clear and thorough exploration of the Object Modelling Technique (OMT)--a generic way of representing objects and their relationships--this book is good as a primer and great as a knowledge booster for those already familiar with object-oriented concepts. Object-Oriented Modelling and Design teaches you how to approach problems by breaking them down into interrelated pieces, then implementing the pieces. In addition to its documentation of the Object Modelling Technique (OMT), a graphical notation for depicting object-oriented systems, Object-Oriented Modelling and Design does a first-rate job of explaining basic and advanced object-orientation concepts. The book then moves on to explain the authors' techniques for breaking down problems into components and figuring out systems of interrelated objects that can be used as designs for programs. Interestingly, the authors devote part of their book to implementing object-oriented solutions in non-object-oriented languages--mainly {C}, {Ada}, and Fortran. There's also a great discussion of implementing object-oriented designs in relational database environments. The authors conclude their book with a sort of recipe section, detailing architectures for various types of programs in OMT. |
| Because of incomplete specifications or inadequate design decisions, software components developed with an object-oriented language require frequent re-organisations before they become stable, reusable classes. We propose a new incremental algorithm that analyses the redefinitions carried out on inherited properties when a class is added to a hierarchy, and restructures the hierarchy to discover missing abstractions and to enforce programming style guidelines. We illustrate our automatic restructuring approach with simple examples, describe formally the algorithm and the object model it is based on, and discuss its suitability for object-oriented software engineering. |
| While software metrics are generally desirable feature in the software management functions of project planning and project evaluation, they are of especial importance with a new technology such as the object-oriented approach. This is due to the significant need to train software engineers in generally accepted object-oriented principles. This paper presents theoretical work that builds a suite of metrics for object-oriented design. In particular, these metrics are based upon measurement theory and are informed by the insights of experienced object-oriented software developers. The proposed metrics are formally evaluated against a widely-accepted list of software metric evaluation criteria. |
| New techniques for browsing amongst functionally related classes, and retrieving classes from objectoriented class libraries are presented. These techniques make use of two potent, and rea.dily available sources of information: the source code of each class, and its associated documentation. We describe how the integration of information retrieval techniques based on document analysis, and domain specific approaches based on code analysis, permits the construction of class retrieval tools based on natural language queries, and new kinds of browsing tools based on class functionality rather than inheritance. The chief advantages of this approach, compared to previous approaches, are that information about classes is acquired automatically and cheaply -- no human intervention is required t,o acquire information about each class; and it is readily scalable and extensible -- classes can be added to the library with very little effort. |
| This standard defines six characteristics that describe, with minimal overlap, software quality. These characteristics provide a baseline for further refinement and description of software quality. Guidelines describe the use of qualitycharacteristics for the evaluation of software quality.This standard does not provide subcharacteristics and metrics, and methods for measurement, rating, and assessment. |
| 1990 |
| Where will the next order of magnitude improvement in software productivity come from? In this book, two leading researchers at M.I.T. answer this question by describing the Programmer's Apprentice, a powerful new approach to computer-aided software engineering (CASE) that combines artificial intelligence and software engineering techniques. The Programmer's Apprentice is an intelligent assistant for software engineers that will provide advice, catch errors, and take care of routine details throughout the software process, from requirements acquisition to implementation and maintenance. Rich and Waters use extensive illustrations and transcripts from a demonstration system to make the principles and methods underlying the Programmer's Apprentice understandable to both researchers and engineers. In the concluding chapter, they give specific examples of how to apply ideas from the Programmer's Apprentice to the next generation of CASE tools. This book will give software professionals and CASE tool designers a glimpse of what to expect in the future of software development. It will also inspire researchers and students in both artificial intelligence and software engineering by showing the results of synergy between these two disciplines. |
| The availability of computer-aided systems-engineering environments has redefined how many organizations approach system development. To meet their true potential, CASE environments are being applied to the problems of maintaining and enhancing existing systems. The key lies in applying reverse-engineering approaches to software systems. However, an impediment to success is the considerable confusion over the terminology used in both technical and market-place discussion. It is in the reverse-engineering arena, where the software maintenance and development communities meet, that various terms for technologies to analyze and understand existing systems have been frequently misused or applied in conflicting ways. In this article, we define and relate six terms: forward engineering, reverse engineering, re-documentation, design recovery, restructuring, and reengineering. Our objective is not to create new terms but to rationalize the terms already in use. The resulting definitions apply to the underlying engineering processes, regardless of the degree of automation applied. |
| Presents a solution that allows flexible mapping of neural nets (such as multi-layered ones) onto uncommitted processing arrays in which a large number of processing elements are interconnected by a switched-bus network. The basic algorithms leading to such mapping are outlined, providing a balance between structure simplicity and parallelism of operation speed. A protocol by which the array can be configured (and, therefore, initialized) is presented: nominal operation is then described, and it is seen that the same solution providing for initialization supports also subsequent algorithms. The structure of the basic elements of the architecture (switches and processing elements) is detailed, so as to allow an evaluation of complexity as regards silicon requirements in CMOS. |
| The objective of this paper is to provide a brief introduction to the area of domain analysis as seen from the software engineering perspective. The approach is by illustrating the concepts through selected reported experiences and to point out the specific characteristics of these experiences that relate to domain analysis. Definitions are introduced after the examples to avoid over explaining the concepts. A model for the domain analysis process is also proposed. The concept of a library based domain infrastructure is introduced as an attempt to show how domain analysis is integrated into the software development process. A second objective in this paper is to give a perspective on some of the research issues facing domain analysis. The nature of the process calls for a variety of multidiciplinary issues ranging from knowledge acquisition and knowledge representation to management and methodologies to cultural and social questions. |
| An experienced programmer can often reconstruct much of the hierarchy of a program's design by recognizing commonly used data structures and algorithms and knowing how they typically implement higher lever abstractions. We call these commonly used programming structures clich\'es. Examples of algorithmic clich\'es are list enumerations, binary searches, and successive-approximation loops. Examples of data-structure clich\'es are sorted lists, balanced binary trees, and hash tables. Psychological experiments have shown that programmers use clich\'es heavily in many programming tasks. Instead of reasoning from first principles, programmers---like other problem solvers---tend to rely on their experience as much as possible. In general, a chlich\'e contains both fixed and varying parts. For example, every binary search must include computations to apply the search predicate and divide the remaining search space in half, but the specific search predicate will vary. A clich\'e may also include constraints that restrict the varying parts. For example, the operation that computes the next approximation in a successive-approximation loop must reduce the error term. We have built a prototype, the Recognizer, that automatically finds all occurrences of a given set of clich\'es in a program and builds a hierarchical description of the program in terms of the clich\'es it finds. So far we have demonstrated the Recognizer only on small Common Lisp programs, but the underlying technology is language-independent. |
| Lawyers disagree about whether it is legal to use the sophisticated reengineering technology now in existence (and being developed) to reverse-engineer programs developed by other firms. The benefits of the reengineering technology all but ensure that ensure that the law will not ban the technology outright, just as videotape recorders could not be banned from the market merely because the machines could be used to make unauthorized copies of copyrighted movies (even though two movie studios once sought such a ban against them). |
| We present an iterative-design approach for reusable object-oriented software that augments existing design methods by incorporating iteration into the design methodology and focuses on the set of problems within the domain, encouraging reuse of existing design information. The model has five separate stages which are described, before an example design is outlined using the model with sample code constructs in C++. Our results have shown a high degree of code reuse when using the model, directly attributable to two distinct design stages. An analysis of these results is also presented. |
| The meta level is probably the most identifiable feature of reflective systems. But although it is essential to have a meta-level, that doesn't mean the notion is clear. What makes a meta level extit{be} a meta level? What kinds of meta level are possible? How does the distinction between code above and below a given reflective level differ from the more traditional distinction between code inside and outside of a module boundary? |
| Object-oriented software engineering (OOSE) is an extremely hot topic. There is a rapidly-increasing number of books, articles, seminars, conferences, and products which focus on the technology. Only a few years ago, the discussion was largely limited to programming language features. Now, however, software engineers are investigating and using such things as ``object-oriented requirements analysis" (OORA), ``object-oriented design" (OOD), ``object-oriented database management systems" (OODBMS), ``object-oriented computer hardware" (OOCH), and ``object-oriented computer aided software engineering" (OO CASE). The character of object-oriented applications has changed. Originally, most object-oriented applications were small and non-critical. Object-oriented software engineering was chiefly experimental, i.e., not production-oriented Slow programming language interpreters, highly non-portable languages and environments, lack of concurrency-related features, and fairly limited access to low-level machine characteristics were all tolerable. Now, object-oriented software engineering is entering the mainstream. Object-oriented technology must demonstrate its suitability for applications which are both large and critical. Software engineers must adapt object-oriented concepts to consider such issues as efficiency, low-level hardware characteristics, portability, and concurrency. They must do this in a way which preserves the desirable features, and the essence, of the object-oriented paradigm. In each object-oriented application, one of the tools that will have to be considered is, of course, the implementation language. At one time, the choice was simple~-- there was only one language (i.e., {Smalltalk}) which claimed to be ``object-oriented." Now there are scores of languages, and a plethora of variants, all of which claim to be object-oriented. The issue is further complicated by those who advocate the (occasional) use of traditionally ``non-object-oriented" programming languages in object-oriented applications. |
| The ability to read and understand a computer program is a critical skill for the software developper, yet this skill is seldom developped in any systematic way in the education or training of software professionals. These materials discuss the importance of program reading, and review what is known about reading strategies and other factors affecting comprehension. These materials also include reading exercises for a modest \ygg@pl{Ada} program and discuss how educators can structure additional exercises to enhance program reading skills. |
| The purpose of the Design Metrics project is to develop a metrics approach for analyzing software designs which helps designers engineer quality into the design product. These metrics will gauge project quality as well as design complexity at all times during the design phase. Having quantifiable measurements could help managers and software developers determine the better design when alternative choices exist, as well as identify stress points which may lead to difficulty during coding and maintenance. We have been developing, for a structured design G, a design quality metric D(G) of the form D(G) = k1(De) + k2(Di). In this equation, k1 and k2 are constants and De and Di are respectively, an external and internal design quality component. In De we consider a module's external relationships to other modules in the software system, whereas in Di we consider factors related to the internal structure. To form De and Di, we are searching for a combination of primitive design metrics which are useful, predictive, objective and automatable. This report will present our D(G), with its current De and Di composite metrics, and empirical results as to how D(G) can identify stress points in a software design and how it is related to the quality of the resulting software. |
| 1989 |
| This book shows software developers the powerful set of tools (CLOS) available for developing oject-oriented programs in \ygg@pl{Common Lisp}. The advantages of using CLOS to design, develop, maintain, and extend complex programs are many: it allows for modular implementation; programs more closely resemble what they model; programs are conveniently extensible; and CLOS defines conventions that will be shared across the \ygg@pl{Common Lisp} community. CLOS has been adopoted as part of \ygg@pl{Common Lisp} by the X3J13 committtee, which is working on creating the ANSI Standard \ygg@pl{Common Lisp}. \ygg@pl{Common Lisp} programmers can use this book to start developing object-oriented programs in \ygg@pl{Common Lisp} as quickly as possible. Readers who are not familiar with \ygg@pl{Common Lisp} can discover from this book the major themes of object-oriented programming. |
| Cet ouvrage est le fruit d'un travail d'enseignement et de recherche commenc\'e en 1985 au CRIN (Centre de Recherche en Informatique de Nancy). Il s'adresse \`a tous les membres de la communaut\'e informatique, des n\'eophytes aux sp\'ecialistes. Il passe en revue les diff\'erentes facettes de la programmation objet et effectue un vaste tour d'horizon des langages \`a objets : pr\'esentation didactique des concepts de base de la programmation objet ; historique et classification des langages \`a objets : langages \`a classes, langages de frames, langages d'acteurs et langages hybrides ; description comparative de nombreaux langages \`a objets : Smalltalk, Objective-C, Flavors, CLOS, C++, Eiffel, KRL, etc. ; \'etude comparative de la programmation avec un langage \`a classe (Smalltalk) et avec un langage plus classique (Ada). Il fournit en outre le source comment\'e de l'impl\'ementation de trois langages \`a objets. Cet ouvrage de r\'ef\'erence, gr\^ace aux nombreux exemples qu'il contient, constitue \'egalement un support de cours id\'eal pour les enseignants d\'esireux d'initier leurs \'etudiants aux langages \`a objets. |
| We introduce a simple, programming language independent rule (known in-house as the {Law of Demeter}) which encodes the ideas of encapsulation and modularity in an easy to follow form for the object-oriented programmer. The rule achieves the following related benefits if code duplication, the number of method arguments and the number of methods per class are minimized: Easier software maintenance, less coupling between your methods, better information hiding, methods which are easier to reuse, and easier correctness proofs using structural induction. We show relationships between the Law and software engineering techniques, such as coupling control, information hiding, information restriction, localization of information, narrow interfaces and structural induction. We discuss two important interpretations of the Law (strong and weak) and we prove that any object-oriented program can be transformed to satisfy the Law. We express the Law in several languages which support object-oriented programming, including {Flavors}, {Smalltalk-80}, {CLOS}, {C++} and {Eiffel}. |
| During the past decade, software development concepts have undergone a dynamic revolution. Software development methodologies have evolved to meet changing life cycle patterns which have had as their objective, emphasis on analysis and design. In addition, computer- assisted software engineering (CASE) has emerged to meet the unprecedented growth in analysis and design activities and is affecting how future systems will be developed and tested. These methodologies reinforce the need to accurately define systems specification prior to implementation. The concern over present and future software quality has grown as the volume and complexity of applications increase. Software applications are critical to business operation and lead to severe maintenance problems when they fail. This fact has prompted many firms to develop software engineering programs which attempt to define and implement techniques for soft- ware validation, verification, and testing throughout the development life cycle. |
| 1988 |
| 1987 |
| The relation as a semantic construct in an object-oriented language clearly expresses associations and constraints among objects which would otherwise be buried in implementation code. The externalization of references between objects permits a symmetric, non-redundant conceptual model which merits its own special notation and predefined operations. The object-relation model, which combines the object-oriented model with the entity-relationship model from data base theory, is particularly useful for designing and partitioning systems of interrelated objects. Relations can be implemented efficiently using hash tables. The model proposed here has been fully implemented in an object-oriented language written by the author which has been used to implement several production applications. |
| In very many situations we consider objects to be constructed from parts. The parts in their turn may consist of smaller, simpler parts. And so forth. In engineering design we speak of assemblies and subassemblies; in science we describe things in terms of their components. However, when we want to model objects consisting of parts in Smalltalk, and many other object-oriented languages, we are confronted with a dilemma: either sacrifice the data encapsulation properties of the language or utterly flatten the whole-part hierarchy. In this paper we describe what a part hierarchy is and why it is so important ({\S}1.1). We then show how many object-oriented languages fail to provide this hierarchy ({\S}1.2). After reviewing previous work ({\S}1.3) we sketch how we added the structure to the Smalltalk ({\S}2). The simple implementation details are outlined in an appendix. We discuss where in our experience the part hierarchy was useful and where it fails ({\S}3). Lastly we stand back and examine the broader implications of adding a part hierarchy, and how a part hierarchy interacts with a single and multiple inheritance class hierarchy ({\S}4). It may roughly be said, to give a taste of the conclusions, that parts and wholes address a different dimension of generalization from that addressed by classes. Classes, like sets, provide a partial ordering structure which can be read as ``is-a-kind-of'' or ``belongs-to'', while parts and wholes provide a much more complicated ``is-a-part-which-fits-there'' structure. |
| The ``programs are data'' philosophy of Lisp uses Lisp's S-expressions to represent programs, and permits a program written in Lisp itself to implement the interpreter for the language. Object-oriented languages can take this one step further: we can use objects to represent programs, and an object-oriented interpreter takes the form of responses to a protocol of messages for evaluating programs. Because objects are a richer data structure than simple S-expressions, the representation of programs can have more built-in intelligence than was feasible using simple list manipulation alone. This paper surveys techniques and applications for object-oriented interpreters. We focus particularly on object-oriented interpreters that are reversible, those that, unlike conventional interpreters, remember their history of evaluation. We illustrate the techniques involved with two applications of reversible object-oriented interpreters: a reversible stepper for Lisp, and a programming environment which constructs Lisp programs from examples. |
| We outline our adaptation of Pattern Language to object-oriented programming. We sumarize a system of five patterns we have successfuly used for designing window-based user interfaces and present in slightly more detail a single pattern drawn from our current effort to record a complete pattern language for object-oriented programs. |
| 1986 |
| L'objet de cet ouvrage est de pr\'esenter les principales techniques et leurs programmes associ\'es, utilisables pour les applications scientifiques et en gestion. Ecrits en Basic sur l'IBM-PC, ces programmes couvrent la plupart des domaines relatifs \`a la collecte et \`a la manipulation des donn\'ees, \`a l'analyse num\'erique et \`a la programmation lin\'eaire. Destin\'e aux \'etudiants et aux praticiens, (ing\'enieurs, scientifiques, gestionnaires), ce livre permet de tirer profit du micro-ordinateur IBM-PC gr\^ace aux nombreux programmes qui y sont pr\'esent\'es et illustr\'es. C'est un compagnon indispensable pour tout utilisateur de m\'ethodes quantitatives. Ecrit de fa\c con claire et pr\'ecises, il permet la manipulation des sous-programmes et leur int\'egration dans des programmes plus vastes en vue de la r\'ealisation d'applications scientifiques ou en gestion. |
| A revolution---fueled by the growing body of cognitive science research into the nature of expertise---is causing radical revision in science and mathematics curricula today. What has been taught in the past is by and large not what an expert actually knows. For example, geometry students typically understand each step in a proof, as the teacher puts it on the board, line by line. However, when attempting to do a proof for homework, students often have no idea where to begin. Why? Mathematicians do not develop proofs in such an orderly, linear fashion. Rather, developing a proof is a nonlinear, search process. Unfortunately, students are not told explicitly about the nonlinear nature of proof development: They see their teacher develop a proof line by line, and not surprisingly, they think they should be able to do the same. Today, teaching topics such as geometric proofs is being revised to include explicit instruction as to the heuristics that guide proof development. This article continues with the curriculum redefinition effort and focuses on concepts that should be taught in an introductory programming course. Textbooks used in introductory programming courses typically focus on the syntax and semantics of constructs in a language. New research with novice programmers, however, suggests that language constructs do not pose major stumbling blocks for novices learning to program. Rather, the real problems novices have lie in putting the pieces together, composing and coordinating components of a program. Expert programmers know a great deal more than just the syntax and semantics of language constructs. They have built up large libraries of stereotypical solutions to problems as well as strategies for coordinating and composing them. Students should be taught explicitly about these libraries and strategies for using them. |
| 1985 |
| A central issue in programming practice involves determining the appropriate size and information content of a software module. This study attempted to determine the effectiveness of two widely used criteria for software modularization, strength and size, in reducing fault rate and development cost. Data from 453 FORTRAN modules developed by professional programmers were analyzed. The results indicated that module strength is a good criterion with respect to fault rate, whereas arbitrary module size limitations inhibit programmer productivity. This analysis is a first step toward defining empirically based standards for software modularization. |
| 1984 |
| 1983 |
| In the beginning, IS-A was quite simple. Today, however, there are almost as many meanings for this inheritance link as there are knowledge-representation systems. |
| 1982 |
| 1981 |
| The nature of “software quality” and some software metrics are defined and their relationship to traditional software indicators such as “maintainability” and “reliability” are suggested. Recent work in the field is summarized and an outlook for software metrics in quality assurance is provided. The material was originally presented as a tutorial at the “ACM SIGMETRICS Workshop/Symposium on Measurement and Evaluation of Software Quality” on March 25, 1981. |
| A combination of program-proving ideas and stepwise refinement is used to develop and explain an algorithm which uses a variation of the sieve method for computing primes. |
| 1980 |
| 1979 |
| 1978 |
| You can use this book to design a house for yourself with your family; you can use it to work with your neighbors to improve your town and neihborhood; you can use it to design an office, or a workshop, or a public building. And you can use it to guide you in the actual process of construction. After a ten-year silence, Christopher Alexander and his colleagues at the Center for Environment Structure are now publishing a major statement in the form of three books which will, in their words, ``lay the basis for an entirely new approach to architecture, building and planning, which will we hope replace existing ideas and practices entirely". At the core of these three books is the idea that people should design for themselves their own houses, streets, and communities. This idea may be radical (it implies a radical transformation of the architectural profession) but it comes simply from the observation that most of the wonderful places of the world were not made by architects but by the people. At the core of the books too is the point that in designing their environments people always rely on certain ``languages", which, like the languages we speak, allow them to articulate and communicate an infinite variety of designs within a formal system which gives them coherence. It will enable a person to make a design for almost any kind of building, or any part of the built environment. ``Patterns", the units of this language, are answers to design problems (How high should a window still be? How many stories should a building have? How much space in a neighborhood should be devoted to grass and trees?). More than 250 of the patterns in this pattern languages are given: each consists of a problem statement, a discussion of the problem with an illustration, and a solution. As the authors say in their introduction, many of the patterns are archetypal, so deeply rooted in the nature of things that it seems likely that they will be a part of human nature, and human action, as much in five hundred year as they are today. |
| A theory is presented of how a programmer goes about understanding a program. The theory is based on a representation of knowledge about programs as a succession of knowledge domains which bridge between the problem domain and the executing program. A hypothesis and verify process is used by programmers to reconstruct these domains when they seek to understand a program. The theory is useful in several ways in software engineering: It makes accurate predictions about the effectiveness of documentation; it can be used to systematically evaluate and critique other claims about documentation, and it may even be a useful guideline to a programmer in actually constructing documentation. |
| 1977 |
| 1974 |
| With this text, you gain an understanding of the fundamental concepts of algorithms, the very heart of computer science. It introduces the basic data structures and programming techniques often used in efficient algorithms. Covers use of lists, pushdown stacks, queues, trees, and graphs. Later chapters go into sorting, searching and graphing algorithms, the stringmatching algorithms, and the Schonhage--Strassen integer multiplication algorithm. Provides numerous graded exercises at the end of each chapter. |
| The problem of representation and handling of constraints is here considered, mainly for picture processing purposes. A systematic specification and utilization of the available constraints could significantly reduce the amount of search in picture recognition. On the other hand, formally stated constraints can be embedded in the syntactic productions of picture languages. Only binary constraints are treated here, but they are represented in full generality as binary relations. Constraints among more than two variables are then represented as networks of simultaneous binary relations. In general, more than one equivalent (i.e., representing the same constraint) network can be found: a minimal equivalent network is shown to exist, and its computation is shown to solve most practical problems about constraint handling. No exact solution for this central problem was found. Anyway, constraints are treated algebraically, and the solution of a system of linear equations in this algebra provides an approximation of the minimal network. This solution is then proved exact in special cases, e.g., for tree-like and series-parallel networks and for classes of relations for which a distributive property holds. This latter condition is satisfied in cases of practical interest. |
| It seems to me that the ingredients of most theories both in Artificial Intelligence and in Psychology have been on the whole too minute, local, and unstructured to account–either practically or phenomenologically–for the effectiveness of common-sense thought. The "chunks" of reasoning, language, memory, and "perception" ought to be larger and more structured; their factual and procedural contents must be more intimately connected in order to explain the apparent power and speed of mental activities. Similar feelings seem to be emerging in several centers working on theories of intelligence. They take one form in the proposal of Papert and myself (1972) to sub-structure knowledge into "micro-worlds"; another form in the "Problem-spaces" of Newell and Simon (1972); and yet another in new, large structures that theorists like Schank (1974), Abelson (1974), and Norman (1972) assign to linguistic objects. I see all these as moving away from the traditional attempts both by behavioristic psychologists and by logic-oriented students of Artificial Intelligence in trying to represent knowledge as collections of separate, simple fragments. I try here to bring together several of these issues by pretending to have a unified, coherent theory. The paper raises more questions than it answers, and I have tried to note the theory's deficiencies. |
| 1973 |
| 1972 |
| This paper discusses both the history and future of programming languages ( = higher level languages). Some of the difficulties in writing such a history are indicated. A key part of the paper is a tree showing the chronological development of languages and their interrelationships. Reasons for the proliferation of languages are given. The major languages are listed with the reasons for their importance. A section on chronology indicates the happenings of the significant previous time periods and the major topics of 1972. Key concepts other than specific languages are discussed. |
| 1970 |
| 1969 |
| 1968 |
| 1966 |
| 1965 |
| A widely used method of efficient search is examined in detail. This examination provides the opportunity to formulate its scope and methods in their full generality. In addition to a general exposition of the basic process, some important refinements are indicated. Examples are given which illustrate the salient features of this searching process. |
| 1963 |
| 1956 |
| My problem is that I have been persecuted by an integer. For seven years this number has followed me around, has intruded in my most private data, and has assaulted me from the pages of our most public journals. This number assumes a variety of disguises, being sometimes a little larger and sometimes a little smaller than usual, but never changing so much as to be unrecognizable. The persistence with which this number plagues me is far more than a random accident. There is, to quote a famous senator, a design behind it, some pattern governing its appearances. Either there really is something unusual about the number or else I am suffering from delusions of persecution. |
| 1951 |
| 1950 |
| 1940 |
| 1908 |
This document was translated from BibTEX by bibtex2html