A. Brooks, A. Sobczak CASE tool support for high-level refactorings: keystroke-level model comparisons Abstract Keystroke-level models have been built for four high-level refactorings for each of three CASE tools. Three interface features were found to account for savings in task execution times. The combination of multiple selection and link-type conversion features was found to be particularly effective. In conclusion, it is recommended that any CASE tool incorporate these features. Keywords: CASE tool, Keystroke Level Model, Refactorings, UML Introduction Software artifacts often undergo change as the software engineer iterates towards a solution acceptable to the customer. In the early phases of analysis and design, software engineers often reject use of CASE tools because they do not readily support the degree and frequency of change that occurs. In [Goss98] the advice is given that early on the best CASE tool is a whiteboard. To support creative design, as opposed to simply design capture, unconstrained modeling environments are necessary [HS90, RMB95]. In [JH98], it is concluded CASE tools must be ‘more user-oriented and support creative problem solving’. Modern object-oriented CASE tools are a considerable improvement over their structured counterparts of a decade or more ago, but how do they support change during analysis and design work? Three object-oriented CASE tools (Rational Rose 98 Enterprise Evaluation Edition, TogetherJ 2.1 Whiteboard Edition, and Simply Objects 2.1 Modeler Edition) were examined for their support of four high-level refactorings by using keystroke-level models. This paper is organized as follows: First we discuss refactorings and the chosen instances of high-level refactorings that we used as benchmarks expressed as UML class diagrams. Then we describe our approach to keystroke-level modeling. The main body of the paper is taken up with graphs of the results of the keystroke-level modeling. Features of the interfaces that were responsible for enhancing user performances are identified. In concluding, we recommend that all CASE tools incorporate these features. Refactorings Refactoring is the process of improving the structure of software [Fow97] and is behaviour preserving [Opd92]. Such software restructuring can be considered at two levels: the design level and the implementation level. This paper primarily concerns itself with refactoring at the early design level but note that the TogetherJ tool allowed us to investigate interaction via a code window where code changes were reflected in the window containing the design. In [Opd92], refactorings were divided into two main subsets: low-level refactorings (26 types) and high-level refactorings (3 types). Low-level refactorings are concerned with the creation, deletion, or movement of individual program entities and are said to be atomic. Higher-level refactorings are obtained by combining these atomic refactorings. Three types of high-level refactorings are defined in [Opd92]; but as one was dependent on knowledge of an implementation, we considered only the other two as follows: • Create a super-class (Common attributes and methods are factored out into a super-class.) • Convert an inheritance relation into an aggregation (Can be used to control proliferation of inheritance). In addition, we decided to consider two further types of high-level refactorings: • Divide up a large class (Used when a class has become too big and lacks cohesion.)