SOEN 6461 Software Design Methodologies

Fall 2015 Semester: September 8 to December 8, 2015

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

Section SS


Instructor: Dr Greg Butler, gregb@cs.concordia.ca
Teaching Assistant (Programmer on Duty): To de determined

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

Programmer-On-Duty Hours - To be determined

Official Course Outline


Announcements

2015-12-30: Final Total Marks. Letter grades will be processed by Student Information System (SIS).

2015-12-29: Final Exam Marks and Scaled Design Assignments Marks

2015-12-14: Design Assignment 3 Marks

2015-12-04:
Quiz 2 results will be discussed in the lecture on Tuesday 8 December 2015 in H-820 from 1745 to 2015.

Study all the material for the Final Exam. Go well beyond rote learning, as I expect you to be critical thinkers who know why the material is important to software design, how topics and issues are connected to each other, and who can justify their answers.
Learn from your mistakes. Look at what you did wrong in the assignments (as in Q3 of Quiz 1 and Quiz 2). Know how to describe a class; how to code algorithms using iterators; and practice invariants. Make sure you can write an invariant for each of the 3 assignments.

Final Exam is Monday 14 December 2015 from 1900-2200 in FG B030 and FG B070 on basement level of Faubourg building, 1616 Rue Ste-Catherine West, Montreal, QC H3H 1L7. Be early!

2015-12-01: Quiz 2 Marks

2015-11-30: Design Assignment 2 Marks

2015-11-16: Design Assignments.

Your design document should clearly follow the five required sections, by having clear headings:

  1. Problem Description
    This includes a description of the functionality, as done in the document for the Design Assignments. It also includes a statement of each non-functional requirement that states the non-functional quality, and states a concrete requirement for that quality.
    It does not include introductory material to the problem, nor any design information.

  2. Design Description
    For these kind of designs that have a main algorithm for a computational problem, a useful structure for this section is:
    1. a summary paragraph presenting an overview of the design: give the big picture, and mention major classes and methods;
    2. a class diagram for the whole design, including complete method signatures, with a title and caption for the diagram;
    3. the main algorithm as pseudocode: this can be a figure with title and caption, where the pseudocode is single-spaced, and can be in a smaller font, and properly indented;
    4. a description of each major class:
      1. class name, with responsibility/purpose/function/role clearly described;
      2. data attributes: name, type, description
      3. signature for each method, with pre- and post-conditions, and maybe a description of its purpose
      4. pseudocode implementations of major methods, if necessary.
    5. maybe, descriptions of behaviour using interaction diagrams, if necessary.

    You do not need CRC cards. CRC cards are used while brainstorming the design. Once you have the design, then describe the design using class diagrams and interaction diagrams. Many of you use these wrongly to include methods.

  3. Major Design Decisions
    List the major choices you made and the impact they had on the design.

  4. Design Review
    For correctness, you need an argument as to why your design produces the correct results. For these computational problems that requires you to clearly write an invariant (or several invariants) of the main algorithm, to show it is an invariant of the main algorithm, and to show that the invariant implies the results produced by the main algorithm are correct.
    It is not enough to simply repeat the trace of the scenario in the document for the Design Assignments.
    For most of you the reader would have no confidence that your design is correct: first, because the description of the design is unclear, and second, because there is no logical reasoning justifying that the design produces the correct results. You need a clear design description before you can reason logically.
    For usage of resources, you need explicit formulas for the amount of memory, and the amount of time (number of instruction steps).
    It is not enough to say: I reviewed this quality.
    It is not enough to repeat sentences from the document for the Design Assignments.

  5. Glossary
    These should be dictionary-type entries for the terms important to your design, such as classes, methods, objects, data structures.
    Do not define terms from software engineering or OO design, such as CRC card, state, etc.

You are doing particularly poorly in Section 4 Design Review.

You are doing poorly in Section 2 Design Description. You need to start early, develop a design through several iterations. Then document your finished design.

