CS435F06 Weekly Topics and Readings



week
 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15

Week 1: (Aug. 21-25) Introduction to Software Development and Teamwork

Developing good software is not easy. Although it is generally agreed that there is no one best software development methodology, it is increasingly obvious that successful software developers know how to work well in a collaborative environment. Good person to person skills can reduce process overhead and is at the heart of modern agile processes.

HW0: a well written resume (1-2 pages) appropriate for applying for a position as a software developer (due Mon, Aug. 28)

  1. Software Development Methodology (James Chapman, Project Management Consultant)
  2. What is a Lightweight Methodology?, Don Wells
  3. Agile Processes (Robert Martin, (ObjectMentor)Prentice Hall, 2001)
  4. Iterative and Incremental Development: A Brief History, Craig Larman, July 1, 2003.
  5. “The Demise of the Waterfall Model Is Imminent” and Other Urban Myths, Phillip A. Laplante and Colin J. Neill
  6. An interview with Alistair Cockburn, an expert in the study of development methodologies.
  7. Read the Agile Manifesto
Secrets of Software Success: the Nature of the Team - a whitepaper from Menlo discussing aspects of teamwork.

Week 2: (Aug. 28-Sept. 1) Teamwork issues and Team installs

The paper prototypes were demonstrated for users.  We discussed some concepts and issues of teamwork and began to look at Extreme Programming(XP) and learning some of its practices. Here is another review of XP as well as a summary/discussion of Extreme Programming Core Practices.  In groups, software was installed and tested on the TabletPCs.

Week 3: (Sept. 4-Sept.8) Intro to Eclipse/Ant/Java

We introduce (handout) the Eclipse IDE,  and Ant build scripts(example build.xml) for comiling and running code. The general structure of a Java Swing application (handout) was also reviewed. Good sources for documentation on Java are the Java API documentation and the Java Almanac. Sun also has online tutorials to introduce and explain various aspects of Java.

Each paper prototype group should begin working on how they can present their design as a series of diagrams and explainations. Consider using the TabletPC markup and drawing capabilities. To make things easier, some of the paper prototype extras including the flower pictures are available.

Due date is 4pm, Friday, Sept. 22.

Week 4: (Sept. 11-Sept. 15) Finding Smells and Refactoring

We began discussing some common smells found within classes. Working in pairs, examine the sample PegPuzzle code to find smells (the short list we already discussed should be sufficient for now). Load the code into Eclipse, make sure it is formatted correctly and then print it to a Windows Journal document. Mark-up the code smells using journal. Each group should e-mail me one Windows Journal document consisting of the original code and the smells that you've found. You should easily find more than 16 smells (counting a tight cluster of the same smell as a single smell).

Due date by noon, Wed, Sept 13.

After finding the offending smells, it is advantageous to remove them by refactoring. Here is a catalog of refactorings. There are also tables and listings (cheeseshop)that help show, given a certain smell, what refactorings might be useful. This refactoring cue card also helps in finding refactorings to remove smells.

Go to the PaperPrototypeCS435Fall2006  page on the twiki to find your project group name and get started. You will need to register before you can edit the twiki. The twiki should be used as a way for each group to communicate and organize information.

Prepare Eclipse to better support team coding by loading the subversion plugin, subclipse. We'll try installing version 1.2.x first.
Here is an explaination of version control concepts and using subversion with Eclipse.

Working in your smell detecting pairs, begin to refactor the PegPuzzle code. Focus first on the more obvious easy to refactor parts, then move to stronger smells that may take more effort to refactor. Work incrementally (small change, recompile, run & test).  Try Eclipse's refactoring support for such things as "extract constant", "extract method" and "rename local variable". Remember, refactoring does not add new features. Here is an article which discusses some of Eclipse's refactoring features.  For now, stay in the same class and try to code by intention.

Week 5: (Sept. 18-Sept. 22) Refactoring to MVC & test driven development

We continue refactoring the peg puzzle code so that it uses the Model-View-Controller architecture. Within the same class file, code is refactored to group the routines along the lines of Model and View-Controller components (the refactored code is highlighted to indicate which parts correspond to the MVC components).  The goal is then to separate the model from the GUI (view-controller) and develop the model class with Test Driven Development using JUnit. To run the tests, we need to change our build file to incorporate JUnit. A handout explains this refactoring and testing process. Junit javadocs are available online.

To help clarify some of the ideas of test first development, take a look at the following two articles:

Week 6: (Sept. 25-Sept. 29) Present Prototype Design, Enhance Puzzle

