What Is the Right Size for a Theme?

Fitting Theme into Your Existing Development Process

The analysis and design activities described in the Theme approach can be split up and molded to fit into whichever development process you are happiest using. We briefly outline how that might work.

Waterfall

With the waterfall approach, you have very distinct phases of requirements analysis, design, implementation, and testing. Each one feeds into the next , with little, if any, jumping between them. The Theme approach can be fit into this model by extending your analysis process to include analysis with Theme/Doc followed by doing your design with Theme/UML.

Iterative Approach

With the iterative lifecycle, you divide your system into a number of different parts (most commonly by end-user-recognizable function, but sometimes by technical component). You then design and implement these parts consecutively, each in its own iteration. This approach has the advantage of allowing you to get early feedback from the end user (or other programmers using the services of the component that makes up the iteration), which can be incorporated into the design of the next iteration. The Theme approach supports this style of development, as each iteration can be designed separately in its own (set of) themes.

Agile Processes

Agile processes are lightweight approaches for software development. They are intended to get away from the heavyweight approaches (such as the waterfall approach) in which there are significant analysis and design before implementation begins. Agile processes stress the use of appropriate methodology, and people over process .

There are several offerings of agile processes. Although these processes are quite different, the Theme approach can be flexibly used within them. We discuss three of them here: extreme programming (XP), test-driven development (TDD), and feature-driven development (FDD). For each, we outline how the Theme approach can be applied.

Feature-Driven Development

FDD involves the development of individual features of a system. Developers take ownership of certain features and see them through from modeling to implementation. Themes fit in with FDD ^[2] quite naturally. Themes can be used to represent features in a system, so using the theme approach for AO-FDD would work well. There are five steps in applying FDD with the Theme approach:

^[2] Available from http://www.thecoadletter.com/article/0,1410,29684,00.html.

Build an overall model . In this step, developers and domain experts provide a high-level overview of the system and its scope. This step happens as usual when applying the Theme approach.

Build a features list . This step works with the "identify themes" phase of the Theme analysis process. The descriptions of features is used to generate a Theme/Doc relationship view to identify relationships between themes. Feature clusters, as identified in FDD, translate to groups of themes. The "aspect identification" phase also occurs here, where the heuristics about shared feature responsibilities are assessed to determine whether aspect features (aspect themes) are required.

Plan by feature . This happens the same way as in vanilla FDD.

Design by feature . Here, the only change to the vanilla FDD is that each feature is designed as a separate theme, and the composition semantics are also specified. Class ownership (in which a developer claims responsibility for a pertinent range of classes) could become theme ownership.

Build by feature . Each theme is translated into code, then tested .

Test-Driven Development

In TDD, tests are written before coding begins, then enough code is written to fail and then pass the test. Refactoring happens and is tested along the way. The first phase of TDD is the "think about what you want to do" phase. If, during this phase, you appeal to any written documentation for motivation (requirements for a feature, for instance), or if you write your thoughts down, you enhance the thinking process by looking at a Theme/Doc view of that document, seeing which themes you would like to implement, and identifying requirements that might reveal aspect behavior. In the thinking phase, you also identify themes that should be implemented as aspects.

If you normally use a design language like UML to enhance the thinking process, then here you would use Theme/UML.

Then, you write your tests, write your failure code, and start to write your "hoping to pass" code. If decisions you made during your thinking were wrong, the changes you need to make to fix the problems are reflected back to your list of themes, their responsibilities, and the relationships between themes. The new list of themes and responsibilities is used to regenerate the Theme/Doc relationship view, which might reveal relationships you hadn't foreseen and that would drive further implementation.

If you encoded your design in Theme/UML, then you alter your Theme/UML as well.

This process continues until your tests pass.

As you think about your next collection of functionality, you integrate any documents you were using and generate a Theme/Doc view to predict relationships between functionality in your system. This helps you anticipate how you might accommodate old functionality at implementation, and also reminds you about code reuse: If a behavior is already present in the Theme/Doc view, then you already have a theme that implements it.

Extreme Programming

XP is a highly collaborative, team-based approach to software development. It stresses collaboration between programmers and customers. XP, like the other agile processes described above, prioritizes pragmatic design over design for long- term change.

XP uses TDD for its "inner loop." As such, you would apply TDD for Theme as described above.

XP uses "user stories" to describe functionality to be implemented in the current cycle. These are high-level use-case-style-descriptions of new features to add to the system. While traditionally, user stories are written on note cards, they could be translated to electronic text and used to generate a Theme/Doc view of all the user stories combined, or for a selection, or of just one.

Themes are identified from pieces of functionality included in a user story during the planning-for-implementation phases, and aspects are identified from the relationships between themes.

Alternatively, a single user story can be chosen as corresponding to a theme. Relationships between the texts of user stories may give rise to aspects and would be revealed by a check of a Theme/Doc relationship view.

Class-responsibility-collaboration (CRC) cards informally record developers' planning for implementation in terms of programming language structure. CRCs (again, electronicized) could also be used as input to the Theme/Doc tool to identify where behavioral overlaps occur. Groups or portions of CRC cards would comprise a theme; the scope of the group (entire or partial user story) would depend on your earlier choice about theme scope. If you chose to break up your user story into multiple themes, then one theme per piece of functionality would work well as a starting point. Concept-sharing and crosscutting relationships could be recorded in the collaboration part of the CRC card.

Theme/UML is used in place of UML to capture the themes regardless of whether they were entire user stories or smaller functionality found within. Theme/UML can be used to encode the CRCs for a cycle.

The Theme approach fits well into the "do the simplest thing" and "you aren't gonna need it" philosophies. At the design level, each theme needs to contain only the minimal set of structure and behavior to carry out the responsibilities identified through analysis.

If your project necessitates requirements tracking, in which you must show your customer that the functionality they have requested has been considered from user story to implementation, then a requirements theme to design theme (either in Theme/UML or on CRCs) to code mapping would likely help.