Course Outline

This is an old course outline. It will be updated as the course proceeds.

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. Try out some examples and use the debugger.

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.

Required Readings: Chapters 7-8. Classes - Objects

Required Readings: Chapters 10 (Genericity) and Chapter 11 (Design by Contract up to and including Section 11.11)

Slides: Finish 03 slides. For code to try out, see bank_account#.zip in the SVN. The basic concepts in these slides include:

• The importance of Requirements – happy customers
• Specifications (contracts) vs. Programs
• Design by Contract (DbC)
• What is Design?
• Information Hiding Principle (hide design decisions)
• Uniform Access Principle
• Test Driven Development (TDD)
• Reference vs. Object Comparisons
• Generic Paremeters
• Using ESpec for TDD
• Using the EiffelStudio IDE for code browsing, debugging, contract view, flat view, full view, generating documentation.

Bank User Requirments R3 and R4 are used to explore

• Design by Contract (DbC)
• Test Driven Design (TDD)
• Object (~) vs. Reference (=) comparison

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

On Wednesday we finished the 04 series of slides. Examples of DbC. What does it mean for a class to be correct? Proof obligations. Contracts induce proof obligations. Theorem proving versus run-time contract checking. Loop invariants (as opposed to class invariants) and variants for loop termination.

After the Monday lecture is an exercise Lab in Prism.

Readings: Finish Chapter 11, chapter 26 (A sense of style). You must read chapter 26 before the labtest so that you know how to use the Eiffel style for good self-documentation of code. See Resources for additional notes on Tuples and Agents.

Monday lecture: From the 06 slides – tuples and agents for functional programming in an OO style. Agents are used for creating operations that accept function or command routines as agents e.g. in creating general purpose opeartions that compute the integral of a function, or universal and existenial quantification, or GUI callbacks.

Wednesday lecture: Finished the 06 slides: BON predicate logic and the use of agents in a contracts for a sortable array using the counting quantifier.

Monday lecture: Labtest1

Wednesday Lecture: Cancelled by the university due to snow.

Required Readings: Exception handling ch. 12.1 to ch 12.5 in OOSC2.

N.B: Simoddysey Exercise (polymorphism, static typing, dynamic binding, design patterns) handed out (see SVN) in preparation for Labtest2.

Monday Lecture: 05 slides. Object_oriented = ADTs + inheritance. Illustrating ADTs with a geometric point (rectangular and polar coordinates). Converting mathematical ADT (e.g. POINT) into a computational class POINT. Reference versus Expanded types. Equal/twin and deep_equal/deep_twin. Advantages/disadvantages of aliasing. Persistence/STORABLE.

Wedesday Lecture: Reviewed Labtest1. Choosing between inheritance and client-supplier relationships. Started the the 07 slides. Open-closed principle up to and including slide 14.

Required Readings: Chapters 14 and 15.

Monday Lecture: 07 slides continued. Open-closed principle. Polymorphism, static typing and dynamic binding. Redefinition/subcontracting in the presence of inheritance. Using inheritance well.

Design Pattern: Multi-panel interactive systems

Required Readings: Chapters 15 and 16.

Required readings: Chapter 21. Inheritance case study. Command pattern and the undo/redo pattern in an interactive system.

Monday: Labtest2 on SimOdyssey

Wednesday: The idea of design patterns. Designs/Architectures that support reliability, extendibility and reusability. The command design pattern (Chapter 21) used in SimOdyssey. Design Pattern: Multi-panel interactive systems. The importance of analysis classes such as STATE. The law of inversion in finding the right classes. We also dicussed the project, in particular how to understand the input to the program.

Required Readings: Chapters 17, 20

Monday: 09 slides. Challenge Design Question. Answer: Strategy Design Pattern. Design Principle: Encapsulate what Varies. Design Principle: Program to an Interface not to an Implementation. Libraries as “code resuse” and Design Patterns as “experience reuse”. UML Class diagrams and BON Class Diagrams.

Wednesday: A Design challenge was handed out in class (scene editor). Answer: template pattern. Singleton Pattern with a contract to enforce the singleton. Illustrates Mondays design principles. Discussion of the stripped down version of the Project (TWR and MWR). Question: how would you write a contract to specify TWR and MWR?

Required Readings: Chapters 18, 22, 24

Design Patterns: Adapter and Composite Patterns

Design Patterns: Decorator Pattern.

UML static and dynamic diagrams.

We also reviewed DbC. Defensive programming versus non-defensive programming (and when to use the latter or the former). Loop variants and invariants. Exceptions and DbC. Rescuse clauses. Hoare logic for regular calls and Hoare logic for rescue clauses. See chapters in OOSC2 ob DbC.

Design Patterns: Observer, Visitor

Readings from OOSC2: Chapter 1 on Software Reliability. Chapter 3 on Modularity.The BON approach. The Osborne curve and desigining for quality.

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 exercises and labtests, 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.

We are looking for architectures that support Reliability, Extendibility, and Reusability.

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