CMPT-201 - Data and Program Organization Professor: Bill Havens Office: APSC-10828 Lectures: MWF 2:30pm - 3:20pm Venue: C-9002 WWW: http://www.cs.sfu.ca/coursecentral/201 Office Hours: Monday @3:30pm January 5, 2004 Copyright 2003 by Bill Havens 1 of 17
from CMPT-201 Home Page... Course Details TAs Expectations for Assignments Assignment Marking Scheme Class Notes Homework Assignment Schedule GradeBook JavaDoc Online Resources Administrivia January 5, 2004 Copyright 2003 by Bill Havens 2 of 17
Software Engineering and Computer Science Comparison Close relationship Practical vs. Theoretical Computer Science Study of the natural laws of computation. Computer Scientists develop theories of computation (mathematics) programming languages (formal linguistics) communication (networks) data structures (information representation) algorithms (manipulating information) January 5, 2004 Copyright 2003 by Bill Havens 3 of 17
Software Engineering Real engineering! Concerned with Design of large software systems Implementation and integration Reliability and maintenance Concerns of the Computer Scientist theory abstraction Concerns of the Software Engineer design Data Structures in here January 5, 2004 Copyright 2003 by Bill Havens 4 of 17
Disclaimers This course is NOT about Software Engineering We will not consider software life cycles, design specifications, code reviews, quality assurance, maintenance, etc. This course is NOT theoretical Computer Science We will not consider theory of computation, programming language design or logic. Course Goals Learn to think recursively and abstractly Develop a vocabulary of program structures (both data and procedural) Think about the structure of the problem instead of the syntax. Understand the power of encapsulation (abstraction of data and behaviour) January 5, 2004 Copyright 2003 by Bill Havens 5 of 17
Course Topics Data Structures (the vocabulary of programming) Examples: strings, sets, stacks, queues, lists, hash tables, trees graphs. Abstract datatypes, modularization and reuse. Top-Down design process Object programming, extensible systems, public interfaces. Pointers and References (getting under the hood in Java) Garbage Collection (recycling used bits) January 5, 2004 Copyright 2003 by Bill Havens 6 of 17
Why Java? Other candidates: Assembler, C, Modula, Smalltalk, Lisp, C++ Uniform language for multiple courses Portable across all Operating Systems Sophisticated programming environment (eg- Swing, J2EE) January 5, 2004 Copyright 2003 by Bill Havens 7 of 17
Disclaimer about Programming Languages They are all bad! (so far) At best, a programming language is a vehicle for expressing computation (both structure and algorithm). Learn to think independently of any particular language. Learn to think 1. Recursively 2. Hierarchically 3. Abstractly January 5, 2004 Copyright 2003 by Bill Havens 8 of 17
Object Oriented Design (OOD) Basic Idea: use the Problem Description to discover the abstract objects in the problem. Describe the abstract objects formally Assign behaviour to the objects (anthropomorphism) to implement the desired system. Abstract classes of related objects from the abstraction Implement the classes in some OO language (e.g. Java) Example: Simulating a naval battle at sea Objects: ships, planes, guns, shells, missiles, etc. Behaviour particular to each class of object Many instances of each class Programming involves interaction of multiple instances January 5, 2004 Copyright 2003 by Bill Havens 9 of 17
Principles of OOD 1) Encapsulation: Objects combine data and behaviour Message passing semantics (from SmallTalk by Alan Kay) Objects respond to messages requesting information or behaviour Internal state of any object is not observable (and unimportant) Only external behaviour counts The message protocol of a class specifies the behaviour of every instance of the class Example: class Ship protocol heading(angle) speed(int) destination() January 5, 2004 Copyright 2003 by Bill Havens 10 of 17
2) Inheritance: Classes can inherit behaviour from other classes Complex behaviour can be inherited from other classes Extending a class by defining additional data and behaviour Parent class is called the superclass and the child class is called the subclass Example: BattleShip is a subclass of Ship class Ship protocol includes basic behaviour common to large boats class Battleship extends Ship by including war fighting behaviour class Battleship could be further subclassed as necessary January 5, 2004 Copyright 2003 by Bill Havens 11 of 17
3) Polymorphism: Objects determine their own behaviour Very powerful feature of OO Programming Sending a message elicits the behaviour of the receiving object Different objects will respond according to their own semantics Example: message destination(losangeles) has a very different meaning when sent to a Boat versus a Missile object January 5, 2004 Copyright 2003 by Bill Havens 12 of 17
4) Composition: Classes combine the data and behaviour of their component parts Complex systems are made of parts Recursive decomposition into a hierarchy of components Essence of TopDown Design Decompose complex systems into simpler components until each individual component can be adequately modelled and programmed. Example: class BattleShip Composed of many subsystems hull, steering, propulsion, armaments, airconditioning,... Each recursively composed of simpler components January 5, 2004 Copyright 2003 by Bill Havens 13 of 17
Style Basic Requirements 1. Well defined message protocol for each class 2. Hiding of internal private data fields 3. Extensive error detection and handling 4. Well layed out and readable code 5. Proper documentation (using JavaDoc) see Carrano&Prichard (p.33) see example java src file and javadoc (Havens) January 5, 2004 Copyright 2003 by Bill Havens 14 of 17
Software Testing Overview Important issue (both in industry and class) Goal: to find as many software errors as possible before release. Types of errors: 1. Syntax errors: detected usually by compiler (ex: pioneer spacecraft counter example) 2. Logic errors: program computes something different than specs. 3. Verification errors: mistake (or imprecision) in requirements spec. 4. RunTime errors: bad assumptions about the environment (hardware+software) 5. Maintenance errors: somebody doesnt understand your code. January 5, 2004 Copyright 2003 by Bill Havens 15 of 17
Testing Approaches Two basic approaches 1. Black Box: All viable inputs and expected outputs are tested. Useful for algorithms with predictable and tractable I/O. Expensive with large datasets Difficult with real-time or interactive systems. 2. Glass Box: All sections of the code are exercised. Design of code coverage testing plans. Unit testing of each module/object OOD relevant. January 5, 2004 Copyright 2003 by Bill Havens 16 of 17
Test Plans Three levels of testing 1. Unit Testing (as above) 2. Functional Testing (after system build) 3. Beta Testing (with help of clients) Test Plans Formal document describing procedures for validating software 1. Typical cases: run expected situations first 2. Extreme cases: try limits of intended function 3. Invalid cases: see what happens on nonsense cases (brittleness) We will only be concerned with Unit Testing and Functional Testing January 5, 2004 Copyright 2003 by Bill Havens 17 of 17