1 / 27

Programming project Lecture 1

Programming project Lecture 1. Neil Ghani ng@cis.strath.ac.uk. 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

Download Presentation

Programming project Lecture 1

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. 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

More Related