Use classes and objects from the problem domain, like Genome, Pattern, Nucleotide, Count, Position; rather than built-in types/classes like String, Character, int. Do not include a Problem Domain diagram or section in your document: that belongs in the requirements document, not the design document.
Many examples of pseudocode are not indented properly.

Learn to use Latex.

What I have written here repeats what I wrote for Week 2 below as guidance for Assignment 1.

2015-11-02: Quiz 1 Marks and Design Assignment 1 Marks

2015-10-06: Assignment 1: Due 23:59 Thursday 15 October 2015
I had the wrong day of the week.

2015-10-05: I have activated electronic submission system for SOEN 6461.

2015-10-05: You should have a draft design done by now.
You should know the main classes and objects; their responsibilities; and most of their interface.
Section 1 Problem Description is available in the document describing the assignment 1.
Section 5 Glossary is mostly available from terminology in the document describing the assignment 1. The rest comes from the terminology you use in your design.

2015-09-28: For Design Assignment 1 you should know the Iterator design pattern and use it in your design.
For your concrete iterator class, describe the CRC: the class name, the responsibility of the class, and the collaborators.
For your concrete iterator class, list the methods, give the signature of each method, describe the method, and specify the method using pre- and post-conditons.

2015-09-21: Programmer on Duty sessions start Wednesday 23 September 2015.
POD is Mostafa Erfani, Email: mostafa.erfani@gmail.com each Wednesday 1400-1700 in H-825.

2015-09-14: For design assignments, including design assignment 1, make sure you carefully read slides 4 and 5 from Course Outline slides;
Remember to include a signed Expectations of Originality form as the first page of the pdf that you submit. See link.

2015-09-14: First class for the course is Monday 14 September 2015.
First POD session will be the week of Monday 21 September 2015 at day and time and location to be determined.


Course Description

SOEN 6461 Software Design Methodologies (4 credits)
Prerequisite: COMP 5541.
Introduction to software design processes and their models. Representations of design/architecture. Software architectures and design plans. Design methods, object-oriented application frameworks, design patterns, design quality and assurance, coupling and cohesion measurements, design verification and documentation. A design project.
Note: Students who have received credit for COMP 6471 before September 2011 may not take this course for credit.


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.

Recommended Books

These are valuable references for any practicing software developer, so it is worthwhile to buy them.
You will need to understand the Iterator and Straegy design patterns very well for your assignments, and to understand the Blackboard architecture for the third assignment.

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994.

Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal, Pattern-Oriented Software Architecture, A System of Patterns, Wiley, 1996.


Evaluation

Students are required to complete three design assignments (30%) two quizzes (20%), and a final exam (50%).

The design assignments are to be done individually.

Each quiz will be a closed book examination of at least one hour in duration. Each quiz will require you to answer questions about the designs in the design assignments that have already been completed.

The final examination will be a closed book examination of three hours in duration. The final examination will require you to create a small design as part of the examination, and to answer questions about the designs in the three dessign assignments.

You must pass the final examination in order to pass the course as a whole. You must pass the assignments in order to pass the course as a whole.

Your grade will depend on your performance in the assignments, quizzes and the final examination 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.


Design Assignments

The design assignments require you to creat, analyse, and communicate a design, but not to writie a prgram.

This term the design problems concern patterns in genome sequences. Details are in the Design Assignments Fall 2015.

Assignment 1: Due 23:59 Wednesday 15 October 2015

Assignment 2: Due 23:59 Sunday 8 November 2015

Assignment 3: Due 23:59 Sunday 6 December 2015

Deliverables

The deliverable is a design document of about five (5) pages as a pdf file. Your design document should have sections on

Submit the pdf file to "Project 1", "Project 2", and "Project 3" of SOEN 6461 to the electronic submission system.

Write your design document for a reader audience at the level of a CS or SOEN graduate like yourself.

Communicating your design clearly is a very important skill that you must learn. Use UML diagrams where and when they are appropriate for communicating information about the design, but do not use them if they are not needed.

