CS435F09 Weekly Topics and Readings
Week
1:
(Aug.
24-28)
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. 31)
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.
Our refactoring exercise continues. Here is a worksheet
to construct solutions on.
Week
2:
(Aug.
31
- Sep. 4) Refactoring/Smells & Introduction to TabletPC
To continue with our refactoring
exercise on the tabletPC, use the worksheet.
Open
it
in
a pdf 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 an individually worked out solution to exercise 3 (use
care so you won't have to redo.) Here is a link to the refactoring
grid
game
cards.
We will begin getting ready for team development work. A general
handout on
team work and the TabletPCs was distributed. Please go over your
check sheets and make sure to take care of the machines. 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.
Individually finish
Refactoring Grid Exercise 3 using digital ink (make
sure to write your name on the worksheet). E-mail me your solutions by
the end of this Thursday's class (9/3). Individually complete the
Reflections
questions (on paper - write neatly) to be handed in at the start of
next
Thursday's class (9/10).
Work towards having Eclipse 3.5 installed on your machine and test
using the RaceGame.java starter
code. Examine the starter code for smells and use digital ink
(Journal/Jarnal) to mark-up the
listing indicating the code smells that
you find. Those moving from C++ to Java may find this Crash
Course
by
Horstmann helpful.
Find a partner for group activities (try for grads with grads/ ug with
ug). Consider schedule and chances to meet up to work outside of class.
To further check your Eclipse environment and to get more familar with
the tools we'll be using, follow this handout
to
build
and
run a Java project with Ant.
Week
3:
(Sep.
7
- Sep. 11) Refactoring Code
As a group of 2, collect and save a master mark-up of the starting code
and its smells. After finding the smells, consider how you would
begin to refactor the code. Working in your group, practice pair programming
(an XP
practice) as you begin to refactor the code within Eclipse. After all
but the most trival refactorings, try running your code to make sure it
still works. Make sure to save your refactored version.
Individually complete
the Reflections
questions (on paper - write neatly) to be handed in at the start of
Thursday's class (9/10).
Read Chapter 2 in the text on gathering requirements. Soon we'll start
working on a practice project. To get a feel for how Extreme
Programming works (includes pair programming & test first
development), read this episode
about
developing
a
bowling game scoring application xp development style.
ACM has free bowling this Thursday!
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.
|
Organize the most recent version
of your RaceGame Example project
as shown to the right. The notes
folder begins as an empty ordinary folder. Run the "clean" Ant target to remove the
generated files and folders that ordinarily get placed into the classes and dist folders.
On that machine, register your group's repository and then follow the
"Putting an existing project under version control". (see the version control notes)
Source code, build.xml, notes (things that you create for the entire
group to share) should be added to version control. Things that are
local to your machine and generated files (compiled code, jars etc.)
should be ignored by version control.
Your partner should now be able to check out the project. Using the
repository you can share access to all of your group's resources. Place
your group's mark-ups of the RaceGame source code into the notes
directory (add and commit).
|
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 the refactoring tools to remove smells
for the RaceGame.java starter
code.
Read through chapter 3 in the text.
Week
4:
(Sep.
14
- Sep. 18) Model-View-Controller, JUnit & TDD
A handout introduced the concept of Model-View-Controller (MVC) as a
paradigm for splitting up the work among components for interactive
applications. Groups began analyzing their refactored RaceGame code to
color mark-up the MVC aspects. The goal is to better understand the
existing code so that it can be moved closer to MVC. More immediately
we'd like to refactor (staying within the same class) but making the
MVC functionality more distinct - especially code relating to the
model. Make sure to save your mark-ups to the notes folder in your
repository.
Ideally the model would be developed using Test Driven Development
(TDD). The testing framework we will use is JUnit. Here is a handout to get you started on this process.
After working through the handout continue TDD to build a few more
tests to build up the model. Remember to make frequent commits of your
code (with commit comments). An
important goal is to write code which clearly shows what it is doing,
sometimes refered to as programming
by
intention as described in this sample chapter from "Test Driven
Development" (gives advice on Naming, Refactoring, Comments, Testing
and Keeping it
Simple). A nice summary of TDD (also called Test First Development) is
given in Guidelines
for
Test-First
Development.
A handout introducing Binary Race Game(BRG) was given. Groups were
asked to think about estimating stories for BRG. While told not to
actually begin coding for this game, groups could do coding spikes
to better understand the stories.
Week 5: (Sep. 21 - Sep. 25) Stories, UI
Sketches, Planning Game
Here is a summary
of
how
projects
can
be managed with XP and a one page visual overview.
We
look
at
how customer
stories
can
be used to collect requirements. We talked about
some characteristics
to
look
for
in
good stories.
To help flesh out the BRG stories and better communicate with the
customer, groups are to sketch
screen designs and enter them into the notes folder in the
repository. The sketches help
to facilitate dialog with the customer and clarify requirements. Use
color, notes etc. to add value to your sketches. Hopefully you will
come up with a simple User Interface but it may also make sense to have
an Interface
Flow
Diagram to show how the user navigates between interaction
spaces. This has some relation to state
diagrams which are also useful in understanding the states that the
model (or controllers) may go through.
To help organize information about your stories, install the Eclipse Wiki plug-in.
Check your project notes folder for a starting local wiki. Here you
should add project stories and related information. Please use the
TWiki format. Check the plug-in's help once installed. Note that your
wiki pages should be stored in the repository so remember to
commit/check out.
Week 6: (Sep. 28 - Oct. 2) Practice Project
No class on Monday. Wed. each group checked its repository for updates
to its wiki especially the ProjectLog for comments and questions.
Common questions were about forming the group's work budget for an
iteration, considerations for splitting stories and getting screenshots
linked into the wiki. Here is some info regarding linking in images
within the wiki.
Create a wikispace.properties
file in your wikiNotes
folder.
Have an entry (for your group) like:
OwekeyImages=Eclipse:/RGBF9owekey/Notes/
Where the group owekey's project is called RGBF9owekey
under Eclipse and the images are stored in the Notes
directory under that.
|
set svn to ignore this file
We expect that each
repository user may store
their Eclipse project with
a different name.
|
In the wiki source code, enter
something like:
OwekeyImages:InterfaceDesign.jpg
Where InterfaceDesign.jpg
is the name of the
image file within the Notes folder of the project.
|
See the Eclipse Help section on the Eclipse Wiki plug-in
and also the syntax tab when looking at a wiki page.
Week 7: (Oct. 5 - Oct. 9) Practice Project -
Iteration 1
Groups should have met with the customer and gotten feedback on story
splitting and initial priorities. Project wikis should be kept up to
data about stories and their progress. Build code incrementally
and make sure to commit to the repository regularly (with commit
comments). Follow standard Java coding conventions (summarized on
a single page). Make a habit of including javadoc
comments (at least for your model code, method descriptions, @param
and @return esp.).
I expect to see Test Driven Development for the Model and Pair
Programming during development.
Week 8: (Oct. 12 - Oct. 16) Practice Project -
Iteration 1
Mock objects(HO) were introduced with an example based upon mocking the
random object used to create dice. Reducing redundant code was
revisited looking at some strategies that can be used when the
redundant code involves multiple classes. 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. A HO showing
this and introducing refactoring
thumbnails was given out. A useful tool for reviewing
code coverage(EclEmma) was demonstrated with each group's code. A burndown
chart(and variations) can provide a quick visual way of assessing a
group's progress through a release or iteration (see
text)
Begin thinking about
Exam 1, planned for Thursday, Oct. 22.
Week 9: (Oct. 17 - Oct. 23) Exam - User Tests,
Canonical Form
We pause the clock on the practice project to prepare for the exam and
to consider some other things which come-up. You have been
developing your code using Unit tests, the customer generally has
broader concerns in seeing how the system works to complete a story.
Here is an example of a customer
test
case : User Test 1- it
basically simulates a portion of gameplay. The GUI also becomes more
important as the customer expects to see useful working code; see the Swing
tutorial
on
writing
event handlers for some useful information in
hooking-up your interface.
As your code evolves, you may have developed object which should be
organized using various collections and may also require comparisons
between them (like to verify equality etc.). It is helpful to think
about what basic properites classes should have and the canonical form of a class
considers these issues.
Exam on Thursday, Oct 22.
We take a quick look at code metrics (here is an Eclipse metric plugin ) and
check reports of project code to help determine which parts of the code
may need refactoring.
Week 10: (Oct. 24 - Oct. 30) Demos, Symptoms
of Design Rot, Start -
Iteration 2
The exam was handed back on Monday and the solutions were discussed. A
framework (JDemo) was introduced
(HO) to make it easier to set up demos for the customer to review. The
handout showed how this functionality could be added to your build
file. New stories for iteration 2 were also discussed. The CardLayout
or
JTabbedPane
was suggested as a useful way to manage different groupings of
components which are shown at different times through the execution of
a program (About, Game, Rules). If you need to provide options that can
be turned on/off by the user, consider JCheckBox.
Make sure that at the end of this iteration, you can deliver your
application as a self-contained (images, sounds etc.) executable jar
file. If you use sounds that you haven't recorded yourself (freesound etc.) make sure to give
proper credit (in your about panel). Your build file should have a
"jar" target that creates the executable jar in the "dist"
(distribution) directory. This executable will be used to evaluate the
status of your deliverable code. A HO was given, don't forget to check
the ant manual
if you need to.
In general, 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) on the
first several pages.
We take a quick look at code metrics (here is an Eclipse metric plugin ) and
check reports of project code to help determine which parts of the code
may need refactoring.
Week 11: (Nov. 2 - Nov. 6) DIP, Software
Design Patterns
We talked about the Dependency
Inversion
Principle and how using mocks through interfaces could
help to support it.
Groups have customer priorities, should have updated their wikis and be
well underway for iteration 2. One of the iteration 2 stories involved
sound effects so you may find Audacity (free sound
editor/recorder application) useful. You can record your own sounds or
obtain sounds which are made available for free (such as at freesound.org) so long as you
follow their license (often a matter of giving credit).
Code Reviews (HO example for informal code review), Software Patterns
introduced: Adapter Pattern.
Team pictures for your about boxes are here: dramond, harpal, kirvin, miszel
Week 12: (Nov. 9 - Nov. 13) Sequence Diag,
BRG Release, more Patterns & Princ.
UML Sequence Diagrams to show how classes/objects interact at runtime.
We wrap up coding for our BinaryRaceGame project. A checklist (customer viewpoint) was
distributed. Have your "ready for release code" (executable jarfile)
available at the start of class Thursday for evaluation. A handout with
additional write-up requirements for individuals and groups was also
given.
Principles: ISP and SRP; Patterns: Observer, Template Method
and Strategy
Week 13: (Nov. 16 - Nov. 20) Begin Customer
Project, more Patterns & Princ.
BRG project retrospective/reporting requirements were due Thursday.
Groups presented their code review sections.
A new project concerning mobility of units in ad hoc mobile/sensor
networks was introduced this week (HO. Here are some additional
background
references.). We had a visit from Dr. Akkaya, one of our
external customer(s). A new repository has been made available for the
entire class to work together to satisfy the customer goals.
Principles: LSP, OCP; Patterns: Composite, Decorator
Week 14: (Nov. 30 - Dec. 4) Customer
Project, Patterns
We start to make good progress on the customer project. Keep in mind
how you are involving yourself in this project so that you are ready to
answer retrospective questions (HO). Try to get more experience with
other pair programming partners.
Patterns:
Singleton,
Factory Method (and discussion of Factories)
Week 15: (Dec. 7 - Nov. 11) Customer
Project, (Anti)Patterns, (Package)Princ.
Many times when working with groups of objects, you will need to
process/test each item in the group. The Iterator pattern is designed
to do that. In java, the Collections
routines match data abstractions to implementations for handling
aggregates of objects. The Command pattern is used to wrap
commands as objects - Swing use Actions as Commands.
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.
We considered the package structure of a software system and principles
to guide its design (HO). We also discussed notions of (in)stability
and abstraction. A HO was distributed; it's major reference was from an
article
from
ObjectMentor. A related article discusses Principles
and
Patterns for OO Design.
Check the Agile Alliance
for additional information related to agile development - there is much
more than just Extreme Programming. Scrum is a
very popular agile methodology. Here is a one page summary of
scrum.
Principles: ADP (Acyclic Dependencies Principle) and SDP (Stable
Dependencies Principle);
Patterns: Iterator, Command
Final Exam: Wed., Dec 16
03:10-05:10p.m. [Faner 2204 - followed by final customer demo @4:25 in
the CS Conf. room]
Additional Sources of Information
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)
Remember the practice of Continuous
Integration - tools exist (like CruiseControl)
to automate builds - another reason for build scripts and automated
tests. (Fitnesse)
IEEE Software
(from)
ACM's Special interest group on
Software Engineering(SIGSOFT)
Pressman's Software Engineering Links
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
