CompSci 230 Software Construction

1. CompSci 230 Software Construction Course Revision S1 2014 V1.1 of 2014-06-17: revealed MCQ% and SA% on final exam

2. Overview • In Stage 1, you learned how to write programs to solve small problems. • In CompSci 230, we teach programming “in the large”. • Large software systems have many stakeholders. • What will its users want? • Can we describe user requirements, accurately and succinctly? • Large software systems are very complex. • Can we describe the design of a complex software system, accurately and succinctly? • Can we be sure that a complex system will do what it is designed to do, and that it will not do anything unintended? • In CompSci 230, you learned some incomplete answers to these difficult questions. • I also attempted to teach you how to “learn how to learn” the technical skills you will need in the future – as a competent computer professional. CompSci 230

3. Syllabus • Four Themes: • A. The object-oriented programming paradigm • Object-orientation, object-oriented programming concepts and programming language constructs – because, for many important problems, OO design is a convenient way to express the problem and its solution in software. • B. Frameworks • Inversion of control, AWT/Swing and JUnit – because many important “sub-problems” have already been solved: these solutions should be re-used! • C. Application-level concurrent programming • Multithreading concepts, language primitives and abstractions – because even our laptops have multiple CPUs. Quad-core smartphones are now available. • D. Software quality • Testing, inspection, documentation – because large teams are designing, implementing, debugging, maintaining, revising, and supporting complex software. CompSci 230

4. Theme A: The OO Design Paradigm • Object-orientation, object-oriented programming concepts and programming language constructs – because, for many important problems, OO design is a convenient way to express the problem and its solution in software. • Topics (by lecture): • 01: Software Construction • 02: Use Cases • 03: OOD • 04: Class Diagrams • 05-07: Java Implementation CompSci 230

5. Software Construction • Review (or learn for the first time?) • What is Object-Oriented Programming? • Related objects in classes. State + behaviour. Instantiation. Comparison with procedural and data-architectural styles of programming. • Classes & Objects • Message passing by calls, returns, and exceptions • Variables & Methods (for instances and classes) • Introduction to OO Design • A process: • determining what the stakeholders require, • designing a set of classes with objects which will meet these requirements, • implementing, and • delivering. • You learned two new languages: • Use-case diagram, for requirements • Class diagram, for design • Object diagram, to explain “what’s happening” in an implementation • not emphasised, but may be very helpful for your understanding CompSci 230

6. Use Case Diagrams • Learning goals for this unit: • Interpretative: Any student who passes CompSci 230 can accurately interpret the information presented in a use-case diagram or description. • Productive: Any student with a B or better in CompSci 230 can draw up an accurate set of use cases from an informal specification. • Creative: Excellent CompSci 230 students are able to apply their course-specific knowledge in novel situations. For example, they could discuss the strengths & weaknesses of use case analysis as a methodology for requirements capture. • Note: I cannot test a students performance on all topics, at all levels, in an hour. • The final exam has some questions that are focused at A-level, some at B-level, and some at C-level. I won’t reveal the levels at which topics are tested. • Some topics won’t be tested atall, but I won’t reveal which ones. • Such incomplete (and secret) coverage allows a limited range of quality-assurances e.g. • Any student who knows all important topics “at B level” will get a B. • Some B/C-level students will “get lucky” – they’ll also get a B. • Students who have only C-level knowledge will get a C. • It is impossible to write in a language if you can’t read it. You must be able to read & write in order to express novel thoughts. CompSci 230

7. OOD & Class Diagrams • Abstraction: • The ability of a language (and a designer) to take a concept and create an abstract representation of that concept within a program • Information Hiding: • How well does this language, designer, and programmer hide an object’s internal implementation? (Usually, implementations should be hidden…) • Polymorphism: • How does this language let us treat related objects in a similar fashion? • Inheritance: • The “is-a” relation: important for code reuse. • Composition, Aggregation, Association: • Types of “has-a” relations: ways to build complex classes from simpler ones. (I’m emphasising only the most general case: the “association”.) • Design guideline: Choose composition over inheritance (see Assignment 1) CompSci 230

8. Class Diagrams • Learning goals for this unit: • Interpretative: Any student who passes CompSci 230 can accurately interpret the information presented in a class diagram or a verbal description of a class . • Productive: Any student with a B or better in CompSci 230 can draw a class diagram for a simple design. • Creative: Excellent CompSci 230 students are able to apply their course-specific knowledge in novel situations. For example, they could discuss the strengths & weaknesses of a design decision in a class diagram. CompSci 230

9. Java Implementation • Interfaces and Abstract Classes • Important in practice, but not emphasised this semester. • Java’s type system: Static & dynamic typing, conversions. • Very important in practice, with a complex theory. • Visibility • Important in practice, but not emphasised this semester. • Enum types • Important for readability. (Practice in Assignment 1.) • Java’s runtime system • A very “deep” topic. We skimmed over memory allocation. • Object identity, assignment, equality, copying, cloning, … • Very important in practice, with a straightforward theory if you understand instantiation (which is moderately complex: object diagrams might help). Not emphasised this semester. CompSci 230

10. Theme B: Frameworks • Inversion of control, AWT/Swing and JUnit – because many important “sub-problems” have already been solved: these solutions should be re-used! • You learned some concepts (Frameworks, GUI design principles) as you studied the specifics of AWT/Swing. • You learned how to lay out a GUI, using AWT/Swing classes and methods. • You had some practice (in a homework assignment) with developing a simple GUI. CompSci 230

