COMP 6471 Software Design Methodologies

Fall 2012 Semester: September 4 to December 5, 2012

Lectures: Mondays 17:45 to 20:15 in H-631

Section NN

Instructor: Dr Greg Butler, gregb@cs.concordia.ca
Teaching Assistant (Programmer on Duty): Elias Bou-Harb e_bouh@encs.concordia.ca

Office Hours - Dr Butler: Mondays 16:00-17:00 in EV.003.219

Programmer-On-Duty Hours - Monday 16:30 to 17:30 H811; Thursday 17:30-19:30 H847

Announcements

2012-12-17: Marks for assignments 3 and 4, and the final marks are posted.

2012-11-24: Quiz 2 marks

2012-11-12: Quiz 2 will be 75 minutes long, from 1800 to 1915 on Monday 19 November 2012.

2012-10-29: Quiz 1 marks

2012-10-15: assignment 2 marks
Please do not submit .rar files. I cannot read them.

2012-10-15: Quiz 1 will have three questions. Each question will have four parts, each requiring a short answer. Each part will have a mark out of 5, so each question has a mark out of 20.

Read each question carefully. Answer the question that is asked: do I want a definition, a description, a discussion, an example, etc. Write legibly. Write complete sentences.

Text that does not address the question that is asked, does not gain you any marks.

I mark your answers so that 3/5 is the mark for what I consider to be a good answer. A mark of 3/5 means that you know your stuff, and gave a good answer. A mark of 4/5 means that you understood the issues and used terminology accurately. A mark of 5/5 means that I could not ask for more in an answer.
On the raw mark scale per question, scoring 6-8 outof 20 is satisfactory while more than 12 out of 20 is very good to excellent.
A scaled mark is obtained by "bell curving" to an average of 65.0% and an sd of 13.5%.
As a guideline, a scaled mark of 65.0 would rank as a B (maybe low B+) as a grade; 50.0 would be C or below.

Some sample short answer parts (each out of 5):
a) What is a software design? Who uses a software design, and how do they use the software design?
b) What is use case realization? What information drives the process of use case realization? What design information is produced during use case realization?
c) How is the domain model used during software design?
d) What is a responsibility? What responsibility is being assigned in the Information Expert pattern?

2012-10-15: assignment 1 marks

2012-09-13/14: First POD session is Friday 14 September 2012 special session 1700-2000 in H-847
Regular POD session schedule starts Monday 17 September 2012.

Course Description

This course covers the state-of-the-art in architectural design of software systems. The course considers commonly used software system architectures, techniques for designing and implementing these architectures, models and notations for characterizing and reasoning about architectures and design plans. Design methods, object-oriented application frameworks, design patterns, design quality assurance, coupling and cohesion measurements, design verification and documentation. Assignments include a design project.

Textbook

Craig Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process, 3rd edition, Prentice-Hall, 2005.

We rely heavily on the textbook, so get a copy and read it thoroughly.

Evaluation

Students are required to complete four assignments (60%) and two quizzes (40%).

The assignments include both design and programming and are to be done individually. They all relate to the steps in the project.

Each quiz will be a closed book examination of at least one hour in duration.

You must pass the quizzes in order to pass the course as a whole.

Your grade will depend on both your performance in the quizzes and your performance in the project. A poor performance in any single component may bring down your grade. There is no simple direct correlation between your total mark and the grade.

Project

The project for this semester is based on the game of Sudoku, for which there is plenty of information on the web. I suggest everyone play a few games of Sudoku to familiarise themselves with it.

There are three programs required for the project:

1. An interactive Sudoku game where the user can select a game and play it by entering numbers into squares.
2. A generator of Sudoku games which returns a random game of the required difficulty: easy, medium, hard, evil.
3. An intelligent advisor for Sudoku which knows about the various strategies for playing Sudoku and can tell a user which strategies apply to a current situation.

The project is an incremental project involving four versions of these programs:

