EECS3311

User Tools

Site Tools

You are here: EECS3311 - Software design - Winter 2017 » Course Outline
Trace:
course_outline

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
course_outline [2015/04/08 17:24] – jonathancourse_outline [2017/05/02 16:17] (current) – jonathan
Line 3: Line 3:
 ===== Calendar Description ===== ===== Calendar Description =====
  
-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. Prerequisites: General prerequisites; including SC/MATH 1090 3.00; LE/EECS 2031 3.00. +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. 
  
 ==== Learning Outcomes ==== ==== Learning Outcomes ====
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: 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. Describe software specifications via Design by Contract, including the use of preconditions, postconditions, class invariants, loop variants and invariants +1. **Specification**: Describe software specifications via Design by Contract, including the use of preconditions, postconditions, class invariants, loop variants and invariants
  
-2. Implement specifications with designs that are correct, efficient and maintainable.+2. **Construction**: Implement specifications with designs that are correct, efficient and maintainable.
  
-2. Develop systematic approaches to organizing, writing, testing and debugging software.+3. **Testing**: Develop systematic approaches to organizing, writing, testing and debugging software.
  
-3. Develop insight into the process of moving from an ambiguous problem statement to a well-designed solution (analysis).+4. **Analysis**: Develop insight into the process of moving from an ambiguous problem statement to a well-designed solution.
  
-4. Design software using appropriate abstractions, modularity, information hiding, and design patterns (design).+5. **Architecture**: Design software using appropriate abstractions, modularity, information hiding, and design patterns.
  
-5. 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. +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.
- +
-6. Develop the ability to write precise and concise software documentation that also describes the design decisions and why they were made.+
  
 +7. **Documentation**: Develop the ability to write precise and concise software documentation that also describes the design decisions and why they were made.
  
 ==== Topics ==== ==== Topics ====
Line 33: Line 32:
   * Debugging, Unit Testing and Test Driven Development   * Debugging, Unit Testing and Test Driven Development
   * Abstract Data Types, Modularity and Information Hiding   * Abstract Data Types, Modularity and Information Hiding
-  * Design Patterns+  * Design Patterns (Singleton, Iterator, Observer, Decorator, Visitor, Composite, Undo/Redo)
   * Documenting Design Decisions and demonstrating that code satisfies the design   * Documenting Design Decisions and demonstrating that code satisfies the design
  
-===== Detailed Topics =====+===== Detailed Topics from last year (2015W) =====
  
 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.  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. 
Line 62: Line 61:
   * What is a Class? It's static structure   * What is a Class? It's static structure
   * What is an Object? It's dynamic structure   * What is an Object? It's dynamic structure
-  * Representing system architecture via BON (and UML) class diagrams. +  * Representing system architecture via BON and UML class diagrams. 
   * Relationships between classes: Client-Supplier (associations) and Inheritance   * Relationships between classes: Client-Supplier (associations) and Inheritance
-  * Uniform Acces Principle (and information hiding) +  * Uniform Acces Principle and information hiding 
-  * Using Eiffel for DbC+  * Design by Contract in depth
   * Using the EiffelStudio Debugger for Testing, and ECF files for clusters and libraries   * Using the EiffelStudio Debugger for Testing, and ECF files for clusters and libraries
   * Using the EiffelStudio BON diagraming tool   * Using the EiffelStudio BON diagraming tool
Line 74: Line 73:
   * Void Violation Cases and Void Safety   * Void Violation Cases and Void Safety
   * What is Design? Architecture and Specifications   * What is Design? Architecture and Specifications
-  * The BON diagram notation for Architecture+  * BON and UML diagram notations for Design & Architecture
   * Information Hiding   * Information Hiding
   * Abstraction and abstract (deferred) classes   * Abstraction and abstract (deferred) classes
Line 149: Line 148:
 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**.  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 is almost the reverse: treating the whole+The Eiffel method treats the whole
 process of software development as a continuum; unifying process of software development as a continuum; unifying
 the concepts behind activities such as requirements, the concepts behind activities such as requirements,
course_outline.1428513851.txt.gz · Last modified: 2015/04/08 17:24 by jonathan