--------------------------------------------------------------------------
Software Engineering                 		Fall 2002
COM 3205
---------------------------------------------------------------------------
Assignment 1                                    Due date: Oct. 3, 2002

--------------------------------------------------------------------------

This assignment is stored in file $SE/hw/1

in file hw1-SE.txt
--------------------------------------------------------------------------

Abbreviation:
TPP: The Pragmatic Programmer: our text book.
$SE = http://www.ccs.neu.edu/home/lieber/com3205/f02/

Course Home Page:
$SE = http://www.ccs.neu.edu/home/lieber/com3205/f02/f02.html


Topics:
The following tips from TPP:

Tip 36:
Minimize Coupling Between Modules

Tip 51:
Don't Gather Requirements - Dig for Them

This homework is about the Law of Demeter but it should be seen
in the more general context of style rules for programming.
You will learn how to implement dynamic style rule checkers in
a well modularized way using aspect-oriented programming ideas
(see aosd.net). For the later implementation we will use AspectJ
(see aspectj.org).

Style rules can be checked in two ways: dynamically and statically.
Dynamic checking involves sheparding an executing program
and reporting errors as they happen during the execution
of the program. We focus on dynamic style rule checking.
Static style rule checking would analyze the source code.

In this homework we take Tip 36 (Minimize Coupling)
as starting point and we want to develop
a software tool that checks the Law of Demeter (LoD) as described in
Section 26: Decoupling and the Law of Demeter.
This version of the Law of Demeter is known as the Object Form
of the Law of Demeter but there are several other forms of LoD.

In a later phase we will extend this tool to a refactoring tool
which helps the programmer to turn a program that contains many
violations of the Law of Demeter into a program that contains few
or no violations of the Law of Demeter. We will use an 
integrated development environment called Eclipse (an open source
project; see eclipse.org) for implementing the refactoring tool.


In a first step we write a requirements document for a tool that checks
for the Law of Demeter. We want a tool called
LoDChecker that "watches" an executing
Java program and verifies that each method call conforms to the LoD.
For each method call that violates the Law of Demeter, a message
is printed.

Use a search engine (e.g. google.com)
to search the Web for various Law of Demeter definitions
(this is the requirements digging part).

A good starting point for your requirement digging is 
http://www.ccs.neu.edu/home/lieber/LoD.html

Papers about the Law of Demeter are reachable through:
http://www.ccs.neu.edu/research/demeter/biblio/LoD-formulations.html
http://www.ccs.neu.edu/research/demeter/biblio/LoD.html
Look for .ps files. Those papers define different forms
of the Law of Demeter and help you in requirement gathering.

Note that each form of the Law of Demeter
has certain advantages and disadvantages. Your requirements
document should describe a checker that can check
several forms so that users of the software can 
select the checker most suitable for their needs.
Note also that this is a challenging exercise because you define a program
that does something useful for all Java programs.
Your program will be highly generic and will be able to interact
with any legal Java program.

Note also the reflective nature of this assignment. You are both
designer/programmer and the client/user of the program to be built.

Turn in your requirement document. For help in structuring your
document, read Chapter 7 (TPP): Before the Project.

Here are some variations to consider:
Class Form
Object Form
Strong Form
Weak Form
Global variables
How to deal with static methods?
Compare the object form described in TPP with the object form described at:
http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/object-formulation.html