11. Learning Outcomes: Theme C • Demonstrate a “theoretical understanding” of multi-threaded computations • Hand-execute a simple multi-threaded program (“B” level) • Analyse a program to discover consistency defects (“A” level) • Competently develop, maintain, and test a multi-threaded program • Modify the threading behaviour of a simple program e.g. the Dining Philosopher applet (“B” level) • Accurately diagnose a deadlock condition (“A” level) • Demonstrate proficiency with the basic concepts and vocabulary of concurrency in Java • Be able to define and use common terms and keywords e.g. synchronized, volatile, lock (“C” level) Revision

12. Theme D: Software Quality • Demonstrate a “theoretical understanding” (A-level) of testing • Discuss the role of testing in “famous failures” (Ariane, LAS, INCIS) • Evaluate a test suite, with reference to Myers’ principles • Competently perform some test-driven development tasks • B-level exam questions: write a unit test, specify a test suite. • Homework, tutorials: some experience with JUnit and SVN. • Demonstrate a basic (C-level) understanding (by defining or using) the fundamental concepts and standard terminology of software quality: • Validation testing, defect testing, unit test, component test, system test, XT, XP, inspection, … CompSci 230

13. Theories of Software Quality • Myers’ ten principles: don’t memorise these! • I’ll be testing your “working understanding” (not a rote-recital) of the fundamentals of software testing. If you are able to “test like Myers would test”, then you have a good foundation for developing your own style, and for adapting your style to “fit in” with your team. • Myers’ definition of software quality: • … does what it is supposed to do, and doesn’t do anything unintended… • XP is a method which is based on a theory (or belief) that • Software quality is assured by a simple process which focusses on communicating, testing, refactoring, and seeking feedback. • XT is a method which is based on a theory that • Unit testing and acceptance testing are sufficient to assure quality, if testing is done continuously and carefully within an XP process. CompSci 230

14. Examining Myers’ theory • At “C” level: basic understanding, terminology • E.g. : Briefly explain how stakeholder communication is handled in XP. • At “B” level: application • Generating black-box tests (from a specification) • Generating white-box tests (from an implementation) • Evaluating a test suite, e.g. for coverage of boundaries or paths • At “A” level: interpretation, extension, criticism, appreciation • E.g. : When you are unit-testing a Java module, should you confirm that the runtime type-enforcement system is preventing this module from being invoked on incorrectly-typed input? • Only a strong student will identify the relevant issues in such a question. • Weaker students should try for partial marks! • “C” students should repeat a memorised definition for a term in the question, and be awarded up to 50% of marks -- if they don’t write something absurd, irrelevant, or incorrect. • “B” students should discuss a specific test case, perhaps drawing on their experience in Assignment 4. A student who writes a JUnit test case which invokes CreateImageIcon( (int) 2 ) with an expectation of it throwing a runtime error or exception would be showing an inadequate understanding of Java’s static type-checking, but would demonstrate a good understanding of the sort of invalid input that should be tested (according to Myers). • “A” students will realise that JUnit tests which don’t compile are quite different to JUnit tests which throw runtime exceptions on unexpected inputs. A strong student might produce a brief argument for, or against, the proposition that the unit you’re testing “should” include all of the JVM modules that are invoked when the method is called in this case. I think there are valid arguments on both sides of this proposition… and the lack of a single “correct” answer is common in “A” level questions in a “soft topic” like this one. CompSci 230

15. Final Exam • The final examination covers all parts of COMPSCI 230, • with an emphasis on themes A, C, and D. • We did not emphasise implementation issues in Theme B (frameworks) in this offering of the course. However we do expect you to understand the underlying theory and the overall design of AWT/Swing. • The examination is not comprehensive. • Mike and I can’t test everything we covered this semester, in a 2 hour exam. • This year’s examination differs significantly from prior exams in COMPSCI 230. • Some prior exams were all multiple-choice. Some were all short-answer. • Some prior-year examination questions are directed at assignments you haven’t done. • You worked heavily with class diagrams in Assignment 1. The last time I taught Theme A, my first assignment was focussed on use-case diagrams. This difference affected my lecturing, the midterm, and the examination. • Some prior-year examination questions are directed at lecture slides you haven’t seen. • I’m the only COMPSCI 230 instructor who uses the Myers text in the software-quality theme. • Some instructors emphasise AWT/Swing implementations (rather than GUI design theories) in the Frameworks theme. • This year’s examination will be 50% multiple-choice and 50% short-answer. • You will answer our multiple-choice questions on Teleform sheets. If you haven’t used these sheets recently, you should read https://www.cs.auckland.ac.nz/courses/compsci111s1c/TeleformInstructions.pdf. • Suggested revision strategy: • Do not revise from prior year exams. • Revise by “active learning”, i.e. by making up your own questions from this semester’s lecture slides and assignments, trying to answer these questions, and discussing these with classmates. • I will not answer your email questions about course content, sorry. I cannot provide individual tuition to 215 students. • I will not answer your email questions about “what will be examined”. Now is your last chance to ask questions! CompSci 230

16. Best wishes, and please keep in touch! • I have enjoyed teaching this course. • I’d enjoy hearing from you in the future. • Please don’t hesitate to “volunteer yourself” to give a guest lecture to a future CompSci230 class! CompSci 230