User Tools

Site Tools


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 [2013/02/24 15:45] jonathancourse_outline [2013/04/14 02:01] (current) jonathan
Line 7: Line 7:
 **Learning Outcomes**: **Learning Outcomes**:
  
-Understand how to develop software so that it is:+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:
   - Correct   - Correct
   - Efficient   - Efficient
   - Maintainable   - 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 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 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. 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.+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.
  
 ====== Basic concepts ====== ====== Basic concepts ======
Line 46: Line 46:
   * Iterator Design Pattern and the Eiffel **across** construct for loops and predicate quantification (slides 03)   * 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.   * Abstract Data Types (STACK[G] and POINT). Partial functions (mathematics) and preconditions.
 +  * For the full BON notation and the use of predicate logic, see [[http://www.bon-method.com/book_print_a4.pdf|BON book]]
  
 ====== ADTs, DbC and Correctness ====== ====== ADTs, DbC and Correctness ======
Line 70: Line 71:
   * Decorator Pattern   * Decorator Pattern
   * Visitor Pattern   * Visitor Pattern
-  * Some others+  * 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? 
 + 
 + ====== Tuples and Agents ====== 
 + 
 +Functional constructs & programming. See the slides. 
 + 
 + ====== Loop variants and invariants ====== 
 + 
 +See slides and OOSC2 
 + 
 + ====== DbC: Exceptions ====== 
 +See slides and OOSC2. How to make software products robust. 
 + 
 + ====== Quality First ====== 
 +See the Osmonde curve and the slides.
course_outline.1361720721.txt.gz · Last modified: 2013/02/24 15:45 by jonathan

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki