From SEWiki

Contents 1 The Problems of Interacting Concerns in Code 2 An Analogy to Architectural Design 3 Software Plans 4 Incremental Integration and Implementation 5 Demo and Tutorial 6 Links

The Problems of Interacting Concerns in Code

One of the key goals of software design is to manage complexity using abstraction. Following well-known principles such as information hiding, software engineers attempt to design systems of loosely coupled modules that encapsulate concerns. However, even the best designs have some problematic concerns that can cross-cut the modules of the system, and that can be tangled with other concerns. Examples of such concerns are debugging, optimization, synchronization, and logging. Poorly encapsulated concerns are tangled in the software, compromising the design, obfuscating the overt functionality of the code, and increasing its complexity.

To date, researchers working on this problem have attempted to encapsulate such concerns by developing new programming language abstractions. Abstractions such as functions and classes are well-known. In more recent work, aspect-oriented programming introduces a new aspect abstraction to encapsulate cross-cutting concerns, along with a compile-time weaver for automatically tangling aspects into the base code. In other work, hyperslices implement a concern-oriented dimension of the software that represents the classes and methods relating to the concern. Hypermodules are created by composing hyperslices using integration specifications such as overriding by method name.

Our work seeks to achieve separation of concerns as well, but at the editor level rather than the programming language. This allows us to remain agnostic with respect to the programming language used. Our approach also well-suited for highly context-dependent concerns such as debugging and optimization, which interact with other concerns in non-uniform ways. Finally, our approach is both fine-grained and multi-dimensional in nature, allowing the programmer to document and work with concern-oriented representations of the code that implements a module.

An Analogy to Architectural Design

Architects deal with cross-cutting concerns by using "plans". For example, consider the plans to the right. In such plans, the overall building is composed of modules consisting of rooms. Interfaces between modules are doors, and the external interface for the overall building consists of doors and windows. Architectural plans are orthogonal to the modular structure of the building, and provide an abstracted yet coherent and understandable view.

The first floor plan shows the overall modular decomposition (the rooms), as well as cross-cutting concerns such as the location and relationships of lights and light switches. Importantly, the plan contains sufficient context for the "lighting" concern to make sense. Contrast this plan with the roofing plan, which abstracts the details of the internal structure of the house, and instead presents information such as the location of roof lines and the pitch of the slopes of the roof. The outer boundary of the house provides the context needed to understand the "roofing" concern.

Software Plans

A software plan is a coherent, editable view of the software which presents only the code that relates to the subset of relevant concerns, along with suitable context code. Using an enhanced editor, the programmer develops a module by implementing its concerns in one or more plans. After creating a set of plans that fully cover the concerns of the module, the programmer can then reconcile the plans to create a final plan. The final reconciled plan is similar to the kind of code that is developed today without the benefit of plans. This approach allows the programmer to develop the software in terms of multiple semi-independent plans, and then to compose the plans to create the final system.

The screenshot to the right shows our current prototype plan editor. In the current plan, the user is working on the primary "Input" concern, and has the "Main Program" concern as context. Code associated with the context concern is grayed to indicate that it is not directly relevant. However, this context is important for the Input concern, as can be seen in the implementation of main(), where the call to read_data must be properly located after the declaration of list.

Incremental Integration and Implementation

In addition to providing a multidimensional way to view and edit the code that implements a module, software plans enable incremental implementation and integration of concerns. Rather than implementing a new feature in terms of the complete system, the programmer can create a software plan that contains only those features upon which the new feature depends. The new feature can then be implemented and tested in this new software plan, deferring the integration of this feature with other interacting features. The programmer can then create one or more software plans to test and resolve the interactions with the remaining features of the system.

Demo and Tutorial

Our current Spotlight prototype is implemented in Eclipse. You can download version 1.3.0 here: spotlight-1.3.0.zip. If you do the included tutorial and read the included papers on software plans you'll see concretely the ideas presented above. Note that version 1.3.0 has a new graphical view for the plans, and is not yet described in the tutorial.

Links

Sample Matlab Code from Paul Hovland that shows the need for something like software plans.

FOP Theory and Software Plans. Work by Don Batory and Jia Liu provides a theory for reasoning about features and their interactions. This theory may provide a useful foundation for software plans.