1 / 16

CompSci 230 Software Construction

CompSci 230 Software Construction. Course Revision S1 2014 V1.1 of 2014-06-17: revealed MCQ% and SA% on final exam. Overview. In Stage 1, you learned how to write programs to solve small problems. In CompSci 230, we teach programming “in the large”.

rusk
Download Presentation

CompSci 230 Software Construction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related