Calendar description Gunnar Gotshalks Last updated 1995 July 28
We will examine the following design methods: classical design techniques such as top down, abstract data types, structured design and HIPO (hierarchical input process output); JSP (Jackson system programming); Data Flow; and SADT (System Analysis and Design Technique). In addition, we will examine how literate programming, finite state machines, Petri nets, grammars and Dijkstra's guarded command language are used in describing and documenting designs.
1 September 11 -- Course overview. General information about design. Top down design, bottom up design.
Readings: Lecture notes Chapters 0 and 1, Sections 2.1..2.4, Chapter 10 and [ANON92], [FREE77a], [FREE77b], [COME81].
2 September 18 -- Literate programming. Structured design. Dijkstra's guarded commands.
Readings: Lecture notes Sections 2.5..2.8, and [STEV78], [DROM85]. Optional for literate programming [GOTS90] and FlexOr man page. Optional to see where literate programming came from [BENT86a], [BENT86b], [KNUT84].
3 September 25 -- Abstract data types.
Readings: Lecture notes Chapters 3 and 11, [MEYE82], [BROOK87]. Optional to see where abstract data types came from [PARN72], [PARN78].
4 October 2 -- JSP design.
Readings: Lecture notes Chapters 4, 12 and 13, and [JACK78].
5 October 9 -- JSP implementation part 1.
Readings: Lecture notes Sections 5.1..5.3 and Chapter 14.
6 October 16 -- Review and first class test.
Readings: Previous readings.
7 October 23 -- JSP implementation part 2.
Readings: Lecture notes Sections 5.4..5.6 and Chapter 15.
8 October 30 -- Grammars and languages. Extended BNF as a design notation.
Readings: Lecture notes Chapter 6, and [BERG81.]
9 November 6 -- Finite state machines as a design tool. Petri nets.
Readings: Lecture notes Chapter 7.
10 November 13 -- Review and second class test.
Readings: Previous readings.
11 November 20 -- Dataflow, Martin/McClure notation.
Readings: Lecture notes Chapter 8, and [GANE79], [SWAR82].
12 November 27 -- Structured Analysis and Design technique -- SADT
Readings: Lecture notes Chapter 9, and [ROSS77].
13 December 5 -- Structured Analysis and Design technique -- SADT.
It is up to the you to read and study relevant material without explicit instructions. You are expected to find the required readings in the references and any other sources you can find. Part of the university experience is to acquire a measure of self reliance. The instructor for the course can only guide you as to what is useful to learn; the effort must come from you. The course lectures will not cover all the topics in detail. Instead, the lectures will cover the most important points and give you pointers as to how the rest of the material can be studied.
If for any reason a report is incomplete, then you should submit, on or before the due date, all work done to date (organization counts) along with a note detailing: (1) reasons for the report being incomplete; (2) what work has been completed; (3) what work remains to be done; (4) anticipated completion date were you to continue working on the report.
Reports will normally be handed in, on or before the due date, to the course instructor at lectures, in their office or in the Departmental office CCB126. Reports are to be handed in during normal Departmental business hours and are due by 4pm on the due date. It is recommended that you hand in the reports at the lecture. Missing lectures while working on a report is a poor learning strategy.
I expect professional looking reports. Use single line spacing and normal size type with reasonable amount of white space separating different items in the report; for example, diagrams, lists, paragraphs, etc. Reports in computer science are technical in nature, consequently they are partitioned into sections, sub-sections, etc. For examples look at the structure of these class notes, papers in the supplemental readings and textbooks.
Please submit your report in a plain paper folder (8 1/2 by 11) with your name and course identification on it. Please staple the subreports for each problem individually and place them in the folder. Do not forget to have a cover sheet. Your name should be on each subreport.
A report is not a puzzle to be solved by the reader. As the designer/author it is your responsibility to present, describe and explain everything pertinent to the problem being solved. Give overviews and guidelines for the reader. Tell the reader what you are doing, how to interpret figures, tables, examples, programs, etc. It is not, however, a tutorial on techniques used; assume that the reader knows these or point them to where they can find out. Assume your reader is a student either in the course or just finished the course.
A copy of specifications is useless. I already have a copy. For plausible readers of your reports they are uninteresting. Instead summarize in your introduction what you have done. Think of your reports as something you could take along to a job interview to show the kind of work you do. Just like artists of all kinds you need to collect a portfolio of your work. When someone asks what you have done you can give them an example report and outline what it represents.
Do not use point format, except for the occasional list, or unless explicitly asked for. Use correct, grammatical sentences and paragraphs. Word processors and GNU emacs have spell checkers. There is a stand alone program, spell, on Ariel. Use them.
Judicious use of external sources of material makes for better reports. However, familiarize yourself with the rules and regulations regarding plagiarism. Be sure to read the section "Senate Policy on Academic Honesty", and "Faculty of Arts Policy on Academic Dishonesty" of the York University Calendar. Also see the bulletin coscOnAcadHonesty. Essentially, all quotes and information taken from external sources (everything which is not your own work) must be clearly indicated and correctly referenced. There should be a reference list at the end of the report.
The test questions in the course will be based on the reports you have done, suggested questions appearing in the material provided in the course directory, and all the exercises suggested by the instructor and required readings.
The grades for each individual piece of work will be combined using a weighted average of the point values associated with each grade.
Your course grade will be determined using the following algorithm. You must pass each of reports and tests with a grade point average of 2.0 or higher.
grade assigned to each of three reports (r1, r2, r3) - 14% each grade assigned to each of two class tests (ct1, ct2) - 14% each grade assigned to the final examination (fe) - 30% weighted report grade(wrg) <- (r1 + r2 + r3) / 3.0 weighted test grade(wtg) <- (14*ct1 + 14*ct2 + 30*fe) / 58.0
IF wrg < 2.0 THEN course grade <- 'F' ELSIF wtg < 2.0 THEN course grade <- 'F' ELSE course grade <- 0.42*wrg + 0.58*wtg FI
A C grade means doing only what was asked for, a B grade means doing a good job on what was asked for, and an A grade means doing a good job and showing originality. Originality in the undergraduate environment means doing things that were not explicitly asked for but are useful additions or extensions of the work - doing things above and beyond the call of duty.
A+ (9 - 8.5 .. 9) Exceptional - Thorough knowledge of concepts and/or techniques and exceptional skill or great originality in the use of those concepts and techniques in satisfying the requirements of a piece of work or course.
A (8 - 7.5..8.4) Excellent - Thorough knowledge of concepts and/or techniques together with a high degree of skill and/or some elements of originality in satisfying the requirements of a piece of work or course.
B+ (7 - 6.5..7.4) Very Good - Thorough knowledge of concepts and/or techniques together with a fairly high degree of skill in the use of those concepts and techniques in satisfying the requirements of a piece of work or course.
B (6 - 5.5..6.4) Good - Good level of knowledge of concepts and/or techniques together with a considerable skill in using them in satisfying the requirements of a piece of work or course.
C+ (5 - 4.5..5.4) Competent - Acceptable level of knowledge of concepts and/or techniques together with considerable skill in using them to satisfy the requirements of a piece of work or course.
C (4 - 3.5..4.4) Fairly Competent - Acceptable level of knowledge of concepts and/or techniques together with some skill in using them to satisfy the requirements of a piece of work or course.
D+ (3 - 2.5..3.4) Passing - Slightly better than minimal knowledge of required concepts and/or techniques together with some ability to use them in satisfying the requirements of a piece of work or course.
D (2 - 1.5..2.4) Barely Passing - Minimum knowledge of concepts and/or techniques needed to satisfy the requirements of a piece of work or course.
E (1 - 0.5..1.4) Marginally failing
F (0 - 0..0.4) Failing
Due dates for reports and tests
Report 1 Wednesday, October 11 Test 1 Wednesday, October 18 Report 2 Wednesday, November 8 Test 2 Wednesday, November 15 Report 3 Wednesday, December 6 Final Examination: Date only known in November. Could be anytime within December 11..22.Miscellaneous Dates affecting fall term courses
First day of classes September 11 Last day to enrol in the course September 23 Rosh Hashana September 25 no classes Yom Kippur October 4 no classes Thanksgiving Day October 9 no classes Last day to drop the course November 11 Last day of classes December 6 Last day to hand in term work December 11