CSS 343: Notes from Lecture 1 (DRAFT)

• course web site
• syllabus
• administrivia
• Software Engineering
• complexity theory (performance)
• software complexity (cognitive load)
  • abstraction
  • modeling

Introduction

• modern programming languages implement the data structures studied in this course, either as part of their standard library or some contrib repository (e.g. CPAN)
  • chances are, you will never have to code your own Red-Black tree
• technicians make library calls
• software engineers make library calls but have deeper understanding of what is being called, how it works, and what the tradeoffs are
• important to study these structures because they form the foundation of our problem-solving toolkit.
• pragmatically, for better or worse, DS&A form a reference frame for job interviews.

Goals

• deep understanding how data structures & algorithms work
• understanding how complexity is managed via layered abstractions
• object-oriented concepts
  • what problems are they trying to solve
  • how do they work
  • how and when to use them
• introduction (only) to library/STL (Standard Template Library)
• programming dexterity
  • pointers & recursion

Nongoals

Important stuff that is outside the scope of the course:

• project management
  • team programming
  • agile (fad or real value?)
    • see Fred Brooks, Mythical Man Month, "No Silver Bullet"
• "professional" C++ Programming
  • STL
  • advanced idioms
  • input validation & sanitization
  • internal consistency checking
  • internationalization (I18N)
• concurrency
  • threading
  • networking
• Linux (assignments will be on Linux machines, so you should pick up some useful stuff up by osmosis)
• software devleopment processes & techniques
  • source code control
  • build systems
  • testing frameworks (unit, integration, regression testing)

Talking Points

• software engineer vs. technician
  • there are professional roles suited for a technician and roles suitable for a software engineer
  • the UWB CSS program is about software engineering
    • deeper understanding
    • ability to learn new tools & techniques on your own
• software engineering (SWE) vs. computer science (CS)
  • CS is a math degree
  • SWE is about building and maintaining software systems
  • SWE:CS is roughly equivelent to engineering:physics
  • CSS 343 is Computer Science for Software Engineering students
• abstraction
  • software systems are complex (complicated, cognitive load)
  • abstraction is our technique for managing complexity
  • concept is so important, we use many terms
    • modeling
    • interface/implementation
    • infrastructure
• terminology overload: same word can mean different things (try not to get confused)
  • complexity
    • run-time performance (asymptotic complexity, big-oh)
    • cognitive load

CSS 342 Review

• C++
  • classes
• sorting/binary search
• linked lists, stacks, queues
• pointers/recursion
• analysis of algorithms, big-oh notation
  • recurrence/induction

Complexity Theory

• runtime performance (as function of input size
  • time, e.g. T(n)
  • space
• big-oh: asymptotic performance
  • general shape of curve
  • how things scale
  • upper bound f(n) = O(g(n) iff f(n) ≤ c0 * g(n) for n > n0
  • lower bound f(n) = Ω(g(n) iff f(n) ≥ c1 * g(n) for n > n0
  • tight bound f(n) = Θ(g(n) iff f(n) = O(g(n)) and f(n) = Ω(g(n))
  • identites
  • hierarchy of complexity
    • O(log n)
    • O(n)
    • O(n log n)
    • O(n ** 2)
    • O(n ** 3)
    • O(2 ** n)
  • experimental data how various algorithms perform (Skiena)
• best/worst/average cases: generally need to consider set of all possible inputs

Complexity & Abstraction

• use abstraction to manage complexity
• modeling
  • all models are imperfect because details are folded out
  • some models are useful
  • utility of a model depends on its application
    • model of an airplane:
      • parts or inspections for a maintenance system
      • seats for an airline reservation system
      • position, altitude, speed for air traffic control system
    • Earth is flat—if you're building a house
• interface/implementation
  • interface is public part
  • interface is private/hidden part
  • information hiding is not a security feature
    • perfectly valid (if questionably tasteful) C++ can access hidden part
      • breaking the abstraction may be necessary/expedient to solve some problem
      • breaking the abstraction is likely to be a hack (in the sense of "one who builds furniture with an axe") or kludge
        • refactoring to remove kludges and make systems more maintainable
      • may be useful to access hidden part for some test harness or other development tool
  • information hiding is tool to manage complexity (you don't need to worry about these details right now)
  • good abstractions facilitate maintenance by isolating the effects of changes
    • e.g. change the internal representation of Point from Cartesian to polar coordinates without changing the external behavior