Slides

S1: Overview of C++

S2: 1.6 Life Cycle of Software

Mythical Man-Months & Software Crisis (OS/360 project)
Large software system is developed in several phases
- Problem Analysis: What is the problem?
- Design: Solution components.
- Coding
- Testing
- Maintenance and Documentation
C++ based software systems
- Requirements Document (e.g. Huffman.ps)
- Design: set of class headers
- Coding: set of class implementations
- Testing: "make test" using drivers, testcases
- Documentation: comments, report
Csci 3321 focus is on Coding phase
- With awareness of Design and Testing
- Csci 5180 (Software Eng.) discusses other phases.

S3: 1.7 Testing C++ Classes

Motivation: Quality Assurance, Legal Responsibility.
- Tort - expects best effort from producer to protect the clients.
Quality Assurance for Software
- Testing
- Inspection and Walk-throughs
- Formal verification
Levels of Testing
- Unit Testing - test each class in isolation using drivers, stubs
  - Driver: a program to test another program (e.g. Wtree_test.C)
  - Stub: a program to simulate another program
- Integration Testing: test multiple classes together
  - Bottom-Up - test Wtree before Huffman
- Designing Test Cases
- Black-Box - based on expected input/output behavior
- Glass-Box - based on the code
  Caution: Testing can only show the presence of bugs,
  not the absence of bugs.

S4: File Naming Convention for Csci 3321

We adopt a convention from the Industry
- Each class is tested independently using a driver
- Groups of classes are tested together using drivers
- main() is like a driver for all classes
A set of files for each class
- classname.h - class header
- classname.C - external definition of member functions
- classname_test.C - driver to test the class
- classname_test.?.inp / .exp - testcases for driver
Example: ~lixx0075/3321/lab2
- Class TreeList has (1) TreeList.h, (2) TreeList.C
  (3) TreeList_test.C, (4) TreeList_test.exp, (5) TreeList_test.inp
- Class Wtree has (1) Wtree.h, (2) Wtree.C
  (3) Wtree_test.C, (4) Wtree_test.exp, (5) Wtree_test.inp

S5: Using Predefined Classes

Common Steps
- Read header file and sample input/outputs
  - Ex. WTree.h
- Classes are different from functions
  - Persistent state (previous operations matter)
  - Multiple operations (member functions)
- Examine many sequences of operations
- Ex. Stack [HN pp 207]
  - create, push(2), push(3), push(4)
  - create, push(2), pop(), top()
- Ways of Reuse
- As types - instance of the class
- As components: class code{ ... TreeList L; ... };
- To derive new types - via inheritance
- A family of types - via templets
Caution: Do not use private names
- Watch for inherited functions, polymorphism

S6: 1.2-3 Object Oriented Concepts

< object, class, message, inheritance, polymorphism >
Objects
- encapsulates - visibility boundary
- instance of an ADT: has state variables and operations
- responds to messages
Class = type + object
- template for a set of instance objects
- Is also an object (static members)
- instance variables/operations, class variable/operations
  Q? Why have class variables and class operations?
Message = procedure call
- Message is directed to an object
- Has parameters, returns result

S7: 1.4-5 O. O. Concepts: Reuse via Inheritance.

Related classes, Common properties = > repeated code
class underGrad {
public: int id(); String name();
String internship();
};
class grad {
public: int id(); String name();
String TA_ship();
};
/* ... */ grad G; cout << G.id() << G.TA_ship();
Inheritance reduces duplicated code across related classes
data members (grad) = local one UNION inherited one
member functions (grad) = local one UNION inherited one
Model using inheritance
Create a parent class with common components
Leave the unique part inside individual classes
class Student { public: int id(); String name(); };
class underGrad : Student { public: String internship(); };
class grad: Student { public: String TA_ship(); };
/* ... */ grad G; cout << G.id() << G.TA_ship();

S8: O. O. Concepts - Inheritance Vs. Composition

S9: 1.9 O. O. Concepts - Polymorphism.

Polymorphism = overloading + late binding
Overload = Use one name for multiple meanings
- Conflict resolution based on context
- Compile-time: number of parameters, parameter types
- Run-time: actual recipient object
Late binding = conflict resolution at run-time, not at compile time
- C++ keyword "virtual" allows late binding
- Useful in program with class inheritance hierarchy
Example: Parent class: Student; Derived classes: grad, underGrad
- grad and underGrad INHERIT from Student
- Distinct virtual Student::print(), underGrad::print(), grad::print()
- The body of "print" is unique to each class
Q? Which print method will be used under late-binding?
Student S; grad G; underGrad U; Student *T;
T = &S; T- > print() ; // Actual class of T* changes at run-time
T = &U; T- > print() ;
T = &G; T- > print() ;
Q? Redo the above exercise with compile-time ambiguity resolution.