Suitability of Object and Aspect Oriented Languages for Software Maintenance Khalid Al-Jasser Peter Schachte Ed Kazmierczak The University of Melbourne Australia {aljasser,schachte,ed}@cs.mu.OZ.AU Abstract Program maintenance is an important and frequently a difficult part of the software life cycle. One reason for its difficulty is the presence of crosscutting concerns: aspects of a program that cannot be confined to a single program component. Crosscutting concerns defy the standard wis- dom of program design that individual components should be highly cohesive (they should address only one con- cern) and loosely coupled (they should not share concerns with other components). We consider several approaches to a simple maintenance task in both object-oriented and aspect-oriented languages, analyzing how well they main- tain high cohesion and low coupling. We conclude that none of these approaches is entirely satisfactory, and present a few changes to aspect oriented programming language de- sign that would better support maintenance in the face of crosscutting concerns. 1 Introduction Maintenance is a central part of the software lifecycle, commonly identified as accounting for more than half of the cost of software development. It is not surprising, then, that suitability for maintenance has been a key feature in the design of many programming languages. The robust- ness of existing programs in the face of maintenance, that is how strongly they resist introducing faults during main- tenance, is one important determinant of program maintain- ability. Two other important determinants are sustainability and scalability: how maintainable does maintenance leave a program and how does a program’s size impact its maintain- ability? Also important for maintainability, as well as for initial development, is the reusability of existing program components. We consider how well existing programming languages and methodologies support all these characteris- tics as programs are maintained. Probably the greatest single factor in determining how maintainable a program will be is how well structured it is, that is, how well it is divided into separate components. In proposing structured design, Stevens et al. [14] suggest that two key considerations in choosing a program decom- position is how high is its level of cohesion (how well each component focuses on a single concern of the program) and how low is its level of coupling (to what extent do compo- nents share concerns). Similarly, Dijkstra [4] suggested that separation of concerns, or focusing on one aspect of a de- sign at a time, in one component at a time, is essential to the construction of a good design. A program that does not sep- arate concerns is difficult to maintain because a change to a single concern may need to be made in many parts of the program. By concern we mean any aspect of a program’s desired behaviour; any individual requirement. Dijkstra also wrote “even if not perfectly possible, [sep- aration of concerns] is yet the only available technique for effective ordering of one’s thoughts” [4]. Programming lan- guages, providing a limited set of abstractions, cannot sup- port every way to separate concerns that we may informally conceive; different separations of concerns are possible in different programming languages. We use the term cross- cutting concern [10] to describe any concern that relates to a program component other than its central focus. That is, crosscutting concerns are those that interfere with the co- hesion of individual components. Monitoring, synchroniza- tion, and error-handling are all considered crosscutting con- cerns. Each crosscutting concern is thus tangled in the code of other concerns, thus making the other concerns difficult to maintain. Moreover, it may be scattered across many program components, making the concern itself difficult to maintain. Different programming languages and paradigms sup- port different sorts of components, such as procedures, functions, classes, and templates, but virtually every one requires components to be named where they are defined and referred to by name where they are used. This ensures each use of a component is visible in the program. The definition of many sorts of components specify any para- meters that may be supplied, defining an interface between the component and its clients. The interface constitutes the Proceedings of the 2007 Australian Software Engineering Conference (ASWEC'07) 0-7695-2778-7/07 $20.00 © 2007