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.

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.

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.

• 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

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

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

Contracting with math libraries (MSL)

Readings: Chapters 14. inheritance.

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.

Design Patterns: Template Method, State

Design Pattern: Multi-panel interactive systems

Readings: Chapter 20

Multiple Inheritance

Readings: Chapters 15

Inheritance Techniques

Readings: Chapters 16

How to find the classes - Using Inheritance Well

Readings: Chapters 22,24

Design Patterns: Adapter, Composite

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.

Design Patterns: Observer, Visitor

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

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