The prototype designs assembled on the wiki are presented to the class and nongroup members critique the other groups. Each student should critique the 2 other teams. Use these forms. Hand in your completed forms Monday  Wed.
Refactoring the puzzle application continues. After the Model is extracted into its own class (with tests), it should be hooked back up to a GUI. Once the 1D puzzle has been implemented, begin considering the 2D enhancements. While changes will be required to your Model, many of the routines will still make sense and can be incrementally modified to support the more complex puzzle (remember test first). Here is another helpful article about Test Driven Development with JUnit.  A chapter on JUnit from the book "Java Extreme Programming Cookbook"  is available online.

Remember to talk to the customer about the stories, their priorities and what your estimates for them are.

Week 7: (Oct. 2-Oct. 6) Class Diagrams

As the peg puzzle project gets more complex it is helpful to have a notation to show how different classes relate to each other. Start becoming familar with UML class diagrams.
When brainstorming about what classes should do and how they should interact, consider working with CRC cards. Class Responsibility Collaborator cards (Beck & Cunningham's original article) can also be used  with non-developers on the team to help communicate a common understanding of the system (David Rubin's Intro).
Remember to talk to the customer about the stories, their priorities and what your estimates for them are.

Week 8: (Oct. 9-Oct. 13) JavaDoc, More Refactorings

Part of keeping your code in good shape and making it easier to maintain, is to follow coding conventions (William Wake has summarized his coding standard onto a single page. ) Many conventions require javadoc comments (How to Write Doc Comments for Javadoc).
Add this target to your build.xml file, and incorporate javadoc comments into your code (esp. the model). Customize the items marked in red for your code. Try this out even before you add new comments - javadoc understands the structure of your code.

    <target name="makeDoc" depends="compile" description="Create Java Docs">
        <javadoc sourcefiles="${src.dir}/cs435ex1/Peg*.java"
            destdir="${build.dir}/javadocs" author="true" version="true"
            windowtitle="List team members here" doctitle="PegPuzzle F06">
            <classpath>
                <pathelement location="${build.dir}/classes" />
                <pathelement location="${junit_home}/junit.jar" />
            </classpath>
            <link href="http://java.sun.com/j2se/1.5.0/docs/api" />
            <link href="http://www.junit.org/junit/javadoc/3.8.1" />
        </javadoc>
    </target>

Problems? Consider modifying your path environment variable to include the directory where your javadoc.exe is. You might also check the Ant documentation for javadoc.  An image showing the peg board is here.

Refactorings involving multiple classes include Extract Class (as we extracted the model from the larger class), Extract Superclass, Pull Up Method .  Refactoring Thumbnails gives use a nice notation for explaining refactorings.

Robert Martin defines symptoms of rotting design (higher level than code smells). The rot is essentially caused by changing requirements.
A powerpoint by Martin in which these principles are summarized.

Consider how your application will be deployed. Prepare it as a self-contained jarfile. Test it to make sure that it does not depend upon any external resources. Create the jar file with a new Ant build target something like this (you will have to define your dist.dir)

    <target name="archive" depends="compile" description="Creates a distribution jar file">
        <jar casesensitive="false" destfile="${dist.dir}/pegPuzzle.jar">
            <fileset dir="${build.dir}/classes">
                <include name="**/*.class" />
                <exclude name="**/*Tester.class" />
            </fileset>
            <fileset dir=".">
                <include name="images/*" />
                <include name="sounds/*" />
            </fileset>
            <manifest>
                <attribute name="Main-Class" value="cs435ex1/PegPuzzle"/>
            </manifest>
        </jar>
    </target>
    <target name="runJar" depends="archive" description="Run the jarred Application">
        <java failonerror="true" fork="true" jar="${dist.dir}/pegPuzzle.jar"/>
    </target>

Exam 1 is approaching (Monday, Oct. 16)


Week 9: (Oct. 16-Oct. 20) Begin Customer Project, Wrap-up Peg Puzzle

Monday was exam 1. Wed. our customer comes by and we discuss ideas for the customer project.

To wrap-up the Peg Puzzle project, groups should focus on finishing stories (avoid partially complete stories). Each group should compose a Story check sheet based upon the sample given here. Customize this sheet to explain the tests and variations you made, include the effort (and ideally estimate) for each story.  If you didn't complete a story (it is not expected that all groups will complete all stories) mark that/those stories as not completed. You may do this entirely as an html document or you may make notes using Windows Journal. Your checksheet should be placed under version control in a notes directory.

Introduced Mocks and the Adapter pattern and the Dependency Inversion Principle (DIP) Here is a nice article on "Using Mock Objects for Complex Unit Tests".

Week 10: (Oct. 23-Oct. 27) Customer Project Iteration 1 Starts