1. A minimal version which provides basic functionality and a workable interface.
2. A version which incorporates at least one difficult feature, such as infinite undo and redo.
3. A version which incorporates at least two difficult features, such as infinite undo and redo, generation of a Sudoku game, and tracking.
4. A usable, robust, tested version providing the most important features that time allows, including hints, tracking, and advice.

For the last version, you should integrate the three programs into one Sudoku game application.

Sudoku Game

Features of the game that users need are:

• Tthe ability to input an entry in a square. In general, the game does not check whether the entry violates the rules, or is incorrect (if the game knows the correct answer). However, there could be a way for the user to select such a feature.
• Most users wish to take notes about the possible entries in each square, usually by writing very small in the square. Usually they indicate which numbers 1..9 are possible, or impossible. Either provide a general facility for notes in a square, or allow users to track each of 1..9 for each square as possible or not possible as an entry.
• Sometimes, it comes down to pursuing two possible entries for one square, to see which entry leads to a contradiction: then the correct entry is the other one. To do this, the user must be able to request tracking of entries (in a different colour) from this point in the game, and the ability to clear all tracked entries.

Sudoku Advisor

Features of the Advisor are related to how many heuristics or rules you wish to incorporate, and whether the heuristics are hard-coded in Java or can be described as a rule and then read in by the Advisor.
A minimal version should check the three rules of the game, and not allow entries which violate the rules. A variant of this, if you know the correct answer, is to not allow incorrect entries.
If you play the game, or read articles about the game, then you can discover other heuristics as well, to incorporate into the advisor.
The advisor can act in a reactive mode, ie a user requests help, then the advisor offers a hint (ie an entry) or the advisor checks whether any existing entries violate the rules. The advisor can also be proactive, and essentially generate as many new entries as possible using its set of heuristics.
In the ideal case, the heuristics should be strong enough to provide a complete answer to each game when the advisor works in proactive mode.

Sudoku Generator

Features of the Generator are related to how pragmatic a solution is desired:

• a simple solution is to collect a list of about 10 games with solutions (from some source) for each of the difficulty levels: easy, medium, hard, evil.
• to get a greater number of solutions, but still be pragmatic, is to generate permutations of the games and answers in your lists above. Allowable permutations are (a) any permutation of the entries 1..9; (b) any swap of two rows which lie in the same subgrid; (c) any swap of two columns which lie in the same subgrid; and (d) any permutation of subgrids by row permutations or column permutations.
• a full solution is to be able to generate all solutions in some methodical way. It is really beyond the scope of this course for you to develop such an algorithm, but if you find a good description of an algorithm then you can perhaps implement it.

Assignment 1: Due 10:00 Thursday 27 September 2012

First version of an interactive game in Java for Sudoku. It supports a minimal game: a user can select a game, enter values into grid locations, and the systems reports success or failure when the grid is full.
The game is selected from a list of games that you provide for the system. (You should provide the answer as well for use by your system.)
Concentrate on an architecture and design that is easily extensible.

For the 2-page description of your class model, simply write a short description (about 3-5 lines of text) of the purpose of each of the major classes in your program.

Submit a .tar.gz file with your Java program, list of games files, and a 2-page description of your class model to "Project 1" of electronic submission system.

Assignment 2: Due 10:00 Thursday 11 October 2012

Second version of an interactive game in Java for Sudoku. This is a chance for you to iterate on your solution for Assignment 1. This version should support undo/redo of commands, and provide a hint (ie the correct answer for an entry) to the user when requested.

The domain model describes the concepts in the "problem domain" of the game of Sudoku; see Larman Chapter 1 and 3.

Submit a .tar.gz file with your Java program, list of games files, and a 2-page description of your domain model to "Project 2" of electronic submission system.

Assignment 3: Due 10:00 Thursday 8 November 2012

Third version of an interactive game in Java for Sudoku. This version should use your Sudoku Generator to automatically construct games.

The document should be a clear high-level description of the approach or algorithm that you use for generating games.

Submit a .tar.gz file with your Java program, list of games files, and a 2-page description of your algorithm to "Project 3" of electronic submission system.

Assignment 4: Due 10:00 Thursday 29 November 2012

