Autograders are an invaluable tool for deploying assessments in large classes. However students sometimes rely on the autograder in place of careful thought for ways to improve to their solution. We sought to naturally encourage students to check their own solutions more, and hammer the grader less. To do this, we imposed a penalty each time a student's grade went down: we called these regression penalties. We assessed whether the introduction of these penalties resulted in less reliance on the autograder without hurting student performance.

In this paper we explore the idea that the code that constitutes a program actually forms a higher-level, program specific language. The symbols of the language are the abstractions of the program, and the grammar of the language is the set of (generally unwritten) rules about the allowable combinations of those abstractions. As such, a program is both a language definition, and the only use of that language. This specificity means that reading a never-before encountered program involves learning a new natural language, and that porting code from one program to another requires translation from one natural language into another. We suggest that the complexity and depth of the program language is affected by the gap between the program semantics (what the program is meant to do) and the code semantics (the way in which the machine runs). We believe that in seeing that programs are languages, we gain new insight into our own experience as programmers, and are able to gain new perspective on the intense complexity of code and its creation.

Early aspects deal with crosscutting concerns in requirements analysis, domain analysis and architecture design [1]. Work on early aspects focuses on systematically identifying, modularizing, and analyzing such crosscutting concerns and their impact at the early phases of the software development life cycle.

Conscientious software is a recently proposed paradigm for developing reliable, self-sustaining software systems. Conscientious software systems consist of an allopoietic part, which encapsulates application functionality, and an autopoietic part that is responsible for keeping the system alive by monitoring the application and adapting it to environmental changes. Practical application of the conscientious software paradigm requires solutions to two open problems: The design of suitable autopoietic programming languages and the proposal of concrete architectures for combining the autopoietic and allopoietic parts. In this paper, we tackle the second challenge, and propose a concrete, aspect-oriented architecture for realizing conscientious software. Here, we introduce epi-aspects, a construct for upgrading new and existing applications into conscientious software. This paper provides the architectural design of epi-aspects, an autopoietic simulator, and a concrete framework for developing epi-aspects in Java. The framework and the simulator are used to conduct a case study in which we develop and test a conscientious Java application.

Separation of concerns is one of the main tenets of software engineering - allowing developers to reason about software systems in sensible portions, regardless which phase of the lifecycle they are working in. Many researchers in software engineering are actually in the field of aspect-orientation without realizing it.

Aspect-oriented requirements analysis involves the identification of concerns that behaviorally influence other concerns. Such concerns are described in requirements called emphaspectual requirements: requirements that detail the influence of one concern over another. The current state of the art for aspect-oriented requirements analysis is Theme/Doc, which allows lexical analysis of requirements based on a set of developer-chosen keywords. It provides a graphical depiction of how concerns relate to requirements, and affords identification of potential aspectual requirements. In addition, clusters of requirements and concerns are identified to arrive at a more useful set of concerns than those initially identified.Because of the lexical nature of the Theme/Doc approach, aspectual requirements are missed, or wrongly identified. Additionally, requirements may be wrongly clustered if they contain ambiguous terms.In this work we explored whether the use of a statistical approach for textual analysis, Latent Semantic Analysis (LSA), would improve upon the lexical approach used by Theme/Doc. We found that LSA helps identify useful concern clusters, and helps reduce the number of falsely identified aspectual requirements.

Aspects are behaviours that are tangled and scattered across a system. In requirements documentation, aspects manifest themselves as descriptions of behaviours that are intertwined, and woven throughout. Some aspects may be obvious, as specifications of typical crosscutting behaviour. Others may be more subtle, making them hard to identify. In either case, it is difficult to analyse requirements to locate all points in the system where aspects should be applied. These issues lead to problems achieving traceability of aspects throughout the development lifecycle. To identify aspects early in the software lifecycle, and establish sufficient traceability, developers need support for aspect identification and analysis in requirements documentation. To address this, we have devised the Theme approach for viewing the relationships between behaviours in a requirements document, identifying and isolating aspects in the requirements, and modelling those aspects using a design language. This paper describes the approach, and illustrates it with a case study and analysis.

