Differences

This shows you the differences between two versions of the page.

--- course_outline [2015/05/14 04:22] – jackie
+++ course_outline [2015/05/20 03:41] (current) – jackie
@@ Line 1: / Line 1: @@
 ====== Course Outline ======
-===== Calendar Description =====
+==== Calendar Description ====
-A study of design methods and their use in the correct implementation, maintenance and evolution of software systems. Topics include design, implementation, testing, documentation needs and standards, support tools. Students design and implement components of a software system. Weekly 1.5 hour laboratory. Prerequisites: General prerequisites; including SC/MATH 1090 3.00; LE/EECS 2031 3.00.
+A study of design methods and their use in the correct implementation, maintenance and evolution of software systems. Topics include design, implementation, testing, documentation needs and standards, support tools. Students design and implement components of a software system. Weekly 1.5 hour laboratory.
+==== Prerequisites ====
+  - EECS2001
+  - EECS2031
+  - MATH1090
+  - General prerequisites
+    - EECS2011
+    - GPA of 4.5 or better over all completed major CS courses
+See [[http://lassonde.yorku.ca/course-directory/eecs-3311-300|here]].
 ==== Learning Outcomes ====
@@ Line 34: / Line 46: @@
   * Design Patterns
   * Documenting Design Decisions and demonstrating that code satisfies the design
-===== Weekly Lecture Schedule =====
-| Week | Lecture Date | Topics | Readings ^ Released ^ Due ^ Note ^
-| 1    | May 20       |        |          |          |      |     |
-| 2    | May 27       |        |          |          |      |      |
-| 3    | June 3       |        |          |          |      |      |
-| 4    | June 10      |        |          |          |      |      |
-| 5    | June 17      |        |          | Assignment |      |      |
-| 6    | June 24      |        |          |          | Midterm Test \\ (19:00 - 20:30, in class) | No Lecture (Online Lecture Required) |
-| 7    | July 1       |        |          |          |      | No Lecture (Canada Day)|
-| 8    | July 8       |        |          | Lab Test Preparation | Assignment |      |
-| 9    | July 15      |        |          | Project  |            | **Monday, July 13**: Last date to drop course |
-| 10   | July 22      |        |          |          |            | No Lecture (Summer Break) |
-| 11   | July 29      |        |          |          | Lab Test \\ (17:00 - 18:30, Prism lab) |      |
-| 12   | Aug. 5     |        |            |          | Project Phase 1    |      |
-| 13   | Aug. 12    |        |            |          |     |      |
-| 14   | Aug. 19    |        |            |          | 1. Project Phase 2 \\ 2. Report |      |
-| 15   | Aug. 21 - 28 | Exam Period                |||||
-Due dates are **12 p.m. (noon)** on the corresponding lecture dates (**Wednesdays**).
-====== Grades ======
-The weight distribution of the course components is as follows:
-|                 ^ Weight | Note |
-^ Midterm Test    | 10%    |      |
-^ Assignment      | 10%    |      |
-^ Lab Test        | 15%    |      |
-^ Project Phase 1 | 5%     |      |
-^ Project Phase 2 | 10%    |      |
-^ Project Report  | 5%     |      |
-^ Final Exam      | 45%    |      |
-You can view your marks
-[[https://www.eecs.yorku.ca/~roumani/ePost/server/ep.cgi?year=2014-15&term=S&course=3311|here]].
-You may obtain feedback on your Labs via the command line by doing:
-  >feedback 3311 L1
-  >feedback 3311 L2
-  >feedback 3311 a1-money (assignment)
-  >feedback 3311 tictac  (latest)
-  >feedback 3311 bag-code (L4)
-  >feedback 3111 invoice-src (Project)
-If you have any issues with your grade, print out your feedback, add your name and Prism login, write down clearly and precisely where and what your grading issues are, and hand the feedback to your instructor. This must be done within one week from the date the grades are announced. You may also consult with the TA during office hours for further clarification.
-For any re-grading questions on Lab3 or the Labtest, present your grading sheet and issues during the office hour on Thursday March 12, 5.30-6.30pm.
-  * [[http://www.yorku.ca/secretariat/policies/document.php?document=87|Common Grading Scheme for Undergradate Faculties]]
-===== Detailed Topics =====
-The suggested textbooks should help you do self-paced learning, a requirement for this course. The lectures, Labs, assignments and Project will exercise your understanding that you should develop by reading and working on your own.
-TOC is an introductory text for computer science that covers the topics you normally do in EECS1020/1030/2011 using Java, except that TOC uses Eiffel. It has some more advanced topics such as DbC, multiple inheritance, functional programming, etc. that you may not have seem in your first two years. TOC is highly recommended and you can read it online via the York university Library. The main page of this course wiki also directs you to online lectures and slides for TOC. OOSC2 is on reserve in Steacie.
-See the 591 slides of BigEiffel.pdf in the SVN, for a summary of the language and design features.
-=== Slides 02-W15-DBC-TDD ===
-**Readings:**
-  *Suggested Reading: OOSC2 Chapter 1 and Chapter 3. See [[http://www.eecs.yorku.ca/course_archive/2014-15/F/3311/slides/14-Modularity.pdf|here]] for a brief summary.
-  *Required reading:
-    *OOSC2, Chapter 7 (the static structure: classes). See [[http://www.eecs.yorku.ca/course_archive/2014-15/F/3311/slides/04-Classes.pdf|here]] for a brief summary
-    * Chapter 8 (the runtime structure: objects). See [[http://www.eecs.yorku.ca/course_archive/2014-15/F/3311/slides/05-Objects.pdf|here]] for a brief summary
-    *Chapter 11 (sections 11.8 to 11.9: class correctness via preconditions, postconditions and class invariants).
-Topics covered in class using the slides include:
-  * Requirements, Design and Implementation of software systems.
-  * Why is their a need for Design? What are the goals of doing Design?
-  * Illustration of the Design of a small bank system from Requirements to Implementation.
-  * The importance of Unit Testing. Test Driven Development (TDD).
-  * Using the ESpec testing framework: boolean tests and violation tests
-  * What is a Class? It's static structure
-  * What is an Object? It's dynamic structure
-  * Representing system architecture via BON (and UML) class diagrams.
-  * Relationships between classes: Client-Supplier (associations) and Inheritance
-  * Uniform Acces Principle (and information hiding)
-  * Using Eiffel for DbC
-  * Using the EiffelStudio Debugger for Testing, and ECF files for clusters and libraries
-  * Using the EiffelStudio BON diagraming tool
-  * The design and use of generic collection classes such as ARRAY[G] and LIST[G].
-  * Expanded and Reference Types
-  * Object comparisons versus Reference comparisons
-  * The difference between "=" and "~", and redefining ''is_equal''
-  * Void Violation Cases and Void Safety
-  * What is Design? Architecture and Specifications
-  * The BON diagram notation for Architecture
-  * Information Hiding
-  * Abstraction and abstract (deferred) classes
-  * The Command-Query separation Principle and DbC
-  * DbC: obligations and benefits in contracting
-Class included a demo of compile time void safety checks
-=== Slides 03 ===
-Iterator (with **across** construct for quantifiers in contracts) and Singleton Pattern
-=== Slides 04 ===
-  *Static (compile time) classes vs. dynamic (runtime) objects
-  * Classes as partially implemented ADTs (abstract data types)
-  * reference vs. expanded types
-=== Slides 05 ===
-  * Design by Contract (Dbc)
-  * Hoare Logic
-  * Class correctness proof obligations
-=== Slides 06 ===
-OOSC2 chapters 14, 15, 16 and 17
-  * Inheritance, polymorphism and dynamic binding in design
-=== Slides 07 ===
-OOSC2 and chapter 20
-  *Multi-panael Design Pattern
-=== Slides 08 ===
-  *Eiffel Testing Framework (ETF) and acceptance tests
-  * ETF includes singleton, command, publish-subscribe and MVC design patterns
-=== Slides 09 ===
-Tuples and functional programming (lambda calculus and agents)
-=== Slides 10 ===
-  * Strategy design pattern
-=== Slides 11 ===
-  * Observer Design Pattern
-  * Event Based Programming and Publish-subscribe (EVENT_TYPE abstraction using agents)
-=== SDD -- Software Design Document ===
-SDD -- Software Design Document
-  *See [[https://wiki.eecs.yorku.ca/project/sel-students/p:tutorials:sdd:start|SDD overview and templates]]
-  * Koopman and Toyota Unintended acceleration (see video and slides [[https://mediatech-stream.andrew.cmu.edu/Mediasite/Play/7c2451b6ec764be4bee295095a642c691d?catalog=35969fb7-4f63-4ebb-85d2-5b5a17a3b979|here]]). Note the need for testing, static analysis (typing) and the V model (see Lab3).
-=== Slides 12 ===
-Design Pattern: Decorator and Open-Closed Design Principle. Static Class Digram and Dynamic Sequence Diagram. See Code sample.
-=== Slides 13 ===
-Design Pattern: Composite. See code sample. UML inheritance (generalization) and client-supplier (associations, aggregation and composition).
-=== Slides 14 ===
-Design Pattern: Visitor. See code sample. Static and Dynamic sequence diagram.
-=== Slides 15 ===
-Design by Contract and Exceptions. An exception is a violation of the contracts not a normal sequencing mechanism. The problem with using exceptions in place of preconditions in Java, C# etc. (a) An exception is the negation of the precondition, but is the precondition that the client needs to know. (b) An exception may appear in a Java interface (e.g Arithmetic-Exception), but is it is non-specific. It does not document for the client how it could have been avoided.
-=== Slides 16 ===
-Correctness: (a) Hoare logic and (b) Design by Contract and loop variants and invariants. %%(c)%% **Tolerant** (involving defensive programming) and **Demanding** routines, depend on the strength of the preconditions. (d) The difference between **abstract algorithms** and their **program implementations**.
-[[https://bertrandmeyer.com/2014/12/07/
-lampsort/|Lampsort]]. Algorithms such as Quicksort are normally presented too close to implementation (e.g. as a recursive routine). But Quicksort is really a divide-and-conquer at the abstract level that can be refined to a recursive, iterative or concurrent implementation. Eiffel (and loop variants/invariants) can describe the more **abstract algorithm** rather than its too **detailed implementation**.
-The Eiffel method treats the whole
-process of software development as a continuum; unifying
-the concepts behind activities such as requirements,
-specification, design, implementation, verification,
-maintenance and evolution; and working to resolve the
-remaining differences, rather than magnifying them.
-Formal specification languages look remarkably like
-programming languages; to be usable for significant
-applications they must meet the same challenges: defining a
-coherent type system, supporting abstraction, providing
-good syntax (clear to human readers and parsable by tools),
-specifying the semantics, offering modular structures,
-allowing evolution while ensuring compatibility.
-The same kinds of ideas, such as an objectoriented
-structure, help on both sides. Eiffel as a
-language is the notation that attempts to support
-this seamless, continuous process, providing tools
-to express both **abstract specifications** and **detailed
-implementations**.