• Note that the slides are in the SVN (accessed from the menu at the left).
• Some of the syntax in the textbook OOSC2 is outdated. See 00-W13-BigEiffel.pdf (in the SVN) for summary slides and the current syntax. The online text “Touch of Class” also uses the current syntax.
• Complete documentation and Eiffel Tutorials here and here

Learning Outcomes:

Software products are programs developed by one team to be used and maintained by others. The original development team may not be around to maintain the product. Students are thus expected to understand how to develop software so that it is:

1. Correct
2. Efficient
3. Maintainable

Software cannot be correct without a specification. So we need to master skills that allow us to write a specification, and we must also understand how to read, understand, and implement a specification that we receive from others. For precision, specifications will often require the use of mathematics. Design by Contract and Unit Testing are fundamental skills needed to achieve correctness. So we need to understand how to use Design by Contract to specify software via meaningful preconditions, postconditions and class invariants; given these, we have a precise notion of the correctness of a class (or module). Software is reliable if it is correct (works according to specification) and robust (reacts appropriately to abnormal conditions).

For software to be efficient we need to understand the appropriate use of algorithms and data structures. Loop variants and invariants help to ensure that loops terminate, bound their complexity, and ensure that they terminate correctly.

Maintaining code is often the main cost of producing a software product, i.e. a product that will be used over a period of time by our customers. A disorganized essay is not easy to read. Likewise disorganized code will be hard to maintain, especially where the original development team is no longer around. So how do we develop well-designed code? This is where modularity, good ADTs/API's, Information Hiding, and Design Patterns enter the picture. Object oriented software construction provides high level design capabilities via inheritance, polymorphism, static typing and dynamic binding; thus understanding objected oriented software construction at a deep level is a fundamental design skill. Ultimately, the software design document must document these design decisions to allow others to maintain the product.

• Required readings:
  • OOSC2 Chapter 7 (classes/compile time/static structure),
  • OOSC2 Chapter 8 (objects/runtime/dynamic structure),
  • OOSC2 Chapter 11 up to and including Section 11.9 (Design by Contract),
  • The following are short:
    • OOSC2 Chapter 26 (A sense of style)
    • OOSC2 Section 27.7 (BON Notation)
• Background reading: Chapters 1, 2
• Topics
  • Classes and Objects
  • DbC (Design by Contract)
  • ESpec/TDD (Test Driven Development)
  • BON diagrammes
  • Style/Cosmetics matter
  • Slides 01 and 02
• Exercises
  • Use the Eiffelstudio IDE to do a Hello World example
  • Use the IDE to do the Bank example. See: SVN → Code → bank-account-problem.zip
  • Learn how to use ESpec and the debugger

• Required reading: Chapter 10/Genericity in OOSC2
• Slides 02-03
• EiffelStudio Demo: BON diagrams (including compressed and expanded class interfaces), use of the debugger with ESpec unit testing and documentation production
• Iterator Design Pattern and the Eiffel across construct for loops and predicate quantification (slides 03)
• Abstract Data Types (STACK[G] and POINT). Partial functions (mathematics) and preconditions.
• For the full BON notation and the use of predicate logic, see BON book

• Required reading: Chapter 6/ADTs and Chapter 8 (shared data and once routines)
• Slides: 04-05
• The official text on design patterns, available at Steacie: Design Patterns: Elements of Reusable Object-Oriented Software by the Gang Of Four: Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. Head First Design Patterns By Eric Freeman, et. al. is an interesting read.
• Iterator (with across), Singleton and Factory Method Design Patterns. Program to interfaces and not to implementation. Identify the aspects of your application that vary and separate them from what stays the same.
• Single Choice Principle, Expanded and Reference Types, reference and value semantics (equality, twin and deep_twin). See OOSC2.
• When is a class correct? (see OOSC2)

• Required reading: Sections 11.9 to 11.16 in OOSC2. Loop invariants, and variants. Chapter 12, exception handling.

• Required reading: Chapters 14 and 15 in OOSC2 on inheritance and multiple inheritance. Chapters 16 and 7.

• Multi-panel interactive systems (OOSC2, Ch. 20)
• Singleton pattern
• Iterator Pattern
• Strategy Pattern
• Visitor Pattern. See Visitor Pattern in Eiffel. Also, see section 6.14, pages 606-613, in “Touch of Class”, Springer, available in Steacie.
• Decorator Pattern
• Visitor Pattern
• Composite, Adapter, and Facade

We stress information hiding (as in famous paper by Parnas) and the criteria by which to decompose a system into modules. What are the features? Which features belong together coherently in a module (class)? How are modules related to each other (client supplier and inheritance relationships)? How are modules grouped into clusters? What is the system architecture? How do we choose between one design and another?

Functional constructs & programming. See the slides.

See slides and OOSC2

See slides and OOSC2. How to make software products robust.

See the Osmonde curve and the slides.