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
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:
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.
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.
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.
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.
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.
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.
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.
- 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.- Do.
The two main goals in design areAt the small scale, structure is provided by classes and objects. They bring together related data represented as attributes and behaviour represented as methods.
- 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.
- 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 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.- 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.