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 Communication
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 others 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 little or no underlying functionality Get feedback early (and often) - before you have written much/any other code. Once the code is working, watch users attempting to use your software.
Examples... UI Design III
UI Design Prototype as soon as you can. Get Feedback - lots of it Think about how your users think If you have to present an error message, also provide a solution (if you can).
Top Down Design Make a hard task simpler Turn a big problem into lots of little easier pieces (aka modules) 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 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
Testing & Debugging 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 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?
Testing & 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 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) Check log files for hidden warnings and errors Write a mini program to test your code
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 Web Form SQL query Database Results e.g. Web-fronted database Web interface Database backend Customer view Administration view Develop separately then combine
Model / View / Controller 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 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
Design Changes 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 Web Form when things need to be changed modular design limits the pain SQL query Oracle mysql Results
A Useful Historical Quote No plan survives contact with the enemy - Helmuth von Moltke the Elder. 1800-1891 Make sure you and the project survive
Change DBMS (maintenance) Which program is easier to switch to another DB? $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.!!! function doquery($q)! {! return mysql_query($q);! echo $q. <br>\n ;! }! // function dofetch_row($r)! // etc.
Maintenance Write it twice Second revision is invariably better Rewriting a module is realistic Rewriting a whole program usually isn t
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 Just a different interface Web interface / Standalone app Same underlying processing
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%!! I ve only got 2 weeks to write it! 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!
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 / research / borrow You must reference stuff you got elsewhere Well, most of us are...
Communication Tech staff 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!)
and finally... Monday and Tuesday Help Desk sessions are the best ones to go to for help with Honours Projects I do the Monday sessions, 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