This presentation argues that students can best appreciate the benefits of software design principles when they have to work on a project in which requirements change repeatedly in some sub-stantial way over the course of a semester. It describes two different semester-long projects in which substantial change was enforced upon the students by making them develop a system that had to work on three different user interface platforms (text-based console, desktop Windows, and a mobile Pocket PC). By making the students plan and adapt for this change the students were better able to truly appreciate the benefits of good design and were willing to take the extra effort to implement a design that reflects the principles taught in most object-oriented design courses. One of the key principles engaged by this approach was the importance of a layered architecture to software projects driven by change.

1. Complecto Mutatio : Teaching Software Design Best Practices Using Multi-Platform Development Randy Connolly Dept. Computer Science & Info Systems Mount Royal College Calgary, AB, T2N 0Z6 403 440 6061 [email_address]

2. “ Observe always that everything is the result of change, and get used to thinking that there is nothing Nature loves so well as to change existing forms and to make new ones like them.” -- Marcus Aurelius, Meditations iv 36. “ Software changes its own requirements.” -- Ken Beck, Extreme Programming Explained .

3. Of course, today's developers are generally less concerned with barbarian incursions and unruly Praetorian Guards … … and more concerned with shifting requirements and fast-approaching deadlines.

4. “ Observe always that everything is the result of change, and get used to thinking that there is nothing Clients loves so well as to change existing Windows Forms and to make new ones like them.” -- Randy Connolly, Software Developer Meditations , ix

5. Many authors on software design have noted the ubiquity of change in the typical software project.

6. One high-profile study, for instance, showed that business rules for a typical software project changed at the rate of 8% per month. Another study indicated that over 40% of requirements arrive only after development is well under way. “ Managing the effect of changing requirements remains one of the greatest challenges of enterprise software development .” ( Datta and Engelen, 2006)

7. The ubiquitous nature of change in the software development world is the principal reason for the decline in commitment to waterfall development models and the concomitant rise in interest in iterative and agile methodologies.

8. Indeed, the subtitle of one of the key texts in the field of iterative development is the English equivalent of the Latin in the title of this paper: Embrace Change . As Craig Larmann has noted, rather than fight inevitable change, developers should use a process that acknowledges “ change and adaptation as unavoidable and indeed essential drivers”

9. Yet despite the current wide-spread use of iterative approaches in real-world software development … … the essential ingredient of change can be difficult to add into a typical one semester course. … and the attempt by many teachers to integrate these more agile processes into computer science education …

10. As a result, most programming assignments end up being formulated using a waterfall based approach (i.e., fixed requirements by a set date) This is a particularly unfortunate shortcoming since the value of many of the most important object-oriented design precepts can only be appreciated in a project that is undergoing a certain amount of change .

12. This rest of this presentation details my attempt to integrate changing requirements into two semester-long development projects. In one version of the course, the project was a restaurant browsing application. In the other, the project was a game.

13. The projects were in a third-year course on Windows development that uses C# and Windows Forms within Microsoft’s .NET Framework. This course is somewhat analogous to a capstone course in that it is meant to integrate the development knowledge and experience gained by the students over the three years of the program.

14. In one version of this course, students had to create a board game/simulator. In this game, the player creates an army of one or more units that battles the computer’s units. Each unit contains warriors of a specific type (e.g., knights, pirates, trolls, etc).

15. I have frequently used game projects in this course. The principal benefit of game projects is that they provide an ideal context for teaching the more “higher-order” and abstract software development topics such as architecture, design patterns, and software methodology.

16. One caution, however, … if there are females in the class … … you may hope to get this …

17. … but you might end up with this … At any rate, in the game section of the course, the student body was entirely male.

18. In the other version of the course, the development project was a restaurant browsing and ordering application. It used the gargantuan open source chef moz (http://chefmoz.org) XML dining guide files.

20. Milestone 1

21. Milestones 2 and 3

22. Milestone 4

23. The rationale for this approach was mentioned in the introduction: namely, to give the students exposure to the kind of requirements change encountered in most real-world projects. While there were numerous changes in the course project, it was not total chaos. For all four milestones, the students used C#, the Microsoft .NET Framework, and Visual Studio. And, most importantly, most of the students’ work in one milestone could hopefully be migrated to the next milestone.

24. Indeed, it was in the second milestone that the students became truly appreciative of the general object-oriented principle that one should separate that which varies … … from that which stays the same

25. In order to adapt their milestones to these different user-interface platforms … … the students were forced to refactor their initial milestone in order to make future transitions less time-consuming.

26. Almost without exception, in the first milestone students intertwined user interface logic into their basic domain model … As a result, the students were given the choice to instead use the instructor’s solution to the first milestone, which did in fact separate the domain logic and the user interface logic into two distinct layers . … and were faced with spending time eliminating the console user interface elements from their design.

27. What is a layer ? A layer is simply a group of classes that are functionally or logically related. Using layers is a way of organizing your software design into groups of classes that fulfill a common purpose. Thus a layer is not a thing, but an organizing principle .

28. Many software developers have embraced layers as the organizing principal of their application designs. The goal of layering is to distribute the functionality of your software among classes so that the coupling of a given class to other classes is minimized. By organizing an application’s classes into layers, you hopefully end up with lower coupling than you otherwise might have without using layers as an organizing principle.

29. The most important benefit of using layers is that the resulting application should be significantly more maintainable and adaptable by reducing the overall coupling in the application. If there is low coupling between the layers combined with high cohesion within a layer, a developer should be able to modify, extend, or enhance the layer without unduly affecting the rest of the application.

30. I have taught the design principle of layers to my students in a variety of classes over the years. Until this course students typically echo this content back to me in exams relatively successfully but have a much harder time integrating it into their actual programming practice.

31. To the students, layers (and perhaps other design best practices) often seem like an unnecessary burden for the typical one-month to two-month assignment. In this project by contrast, student attitudes towards design began to change due to their need to adapt software between platforms.

32. By using the instructor’s domain layer, the students were able to more easily implement the user interface changes in the remaining milestones. The students, perhaps for the very first time, became receptive to the idea that proper design will actually save them time and effort .

33. Surveyed student comments at the end of the course did seem to verify this impression. Over half the surveyed students indicated that the most important thing learned in the course was : “ spending time doing good design actually saved me time in the long run because I had to do less coding and debugging,” as one student noted.

34. The payback for the additional design effort arrived in the fourth and final milestone. On the face of it, this milestone was quite intimidating. The students had to move their game to a completely different piece of hardware: a hand-held Pocket PC. Yet because the students were using the Compact .NET Framework, they were able to port their domain, data, and presentation helper layers with little or no change. The students only had to redesign and re-implement their presentation view layer in order to fit their project’s user interface into the constrained space and controls of the device.

35. As a result, the final milestone was by far the easiest: most students reported that it only took a day to complete ! Certainly at this stage of the course the students had become true believers in the benefits of proper software design.

36. For the very first time in my teaching experience … … students had not just memorized the design principles nor simply believed in them as an article of faith because the professor told them so.

37. Instead, thanks to the multi-platform nature of their project… … the students had their own empirical evidence of the utility of design principles in managing requirement changes in a software project.

38. Conclusion

39. It can be difficult to get students to fully appreciate the benefits of a proper software design. To appreciate the benefit of a proper design, students need to work on a project with substantially changing requirements. In such a project, students are able to see for themselves that proper design can save time and effort. For most assignments, proper design just seems to be an instructor-enforced hassle because it generally only increases the amount of work for the student in a given assignment.

40. Randy Connolly Dept. Computer Science & Information Systems Mount Royal College, Calgary [email_address]