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/03/24 18:47] 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 71: 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?+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 ======  ====== Tuples and Agents ======
Line 84: Line 84:
  
  ====== DbC: Exceptions ======  ====== DbC: Exceptions ======
-See slides and OOSC2+See slides and OOSC2. How to make software products robust. 
 + 
 + ====== Quality First ====== 
 +See the Osmonde curve and the slides.
course_outline.1364150857.txt.gz · Last modified: 2013/03/24 18:47 by jonathan

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki