interface a Java contract From designing to coding 1 st step: - PDF document

interface – a Java contract From designing to coding � 1 st step: sensibly split work among team � So write the interfaces members � Formalizes much of the contract – Choose splits along “thin” interfaces – Precisely defines available services (methods) � Probably not equal parts; split biggest parts again later – But pre- and post-conditions are not insured – Formalize the interfaces – think of them as contracts � These are communicated by documentation only – Write least-coupled parts first … most-coupled last � Implement class and client class independently � i.e., classes that don’t depend on any other classes – Can even compile clients (but cannot fully test) � Oh yeah, one more thing to think about: � Note: maybe change an interface to a class later Reserve ample time for testing! – e.g., client developed using interface A – okay to replace with class A later javadoc comments Pre- and post-conditions � The most important points to document � “Cheap” external documentation � Pre-conditions – what the client is responsible for – Handy way to share just a class’s interface with team � Should always use to document all public declarations – – The “requires” clauses of the contract classes, instance variables, methods � Especially include any restrictions on calling arguments – Easy way to communicate pre- & post-conditions � Also any associations that should already exist � Even ready to post on the web (or intranet) � Post-conditions – what will be accomplished by – Easily kept up-to-date – just recompile with javadoc the operation if the pre-conditions are met after completing each class – The “effects” and/or “modifies” contract clauses � Learn to use javadocs – then make them a habit � Including all side effects (objects created/destroyed, associations formed/broken, attribute values modified) – See any Java text (often in an appendix though) � Also should state any exceptions that might be thrown – And/or see Sun’s javadoc how-to pages Converting designs into code Defining attributes and methods public class SalesLineItem { � Largely a direct translation of key artifacts private int quantity; – Class specs – variables and method definitions public SalesLineItem(ProductSpecification spec, int qty) { ... } – Class and package diagrams – associations public Money getSubtotal() { ... } � Translate to instance variables and/or method arguments } – Interaction and state-chart diagrams – method calls and sequences � Still involves creativity, and probably change ProductSpecification SalesLineItem – Good ideas often arise during coding – okay, go for it description : Text Described-by quantity : Integer price : Money � But also plan to revise design artifacts to match later 1 itemID : ItemID * getSubtotal() : Money ... 1

Implementing interactions – e.g., Translating associations enterItem(id, qty) { public class SalesLineItem ProductSpecification spec = catalog.getSpecification(id); Simple attribute { private int quantity; sale.makeLineItem(spec, qty); } private ProductSpecification productSpec; Reference attribute public SalesLineItem(ProductSpecification spec, int qty) {... } enterItem(id, qty) 2: makeLineItem(spec, qty) public Money getSubtotal() { ... } :Register :Sale } ProductSpecification 1: spec := getSpecification(id) SalesLineItem description : Text Described-by quantity : Integer price : Money * 1 itemID : ItemID :Product getSubtotal() : Money Catalog ... Least- to most-coupled order Use your resources 7 Store Uses � i.e., “don’t reinvent the wheel” if possible 1 1 address : Address 1 2 name : Text 3 ProductSpecification ProductCatalog – JDC Tech Tips, Java user groups, &c – see web addSale(...) description : Text Contains ... price : Money 1 Looks-in 1 1 * 1.. itemID : ItemID – See books like Effective Java (by Joshua Bloch) getSpecification(...) ... Houses for lots of useful advice 1 5 Describes 1 1 � On a real project: consider 3 rd party Sale 6 * Register 4 date : Date SalesLineItem isComplete : Boolean solutions, existing code, other quick fixes ... Captures time : Time Contains quantity : Integer 1 1.. * endSale() 1 1 becomeComplete() enterItem(...) getSubtotal() – Of course, we hope you do yourself in CS 50 makeLineItem(...) makeNewSale() makePayment(...) makePayment(...) getTotal() � And don’t wrestle with revision control 1 * 1 4 Payment Logs-completed Paid-by problems – use a revision control system amount : Money 1 ... Revision control problem Lock-Modify-Unlock Solution 2

Copy-Modify-Merge Solution: 1 Copy-Modify-Merge Solution: 2 e.g., Subversion – an open source Continued and widely used next slide revision control Testing – goal is to find faults When are faults introduced? � Faults (a.k.a. bugs) cause systems to fail � During requirements analysis – e.g., a system crashes – the most obvious type of fault – Incorrect, missing, or unclear requirements � During domain analysis and system design – e.g., a security system that allows unauthorized entry – Incorrect or unclear translation of problem – e.g., a shot-down plane that continues on its flight path – Incorrect or unclear design specification � Can verify the presence of bugs, not their absence � During system implementation � Testing and debugging are separate processes – Misinterpretation of system design Note how naïve to – Testing identifies faults – Incorrect syntax or semantics consider this the – Debugging corrects/removes faults only source of bugs � Even during testing � But it can also introduce new ones, so retesting is required – New faults introduced when old ones corrected Testing steps Unit and integration testing � Unit testing – insure each part is correct � Test parts of the system before the whole – Each method of each class of each package should be – Units – test basic parts (methods, classes, packages) tested independently – Integration – test basic connections between parts � Integration testing – insure parts work together � Requires special purpose test programs � System testing – i.e., “driver” programs and “stubs” – Functional tests – a.k.a. use case testing – Or can use a framework – Performance tests – test system attribute requirements � e.g., JUnit – by Erich Gamma and Kent Beck � Java note – any class can have a main method – Acceptance tests – client hands-on testing – Installation tests – final platform testing (on-site) – Can use just for testing all parts of that class 3

System testing phases Tragic truth: testing takes time � Use case testing � But it can save time and money in the long run – Test pre- and post-conditions of system – Get in the habit: “code a little, test a little, …” functions � Inadequate testing costs lots of real world $$$ and maybe lives – Best if independent of the user interface � Fact: costs of testing/debugging increase as � i.e., also requires special purpose testing code development progresses � Performance, acceptance, installation tests – Cheapest during requirements analysis (especially if – All involve the complete working system, an impossible requirement is uncovered) GUI and all – Cheaper during unit than integration testing, … � If any changes to code – rerun all tests Remaining “lecture” plan and student responsibility summary Monday Wednesday Friday Week 2/15 – 2/17 – 2/19 – No lecture; 1st 7 Holiday Exam implementation due 2/22 – 2/24 – 2/26 – 8 3 Presentations 3 Presentations 3 Presentations 3/1 – 3/3 – 3/5 – 9 3 Presentations 3 Presentations 3 Presentations 3/8 – No lecture; 3/10 – Evals; 3/12 – No lecture; 10 Demonstrations work on project final project due 4