CS435F08 Weekly Topics and Readings
Week
1: (Aug. 18-22) 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
keep their customer's interests in mind and work well in a
collaborative environment.
HW0: a well written resume (1-2 pages)
appropriate for applying for a position as a software developer (due
Mon, Aug. 25)
Read Chapter 1 of the text. For additional background on software
process, also review the following:
- What is a
Lightweight Methodology?, Don Wells
- An interview
with Alistair Cockburn, an expert in the study of development
methodologies.
- Scott Ambler on Agile Development (available
as a podcast or transcript)
- Iterative
and
Incremental Development: A Brief History, Craig Larman, July 1,
2003.
We will also begin working on a small team project to explore
refactoring and teamwork. These are both important aspects of Extreme Programming
and other Agile Software Development methodologies. See refactoring in the leftovers
section of the text.
Week
2: (Aug. 25-29) Refactoring & Introduction toTabletPC
The refactoring exercise continues. To continue with our refactoring
exercise on the tabletPC, download this worksheet.
Open it in Acrobat Reader and print it to Windows Journal. Then using
Journal, fill out the form to show the refactorings to remove the
smells. Fill out your name on the worksheet and print it to the lab
printer when your are finished. Hand in your solutions. Each individual
should hand in a solution to exercise 3.
We will begin getting for team development work. A general handout on
team work and the TabletPCs was distributed. The TabletPCs also
need to be readied for development work. Please take a look at the initial software installations page
and work together informally to install software on your machine. There
is also a question set on the refactoring exercise to be filled out
individually (due Wed. Sept. 3).
Friday, everyone should have Eclipse installed on their machine and be
ready to started getting familar with using Java and Ant with Eclipse (see HO). We will be using the MatchGame.java starter code to begin
with. Continue examining the starter code for smells. Mark-up the
listing indicating the code smells that
you find using Journal (write in your name as well). We will continue
discussing code smells and refactoring next week.
Those moving from C++ to Java may find this Crash
Course by Horstmann helpful.
Week
3: (Sept. 3-5) Refactoring Code with Eclipse
Today everyone should turn in their question sheet reflecting on
refactoring and the refactoring grid game exercise. You should have
also marked up the original MatchGame class for smells. We will discuss
briefly and have a little time for a last look but I do want you to
e-mail me your mark-ups (Journal or pdf file).
Next we prepare Eclipse for working on a Team. Sharing code when
working together can be problematic.
Source code
control systems are used to help manage this process. We will be using subversion through an
Eclipse client called Subclipse. Here is a link to the subclipse installation
instructions. Please install the latest version of the plugin
on your machine. Here are some notes
on using version control.
Eclipse has many capabilities including some features to help you catch
and fix problems as well as for refactoring.
Explore a quick introduction to some of
them here and begin trying to remove smells for the MatchGame code.
Please continue reading in the textbook through chapter 4.
Week
4: (Sept. 8-12) Refactoring to MVC and TDD
After some basic refactoring to clear out most of the smells in the
sample code, we consider the model/view/controller (MVC) paradigm
(class handout). Groups are to markup up their refactored source code
(in Windows Journal) to show parts which correspond to model(light
blue)/ view (yellow)/ controller(orange). Please your mark-ups
(mvcMarkups) in your repository. Continue refactoring your
code with the new refactoring goal of separating the MVC
components into separate methods (still in the same class file) similar
to what we might get once a model class is extracted out of the
original class. Next the model class will be re-created using Test
Driven
Development. JUnit is introduced. JUnit is used to create automated
unit tests
enabling test driven development. A handout
discussing MVC and test driven development relating to our project
was distributed.
Week
5: (Sept. 15-19) User Stories, Practice Project
We begin considering user stories for our practice project. Test Driven
Development using JUnit should be
used to construct the model.
To help clarify some of the ideas of test first development, take a
look at the following 3 articles:
Each group was given a list of initial stories and asked to estimate
the stories in ideal hours. A quick coding spike may help you better
understand the effort involved. We'll talk more about developing Swing
GUIs shortly. A Handout (StateApp, StateModel, StateModelViewer) giving
an example of developing test first to build a model and hooking it up
to a gui was distributed. While the GUI code is not emphasized
here, groups were to sketch
an interface design and enter it into the repository. The sketch helps
to facilitate dialog with the customer and clarify requirements. UML
state machine diagrams were introduced. Groups are suggested to
think about the behavior of their model as it moves through different
states - a state diagram may help to clarify your design. An interface
flow diagram helps to show how a user navigates through the gui.
For now if your looking for help on your estimates
consider Sun's
Swing tutorial and this quick look at Java
2D graphics. Sun has a large collection of
Java tutorials. The Java Developers Almanac is also useful - here
is an
example on reading in images.
Week
6: (Sept. 22-26) Iteration 1 of Practice Project Begins
All groups handed in estimates for the initial stories of the practice
project. The customer has defined priorities (different for each group).
Your group can find its stories and priorities in a wikiNotes folder within your
repository's notes folder. Load the EclipseWiki plugin into
Eclipse to be able to use the wiki properly (we are using the TWiki
renderer). Use wiki notes to help communicate among your group (and
customer) and to track your progress. All wiki pages are to be placed
under version control. Each group should select a tracker (let everyone
have turns) for each week to be in charge of making sure the group's
project is recorded and the wiki kept in good order. (see the Progress
Log wiki page). Keeping the tests clean was discussed along with the
use of JUnit's
setUp method.
Week
7: (Sept. 29-Oct 3) Iteration 1 of Practice Project Ends
Development continues on the stories selected for iteration 1. To
assist in testing the model with randomly shuffled cards, the concept
of mocks was introduced along with a Mock Random
object. Adding javadoc comments
to code and generating html pages with Ant. More examples of creating
Swing GUIs to work with models were given (along with some UML class
diagrams). The CardLayout
was suggested as a useful way to manage different groupings of
components which are shown at different times through the execution of
a program. Demonstrations of GUI can be very valuable in working with
customers: JDemo is a framework to
support this. Projects should add the JDemo library to a lib directory
and support a "show demos" run target with their build file.
Week
8: (Oct 6-Oct 10) Iteration 2 of Practice Project Begins
Reflect upon the progress so far and consider what the stories (and
estimates) and priorities are for this iteration. We consider more
about the GUI now since this is obviously needed for the final product.
Previously we discussed some aspects of the view but the controller
will need to capture and handle events. See this Swing
tutorial on writing event handlers for some useful information. Refactoring thumbnails
were also introduced as a way of giving an overview of how a
refactoring could be accomplished. Examples of refactorings to remove
redundant code using Extract
method and variants that move redundant code to other classes (Extract
Superclass, Pull Up
Method) or even delegate to a helper class were given.
Remember to keep the focus on giving the customer something of value by
the end of the iteration (as weighted by customer priorities).
Additional discussion on building the GUI to hook up to the model was
undertaken.
Week
9: (Oct 13-Oct 17) Iteration 2 of Practice Project, Last Week
Remember to keep refactoring your
code and tests. Of course, you want to code in a clear
and consistant style. Here is a nice list of guidelines
that address java style and code structure from Bruce Eckel. Use
pair programming esp. for GUI code which is
difficult to write tests for. Help each other out and seek to
understand all aspects of the project rather than delegating each
member to a specific task. As the project nears completion, you should
be adding tests (and/or demos) which seek to show compliance with
customer expectations (some notes are
gathered here).
As a project evolves, the original design can become inadequate; it can
start to smell. Martin's
paper, "Design Principles and Design Patterns", discusses symptoms
of rotting design (rigidity, fragility, immobility, viscosity) in the
first several pages. A powerpoint
from ObjectMentor in which these principles are summarized
Three
more design smells have been added (needless
complexity, needless repetition and opacity) in subsequent writings
(See Agile
Principles, Patterns and Practices, this book and many others are available
online for ACM members.)
I scanned your model
class
with an Eclipse plugin which
does test coverage reporting by exercising it with your unit tests.
From the reports, placed in your repository notes folder, you can see
which parts of your model were not tested (code in red). Coverage
should be fairly high (90% +) if using test first development
properly. In addition I also scanned your files with the Eclipse Metrics plugin
. The metric I focused upon is the McCabe
Cyclomatic Complexity Metric. The higher the number the more
paths there are through a method and
thus the higher its complexity. Ideally this number should be
smaller than 10 or so. Large numbers in
general, indicate methods which are harder to understand and maintain
and more likely to contain errors. You want to keep the complexity
within the model where it can be thoroughly tested.
Exam 1 next Thursday, Oct 23
Week
10: (Oct 20-Oct 24) Exam, Practice Proj. Checks, ...
Perform self assessment on your project and prepare to assess/be
assessed by others. Review for exam on Thursday. A study sheet with
code that might be used on the exam was handed out on Monday. Customer
Project, Mobile Network Simulator introduced on Friday.
Week
11: (Oct 27-Oct 31) Customer Project, Patterns and Higher-level OO
Considerations
Reviewed the exam and introduced software design patterns. The exam
provided an introduction to the Adapter
pattern. The Iterator pattern
allows sequential access to aggregates of objects. Some basic
properites of objects were discussed as we considered the canonical form of a class. We
continued exploring the customer project with customer representatives
as well as looking into some higher principles of Object Oriented
Design beginning with the DIP -
Dependency Inversion principle. Handouts were also given on the
topics of Pair Programming
and Code Reviews. Make
sure to get experience pair programming with several different people
as you work on the project.
Week
12: (Nov 3-Nov 7) Customer Project, Patterns and Higher-level OO
Considerations
The customer project requirements are becoming more clear. We discussed
the use of important interfaces to aid the construction of our
software. Strategy and Template Method patterns were
introduced as well as the Open
Closed Principle and the Liskov
Substitution Principle. You may also find the scrapbook feature of Eclipse
useful. It allows pieces of code to be run without the need to create
new classes.
WARNING OF CRITICAL WINDOWS PATCH - please take care that your system
is properly protected.
Back
to CS435F08