Marking Scheme

For each design document, the marking scheme will assign a mark out of 2 for each of the sections listed above, for a total mark out of 10:

Length Penalty: There is a penalty of 10% of the assignment mark for each page that your assignment is over 7 pages.

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 - 14 September 2015: Course Outline; Life-long Learning for Software Development; Major Issues in Software Engineering; Intro to Design;
Reading: Larman, Ch 1-7; Slides: Course Outline slides; Learning;
Did not get to slides: Issues; Design Introduction;

Week 2 - 21 September 2015: Intro to Design; Detailed Design: Collections, Maps, Algorithms, and Libraries; Domain Modeling;
Reading: Domain Modeling Larman Ch 8-12. Design Evaluation and Analysis Ch 33. Slides: Issues; Design Introduction;
Did not get to slides: Detailed Design, Design Assignment 1,

Software Design 101

Design describes the "machine" in terms of its "parts", how parts are "connected", and how parts work together to achieve the overall task.

  1. Plan.
    Understand the problem; in particular, know the required inputs and outputs, and the information they contain, and in what format.
    Gather examples of inputs and outputs, and understand how the outputs relate to the inputs.
    Describe the "parts" of the real-world represented in the inputs and outputs, and in the description of the problem. This is the problem domain model.
    Know which qualities are required for the design, such as correctness, performance, scaleability, etc.
    Specify the system to be designed as a black box; that is, use pre-conditions, post-conditions, and invariants to describe the required properties of the inputs and outputs, the conceptual states of the system, and their relationship to one another.
  2. Do.
    The two main goals in design are
    1. to make the parts work together to achieve the qualities of the overall task; the designer looks at correctness first, and then looks at the non-functional qualities.
    2. to "structure" or organize the design so that it is understandable, and therefore other developers are able to debug, maintain and evolve the system.
    At the small scale, structure is provided by classes and objects. They bring together related data represented as attributes and behaviour represented as methods.
    At the large scale, a design is often divided into layers or as a hierarchy of subsystems.
    At both scales, you may use class hierarchies to organize a set of related classes in order to be clear about what they have in common, and to be clear how they differ from one another. Note that template classes (also called generic classes) perform a similar role in that the parameter captures how the set of classes differ, while the template class represents their commonality.

    You design your machine using your experience with best practice, that is, patterns, and your understanding of the problem obtained in 1. Plan above. The things that you consider as you select the parts of your design are the following:

    • Objects
      These are typically computer representations of the real-world parts in the problem domain model.
      They are organized into classes.
      You need to describe each object and class: give it a meaningful name; what is its purpose, role, function, responsibility in the design; and its behaviour.
      That is, answer the questions: What is it? Why is it there? What does it do?
    • Associations between things
      There is a link between two objects because of an association between their classes that "relates" the two objects. This can be due to several different types of associations. The common ones are:
      • data relations between the objects or their attributes as in database modeling;
      • work collaborations of the objects;
      • one object making use of another object's information, knowledge, or services; or
      • connections between objects such as use of interfaces, remote procedure call, http, TCP/IP protocols, messages, event notification middelware, etc.
    • Interfaces
      An interface collects together methods related to a set of services.
      An interface hides the internal representation of an object from the rest of the design.
      An interface may be an endpoint or port at one end of a connection between two objects.
      An interface makes an object into a black box.
      How do you describe the services offered by an interface in such a way that client objects know what to expect from the service object? Answer: Specify it with pre-conditions, post-conditions, and invariants to describe the required properties of the inputs and outputs, the conceptual states of the object, and their relationship to one another.
    • Collaborative behaviour amongst objects
      The design must go beyond simply describing each class and its interfaces. The design must describe how objects work collaboratively to achieve the overall task.
      This can be done using UML sequence diagram, UML collaboration diagram, UML activity diagram, or pseudocode for methods that coordinate the work.
  3. Review.
    Hand execute your design on explicit scenarios to check that the design has the required qualities.
    Demonstrating correctness needs you to provide an argument (logical reasoning) that your design produces the correct output in all circumstances.
    Demonstrating efficient use of resources such as time, memory, or disk, requires you to provide formulas for the amount of resources used for a given size of input; or to provide an upper bound on the amount of resources used.
    Scaleability is demonstrated by showing that your formulas for resource use grow linearly (or less) as the size of the input grows.

