Agenda (54 slides in one hour)

1. Agenda (54 slides in one hour) • New curriculum recap; where we are now (5 min) – Dan • CSE311: Foundations of Computing I (8 min) – Martin • CSE331: Software Design and Implementation (8 min) – Mike • CSE332: Data Abstractions (8 min) – Dan • CSE351: The Hardware/Software Interface (8 min) – Gaetano • CSE390A: System and Software Tools (4 min) – Marty • Next steps (5 min) – Dan • Career tracks (6 min) – Dan • ABET process to start in fall (8 min) – Gaetano

2. Timeline • Jan-May 2009: Weekly meetings, emails • May 2009: “Approval in principle” • October 8, 2009: Faculty approval • Spring 2010: 4.25 new courses • Martin, Mike, Dan, Gaetano • Plus Marty/student in 390A • Turn 2-3 page overviews into 4-credit courses! • Taught each quarter henceforth • AY 2010-2011: 4 more new courses • 2 in Fall, 2 in Spring • And flush old pipe: 1x322, 2x378 Fall 2010 – Spring 2013: 4xx students with old & new 3xx • 4xx instructors should start planning now: talk to us!

3. 331 Sw Design / Impl 344 Data Management 332 Data Abstractions required CS & CompE software required CompE required CompE hardware required 311 Foundations I 341 Programming Languages 312 Foundations II not required pre-req co-req or pre-req STAT391 351 Hw/Sw Interface 352 Hw Design / Impl Signal Conditioning (EE) 333 Systems Programming

4. Who is worried about what? • Students & advisors: Degree requirements, especially in transition • Faculty: What we are teaching at the 300-level • As 400-level instructors: • May need “extra meeting with TA” due to “transition gap” • Permanent adjustment (“10-15%”) to new 300-level • As 300-level instructors: for consistency and improvement • Needs to remain reorganized and more modern • Consistency has some inherent value • But of course we learn from experience • Instructors for each course should meet! (I can help) • 30 minutes from now: What else the students need from you

5. For more information • Today’s presentations focus on individual courses • For additional background and relevant links: www.cs.washington.edu/homes/djg/curriculum_overview_for_faculty.html (Feedback welcome)

6. Courses

7. CSE 311: Foundations of Computing I • Goals • Understand the discrete math underlying all of CSE • Develop ability to reason correctly • Develop ability to follow and construct proofs

8. Topics Used in: 312 352 312 332 312 331 332 332 312 331 332 312 331 332 352 352 312 • Logic • Basic proof techniques • Sets, functions, and relations • Basic number theory • Induction proofs • Graphs: just the definition • Combinational circuits • Finite-state machines • Computability 311 = 321 – {counting, graph theory} ⋃ {circuits, finite-state machines, computability} Good media for simple proofs (mod arith., primes, RSA)

9. Lessons • What works • Topics build nicely on each other • Proofs are simple enough that students learn a rigorous style • RSA cryptosystem as a fun application of number theory • Tantalizing references to fame via topical open problems • What doesn’t work • Like 321: • Too many topics, necessarily covered superficially • Difficult to motivate (“Trust me, you’ll need this next year.”) • Difficult to retain (“Too bad you’ll have forgotten it by next year.”) • Textbook: Rosen, Discrete mathematics and its applications • Applications weak, examples and exercises contrived and boring • New edition every couple years, with material shuffled • Expensive

10. CSE 331: Software Design & Implementation Goal: Enable students to • manage complexity • ensure correctness • write small programs

11. CSE 331 topics • Manage complexity: • Abstraction • Specification • Modularity • Program design/organization • Sub-typing • Documentation • Ensure correctness: • Reasoning • Testing • Debugging • Write programs: • Practice and feedback • Introduction to: software process, requirements, usability, teamwork, understanding libraries

12. Teaching tools • Learn by doing • realistic tasks • avoid indirect measures of competence • give opportunities to fail and to succeed • "Re-turnin" • after TA feedback, debug and re-submit assignments • all-or-nothing grading on resubmission • motivates documentation, testing, debugging, reasoning • Cross-checking of tests • run each student's tests against each student's code • Weekly programming assignments build to a single project • less and less scaffolding each week • see a bigger system, use design patterns • be proud of a result

