COMP390 (Design &) Implementation Phil (& Dave s) rough guide Consisting of some ideas to assist the development of large and small projects in Computer Science (and a chance for me to try out some features of Apple s Keynote presentation software) Design & Implementation What are we going to look at this morning? Modularity UI Design Top Down Design Testing & Debugging Timetabling Partial Completion Documentation UI Design I Most clients consider UI above every other aspect of your project. It is the single aspect of your project to which the client and staff are exposed. Your client doesn t usually care if your code is efficient (we do of course). If your program is unnecessarily hard to use, then it is unlikely to be used by your client. UI Design II How can I be certain my UI is appropriate and easy to use? Develop prototypes early on in the project and give these to the client to obtain feedback Prototypes can be drawings, web pages or simple programs with no or little underlying functionality Get feedback early (and often) - before you have written any other code. Once the code is working, watch users attempting to use your software.
UI Design III What are some of the typical UI design errors? use of inappropriate controls UI Design III What are some of the typical UI design errors? At least three programmer errors in this UI 18 329 2885 2715 13 121 51 UI Design III What are some of the typical UI design errors? use of jargon / human-unfriendly text UI Design III What are some of the typical UI design errors? use of jargon / human-unfriendly text
UI Design III What are some of the typical UI design errors? giving the user unhelpful help... UI Design III What are some of the typical UI design errors? giving the user unhelpful help... UI Design Prototype as soon as you can. Get Feedback - lots of it Think about how your users think Top Down Design Make a hard task simpler Turn a big problem into lots of little easier ones If you re not sure what to do now, decide what to do next Never do today, what you can put off until tomorrow
Testing & Debugging Testing & Debugging Test each module individually If things work individually they ll probably work together If not its easier to fix one or two small modules Write tests for a module as you go along Keep testing Test Harness Extend the tests as you uncover problems Don t leave testing until the end Test in the final environment Don t assume if it works on your laptop it ll work here Testing & Debugging Testing & Debugging What do I do when my program stops working? Does your development system support a real debugger? No debugger? What tricks can be employed to assist debugging? Real Debugger step through code - check variable values etc. (remember COMP103?) Set breakpoints Modify values live to test conditional code Difficult to debug real-time, asynchronous or interactive code
Testing & Debugging Testing & Debugging - example 1 No debugger? Don t Panic! Add output statements to your code - display the values of variables, your sql queries... Set variables to fixed values to test conditional code Dump output into files to view when done. (like an audit trail after the event) Run your code on the command line and see what happens (errors are more direct) Write a mini program to test your code Check log files for hidden warnings and errors Testing & Debugging - example 1 Testing & Debugging - example 1
Testing & Debugging - example 1 Testing & Debugging - example 1 Testing & Debugging - example 2 Testing & Debugging - example 2
Testing & Debugging - example 2 Testing & Debugging - example 2 Testing & Debugging - example 2 Testing & Debugging - example 2
Testing & Debugging - example 2 Testing & Debugging - example 2 Timetabling Modules help in drawing up a timetable January February March April May think up great ios app learn objective C Design UI Code & test Adjust the timetable if necessary Sell app & retire January February March April May think up great ios app learn objective C Design UI Code & test Sell app & retire Partial Completion If you run out of time prioritise and complete selected modules Half a program that works - ok to demo A program that half works - much less use
Functional Modularity Model / View / Controller Web Form SQL query Database Results e.g. Web-fronted database Web interface Database backend Customer view Administration view Develop separately then combine Separates the underlying data representations from the input and output modules Changes in one don t necessarily require changes in the other Modules have well defined APIs of course if the interfaces change, then all affected modules must also be modified Prototyping Design Changes Web Form SQL query Database Results Prototype the form and output - get feedback from users e.g. use fixed results to illustrate the interface Don t need to query the database initially - we may not even have a DB or real data yet! Simulate real code behind the scenes Full catalogue Special offers SQL query Database Results Feedback from prototypes likely to lead to changes to original design Modular design limits the pain - just the affected modules If you had developed everything prior to first test - potentially lots to modify! Get feedback as soon as you can!
Maintenance Maintenance Web Form if things need to be changed Web Form when things need to be changed modular design limits the pain SQL query SQL query Oracle mysql Oracle mysql Results Results A Useful Historical Quote Change DBMS (maintenance) Which program is easier to switch to another DB? No plan survives contact with the enemy - Helmuth von Moltke the Elder. 1800-1891 Make sure you and the project survive $x = mysql_query($query); $z = mysql_fetch_row($result); $this = mysql_query($query2); $that = mysql_query($query4); $y2 = mysql_fetch_row($result3); $z = mysql_query($query1); $t = mysql_query($query5); // etc. $x = doquery($query); $z = dofetch_row($result); $this = doquery($query2); $that = doquery($query4); $y2 = dofetch_row($result3); $z = doquery($query1); $t = doquery($query5); //etc. function doquery($q) { return mysql_query($q); } // function dofetch_row($r) // etc.
Change DBMS (maintenance) Which is easier to debug? $x = mysql_query($query); $z = mysql_fetch_row($result); $this = mysql_query($query2); $that = mysql_query($query4); $y2 = mysql_fetch_row($result3); $z = mysql_query($query1); $t = mysql_query($query5); //etc. $x = doquery($query); $z = dofetch_row($result); $this = doquery($query2); $that = doquery($query4); $y2 = dofetch_row($result3); $z = doquery($query1); $t = doquery($query5); //etc. Maintenance Write it twice Second revision is invariably better Rewriting a module is realistic Rewriting a whole program usually isn t function doquery($q) { return mysql_query($q); echo $q. <br>\n ; } // function dofetch_row($r) // etc. Choice of Development Environment For many projects - don t need to decide up front Usually has minimal impact on design, though language special features may affect things. Design should drive development choices (not the other way round) Choice of Development Environment Modularity allows easy change A clean design is adaptable Web interface / Standalone app Same underlying processing Just a different interface
Development Environment Considerations What do you already have experience of? What would you like experience of? What is available to you? What is available to the client? What can the client support? What is suitable for the task? Be prepared to defend your choice (don t just choose something on a whim) Documentation It s worth 65%!! Write down everything you re doing Write it down now! Yes everything! Don t forget to write the why s Much easier to take existing material and edit and filter it than to write from scratch Revision Control It used to work, now something s changed and it s broken Regular snapshots Full revision control - snapshots of all changes Essential for collaborative work Continuous documentation! Essential for collaborative work Communication Talk to your client Talk to us (the tech staff are your friends) Talk to each other Don t feel you have to do it all alone It s ok to consult But reference stuff you got elsewhere Well, most of us are...
Communication and finally... We can help you with more information on detailed topics - each of us has expertise in specific areas Don t be afraid to ask for assistance (the setup here may be different from elsewhere e.g. your laptop - so test it here as well as on your laptop!) Monday and Tuesday Help Desk sessions are the best ones to go to for help with Honours Projects I do the Monday session, Dave Shield does the Tuesday ones. If we can t help you directly, we will attempt to point you in the right direction (to the right person or the right bit of the web!) The End