Abstract not found

Refactorings are behavior-preserving program transformations that automate design evolution in object-oriented applications. Three kinds of design evolution are: schema transformations, design pattern microarchitectures, and the hot-spot-driven-approach. This research shows that all three are automatable with refactorings. A comprehensive list of refactorings for design evolution is provided and an analysis of supported schema transformations, design patterns, and hot-spot meta patterns is presented. Further, we evaluate 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.

A safety case should present a clear, comprehensive and defensible argument that a system is acceptably safe to operate within a particular context. However, many existing safety cases, in their attempt to manage potentially complex arguments, are poorly structured, presented and understood. This creates problems in developing and maintaining safety cases, and in capturing successful safety arguments for use on future projects. This thesis defines and demonstrates a coherent approach to the development, presentation, maintenance and reuse of the safety arguments within a safety case. This approach is based upon a graphical technique -- the Goal Structuring Notation (GSN) -- and has three strands. Firstly, a method for the use of GSN is defined together with an approach to supporting incremental safety case development. Secondly, the thesis presents a systematic process for the maintenance of a GSN-structured safety argument. Thirdly, the concept of `Safety Case Patterns' is defined as a means of supporting and promoting the reuse of successful safety arguments between safety cases. Examples of the approach are provided throughout. Evaluation of the approach is described through tool implementation, case studies, pilot projects and industrial project applications. Through these activities the approach has been shown to be both a valid and capable tool for safety case management.

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 software development.

Understanding the architecture of a program requires determining both the major components into which the system is broken and the ways in which the components interact to accomplish the program’s goals. Both static and dynamic analyses of the software can aid in obtaining this understanding. This paper describes an analysis technique for gaining such understanding and a visualization tool, called ISVis, that supports it. The technique is applied to the problem of enhancing the Mosaic web browser by both visualizing its architecture and finding the components of the browser into which an enhancement should be inserted.

Modern software systems are increasingly required to be open and distributed. Such systems are open not only in terms of network connectR06 andint0 operabilit support forhet1 ogeneous hardware andsoft are plat orms,but above all, int2 ms of evolving and changingrequirement . Alt169, object,7 ient3 t331,7E8 offers some relief,t o a largeext27 t he languages,met2R8 andtd,2 fail t addresstd needs of opensystE3 becausetc y donot escape from tadit192, models of soft are development tpm assume syst, requirement t be closed and st ble.We argue te, open systE8 requirement can only beadequat7E addressed byadopt9, a component,t ient0 as opposedt a purelyobject3E ient2 soft are development approach, byshift7, emphasis away from programming and towards generalized software composition.

A design pattern is a particular prose form of record-ing design information such that designs which have worked well in the past can be applied again in similar situations in the future. The availability of a collec-tion of design patterns can help both the experienced and the novice designer recognize situations in which design reuse could or should occur. We have found that design patterns: 1) provide an eflective “shorthand ” for communicating complex con-cepts effectively between designers, 2) can be used to record and encourage the reuse of “best practices”, 3) capture the essential parts of a design in compact form, e.g. for documentation of existing software architec-tures. Since the patterns community is one that shares in-formation in an open forum and builds on the experi-ences of others, we chose to submit a joint paper on our industrial experiences with patterns. We focus on the lessons learned in our respective industrial settings as a jirst step towards answering the questions ‘patt-erns sound very promising, but how are they actually used m the industry and what benefits, if any, do they bring in practice?“ We proceed by briefly describing each of our respec-tive experiences with patterns. This is followed by a joint “lessons learned ” section and conclusion.

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. 1 Introduction Object-oriented programming is advertised as leading to more extensible programs than conventional programming [Mey88]. Modifications to a system that would require many changes in conventional programming often can be carried out in an object-oriented program by simply adding new classes. Nevertheless, there are many t...

Abstract. The expression problem (aka the extensibility problem) refers to a fundamental dilemma of programming: To which degree can your application be structured in such a way that both the data model and the set of virtual operations over it can be extended without the need to modify existing code, without the need for code repetition and without runtime type errors. Over the years, many approaches to this problem have been proposed, each having different characteristics of type safety and reusability. While many of these rely on exotic or problem specific language extensions, this paper investigates the solution space within the framework of the soonto-be mainstream generic extensions of C # and the Java programming language. Four new solutions are presented which, though quite different, all rely on techniques that can be used in everyday programming. 1

Patterns have shown to be an effective means of capturing and communicating software design experience. However, there is more to patterns than software design patterns: We believe that patterns work for software development on several levels. In this paper we explore what we have come to understand as crucial aspects of the pattern concept, relate patterns to the different models built during software design, discuss pattern forms and how we think that patterns can form larger wholes like pattern handbooks. 1 Introduction Design patterns have become a hotly discussed topic in software development. We and many other researchers have been using and experimenting with patterns over the last years. We have applied patterns and observed their usage within software development. We have used and seen several definitions of patterns, and we have experimented with pattern forms. The emerging literature shows a flourishing and fruitful diversity of pattern definitions, forms and applications. ...