We have been using Structure 101 as part of a Design Patterns post-graduate module at Waterford Institute of Technology. Central to the course is an understanding of the classic GoF patterns [1] plus the application of key design principles associated with modern, effective java development [2]. Structure 101 has proved an outstanding product in this context. It is particularly strong in reinforcing key packaging principles, visualising tangles and prompting the students to re-evaluate their design informed by Structure101 analysis. There is no other product on the market with its range, innovative use of graphical reporting modes and flexible perspectives.

As the course progressed we discovered fascinating uses for Structure101. Its design lends itself very well to iterative development and extensive refactoring cycles. This enabled the students to visualise package and class dependencies, refactor using Eclipse tools towards patterns designed to reduce some specific coupling relationship and then dynamically reload (without reaunching) Structure101 to view the structure of the refactored design. Observing the progression reinforced the key principles and yielded a superior understanding than could be ascertained from merely observing class text, outline or UML models. Thus pattern directed refactoring - an important movement in modern design [3] - now has a product to reinforce its insights and practices.

Figure 1

Figure 1 shows a typical problem prior to refactoring. Structure101 identified two key tangles and the challenge was to diagnose these and plan a series of refactorings to eliminate them. The students were schooled in Bob Martin's packaging principles [2] and were able to quickly diagnose the issues associated with the first tangle. The required refactorings were to move specific classes between packages - drag'n.drop in the Eclipse Package Explorer eliminated this tangle very easily. Just reloading Structure101 produced a pleasing simplification (Figure 2).

Figure 2

On closer inspection, the tangle in Figure 2 contains a particularly tight set of interdependencies. Switching perspectives to directory hierarchy (Figure 3) we can start to get a handle on the tangles and commence a more detailed exploration. The application implements the Model View Controller composed pattern (Observer, Strategy + Façade) for a simple GUI. This GUI incorporates a tabbed window, a set of views and a set of commands and actions. Although the pattern implementation is robust - there is clearly an issue with the dependencies.

Figure 3

Structure101 allows each of these dependency "legs" to be examined in more detail, and the specific dependency sequences identified (Figure 4). This analysis leads to some more restructuring and a less severe tangle emerges (Figure 5). These refactorings have required code modifications - in fact an application of Martin's recommendations: eliminating a coupling by replacing a bi-directional dependency with a shared dependency on a common abstraction.

Figure 4

However a more persistent coupling (Figure 5) remains and this one does not yield easily to code reorganisation or simple refactoring steps. At the heart of this coupling tight bidirectional binding between controllers, views and the model in the MVC implementation. The particular difficulty centres around event propagation from view to a hierarchy of controllers - required to give the application structure some flexibility (particularly the ability to attach additional view seamlessly).

However, a pattern directed refactoring - via the introduction of the Chain of Responsibility - delivers the decoupling necessary to eliminate this tangle (Figure 6). This step requires the introduction of the pattern interfaces, their implementation in the appropriate context and the verification and validation of the desired functionality.

Structure101 provided the visualisations that drove these refactoring steps. All tangles were eliminated via code restructuring, the concrete implementation of packaging principles and the introduction of a key design pattern. The result is an elegant layered architecture (Figure 7), flexible, modular and informed by intelligent design decisions.

Figure 7

Interestingly, the corresponding UML diagrams were insufficient for this more agile style of development. They were either too simple (not rendering inter package dependencies at all) or too complex (the design was overcome with noise). Structure101 produced a more reflexive tool, directly tied to the code artefacts but with just the right amount for abstraction to encourage high-quality reasoning about the design.

References:

• [1] Design Patterns, Gama et all, Addison-Wesley, 1995
• [2] Refactoring to Patterns, Joshua Kerievsky, Addison-Wesley, 2004
• [3] Agile Software Development, Principles, Patterns & Practices. Martin, Prentice-Hall, 2003