course_outline
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
course_outline [2009/05/27 00:29] – 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. | 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. | 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. | 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**: | ||
+ | |||
+ | **Suggested reading**: OOSC2 chapters 1 and 3. | ||
===== Week 2 ===== | ===== Week 2 ===== | ||
Line 22: | Line 26: | ||
What does it mean for a class to be correct? Proof obligations. | What does it mean for a class to be correct? Proof obligations. | ||
- | **Readings**: | + | **Required |
- | ===== Week 3 (March 16th) ===== | + | ===== Week 3 ===== |
**Readings**: | **Readings**: | ||
Line 35: | Line 39: | ||
- | ===== Week 4 (March 23) ===== | + | ===== Week 4 ===== |
| | ||
Line 58: | Line 62: | ||
Complete contracting with math libraries (MSL). | Complete contracting with math libraries (MSL). | ||
- | Readings: See the material in the code directory. | + | Readings: |
===== Week 7 ===== | ===== Week 7 ===== | ||
Line 104: | Line 108: | ||
===== Final Exam ===== | ===== 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 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, |
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, | 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, | ||
Line 111: | Line 115: | ||
*Specify a solution that satisfies the Requirements (e.g. via contracts and specification tests) | *Specify a solution that satisfies the Requirements (e.g. via contracts and specification tests) | ||
* Decide what modules we need for the solution | * Decide what modules we need for the solution | ||
- | * Choose an API (features | + | * Choose an API (features, their signatures |
*Decide how to organize the modules (classes), e.g. via client-supplier and inheritance relations. BON diagrams | *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 | + | * Decide how to test that the final implementation |
Contracts, specification/ | Contracts, specification/ |
course_outline.1243384168.txt.gz · Last modified: 2009/05/27 00:29 by jonathan