13. What worked • Lecture material / topics • relevant to jobs • mostly new to CSE • Readings • Effective Java • Pragmatic Programmer • handouts (need more) • Rigor • students really “get” the material • much faster completion times on subsequent tasks • Use of research tools

14. Growing pains • Students were not prepared • Assignments took too much time • The plan • six 1-week assignments • one 3.5-week group project • Change of plan • canceled the project • added two assignments • In the future: • easier problem set sequence, or • cancel the project • Students under-used the TAs • A 55-person class is not efficient

15. CSE332: Data Abstractions Catalog Description: Abstract data types and structures includingdictionaries, balanced trees, hash tables, priority queues, and graphs; sorting; asymptotic analysis; fundamental graph algorithms including graph search, shortest path, and minimum spanning trees;concurrency and synchronization; and parallelism. Goals: • Deep understanding of core data-structure trade-offs • Fluency with asymptotic complexity, exponentials, etc. • Ability to analyze correctness (?) and efficiency • Recognizing basic opportunities for parallelism • Addressing challenges of concurrent access to resources

16. Topics: Data structures + Threads 326 & 332 (20 lectures) Big-Oh, Algorithm Analysis Binary Heaps (Priority Qs) AVL Trees B Trees Hashing Sorting Graph Traversals Topological Sort Shortest Paths Minimum Spanning Trees Amortization

17. Topics: Data structures + Threads 326 & 332 (20 lectures) Big-Oh, Algorithm Analysis Binary Heaps (Priority Qs) AVL Trees B Trees Hashing Sorting Graph Traversals Topological Sort Shortest Paths Minimum Spanning Trees Amortization Removed from 326 (8 lectures) D-heaps Leftist heaps Skew heaps Binomial queues Splay trees Disjoint sets Network flow Hack job on NP (moves to CSE312)

18. Topics: Data structures + Threads 326 & 332 (20 lectures) Big-Oh, Algorithm Analysis Binary Heaps (Priority Qs) AVL Trees B Trees Hashing Sorting Graph Traversals Topological Sort Shortest Paths Minimum Spanning Trees Amortization Added to 332 (8 lectures) Multithreading Basics (1) Fork-Join Parallelism (3) • Using Java library • Analysis: T1 and T  • Amdahl’s Law • Reductions, Prefix, Sorting • Concurrency (4) • Races, deadlocks • Locks (mostly) • Condition variables (a bit) • Programming guidelines (!)

19. What works • Triage 30% without killing the patient • Plus pretty deep scrub of other 70% • Projects use more modern Java (generics, iterators, JUnit) • Still keystone course with algorithms, code, proofs, and charts • Parallelism and concurrency in this course • Natural fit (!): same notion of trade-offs, asymptotics • Example: Sequential cut-off • Example: Bounded buffer for condition variables • Example: Amdahl’s Law in the limit • Data structures & algorithms are canonical examples • Divide-and-conquer, atomic operations, etc. • All at the Java / pseudo-code level

20. What might not work • No textbook for parallelism and concurrency (no complaints?) • Aimed for “teachable by others,” but never quite sure • 1.5 / 3 new projects and lots of new slides • No disasters, but could use some sanding • Due to project scheduling, graphs in weeks 6 and 10 • Did not fit: map/reduce, declarative queries • Leave to (optional) CSE344

21. CSE351 – The Hardware/Software Interface • How does the hardware (0s and 1s, processor executing instructions) relate to the software (Java programs)? • Programmer’s perspective on computing system abstractions • What are these abstractions and what does a programmer need to know? • What bugs can they cause and how do you find them? • What tradeoffs are being made that may change for a new technology? • Key abstractions • How to represent data in bits • Mappings, stacks, bookkeeping • Locality and caching • Processes and virtual memory • High-level language support CSE477/481 Capstones CSE451 OpSystems CSE466 EmbSystems CSE352 HW Design CSE333 Systems Prog CSE401 Compilers CSE461 Networks CSE484 Security Execution Model Performance DistributedSystems Concurrency Machine Code Real-TimeControl Comp. Arch. CSE351 CS 143 Intro Prog II

