A study of design methods and their use in the correct implementation, maintenance and evolution of software systems. Topics include design, implementation, testing, documentation needs and standards, support tools. Students design and implement components of a software system. Weekly 1.5 hour laboratory (starting 2017). Prerequisites: General prerequisites; including SC/MATH 1090 3.00; LE/EECS 2031 3.00.
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:
1. Specification: Describe software specifications via Design by Contract, including the use of preconditions, postconditions, class invariants, loop variants and invariants
2. Construction: Implement specifications with designs that are correct, efficient and maintainable.
3. Testing: Develop systematic approaches to organizing, writing, testing and debugging software.
4. Analysis: Develop insight into the process of moving from an ambiguous problem statement to a well-designed solution.
5. Architecture: Design software using appropriate abstractions, modularity, information hiding, and design patterns.
6. 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.
7. Documentation: Develop the ability to write precise and concise software documentation that also describes the design decisions and why they were made.
The suggested textbooks should help you do self-paced learning, a requirement for this course. The lectures, Labs, assignments and Project will exercise your understanding that you should develop by reading and working on your own.
TOC is an introductory text for computer science that covers the topics you normally do in EECS1020/1030/2011 using Java, except that TOC uses Eiffel. It has some more advanced topics such as DbC, multiple inheritance, functional programming, etc. that you may not have seem in your first two years. TOC is highly recommended and you can read it online via the York university Library. The main page of this course wiki also directs you to online lectures and slides for TOC. OOSC2 is on reserve in Steacie.
See the 591 slides of BigEiffel.pdf in the SVN, for a summary of the language and design features.
Readings:
Topics covered in class using the slides include:
is_equalClass included a demo of compile time void safety checks
Iterator (with across construct for quantifiers in contracts) and Singleton Pattern
OOSC2 chapters 14, 15, 16 and 17
OOSC2 and chapter 20
Tuples and functional programming (lambda calculus and agents)
SDD – Software Design Document
Design Pattern: Decorator and Open-Closed Design Principle. Static Class Digram and Dynamic Sequence Diagram. See Code sample.
Design Pattern: Composite. See code sample. UML inheritance (generalization) and client-supplier (associations, aggregation and composition).
Design Pattern: Visitor. See code sample. Static and Dynamic sequence diagram.
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.
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.
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.