What Is the Right
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
With the waterfall approach, you have very distinct phases of requirements analysis, design, implementation, and testing. Each one feeds into the
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
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
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  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:
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
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.
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-
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
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
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