22. The three “little” themes of CSE351 • Representation • Numbers, characters, strings, addresses,pointers, data structures, … • Memory organization, virtual memory • Translation • Java/byte-codes, C/assembly, machine code • How do we move between them? • Control Flow • Stack discipline • Illusions of parallelism • Interrupts, traps, faults

23. Outcomes • Understand implementations details of some important abstractions • E.g., caching (caches, virtual memory, TLBs) • E.g., stacks (parameter passing, return values, recursion) • E.g., high-level (Java) vs. low-level languages (C) vs. assembly language • Become more effective programmers • More efficient at finding and eliminating bugs (heavy use of GDB, both asm and C) • Understand some of the many factors that influence performance • Programming assignments • Manipulate number representations (manipulate number representations in C) • Defuse a bomb by disassembling a program (read assembly code) • Implement stack overflow exploits (write assembly code) • Implement malloc and free (in C) • Written assignments (problems from text) • numbers, compilation, caches, virtual memory

24. Lessons • What seemed to work • Textbook: Computer Systems, A Programmer’s Perspective • Bryant / O’Halloran and wonderful complete set of materials • Choice of topics to cover (some tweaking required) • Reasonable workload for a quarter • Teaching C as a more readable assembly language • Java as an example of a high-level language • Practical work on each of the key concepts • representation, translation, and control flow • Alternating programming and written assignments • Using attu for all the programming (single environment to get right) • What could improve • 3-hour weekly lab: one hour review/discussion, two hour practicum • Learn how to use tools together (Linux, GDB, disassembler, etc.) • I’m sure we’ll hear a lot more from student evaluations

25. CSE 390A: System and Software Tools • Major Topics • setting up and navigating a Unix/Linux environment • connecting to remote servers and using multi-user shared Unix systems • permissions, groups, and users • using a Unix command-line shell • Unix file system; file/directory management; process management • pipes and redirection • string and text processing basics: filtering, substituting, etc. • regular expressions and related tools • Bash shell scripting • compiling/executing programs from a command line;compilation management tools (make, ant) • version control basics (subversion)

26. CSE 390A Example assignment tasks • hw1 (basics): Basic Unix commands: Copy/list/rename/delete/view files • hw2 (basics 2): More Unix commands; Combining commands with > < | • hw3 (attu): Connect to the attu server; examine processes/users/etc. • hw4 (users/groups): Set a group of files to have particular permissions. • hw5 (shell scripts): mantra (repeated text), filestats (print file info) • hw6 (Bash scripts): A grading script that diffs/scores student programs. • hw7 (regexes): Find all words in /usr/share/dict/words that match a given pattern (example: strings of at least 5 vowels in a row). • hw8 (make): Download/compile/run open source software using make. Write a Makefile and an Ant build.xml file. • hw9 (svn): Check out contents of a known SVN repo, make changes, add files, and check them in. Create a SVN repo with given properties. • Quick reflections • bad: Limited help; only 1 lecture/week; easy to make it too hard/long • good: TA Josh Goodwin; student HW eval surveys; loose collab. policy 26

27. Next steps

28. 331 Sw Design / Impl 344 Data Management 332 Data Abstractions required CS & CompE software required CompE required CompE hardware required 311 Foundations I 341 Programming Languages 312 Foundations II not required pre-req co-req or pre-req STAT391 351 Hw/Sw Interface 352 Hw Design / Impl Signal Conditioning (EE) 333 Systems Programming

29. Next year CSE312: Foundations of Computing II • Counting, probability, properties of random variables • Applications, central-limit theorem, statistics • P, NP, NP-completeness Fall: Lee, Winter: Ruzzo, Spring: Domingos To be determined: Lots, including working with STAT to evolve STAT391 to be complementary

30. Next year CSE352: Hardware Design & Implementation • Lab-intensive course • Circuit-design, processor-design, and systems integration • Uhm, obviously not too much of any one • Lean on CSE351 and CSE311 for quick start Fall: Ebeling, Spring: Hemingway To be determined: Lots, may use same book as CSE351 (?)

31. Next year CSE333: Systems Programming Still working out how to describe the goals of this course: • it has aspects of teaching C/C++ programming • also aspects of teaching systems-software issues like performance, caching, and asynchrony Optional for most students, but recommended for 400-level courses that are C and/or systems-level Spring: Gribble

