Speaking at Boulder Java User Group, 9 February 2010
I will be presenting a lecture on Design Fragments at the Boulder Java User Group meeting on 9 February 2010 at 6pm (before the pizza break). The lecture will be based on my thesis work. You can find a preview slide presentation on the work here. More details, including the full thesis, are available here.
You can watch a video of this talk, given at CU Boulder.
Example design fragment
The following picture shows a UML static structure diagram of a design fragment. It shows the framework classes involved with creating an Eclipse context menu (right-click menu) and the classes that a developer must implement. The complete DF would also include behavioral specifications. (Apologies for the cropped text in the SVG diagram).
Abstract
Frameworks are a valuable way to share designs and implementations on a large scale. Client programmers, however, have difficulty using frameworks. They find it difficult to understand non-local client-framework interactions, design solutions when they do not own the architectural skeleton, gain confidence that they have engaged with the framework correctly, represent their successful engagement with the framework in a way that can be shared with others, ensure their design intent is expressed in their source code, and connect with external files.
A design fragment is a specification of how a client program can use framework resources to accomplish a goal. From the framework, it identifies the minimal set of classes, interfaces, and methods that should be employed. For the client program, it specifies the client-framework interactions that must be implemented. The structure of the client program is specified as roles, where the roles can be filled by an actual client s classes, fields, and methods. A design fragment exists separately from client programs, and can be bound to the client program via annotations in their source code. These annotations express design intent; specifically, that it is the intention of the client programs to interact with the framework as specified by the design fragment.
We can provide pragmatic help for programmers to use frameworks by providing a form of specification, called a design fragment, to describe how a client program can correctly employ a framework and by providing tools to assure conformance between the client program and the design fragments.
I built tools into the Eclipse IDE to demonstrate how design fragments could alleviate the difficulties experienced by client programmers. I performed two case studies on commercial Java frameworks, using demo client programs from the framework authors, and client programs I found on the internet. The first case study, on the Applet framework, yielded a complete catalog of twelve design fragments based on our analysis of fifty-six Applets. The second case study, on the larger Eclipse framework, yielded a partial catalog of fourteen design fragments based on our analysis of more than fifty client programs.
This work provides three primary contributions to software engineering:
- It provides a new technique to help programmers use frameworks.
- It provides a systematic way to increase code quality. Design fragments provide a means to communicate known-good designs to programmers, and, unlike simple copying of examples, a means of influencing the uses of that design so that revisions can be propagated.
- It provides an empirically-based understanding of how clients use frameworks, which aids researchers in choosing research directions and aids framework authors in delivery of new frameworks.
