Differences

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

--- course_outline [2009/05/27 00:23] – 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 58: / Line 62: @@
 Complete contracting with math libraries (MSL).
-Readings: See the material in the code directory.
+Readings: Execption handling ch. 12.1 to ch 12.5 in OOSC2. See the material in the code directory.
 ===== Week 7 =====
@@ Line 104: / Line 108: @@
 ===== Final Exam =====
-The exam is closed book. A single data sheet (US letter size) will be allowed, but nothing else. Everything covered in class, in the slides, the project, the assignments, the required readings in the text (OOSC2), and the forum, is required for the exam. See wiki:resources for a link to test questions from previous years.
+The exam is closed book. A single data sheet (US letter size) will be allowed, but nothing else. Everything covered in class, in the slides, the project, the assignments, the required readings in the text (OOSC2), and the forum, is required for the exam. (See wiki:resources for a link to test questions from previous years; you may choose to do those that are relevant to the course outline here, but it is not required that you do them).
 Software development is a process of eliciting the customer’s desired Requirements (in the problem domain), coming up with a Design (in the solution domain) to satisfy the Requirements, and then to build an Implementation of the Design in code. The focus of this course is Design.
@@ 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 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}).
+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.
   * Contracts and tests are specifications that allow us to assess the correctness of the implementation, i.e. the code that implements a software component. Both classical contracts and MSL contracts are important tools. Without these tools we would have no way of knowing if our implementations are correct (i.e. satisfy their specifications). Also, our code must work in a hostile environment and contracts are an important tool for capturing environmental constraints and client needs from our User Requirements Document (such as in the Ariane-5 example, and the validity constraints on grades as in the Project).
   * Design Patterns. Another vital component of understanding Design is understanding some of the important design patterns. Good software developers have struggled with the same design problem that you may face – and they have already solved something like your problem. Knowing these road-tested patterns allows you take advantage of best practices and to communicate aspects of your design to others. BON/UML static and dynamic diagrams and contracts are useful for describing design patterns (for the exam, you must know BON class diagrams).