Remember that the design process is an iterative process: you discover issues with your design; you brainstorm potential solutions to the issue; you select a solution and incorporate it into the design. And then you review once more.

Basic Steps in Object-Oriented Detailed Design of Software

Sketch CRC (Class-Responsibility-Collaboration) for each class
UML diagram for system objects and their collaboration
Determine interfaces (that is, the operations) of each class
Specify contract for each operation
Select algorithms and data structures for each class
Describe algorithm for each major operation using UML note

Week 3 - 28 September 2015: Evaluating Designs;
Reading: Larmen, Ch 33. Slides: Detailed Design, Design Assignment 1, Scenario-Driven Review of Design,

Background material slides: Domain Models,

Week 4 - 5 October 2015: Responsibility-Driven Design (responsibilities, GRASP, use case realization, visibility)
RDD, responsibilities, representation gap, use case realization.
Reading: Larman Ch 12, 14, 17, 18, 19. Slides: RDD;

Week - 12 October 2015: Thanksgiving holiday - No lecture.

Week 5 - 19 October 2015: Functional Design; Modularity, Interfaces, Encapsulaltion.
Functional design for business data processing, modules and interfaces, cohesion and coupling, encapsulation. GRASP for closing representation gap, Information Expert, Creator, Control, High Cohesion, Low Coupling.
Reading: Larman Ch 12, 14, 17. Slides: function-oriented design; RDD;

Week 6 - 26 October 2015: Quiz 1

Week 7 - 2 November 2015: Design patterns;
Reading: Larman Ch 26, 36. Gamma Ch 1-2. Gamma patterns: Iterator(page 257), Strategy(page 315); Gamma patterns: Composite(page 163), Facade(page 185), Proxy{page 207); Gamma patterns: Factory Method(page 107), Template Method(page 325), Visitor(page 331). Gamma patterns: Observer, Command.
Slides: Design Patterns;

Week 8 - 9 November 2015: Software Architecture (Layers, MVC, Blackboard)
Reading: Larman Ch 13; Buschmann Ch 1-2. Slides: Software Architecture; Blackboard Architecture;
Software Architecture: An Executive Overview SEI TR-003, 1996.

Week 9 - 16 November 2015: Documenting Architectures.
Reading: Larman Ch 33-39. Slides: Documenting Architecture;

Week 10 - 23 November 2015: Quiz 2.

Week 11 - 30 November 2015: Software Architecture (4) Styles and Patterns
Reading: Buschman Ch 1-2. Slides: Software Architecture Styles;

Week 12 - 7 December 2015: Software Architecture (5) Evaluation and Analysis
Reading: Larman Ch 33. Slides: Scenario-Driven Review of Design, ATAM;
R. Kazman, M. Klien, P. Clements, ATAM: Method for Architecture Evaluation, CMU/SEI-2000-TR-004
The Architecture Tradeoff Analysis Method (ATAM)

Week 13 - Tuesday 8 December 2015: Software Frameworks;
Reading: Previous reading.
slides

Final Examination
Format: true/false, multiple choice, one word answers, short answer questions. And a design question.
Material: Week 1 to Week 12 chapters of Larman. Ch 1-19, 25, 26, 33-39.
Material: Architectures - Layers, MVC; Design patterns - Iterator, Strategy, Composite, Facade, Proxy.
Material: Designs in Assignments 1-3 including UML and evaluation/review of design.
Think about your use of architectures, design patterns, and GRASP patterns in your assignments.


Last modified on 5 December 2015 by gregb@cs.concordia.ca