Differences

This shows you the differences between two versions of the page.

--- course_outline [2015/03/25 22:51] – jonathan
+++ course_outline [2015/06/24 17:53] (current) – jonathan
@@ Line 9: / Line 9: @@
 Software designers are experts at developing software products that are correct, robust, efficient and maintainable. Correctness is the ability of software products to perform according to specification. Robustness is the ability of a software system to react appropriately to abnormal conditions. Software is maintainable if it is well-designed according to the principles of abstraction, modularity, and information hiding. At the end of the course, students will be able to:
-. Describe software specifications via Design by Contract, including the use of preconditions, postconditions, class invariants, loop variants and invariants
+. **Specification**: Describe software specifications via Design by Contract, including the use of preconditions, postconditions, class invariants, loop variants and invariants
-. Implement specifications with designs that are correct, efficient and maintainable.
+. **Construction**: Implement specifications with designs that are correct, efficient and maintainable.
-. Develop systematic approaches to organizing, writing, testing and debugging software.
+. **Testing**: Develop systematic approaches to organizing, writing, testing and debugging software.
-. Develop insight into the process of moving from an ambiguous problem statement to a well-designed solution (analysis).
+. **Analysis**: Develop insight into the process of moving from an ambiguous problem statement to a well-designed solution.
-. Design software using appropriate abstractions, modularity, information hiding, and design patterns (design).
+. **Architecture**: Design software using appropriate abstractions, modularity, information hiding, and design patterns.
-. Develop facility in the use of an IDE for editing, organizing, writing, debugging, testing and documenting code including the use of BON/UML diagrams for documenting designs. Also the ability to deploy the software in an executable form.
+. **Tools**: Develop facility in the use of an IDE for editing, organizing, writing, debugging, testing and documenting code including the use of BON/UML diagrams for documenting designs. Also the ability to deploy the software in an executable form.
-. Develop the ability to write precise and concise software documentation that also describes the design decisions and why they were made.
+. **Documentation**: Develop the ability to write precise and concise software documentation that also describes the design decisions and why they were made.
+===Commentary===
+A design for a software product is the combination of its specification (to verify its safety and correctness) and a suitable architecture (for maintainability). A design that is not correct cannot be a good design. A design that does not have a suitable modular architecture is not a good design.
+===Eiffel==
+Why do we use the Eiffel method in this course? The worldview underlying the Eiffel method is to treat the whole process of software development as a continuum; unifying the concepts behind activities such as requirements, specification, design, implementation, verification, maintenance and evolution; and working to resolve the remaining differences, rather than magnifying them. Anyone who has worked in both specification and programming knows how similar the issues are. Formal specification languages look remarkably like programming languages; to be usable for significant applications they must meet the same challenges: defining a coherent type system, supporting abstraction, providing good syntax (clear to human readers and parsable by tools), specifying the semantics, offering modular structures, allowing evolution while ensuring compatibility. The same kinds of ideas, such as an object-oriented structure, help on both sides. Eiffel as a language is the notation that attempts to support this seamless, continuous process, providing tools to express both abstract specifications and detailed implementations. One of the principal arguments for this approach is that it supports change and reuse. If everything could be fixed from the start, maybe it could be acceptable to switch notations between specification and implementation. But in practice specifications change and programs change, and a seamless process relying on a single notation makes it possible to go back and forth between levels of abstraction without having to perform repeated translations between levels. [Quoted from [[https://bertrandmeyer.com/2014/12/07/lampsort|here]]]
 ==== Topics ====
@@ Line 47: / Line 52: @@
 **Readings:**
-  * Design by Contract (Dbc)
-  * Hoare Logic
-  * Class correctness proof obligations
   *Suggested Reading: OOSC2 Chapter 1 and Chapter 3. See [[http://www.eecs.yorku.ca/course_archive/2014-15/F/3311/slides/14-Modularity.pdf|here]] for a brief summary.
@@ Line 94: / Line 96: @@
 === Slides 05 ===
+  * Design by Contract (Dbc)
+  * Hoare Logic
+  * Class correctness proof obligations
+=== Slides 06 ===
+OOSC2 chapters 14, 15, 16 and 17
+  * Inheritance, polymorphism and dynamic binding in design
+=== Slides 07 ===
+OOSC2 and chapter 20
+  *Multi-panael Design Pattern
+=== Slides 08 ===
+  *Eiffel Testing Framework (ETF) and acceptance tests
+  * ETF includes singleton, command, publish-subscribe and MVC design patterns
+=== Slides 09 ===
+Tuples and functional programming (lambda calculus and agents)
+=== Slides 10 ===
+  * Strategy design pattern
+=== Slides 11 ===
+  * Observer Design Pattern
+  * Event Based Programming and Publish-subscribe (EVENT_TYPE abstraction using agents)
+=== SDD -- Software Design Document ===
+SDD -- Software Design Document
+  *See [[https://wiki.eecs.yorku.ca/project/sel-students/p:tutorials:sdd:start|SDD overview and templates]]
+  * Koopman and Toyota Unintended acceleration (see video and slides [[https://mediatech-stream.andrew.cmu.edu/Mediasite/Play/7c2451b6ec764be4bee295095a642c691d?catalog=35969fb7-4f63-4ebb-85d2-5b5a17a3b979|here]]). Note the need for testing, static analysis (typing) and the V model (see Lab3).
+=== Slides 12 ===
+Design Pattern: Decorator and Open-Closed Design Principle. Static Class Digram and Dynamic Sequence Diagram. See Code sample.
+=== Slides 13 ===
+Design Pattern: Composite. See code sample. UML inheritance (generalization) and client-supplier (associations, aggregation and composition).
+=== Slides 14 ===
+Design Pattern: Visitor. See code sample. Static and Dynamic sequence diagram.
+=== Slides 15 ===
+Design by Contract and Exceptions. An exception is a violation of the contracts not a normal sequencing mechanism. The problem with using exceptions in place of preconditions in Java, C# etc. (a) An exception is the negation of the precondition, but is the precondition that the client needs to know. (b) An exception may appear in a Java interface (e.g Arithmetic-Exception), but is it is non-specific. It does not document for the client how it could have been avoided.
+=== Slides 16 ===
+Correctness: (a) Hoare logic and (b) Design by Contract and loop variants and invariants. %%(c)%% **Tolerant** (involving defensive programming) and **Demanding** routines, depend on the strength of the preconditions. (d) The difference between **abstract algorithms** and their **program implementations**.
+[[https://bertrandmeyer.com/2014/12/07/
+lampsort/|Lampsort]]. Algorithms such as Quicksort are normally presented too close to implementation (e.g. as a recursive routine). But Quicksort is really a divide-and-conquer at the abstract level that can be refined to a recursive, iterative or concurrent implementation. Eiffel (and loop variants/invariants) can describe the more **abstract algorithm** rather than its too **detailed implementation**.
+The Eiffel method treats the whole
+process of software development as a continuum; unifying
+the concepts behind activities such as requirements,
+specification, design, implementation, verification,
+maintenance and evolution; and working to resolve the
+remaining differences, rather than magnifying them.
+Formal specification languages look remarkably like
+programming languages; to be usable for significant
+applications they must meet the same challenges: defining a
+coherent type system, supporting abstraction, providing
+good syntax (clear to human readers and parsable by tools),
+specifying the semantics, offering modular structures,
+allowing evolution while ensuring compatibility.
+The same kinds of ideas, such as an objectoriented
+structure, help on both sides. Eiffel as a
+language is the notation that attempts to support
+this seamless, continuous process, providing tools
+to express both **abstract specifications** and **detailed
+implementations**.