Programming project Lecture 1

1. Programming projectLecture 1 Neil Ghani ng@cis.strath.ac.uk 1

2. Course aim • “To provide experience in the development of larger scale software, as an introduction to software engineering” • To allow you to demonstrate your ability • To design a system relative to a given specification • Related to programming techniques and systems analysis and design • To effectively code the design • Related to programming foundations and programming techniques • To test the code in an appropriate manner • To document the system • A technical description of the software • To manage all of the above 2

3. How • I will provide initial specifications for 5 systems • e.g. machine translation, search engine • You choose one • Cover these in next lecture • Develop a specification of your system • Develop a plan for the design, implementation, etc • Build a system to meet your specification • Test the system • Covered in testing lecture • Document the system in a formal report • Covered in writing lecture • Note: this is an individual exercise! 3

4. Prerequisites • Already you know • How to design • How to program (in Java at least) • Later classes will give experience in • Software correctness • Formal approaches to proving code is correct • Software quality • Techniques for designing and implementing quality software • This class is the opportunity to show what you have learnt already in a practical setting 4

5. Course details - lectures • 6 lectures • Lecture 1 :Introduction (this one) • Lecture 2 :Practical exercises • Lecture 3: Testing • Lecture 4: Writing • Lecture 5: Practical exercises revisited • Lecture 6: Open session • Intended to support practical work • All lectures will be on Tuesdays (K317) • Lecture notes and lecture dates at http://www.cis.strath.ac.uk/~ng 5

6. Course details practical work • NO EXAM! • 4 practical exercises • Revision practical • Finish off work from last semester especially stuff on binary trees and binary search trees • Initial practical (10%) • Warm-up • Week 6 • Assessed practical (90%) • Week 1 • Details of practicals and dates in next lecture • Labs start next week 2 6

7. Books • No required text! • Pressman R; Software Engineering: a practitioner’s approach, fifth edition, European adaptation, McGraw-Hill, 2000. • Van Vliet H; Software Engineering: Principles and Practice, Wiley, 2000. • Fenton N E, Pfleeger S L; Software Metrics: a rigorous and practical approach, Thomson Computer Press, 1996. • Schach, S. Object-oriented and classical software engineering (using Java and UML). 5th edition. McGraw-Hill • Sommerville, I. Software engineering. 6th Edition. Addison-Wesley • But probably want to invest in a Java book 7

8. Introduction • This course is about software engineering • How we build a software product and the process by which we build it • requirements & specification • design • implementation • testing and evaluation • maintenance • retirement • These steps are known as the software lifecycle 8

9. Requirements/specification • In this stage we decide • What tasks the system will perform • I will give minimal specification • e.g. Spell-checker • input: English dictionary • output : an list of those words in the input text which are not found in the dictionary • Also some hints and restrictions • Must use bst to store words in dictionary • Should allow user to add news words 9

10. Requirements/specification • You decide what else (if anything the system is to do) • E.g. does it have a gui? • how does it handle punctuation? • do users type in input text or does it come from a file? • What assumptions are you making about system? • This is your system • Minimal/better solutions 10

11. Requirements/specification • (Usually) we also consider language to be used • Hardware • Problem • Choose a language we know well? • Low cost, may choose wrong language • Choose the right language, but increase costs? • Experience of team • (your experience, demonstrator’s experience) 11

12. Specification decisions • Set criteria for end system • e.g. • Correctness – how well does it fulfil its function? • Efficiency – how well does it operate? • High correctness and efficiency cost money and take longer to build • Effort and cost must be appropriate to problem 12

13. Some criteria for correctness • Correct? • usually works? • e.g. telephones, cars, my pc • This may be acceptable, e.g. if works often enough • Spell-checker will detect most incorrectly words? • passes all tests attempted? • Need to define tests • Spell-checker will work under the conditions I specify? • guaranteed to work in all cases • Best but is it appropriate? • Spell-checker will give some sensible response for any user input? 13