PegProject code should be finished on Wed (the 25th). If you are using images to represent pegs and having trouble accessing images from within a jar file, this class(ImageLoad) may help. We should be able to access all code, javadoc and checksheet through the repository.  A week later (Wed, Nov 1)  remember each group should also turn in a handout (as if for a code review discussing your data structure for the 2D peg puzzle board and how you check to assure valid moves). As individuals, you should also turn in a 1-2 page (typed) project retrospective [Your major contributions, thoughts on team work: communications, pair programming, etc. Compare to paper prototyping team effort, Is it helpful having TabletPCs (how?), What can we do better? What should we keep doing? ]

We brainstorm some more and work with the customer to come up with an initial list of stories. A project wiki site has been started so we have a central place to put stories and other information.

We went over exam 1. To review again what Agile Development is like in real life see a day in the life of an Agile programmer (game developer) . Contrast this to the waterfall method as discussed at  Waterfall 2006 (please note this conference is scheduled for April 1!)

A handout gave an overview of the application framework on the wiki (RoboSim). This handout also showed a statechart. Statdecharts provide a useful notation to help understand an application's internal states and the events that cause state transitions. UML 2 now calls statechart diagrams, state machine diagrams.

Introduced the Composite pattern as well as the Liskov Substitution Principle (LSP)

Week 11: (Oct.30-Nov. 3) Customer Project Iteration 1 Continues

We discuss the options in Java for handling collections of objects. Java has a Collection interface as well as a class Collections with many static methods which operate on collections. To help keep track of our efforts, a weekly effort sheet was introduced.

As we start defining new classes it becomes important to consider characteristics that are generally expected of well behaved Java classes. The Canonical Object Idiom: Defining a Baseline Set of Functionality for Objects  by Bill Venners and Joe Bergin's article on the Canonical Form of a Java Class discuss these aspects in detail.

Software design patterns Iterator, Strategy and Template Method were discussed.

Week 12: (Nov. 6-Nov. 10) Customer Project Iteration 1 Ends

As our system grows, we expect our design to evolve. Bob Martin discusses two more  principles of object oriented design which are helpful to consider. It may be that a class or interface seems to be evolving to do too much. The Single Responsibility Principle(SRP) seeks to assure that a class or interface is devoted to a single narrow focus.  More narrow focus means changes will affect fewer clients since only the specific classes using the methods they actually need will have to be updated.
Related to this principle is the Interface Segregation Principle (ISP) which realizes that objects may evolve to have a variety of aspects but doing so should not result in polluting higher level interfaces with methods not of general use. As objects evolve to require more methods this exerts forces back on their interfaces to expand to include more capabilities. When the interface (or parent class) becomes bloated, many of the new methods may not apply to other implementations forcing those objects to create null methods. Clients should not have to depend upon functionality that they don't need. A single object may however implement multiple interfaces.

The Factory Method pattern as well as the Open Close Principle (OCP) were also introduced.

Some observations from project work.

Week 13: (Nov. 13-17) Customer Project Iteration 2, Week 1

As one of the important stories for this project is to produce and output log, a handout was given which discussed strategies for developing I/O using Readers and Writers rather than directly depending upon files. Please make an effort to integrate your code with the rest of the project. We should be doing this almost constantly by now. Unexpected problems almost always occur when there is a long delay in integrating all the code together. See Martin Fowler's article on Continuous Integration.


 * * * * * *  T H A N K S G I V I N G       B R E A K ***********

Week 14: (Nov. 27 - Dec 1) Customer Project Iteration 2, Week 2

The Observer pattern was introduced - it is often used by models (the subject) to let the views (the Observers) know when changes have been made. Java defines Observer and Observable for this pattern but actually uses the  EventListener interface to create observers for Swing events.    UML Sequence diagrams help to show how objects coordinate activities between them. We looked at adding menus to our project and using actions.

Keeping track of progress in software projects is very important. Agile processes that use estimates and tracks such things as stories or story points completed can generate a wealth of useful data to show how the project is progressing. Velocity is based upon estimated effort accomplished during an iteration. Progress can also be monitored by considering total work done  at the end of an iteration and work remaining against resources remaining(plotting work remaining against time remaining gives a burndown chart). A variety of possible charts are useful in XP.

Week 15: (Dec 4-Dec 8) Customer Project Iteration 3, Week 1

A study guide for the last exam was passed out. We looked at the Decorator Pattern for adding features to objects at run time. (A chapter from Head First Design Patterns explains Decorator and OCP). The book "The Design Patterns Java Companion" by James Cooper  is free online.

Software process improvement and the CMM was discussed. Be aware of anti-patterns as they indicate common ways of solving problems which often lead to failure (there are quit a lot of ways to fail - see the Anitpatterns catalog). Here is an article describing some anti-patterns for JUnit testing. The book "Bitter Java" discussing Java anti-patterns is available for download.

As part of the Final Project Retrospective, you are to submit a radar chart of your project activities. You can use this image for the blank chart.

Back to CS435F06