Some concerns, such as debugging or logging functionality, cannot be captured cleanly, and are often tangled and scattered throughout the code base. These concerns are called crosscutting concerns. Aspect-oriented programming (AOP) is a paradigm that enables developers to capture crosscutting concerns in separate aspect modules. The use of aspects has been shown to improve understandability and maintainability of systems. It has been shown that real-time concerns, such as memory management and thread scheduling, are crosscutting concerns [A. Corsaro et al., (2002), M.Deters et al., (2001), A. Gal et al., (2002)]. However it is unclear whether encapsulating these concerns provides benefits. We were interested in determining whether using AOP to encapsulate real-time crosscutting concerns afforded benefits in system properties such as understandability and maintainability. This paper presents research comparing the system properties of two systems: a real-time sentient traffic simulator and its aspect-oriented equivalent. An evaluation of AOP is presented indicating both benefits and drawbacks with this approach.

A developer attempting to evolve a system in which design patterns have been applied can benefit from knowing which code implements which design pattern. For instance, the developer may be able to understand the purpose, or to assess the flexibility of the code, more quickly. The degree to which the developer benefits depends upon their understanding of the pattern. Achieving an in-depth understanding of even a simple pattern can be difficult as pattern descriptions span several pages of text, and discuss interrelated design concepts and choices. To enable a developer to effectively trace the design goals associated with a pattern to and from source, we have developed the Design Pattern Rationale Graph (DPRG) approach and associated tool. A DPRG makes explicit the relationships between design concepts in a design pattern, provides a graphical representation of the design pattern text, and supports the linking of those concepts to implementing code. In this paper, we introduce the DPRG approach and tool, and present case studies to show that a DPRG can, at low-cost, help a developer identify design goals in a pattern, and can improve a developer's confidence about how those goals are realized in a code base.

The principle of separation of concerns has long been used by software engineers to manage the complexity of software system development.Programming languages help software engineers explicitly maintain the separation of some concerns in code.As another step towards increasing the scope of concerns that can be captured cleanly within the code, Kiczales and colleagues have introduced aspect-oriented programming.In aspect-oriented programming, explicit language support is provided to help modularize design decisions that cross-cut a functionally-decomposed program.Aspect-oriented programming is intended to make it easier to reason about, develop, and maintain certain kinds of application code.To investigate these claims, we conducted two exploratory experiments that considered the impact of aspect-oriented programming, as found in AspectJ version 0.1, on two common programming activities: debugging and change.Our experimental results provide insights into the usefulness and usability of aspect-oriented programming.Our results also raise questions about the characteristics of the interface between aspects and functionallydecomposed core code that are necessary to accrue programming benefits.Most notably, the separation provided by aspect-oriented programming seems most helpful when the interface is narrow (i.e., the separation is more complete); partial separation does not necessarily provide partial benefit.

Determining whether a new software development technique is useful and usable is a challenging taste. Various flavors of empirical study may be used to help with this task, including surveys, case studies, and experiments. Little guidance is available within the software engineering community to help choose among these alternatives when assessing a new and evolving software development technique within some cost bounds. We faced this challenge when assessing a new programming technique called aspect-oriented programming. To assess the technique, we chose to apply both a case study approach and a series of four experiments because we wanted to understand and characterize the kinds of information that each approach might provide. We describe and critique the evaluation methods we employed, and discuss the lessons we have learned. These lessons are applicable to other researchers attempting to assess new programming techniques that are in an early stage of development.

Many tools have been built to analyze source code. Most of these tools do not adequately support reengineering activities because they do not allow a software engineer to simultaneously perform queries about both the existing and the desired source structure. This paper introduces the conceptual module approach that overcomes this limitation. A conceptual module is a set of lines of source that are treated as a logical unit. We show how the approach simplifies the gathering of source information for reengineering tasks, and describe how a tool to support the approach was built as a front-end to existing source analysis tools.