32. Next year CSE344: Introduction to Data Management Currently many students are taking CSE444 databases because they want to use databases or manage large data sets • CSE344 will meet a growing need and let CSE444 be more about database design/implementation Spring: Suciu

33. Lots of thank-yous and a segue… • Hundreds (thousands?) of hours of thought and discussion • 8 faculty teaching a course that’s never been taught before • Paul figuring out a stranger-than-usual teaching schedule • Advisors getting students into the right place • … All part of a much more flexible major In fact, a little too flexible for students who need guidance…

34. Advice from faculty Our students have very diverse interests and career goals • The advice each student needs is varied and unlimited But that’s no excuse for not having rough guidelines: “If you want to do X after you graduate, then course Y is especially important.” What we provide today: • Degree requirements: and they just got more flexible • Results from a 12-person, 5-minute survey at Affiliates’ Day • Our advisors’ best guesses • Nothing from faculty (frankly not doing our job for most students) Some day we’ll have “tracks”, but we need advice first

35. Current Students

36. Information for Current Undergrads

37. Career Information

38. Course Planning for Specific Careers

40. One example: Hardware Designer good enough great, but some too generic bizarre mish-mash

41. What we need • A new web page with advice from faculty • Organized similarly • Revised list of career paths (about 15, not all possible) • List of highly recommended courses • List of other recommended courses • Plus an “outlet” for other advice not specific to a career path • The plan: • Huddles give us raw data from a simple template • Deadline: July 15 • We’ll collate, fill in gaps however I want , and web-ify

42. Career paths Current list Backend Developer Embedded Systems Developer Game Developer Hardware Designer Project/Program Manager QA / Test Engineer Software Engineer Systems Operator Technical Writer Test Engineer Web / Internet App Developer UI Designer Missing? Data Miner? Computational Biologist? Security? Ph.D. student … But: • Idon’t want one career path per faculty member • What to do to be a PL faculty member doesn’t belong here

43. Course advice • Highly recommended = a course people in the field all need • No such thing as “too obvious” (e.g., 440 for UI design) • Other recommended = definitely important, but remember students take 4-9 400-level courses total and need flexibility • Making it too long dilutes influence • What I don’t want here: generic or biased advice! • I think everyone ought to take compilers, but that’s my personal opinion, which doesn’t belong in guidelines that line up careers with courses

44. Outlet Conjecture: Faculty are incapable of restraining themselves from generic advice outside of the template Conjecture: Sharing generic advice would be a great help to students So: I’ll also make a “general advice” web page • Initial state: Whatever any huddle sends me, lightly edited • Pre-publish: Call for faculty input / discussion • Guideline: Anything “controversial” gets removed • This ought to be the stuff so obvious we’re surprised it needs saying. Example: Technical writing/presentations

45. Next steps • (1) A long email with instructions and an example template • (2) You find 1 hour to look over our course list and fill out the template with colleagues • Should work fine over email • Email me the output and I’ll iterate with you a bit • (3) When nobody does (2) , I do it all myself and then you complain about the results • Go to step (2) • (4) Web-site up by start of Fall Quarter • Thank you!

46. ABET

47. ABET • Accreditation Board for Engineering and Technology • Accredit our Computer Engineering Program • As well as all other BS degrees in CoE • Six year cycle (last site visit was 2007) • Fall of 2013 will be next visit to UW • Believe it or not, it is time to get ready again • Lots to do over next 3 years – need to start now • Document our improvements and feedback cycle • Collect evaluation materials from our courses • Prepare new self-study • Big opportunity and lots of work because of our new curriculum

48. Major changes since last visit • New CompE requirements, some more to come • New undergraduate core curriculum at 300-level • These will require • Documenting why we did it, how well it is working • Student focus groups? Document course iterations and why? • Mapping new curriculum to ABET outcomes • We are in flux and may need multiple maps

49. Weaknesses • Multi-disciplinary teams (criterion d) • Especially ethics and societal implications (criterion f) • Knowledge of contemporary issues (criterion j) • High work-to-credit ratio in many of our courses • Better documentation of feedback loops • Better documentation of input from stakeholders

50. Curriculum to Outcome Mapping