Differences

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

--- course_outline [2009/05/27 00:43] – jonathan
+++ course_outline [2011/01/05 18:15] (current) – jonathan
@@ Line 3: / Line 3: @@
 It is important to do all the readings associated with the course from the textbook. There are some items in the readings that we will not have time to cover in class, but this material may be on the exam.
-===== Week 1 =====
+===== Week 1: Jan 4=====
 Introduction - Administrivia.
 Models in Engineering. The Problem Domain (User Requirements) and the Solution Domain (System Specifications). Specifications are not programs, but something different. Design is the process that gets us from the Problem Domain to implemented code in the Solution Domain that satisfies the User Requirements.
+**Required**: get "hello world" program working in EiffelStudio.
+**Suggested reading**: OOSC2 chapters 1 and 3.
 ===== Week 2 =====
@@ Line 22: / Line 26: @@
 What does it mean for a class to be correct? Proof obligations.
-**Readings**: Chapters 7-8. Classes - Objects
+**Required Readings**: Chapters 7-8. Classes - Objects
-===== Week 3 (March 16th) =====
+===== Week 3  =====
 **Readings**: Chapter 10 -  11-1 .. 11-9. Genericity - Design by Contract
@@ Line 35: / Line 39: @@
-===== Week 4 (March 23) =====
+===== Week 4  =====
  **Readings**: Chapters 11-11, 11-12, chapter 26. See Resources for additional notes on Tuples and Agents.
@@ Line 111: / Line 115: @@
   *Specify a solution that satisfies the Requirements (e.g. via contracts and specification tests)
   * Decide what modules we need for the solution
-  * Choose an API (features and their signatures) for each module
+  * Choose an API (features, their signatures and contracts) for each module
   *Decide how to organize the modules (classes), e.g. via client-supplier and inheritance relations. BON diagrams
-  * Decide how to test that the final implementation satsifies the Specification and utimately the User Requirements.
+  * Decide how to test that the final implementation satisfies the Specification and utimately the User Requirements.
 Contracts, specification/unit tests, and BON class diagrams are important for describing the Design. Using contracts we can define what it means for a class to be correct (e.g. that the body B of every exported routine must satisfy {//Inv & Pre//} B {//Inv and Post//}). We can define an exception to be a state of affairs that breaks the contract (and is thus handled by a rescue clause). Also, contracts ensure that a subclass is guaranteed to satisfy the contracts of its superclass (subcontracting). Contracts also document the public interface of a class (via the contract view) thus contributing to information hiding.