CS435F07 Weekly Topics and Readings
Week
1: (Aug. 20-24) 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. 27)
- 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)
- Read the Agile Manifesto
- Agile
SkypeCast 2007 - Bob Martin - What is Agile?
- Agile
Processes (Robert Martin, (ObjectMentor)Prentice
Hall,
2001)
- Iterative
and
Incremental Development: A Brief History, Craig Larman, July 1,
2003.
- “The Demise of
the
Waterfall Model Is Imminent” and Other Urban Myths, Phillip A.
Laplante and Colin J. Neill
We begin working on a short team project to introduce refactoring.
Secrets
of Software Success: the Nature of the Team - a whitepaper from
Menlo discussing aspects of teamwork.
Week
2: (Aug 27-31) Refactoring and Introduction to TabletPC
The refactoring exercise continues. Refactoring is an import
practice in Extreme
Programming(XP). You may like to listen to a podcast
introducing refactoring. 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.
This Thursday the TabletPCs will be distributed (assuming all paperwork
is completed). To get your machines ready for use as a development
platform, follow this link and start
installing software.
Friday we went over a handout which
looked at building projects with Ant using Eclipse.
Week
3: (Sept 3-7) Java Example & Finding Smells
We discussed a Java code sample, RaceGame.java.
Working in
pairs, examine the sample code
to find smells (this 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. You should easily find more than a dozen
smells (counting a
tight cluster of the same smell as a single smell). Each group should
e-mail me one Windows
Journal document consisting of the original code and the smells that
you've found (by 4pm Friday). Write your name (using the tablet pen) on
the source listing you mark-up in Journal. Each group should also
indicate a best example for each of the 1st 6 types of smells listed.
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.
Working in your smell detecting pairs, begin to refactor the RaceGame
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.
Week 4: (Sept 10-14) Refactoring in Pairs
Continue refactoring the RaceGame code. Frequently test your code after
making changes. 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. This guide to using
version control with Eclipse will get you started using subversion.
By the end of the week, each group should keep their most recent code
in the repository.
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). Place your journal file under
version control in a "doc" directory. 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 created using Test Driven
Development.
Week 5: (Sept 17-21) Building up a Model
Test-First with JUnit
JUnit is introduced. JUnit is used to create automated unit tests
enabling test driven development. We continue refactoring our code,
first to group together the MVC aspects then to factor out the model
from the GUI code. A handout discusses
this in more detail as well as how to modify your build file to run
tests. You will need to download JUnit 3.8.2 if you have not already
done so. Learn more about the available asserts
in JUnit through the online javadoc.
To help clarify some of the ideas of test first development, take a
look at the following 3 articles:
model class is extracted out of the
original class. Next the model class will be created using Test Driven
Development.
Week 6: (Sept 24-28) User Stories, the
Planning Game, Practice Project
We reviewed XP practices involving how requirements are collected and
how work is scheduled. See the overview of Extreme
Programming as a one page poster. XP uses customer
stories to collect requirements. Here is a summary of how
projects can be managed with XP. We talked about some characteristics to
look for in good stories.
A practice project and some initial stories for it was introduced
(binary racegame). To make things clearer, each group was to
start a new Eclipse Java Project for binary racegame and put it under
version control. This project is to be implemented using a model
created with Test Driven Development. Let the tests drive the
design. Model code should not exist unless there is a test that
requires it.
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. The concept
of a "spike" was also introduced. A handout gave an example of a coding
spike to learn about drawing simple Java 2D graphics in a Swing
component.
Week 7: (Oct 1-5) Javadoc, iteration 1 of
practice project, estimating
Using javadoc
comments is discussed. Coding conventions
for Java and a set of coding
standards summarized on a single page. Try to estimate the effort
that the initial binary racegame stories will require. Think about how
stories can be tested. Work on creating the model driving it's design
using test first development.
There were some problems running the javadoc task. One possible cause
is that the command
becomes too long for Windows to handle after all the directory
names have been expanded. You might try using <javadoc
classpath=""/> in the javadoc task.
To keep better track of where our efforts are going (hopefully allowing
better estimates in the future), project
time sheets have been created.
Please record your efforts on these sheets. Print them to windows
journal, fill them out and put them under version control. Make a new
folder "workLog" to keep these in. Name them using a sequence number
like "bartSimpsonIter1ws01", "bartSimpsonIter1ws02" etc. Each person
has their own worksheets.
UML Class diagrams and some Swing event handling options.
Introduced idea of mock objects and how they might be used to control a
random process to make testing possible
Week 8: (Oct 8-12) Refactoring thumbnails,
iteration 1 wrap-up
Extract
method can be used to remove redundant code if that same code
appears in multiple places. When the same code appears in multiple
classes, the extracted code might be placed into a new ancestor class(Extract
Superclass, Pull Up
Method) or a helper class. Refactoring thumbnails
are useful for giving an overview of how to breakdown and perform more
complicated refactorings. As you write classes, especially those that
might be used by others or with other libraries, consider if your
classes have what is generally expected of good classes. This has been
termed the Canonical
form of a class, among other things, it involves implementing
equals and hashCode methods. 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.
Iteration 1 of the binary race game was to wrap up on Wed. How do you
show progress? Here is an example of
user gameplay and some thoughts about checking progress on stories.
Your repository should include your time/effort sheets for the
iteration as well as a brief progress report.
Week 9: (Oct 15-19) Wrapping up the practice
project, design smells
The 2nd iteration of the binary race game (brg) wraps up on Friday. You
will
need some form of user interface so the user can interact with your
game. Eclipse has a scrapbook feature
that may help you with coding spikes. Remember to keep refactoring your
code and tests. Use pair programming esp. for GUI code which is
difficult to write tests for. Here are some
considerations based upon a review of the code that the class has
created so far.
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
by Martin 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.)
The second iteration of the Binary Race Game project officially
ends today. Remember to fill out effort sheets, keep up on your
testing and provide a GUI that hooks up to your model to allow the user
to play the game. Project wrap-up activities will be described next
week.
| Exam 1 will be
given on Thursday Oct 25 - covering material so far. An exam review
will be given next week. |
Week 10: (Oct 22-26) Assessing the brg
project, Exam 1
To confirm that the customer stories for the Binary Race Game project
were implemented correctly, a checklist
was constructed. Each group should self-report (using Journal) and
add their checklist to their documents on the repository. Also ask for
2 more reviews each from a different group. Those reviews, again done
in Journal, will be collected from the reviewers' repositories. You
should indicate which reviewers you asked. Test Driven
Development should have provided tests for the all the required model
logic. To show how your model lines up with your tests, each group
should fill out a test
correspondence table. Also fill this form out in Journal and place
it on the repository.
Each group should also post
in the repository a UML class diagram of your classes with a
particular focus upon how your application is able to keep the view
updated based upon the model. Make sure you are caught up on your time
sheets. The effort here may be useful for arriving at future estimates
(what was the combined group effort for story 1, 3, 7 etc.?.)
A study guide for exam 1 was passed out in class on Monday. Additional
material may be handed out on Wed. The exam is on Thursday.
Deployment: Consider making your
application into a jar file so your user doesn't need to run an IDE to
use your program.
Week 11: (Oct 29-Nov 2) Starting the Customer
Project - JDemo, wiki
We start on our customer project which simulates aspects of Sensor
Networks for Dr. Akkaya's research. To better communicate, we have a wiki
site for the project. We will also be working together in a new
subversion repository (sensor435). Both the wiki and repository are
limited to oncampus (or vpn) access. JDemo,
a framework for creating demos (like Junit is a testing framework) will
be introduced to help with customer demos as well as code spikes. Since
graphs are important to this project, we'll explore using the JGraphT library to model graphs.
We begin to consider OO Principles that should help inform our design
of
systems to combat design smells.
The DIP
(dependency
inversion principle) . Software
design patterns often utilize
the DIP. We had a handout which discussed the DIP, Mocks and the Adapter pattern. Another pattern
considered was the Iterator pattern.
We talked about 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.
Week 12: (Nov 5-9) Refining & Estimating
the
Stories, Starting Iteration 1
A handout giving an overview of the starting framework for the Sensor
Network Simulator was given. To demonstrate how various classes might
call each other, UML
Sequence diagrams were introduced along with an
example for handling the exit action.
Trackers are working within small groups to refine the stories
(with the customer's help) and put estimates on the web.
Also consider ideas for testing the stories. Begin spiking if it helps
to provide better estimates.
Iterations start on Thursdays. Remember to fill out effort sheets
beginning with iteration 1. Here
are the forms. Save in a worklog
folder on the repository. Create separate iterations files
within worklog. Name your sheet based upon your last name and a
sequence number.
As we begin working and defining interfaces and classes, it is useful
to consider more OO Design Principles. The ISP and
SRP.
An online Java book has a section on Graph
Algorithms
and here is a quick reference for
Java IO .
Week 13: (Nov 12-16) Acceptance Tests,
Charting Progress
A key way of measuring progress is by completing stories. Two articles
about keeping
track of progress and various
charts which might be useful in XP. On Wed. we stumbled upon a Windows/subversion
issue relating to case changes in file names. Try a fresh check-out
if you are still having problems. Thursday, StateFarm representatives
will give a presentation at the end of class. As a user interface
begins to take shape, note that Java has a Preferences
class to help remember
what a user's preferences are.
A discussion regarding OO
design principles.
To help reduce errors and misunderstandings, many software process
(esp. the more formal ones) use some form of code review. Here is a
summary of a more
formal inspection process from NASA.
* * * * * * T H A N K S G
I V I N G B R E A K ***********
Week 14: (Nov 26-30) More patterns, wrap up
of Iteration 1
Our iteration length was changed to 2 weeks so iteration 1 ended this
week. Two more behavioral patterns that allow for customization of
algorithms the Template Method, and Strategy patterns were
discussed. The patterns Singleton and Command were
also introduced. As the course comes near an end, begin to consider
your contributions to the customer project. Some retrospective questions for the final project
will be collected at the start of the final.
Articles
from JavaWorld on Java patterns and a couple of other collections
of information about software
design patterns
(Vince Huston) and Java
Design Patterns at a Glance
Week 15: (Dec 3-7) More OO Design Principles,
Patterns, Final Project Iteration
Additional OO-Design principles the Open
Close Principle (OCP) (discussion)
and Liskov
Substitution Principle (LSP) as well as Stability
and the Stable Dependencies Principle(SDP) were introduced. The
Composite design pattern, useful when constructing composite
objects from simpler components as is common with GUI toolkits and the
Observer pattern were introduced. Observer 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. The Factory Method
pattern is useful for differing to a subclass specific objects which
must be created (like a specific model, viewer, graph generator etc.).
Please remember to consider deployment (this is something that a
customer might just assume will be taken care of). One-Jar, a project to place
all files, including other jars, into a single jar is available along
with an
article describing it.
While our project could probably use some more tests, focus on useful
tests - ideally tests drive the design, clarify or serve as an example
of how to use the code, and verify correctness. It is possible to write
tests which aren't very useful - see this note from
the JUnit FAQ. Here is an article describing some anti-patterns
for JUnit testing. Be aware of anti-patterns as
they indicate common ways of solving problems which often lead to
failure (there are quite a lot of ways to fail - see the Anitpatterns catalog).
The book "Bitter
Java"
discussing Java anti-patterns is available for download. Demos can also
be written as examples on how to use the code or to prepare parts of
the user interface.
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. We are experimenting with CruiseControl, a tool
which automatically
builds code and reports tests etc.
There has been concern for many years about improving software process.
The Software Engineering
Institute developed a system for process improvement, the
Capability Maturity Model [ CMM
(entry from wikipedia) and description and discussion on Ward's
Wiki CMM ]
Exam 2 will be
given on Friday, Dec 14 at 12:50 in Faner 2204. Immediately after the
final, at 2:15, class meets in the conference room for the final
project demo. Remember to turn in your final
project retrospective questions at the start of the final.
|
This course was taught using a
hands-on, agile approach. To review again what Agile Development can be
like in
real
life see a day in
the life of an Agile programmer (game developer) . There is
an Extreme
Programming group in St. Louis (this is true for many larger
cities) and an annual Agile
conference. The field of software development/engineering is very
large
and you are encouraged to explore other practices and techniques. Here
are some software engineering related links to get you started.
Agile Modeling
artifacts (more than just UML)
IEEE Software
(from IEEE's
Computer Society)
ACM's Special interest group on
Software Engineering(SIGSOFT)
Software
Engineering Body of Knowledge
Pressman's Software Engineering Links
Back
to CS435F07