COMP390 (Design &) Implementation

Transcription

1 COMP390 (Design &) Implementation A rough guide Consisting of some ideas to assist the development of large and small projects in Computer Science (With thanks to Dave Shield)

2 Design & Implementation What are we going to look at this morning? Modularity UI Design Top Down Design Testing & Debugging Timetabling Partial Completion Documentation Communication

3 UI Design I For those projects that have a UI 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.

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

5 UI Design III What are some of the typical UI design errors? solutions that do not scale appropriately

6 UI Design III What are some of the typical UI design errors? Use of inappropriate technical detail

7 UI Design III What are some of the typical UI design errors? use of jargon / human-unfriendly text

8 UI Design III What are some of the typical UI design errors? use of jargon / human-unfriendly formats/text

9 UI Design III What are some of the typical UI design errors? giving the user unhelpful help...

10 UI Design III What are some of the typical UI design errors? giving the user unhelpful help...

11 UI Design IV What are some of the typical UI design errors? confusing the user

12 UI Design Prototype as soon as you can. Get Feedback - lots of it Watch people use your interface and see where they fail, or make mistakes Think about how your users think Think about the language they use If you have to present an error message, also provide a simple solution (if you can).

13 The Design Document COMP390 Guidelines suggest what to include in the document Remember that not all of the items listed will be relevant to your specific project e.g. Research project vs an App Development project Decide what is appropriate Consult your Supervisor if you can t figure it out yourself Don t just throw everything into the report!

14 A Useful Quote In 1989, Rick Cook wrote: Programming today is a race between software engineers striving to build bigger and better idiotproof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

15 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

16 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

17 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

18 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?

19 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

20 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 Use a Swift Playground to test code

21 Testing & Debugging - example 1

22 Testing & Debugging - example 1 Web access log-file output:

23 Testing & Debugging - example 1 php program run on command line:

24 Testing & Debugging - example 1

25 Testing & Debugging - example 1

26 Testing & Debugging - example 2

27 Testing & Debugging - example 2

28 Testing & Debugging - example 2

29 Testing & Debugging - example 2

30 Testing & Debugging - example 2

31 Testing & Debugging - example 2

32 Testing & Debugging - example 2

33 Testing & Debugging - example 2

34 Timetabling Modules help in drawing up a timetable January February March April May think up great ios app learn Swift Design UI Code & test Adjust the timetable if necessary Sell app & retire January February March April May think up great ios app learn Swift Design UI Code & test Sell app & retire

35 Partial Completion If you run out of time prioritise and complete selected modules You can show those completed modules Half a program that works - ok to demo A program that half works - much less use

36 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

37 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

38 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

39 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!

40 Maintenance Web Form if things need to be changed SQL query Oracle mysql Results

41 Maintenance Web Form when things need to be changed modular design limits the pain SQL query Oracle mysql Results

42 A Useful Historical Quote No plan survives contact with the enemy - Helmuth von Moltke the Elder Applies just as much to application development as it does to war.

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

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

45 Maintenance Write it twice Second revision is invariably better Rewriting a module is realistic Rewriting a whole program usually isn t

46 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)

47 Choice of Development Environment Modularity allows easy change A clean design is adaptable Web interface / Standalone app Same underlying processing Just a different interface

48 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)

49 It s worth 65%!! Documentation 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 Write a daily log consisting of things you did and things you learned Much easier to take existing material and edit and filter it than to write from scratch

50 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!

51 Communication Talk to your client Talk to each other Talk to the tech staff (they are your friends) Don t feel you have to do it all alone It s ok to consult / research / borrow But you must reference stuff you got elsewhere Well, most of them are...

52 Communication Tech staff can help you with more information on detailed topics - each of them 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!)

53 and finally... You can go to any Help Desk session for help with Honours Projects If they can t help you directly, they will attempt to point you in the right direction (to the right person or the right bit of the web!)

54 The End