CMPT 225

1
CMPT 225

• Data Structures and Programming

2
CMPT 225 Topics

• Software Development Process
• Software Life Cycle
• Abstraction, Decomposition and Encapsulation
• Specification and Testing
• Data Structures and Abstract Data Types
• Arrays and Linked Lists
• Stacks, Queues and Priority Queues
• Trees and Graphs
• Hash Tables
• Algorithms
• O Notation
• Recursion
• Sorting Algorithms

3
Course Objectives

• Develop problem solving techniques
• Use abstraction to design solutions
• Design modular programs
• Use recursion as a problem-solving strategy
• Provide tools for the management of data
• Identify abstract data types (ADTs)
• Examine applications that use the ADTs
• Construct implementations of the ADTs

4
What is a Good Solution?

• A good solution is cost effective
• To run (i.e. to perform its task)
• To develop and maintain
• Components of a solution
• Algorithms that specify methods to solve the
  problems
• Data structures to store the data and support the
  algorithms

5
Cost Effective Solutions

• Minimize the cost of the program
• Running costs
• Resources (computing time and memory)
• Interaction costs (e.g. poor GUI may result in
  the loss of business)
• Costs related to errors (e.g. loss of customer
  information, storing incorrect data, etc.)
• Development and maintenance costs
• i.e. costs related to the software life cycle

6
Software Life Cycle
Documentation
7
Software Life Cycle Phases - 1

• Specification
• Understand the clients problem and requirements
• Ensure that the requirements are clear and
  complete and understood by all stakeholders
• Design
• Plan the implementation of the applications data
  and operations
• Plan the testing
• Risk Analysis
• Verification
• Ensure that algorithms are correct
• Ensure that the design satisfies the requirements
  (validation)
• Implementation
• Write application and test code

8
Software Life Cycle Phases - 2

• Testing
• Verify that code works
• Verify that the code meets the clients
  requirements
• There are various types of testing, unit testing,
  integration testing, system testing, user
  acceptance testing
• Refining
• Production
• Package, distribute and install application and
  train users
• Maintenance
• Add features
• Fix bugs
• Documentation
• Common to all the phases of the life cycle
• Includes the user manual

9
Software Life Cycle and CMPT 225

• We are primarily concerned with three phases of
  the life cycle
• Design
• Implementation
• Testing

10
Example Bank Accounts

• The Toronto Domination bank wants an application
  to handle its customer accounts
• You are to design this application
• What do you need to know?

11
Design

• The goal is to design a modular solution, using
  the techniques of
• Decomposition
• Abstraction
• Encapsulation
• In Object Oriented Programming this is done by
• Identifying the objects in the problem and
• Determining how the objects interact with each
  other

12
Modular Design Decomposition

• Simplify a complex problem by dividing it into
  smaller, simpler parts (modules)
• Modules should be loosely coupled and
• Highly cohesive
• The purpose, inputs and outputs of each module
  and method should be specified
• This specification should not include a
  description of the implementation
• Different programmers can work on different
  modules

13
Modular Design Abstraction

• Abstraction separates the purpose of a module
  from its implementation
• The implementation details are ignored (or
  suppressed) to concentrate on the purpose of a
  module
• Procedural abstraction
• Separates the purpose of a method from its
  implementation
• Can be specified in pre and post conditions
• Data abstraction
• Specifies what can be done to data in a data
  collection, not how it is done
• Specified in the description of an abstract data
  type

14
Modular Design Encapsulation

• A decomposition technique where a complex object
  is decomposed into modules which have a separate
  and distinct purpose
• i.e. highly cohesive
• Because a module is a complete entity with one
  purpose it can be re-used in another application
• This allows each module to be relatively
  independent from the others
• i.e. the modules are loosely coupled
• This also makes it easy for different people to
  work on different modules at the same time
• Because modules are independent their inner
  details can be hidden from each other
• Referred to as information hiding
• To use a module one is only required to learn its
  interface, rather than its entire implementation

15
Object Oriented Design

• An object combines data and operations on that
  data
• data class variables
• operations methods
• Three principles of Object Oriented Design
• Encapsulation discussed earlier
• Inheritance discussed later in the course
• Polymorphism discussed later in the course

16
Object Design Identify Objects

• Identify objects
• Identify objects that exist in the problem
  statement and requirements
• Typically, select nouns, ignoring irrelevant
  ones, such as synonyms
• Look for relationships amongst the (real-world)
  objects that were identified
• Generalization relates to inheritance
• Containment where one object contains another
• Multiplicity determine the quantity
  relationships between objects (e.g. one bank can
  have many accounts)

17
Object Design Identify Operations

• Identify the operations of objects
• Typically, select verbs, ignoring irrelevant
  ones, such as actions performed by the user
• Associate each operation with the object that is
  responsible for providing the behaviour
• Note that an object should be responsible for
  modifying its own data

18
Object Design Create Interface

• An interface should be created for each object
  that is to be represented by a class (rather than
  a variable)
• The interface describes how the class can be
  used, by specifying its public operations
• There are a number of ways of creating
  interfaces, e.g.
• C Header files
• Java Interface
• An interface should include
• Class invariants (conditions that must be true
  for an object)
• Public methods, for each such define
• Parameter lists
• Return type
• Purpose (i.e. a description)
• Pre and post conditions

19
Class Invariants

• A class invariant is an invariant on the values
  of the variables of an object, For example
• Account balance is always gt 0
• Account ID numbers are unique and cannot be
  modified
• All object constructors and mutators should
  respect class invariants
• That is, they should always make sure that class
  invariants are true

20
Pre-Conditions

• A pre-condition is an assertion about conditions
  at the beginning of a method
• An assertion is a statement about a condition
• More generally a declaration that is made
  emphatically (as if no supporting evidence were
  necessary)
• It is part of the "contract" implicit in a method
• If the pre-conditions are not true then the
  method is not guaranteed to produce the desired
  results
• e.g. for binary search, there is a pre-condition
  that the array or list being searched is sorted,
  it is not, there is not guarantee that the
  correct result will be returned
• Or, to put it another way, that the
  post-conditions will hold

21
Post-Conditions

• A post-condition is an assertion about conditions
  at the end of a method
• The post-conditions describe the state after the
  method has been run
• They therefore describe the desired output of a
  method
• To prove that an algorithm is correct we need to
  prove that, if the pre-conditions are correct,
  following the steps of the algorithm will lead to
  the post-conditions
• We should be able to show how the each step of an
  algorithm leads to the post-conditions

22
Object Interaction Design

• Design the entire application by describing how
  the objects are to interact with each other
• One approach is to write a high level algorithm
  and then decompose it into several methods
• Each such method should have one specific purpose

23
Operation Design

• Each of the operations identified in the object
  design should be designed
• If possible, re-use previously written methods or
  functions
• Otherwise design algorithms to implement each
  operation

24
Test Design

• Determine how each class (or unit, or module)
  will be tested before writing the application
• Write unit test cases that test the entire range
  of input that can be given to a method
• Expected values
• Boundary values
• Invalid values
• For each input specify the expected result and
  when testing is performed compare this to the
  actual result
• Debug where necessary!

25
What makes a good program?

• Well structured
• Modular
• Modifiable
• Good style
• Includes program documentation
• Easy to use
• Efficient
• Degrades gracefully (fail-safe)
• Debugged