- Software Development and the Object-Oriented Paradigm
- The Case for Aspects
- What Is an Aspect?
- Why Consider Aspects in Analysis and Design?
- Aspects and Other Concerns
- The Theme Approach
- Applying the Theme Approach
- Theme: Symmetric or Asymmetric?
- Fitting Theme into Your Existing Development Process
- What About Implementation?
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
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. Later, in Chapter 3, "The Theme Approach," we briefly outline how that might work. Fitting the Theme approach into processes such as the iterative and waterfall approaches is quite straightforward. Figuring out how to work them into the family of agile processes7 deserves further discussion. In Chapter 3, we go into some of the processes in more detail. Here, however, we discuss analysis and design in the context of agile processes from a high-level point of view.
The use of Theme/UML in agile processes mirrors the relationship between standard UML and agile processes, which is a much larger question. After sifting through rhetoric from experts on both sides (UML is crucial versus UML is useless), we found words of wisdom that struck many chords with us—Martin Fowler’s paper entitled "Is Design Dead?"8 which we highly recommend.
What we have taken from the "Is Design Dead?" article is that if you are the type of developer to find diagrams helpful, then you will continue to do so with agile processes, and if you are not, then you won’t. In addition, it is especially important to recognize that diagrams can "actually cause harm" and therefore should be used judiciously. The use of diagrams has potential value from a number of perspectives: communication; as a means to explore a design before you start coding it; and documentation both ongoing and for handover situations. From a Theme approach perspective, we paraphrase or steal directly from "Is Design Dead?" in the following list of recommendations for managing both Theme/Doc and Theme/UML diagrams in an agile process environment:
Capture the interesting analysis and design decisions in the diagrams. Not every class in every theme may be interesting and not every attribute or method in an interesting class may be interesting. Do, however, consider capturing all the composition relationships and crosscutting behaviors during your exploration phase.
Keep the analysis diagrams and designs only as long as they are useful. Don’t be afraid to throw away diagrams that have become outdated through refactoring or other reasons—they were useful for a time, but you can let them go. Since Theme/Doc views are automatically regenerated, generate new ones when changes occur.
When you are coding, if you think diagrams would be useful for communication outside the immediate team or for capturing a point in time, then re-create them for that purpose.
Even if you fall into the category of people who don’t really find diagrams useful, bear in mind that there are others who do, and so when you are handing over the system to other people, then diagrams that represent the current state of the code may be appreciated.