14. Criteria for efficiency • Efficient? • usually runs in acceptable time? • When does it not, are these cases likely/appropriate? • Spell-checker - will give response in 10ms for dictionaries of less than 1000 words? • always runs in acceptable time? • What do you mean by acceptable? • Spell-checker – will operate in O(n) time? • runs in optimal time? • Investigate all possible barriers to efficiency and prove your system runs as fast as possible • Again, best but is it necessary? 14

15. Criteria • Also can consider scale • One-off calculation requires less rigorous methods than code to be re-used • And consequences • Can your mistakes kill people? • In this course you make these decisions • Must be sensible… • Must be justified… • Must be planned… 15

16. Planning • Before you start develop a plan • Biggest danger in any software project is underestimating time • Things to think about • What are your skills/weaknesses? • What are the milestones? • What checking and adjustments are you going to do? • What are the dependencies? 16

17. Gantt charts 0 1 2 3 4 5 6 7 8 9 10 T1 T2.1 T2.2 * Milestone Duration of activity In this project 5% marks come from development of initial plan 17

18. Design • Once we have specification of functions • Move to system design • Do not need formal techniques such as UML • For this class (well-explained) English description is sufficient • You are strongly advised to make (and keep up-to-date!) a formal record of all design and implementation decisions • no matter how trivial! 18

19. Design • Especially for user interaction, use techniques of defensive programming • each method should error-check its input first • Spell-checker? • Don’t assume legitimate input, i.e. whole words • Check punctuation in middle of words ‘ca?t’ • Assume users will read instructions • Enter word to be spell-checked then click ‘go’ • Users will click button before entering text • Users will always do unusual things 19

20. Defensive programming • This is also important because • other programmers won't ever have known, or will make invalid assumptions about what code can do • So make it obvious (from code) what input is correct • our program should always react gracefully • no matter what peculiarities may be fed to it! • you will forget things as your code evolves/changes 20

21. Defensive programming • Defensive Programming has in essence two parts • Checking all input (each entry at a time) • Take input a character at a time • If correct cast input to appropriate form. • -e.g. use successive characters 1,2,3 to input integer 123? • Check each character is in range ‘0’..’9’ • If all correct put whole character series together and convert to integer • Checks for duff data 12x abc 0a1 etc • if no sensible input available give suitable error message and then jump to a legal exit from program 21

22. Maintenance costs • Also, remember maintenance costs • Maintenance – changing it • To do something new, to do something better, to do fulfil the original requirements • Make the code easier to change • sound modular design eases reading as well as writing • so do "small" things like careful ... • choice of identifiers • single letters seldom good! • layout • unless house style required, anything consistent and justifiable (with spaces between but not within blocks of code) • comments 22

23. Rest of lifecyle • Testing • What tests do you apply to individual modules? • How do you know if your code is correct • (answer: never) • Bu the more different tests you apply the more confident you can be • Testing is about finding errors • How do you know if system meets requirements • Different types of requirements • Usability • Functional • Non-functional • 25% of marks come from ability to test your own system 23

24. Documentation • Documentation • Who needs to know about your system • Me • can they understand it • can they change it • can they use it • 30% of marks will come from report 24

25. Management review • 5% of marks come from developing an initial plan for the project • Another 5% comes from your assessment of • How realistic your plan was • How well you stuck to it • This is not a trick • Aim is to demonstrate learning not perfection 25

26. This course • Testing lecture • how testing is to be handled • Writing lecture • how to write a technical description of your software • Note: you are not going to be assessed on • Your ability to build the most complicated system • A simpler system built well is better than a half-finished masterpiece • Your ability to write a breathtaking epic of a report • Simple, concise English is fine • Your ability to do it all in one night 26

27. Next time • We will go over the assessed work • Sneak preview at http://www.cis.strath.ac.uk/~ng • Use programming techniques newsgroup for discussion • strath.cis.teaching.ug.programming-techniques • All pieces of assessed work • use binary search trees • you can re-use code from last semester • read about these, now • how to build and traverse them • (possibly) more advanced ideas such as the AVL tree and balancing trees 27