Fourth version of an interactive game in Java for Sudoku. This version should include a Sudoku Advisor.

Submit a .tar.gz file with your Java program, list of games files, and a 4-page description of your architecture to "Project 4" of electronic submission system.

Marking Scheme

For assignments with documents, the marking scheme (for a mark out of 10) is

• structure of code: 0, 1, or 2 marks. For use of classes, methods, structured loops, and if/case.
• clarity of code: 0, 1, or 2 marks. For clear logic of code, good variable names, obvious correctness.
• code documentation: 0, 1, or 2 marks. For appropriate documentation within code itself: identification of purpose of program, author and date; description of responsibility of classes; desc. of methods; desc. of main blocks of structured code. Not excessive documentation.
• document: 0, 1, or 2 marks. For clear diagrams, explanatory text, completeness and understandability of document.
• Bonus 0.5 marks in each of the above categories when it is done very well. So each of the four above items is out of 2.5 marks.

Late Penalty: There is a penalty of 10% of the assignment mark for each day that your assignment is late.

Lecture Schedule

Tentative - subject to change.

Week 1 - 10 September 2012: Course Outline; Intro to Larman's process; Role of Software Architecture.
Reading: Larman, Ch 1-7; Software Architecture: An Executive Overview SEI TR-003, 1996.
slides

Week 2 - 17 September 2012: Domain Modeling.
Reading: Larman Ch 8-12.
slides up to slide 38.

Week 3 - 24 September 2012: More Domain Modeling.
Reading: Larman Ch 31.
slides 39 onwards.

Week 4 - 1 October 2012: Software Design (1: responsibilities, GRASP, modularity)
Reading: Larman Ch 12, 14, 17, 18, 19, 20.
slides Up to slide 51.

Week - 8 October 2012: Thanksgiving holiday - No lecture.

Week 5 - 15 October 2012: Software Design (2: use case realization, object design, visibility)
Reading: Larman Ch 12, 14, 17, 18, 19, 20.
slides From 52 onwards.

Week 6 - 22 October 2012: Quiz 1

• Quiz 1 18:00 to 19:00 Monday 22 October 2012.
  Format: short answer questions.
  Material: Week 1 to Week 5 chapters of Larman. Ch 1-12, 14, 17, 18, 19, 20.

Week 7 - 29 October 2012: Software Architecture (1: Layers, MVC, GRASP, design patterns))
Reading: Larman Ch 13, 25, 26.
slides up to slide 44

Week 8 - 5 November 2012: Software Architecture (2: Design patterns)
Reading: Larman Ch 26, 36;
slides from slide 45
slides more on design patterns

Week 9 - 12 November 2012: Software Architecture (3) Documenting Architectures.
Reading: Larman Ch 33-39.
slides

Week 10 - 19 November 2012: Quiz 2.

• Quiz 2 18:00 to 19:00 Monday 19 November 2012.
  Format: short answer questions.
  Material: Week 4 to Week 9 chapters of Larman. Ch 12-20, 25, 26, 33-39.
  Focus on Software architecture: definition, need for, importance, properties, documentation.
  Focus on Layered architecture, Model-View-Control architecture.
  Focus on design patterns: Command, Observer, Composite, Adapter, Proxy, Decorator, Facade.
  Focus on GRASP patterns: Controller.
  Think about your use of architecture, design patterns, and GRASP patterns in your assignments.

Week 11 - 26 November 2012: Software Architecture (4) Styles and Patterns
Reading: Books on Pattern-Oriented Software Architecture, MSDN Chapter 3: Architectural Patterns and Styles, wikipedia.
slides

Week 12 - 3 December 2012: Software Architecture (5) Evaluation and Analysis
Reading: Larman Ch 33.
Reading: Len Bass, Paul C. Clements, Rick Kazman, Software Architecture in Practice (2nd Edition), Addison-Wesley. Published: April 2003 ISBN: 0321154959
slides

Week 13 - Tuesday 4 December 2012: Software Architecture Recap; Frameworks, Generation, Model-Driven Development.
Reading: Previous reading.
slides