CSE3311

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Course Outline ======

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: 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 =====

A problem is presented (the user requirements for a banking system). The problem is used to discuss Design; Specifications (contracts) vs. Implementations; Test Driven Design(TDD) and the ESpec unit testing tool.

A contract specifies the benefits and obligations of clients and suppliers. Contracts induce proof obligations. Theorem proving versus run-time contract checking.

== Design questions ==
  * What modules are needed to satisfy the User Requirements?
  * What are the public features of the modules?
  * How are the modules organized to work together (e.g. via associations and inheritance)? Later in the course we will amplify this question via a study of Design Patterns.

What does it mean for a class to be correct? Proof obligations.

**Required Readings**: Chapters 7-8. Classes - Objects

===== Week 3  =====

**Readings**: Chapter 10 -  11-1 .. 11-9. Genericity - Design by Contract

See C-slides and code ''bank_account3'' in the SVN. User Requirments R3 and R4 are used to explore
  * Design by Contract (DbC)
  * Test Driven Design (TDD)
  * Object (~) vs. Reference (''='') comparison
  * Up to slide 41
 

===== Week 4  =====

 **Readings**: Chapters 11-11, 11-12, chapter 26. See Resources for additional notes on Tuples and Agents.

Monday is an exercise Lab in Prism. 

  * From the C slides: Information hiding (LIST[G] with generic parameter G)
  * aliasing, twin and deep_twin
  * Tuples and Agents




===== Week 5 =====

Contracting with math libraries (MSL)

**Readings**: Chapters 14. inheritance.

===== Week 6 =====

Complete contracting with math libraries (MSL).

Readings: Execption handling ch. 12.1 to ch 12.5 in OOSC2. See the material in the code directory.

===== Week 7 =====



**Design Patterns**: Template Method, State

===== Week 8 =====

**Design Pattern**: Multi-panel interactive systems

**Readings**: Chapter 20

Multiple Inheritance

**Readings**: Chapters 15

===== Week 9 =====

Inheritance Techniques

**Readings**: Chapters 16

How to find the classes - Using Inheritance Well

**Readings**: Chapters 22,24

===== Week 10 =====

**Design Patterns**: Adapter, Composite

===== Week 11 =====

**Design Patterns**: Decorator. (We usually cover the command pattern as well, but it was left out due to the fact that the term was compressed; howver, the multi-display pattern uses the command pattern, in part).

UML static and dynamic diagrams.

===== Week 12 =====

**Design Patterns**: Observer, Visitor

Readings from OOSC2: Chapter 1 on Software Reliability. Chapter 3 on Modularity. 

===== 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; 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. 

In Design we need to: 
  *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, 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 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.

  * 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).