The STREAM process – programming in practice

1. The STREAM process –programming in practice

2. What are we trying to do? Tools Language Specifications Intellect Programs that work… HOW?

3. The programming process • What elements are involved in writing a (correct) program? • In the ideal world: • Understand – read the specification until you are sure you understand it completely • Think – now think hard about how to solve the program • Code – now write the program! • A simple, linear process…but it does not work that way in real life

4. The ideal world Understand Think Code

5. The real world Understand Think Code Test

6. How to get started • We will not address the problem of understanding – and develop-ing – the specification here (Software Design) • Given a reasonable under-standing of the problem to solve, how do we get started at all? • The traditional approach is stepwise refinement

7. Stepwise refinement public class MyMainClass { public void solveProblem() { // Just add code here… } }

8. Stepwise refinement • From this point, simply break down the problem into smaller and smaller pieces • Code evolves from being abstract to becoming concrete • Not a bad strategy, but still too naive • Assumes perfect knowledge of problem • Still a linear process • A more realistic process is stepwise improvement

9. Stepwise improvement • The Stepwise improvement process adds two more activities to the Refinement process • Extension: we extend the code to cover more of the specification – for instance include an additional case • Restructuring: we change the structure of the code, without changing the functionality of the code

10. Activity diagram Refinement The Goal You are here! Extension Restructuring

11. Stepwise refinement Refinement The Goal Extension Now we understand the problem com-pletely, start coding! Restructuring

12. Stepwise improvement Refinement The Goal Extension Restructuring

13. Embrace change… • Is Stepwise Improvement completely chaotic!? • No, but it can appear confusing  • There is no given order of the three types of activities, they can ”happen” at any time during program development • Notice, however, that they are separate activities • We can provide advice about how to perform each activity

14. Extension • In real life, a full specification is often very large, hard to under-stand, incomplete and ambiguous • Does not really make sense to try to make a complete program in one attempt • Instead, select a part of the functionality, and make it work

15. Extension • Once the selected part of the specification works, we can proceed to including more parts of the specification • Before that, we may possibly do some refinement and restructuring • The specification itself might change as well…

16. Refinement • In this activity, we try to actually implement some part of the specification • This activity only involves programming • Do not try to be too clever here! • Refinement is complicated enough in itself • The STREAM process is a simplified process for the refinement activity

17. The STREAM process • Stubs • Test • Representations • Evaluation • Attributes • Methods

18. Stubs • What are ”stubs” – methods which do not yet have code inside them • We assume that at this point, we are about to implement some well-known classes • Well-known: The expected behavior of the classes is known • We should be able to figure out the public interface to the classes

19. Stubs public class BankAccount { public void deposit() {} public void withdraw() {} public double getBalance() { return 0.0; } }

20. Stubs • We can create classes with stub methods for all classes under consideration • Our program will compile…but do nothing • This state of a program is often called a walking skeleton

21. Test • We assume we fully understand the classes under consideration • We should thus be able to write test cases for them, before proceeding further • Gives us a clear target – once the program passes our tests, we are done with the activity • Usual considerations about test still apply…

22. Representation • During the ”stub” part, we did not pay any attention to data representation • Data representation is not part of the public interface • Need to make a choice, however… • Think about alternatives for represen-tation – you should come up with at least two alternatives

23. Evaluation • Given some alternatives for representation, we must now evaluate them • Evaluate: How hard will it be to implement the methods in the public interface, given that we use some specific representation • Will of course be a subjective evaluation • Evaluate each representation alternative for each public method • REM: Representation Evaluation Matrix

24. Evaluation

25. Attributes • Now we have chosen a representation for our data, so implement the representation • That is: • Define instance fields • Set proper values in class constructors • This does not mean that we are done with representation – we may need more instance fields when implementing methods • Can still use REM

26. Attributes public class BankAccount { double balance; public BankAccount() { balance = 0.0; } public void deposit() {} public void withdraw() {} public double getBalance() { return 0.0; } }

27. Methods • All that remains now is to fill in the code in the public methods… • …but that is also the hardest part! • In a sense, we try to re-apply parts of the STREAM steps when implementing a method • We have a set of method implementation rules to assist us during implementation

28. Methods • Again, the guiding principle is to manage the complexity, by breaking problems into smaller, more manageable pieces • In practice – push your problems ahead of you! • Keep method implementations simple, by inventing new methods as you go along • Implement the new methods as stubs, and return to them later on • The mañana principle (or the Good Fairy)

29. The mañana principle public void convertFromInchesToCm() { double inches = getInchesFromUser(); double cm = calculateCmFromInches(inches); presentCmToUser(cm); } private double getInchesFromUser() { return 0.0; } private double calculateCmFromInches(double inches) { return 0.0; } private void presentCmToUser(double cm) {}

30. The mañana principle • When to use the mañana principle • Special case: Move implementation of a special case to a separate method • Nested loop: If you have a nested loop, move the inner loop to a separate method • Hard problem: If you need the answer to a problem that you cannot immediately solve, make it a separate method • Heavy functionality: If a sequence of statements or an expression becomes long or complicated, move some of it into a separate method

31. Methods • The mañana principle is not a rule, but a principle – apply when necessary • The ”threshold” for when to apply it is individual • Rule-of-thumb: Methods which cannot fit into a single screen are too long, and should be divided into more methods • Remember we still have the test cases to guide us – when the tests are passed, we are done

32. Keeping the compiler happy • This is a very practical advice  • Compilers try to find all errors in the code, but often get it wrong… • Error messages from the compiler can be quite confusing • Only try to fix those errors which make sense • Fortunately, compilation is fast!

33. Keeping the compiler happy • Compile often! • Try to keep the program free of syntax errors at all times • Fix errors immediately • If the compiler only reports one or a few errors, they are much easier to fix • Error(s) must be in the code you have just entered…

34. Example: a Date class • We are given the task of implementing a Date class, specified as follows: • The Date class represents a date, given by year, month number and day number • When created, a Date object is initialised with a year, month and day (it can be assumed that the input data always represents a valid date) • It must be possible to advance the date in a Date object to the next valid date • It must be possible to retrieve the data as a String

35. Date class – Stubs public class Date { public Date(int year, int month, int day) { } public void advanceToNextDate() { } public String toString() { return null; } }

36. Date class – Test • We will not detail this now, but there are actually a lot of cases to test • Simple advance of date • Advance of date across month • Advance of date across year • Leap years • …etc. • But we can just write up the test cases, without worrying about implementation

37. Date class – Representation • What are possible – and reasonable – represen-tations of a date? • String – we need to get it back as a String • Multiple integers – one for day, one for month and one for year • One integer – days since Jan 1st, 0001 • We evaluate the alternatives using the REM (Representation Evaluation Matrix)

38. Date class – Evaluation

39. Date class – Attributes public class Date { private int year; private int month; private int day; public Date(int year, int month, int day) { this.year = year; this.month = month; this.day = day; } public void advanceToNextDate() { } public String toString() { return year + ”-” + month + ”-” day; } }

40. Date class – methods • The only task left now is to implement the advanceToNextDate() method • First attempt: public void advanceToNextDate() { date = date + 1; }

41. Date class – methods • A little naive, but actually works in 97 % of all cases  • We do need to handle special cases • Next attempt: public void advanceToNextDate() { date = date +1; handleDayOverflow(); }

42. Date class – methods • Now advanceToNextDate() is done, assuming that handleDayOverflow()works! • The mañana principle at work! • Now on to handleDayOverflow() private void handleDayOverflow() { if (day > 30) { day = 1; month = month + 1; } }

43. Date class – methods • This will work, except for two situations • Month does not have 30 days • Across a new year • Once again, we fix this by inventing some new methods and implement them later: • daysInMonth() • handleMonthOverflow()

44. Date class – methods private void handleDayOverflow() { if (day > daysInMonth()) { day = 1; month = month +1; handleMonthOverflow() } } private int daysInMonth() { return 30; } private void handleMonthOverflow() {}

45. Date class – methods • And we just keep going like this… • The final implementation will – of course – handle all cases correctly, including leap years • Manage the complexity – only try to solve one problem at a time! • Do not think too much about whether or not the code is optimally structured – this is adressed during the restructuring activity

46. Restructuring • During a refinement activity, focus is on achieving functionality • Should not be too concerned with code structure • During a restructuring activity, we restructure code but preserve functionality • Easy to forget/neglect this activity in real life…

47. Restructuring • How do I know what to restructure…? • Not an easy task, requires some experience • You have to develop an ability to ”smell bad code” • What does bad code smell like?

48. Smelly code… Hmm, bad choice of names…? private void hDO() { if (d > dIM()) { d = 1; m++; hMO() } } private int dIM() { return stdDiM; }

49. Restructuring • It could be as simple as that… • In the heat of the fight, we might have chosen names which are ”non-informative” • Similar ”clean-up” activities could be: • Non-consistent naming • Replace magic numbers with constants • Fixing alignments • Eliminate unused parameters • Remember, no change in functionality!

50. Smelly code… public void printWorkerInfo(Employee worker) { System.out.println(”Worker information”); System.out.println(”-------------------------”); System.out.println(worker.GetName()); System.out.println(worker.GetAddress()); } public void printManagerInfo(Employee manager) { System.out.println(”Manager information”); System.out.println(”-------------------------”); System.out.println(manager.GetName()); System.out.println(manager.GetAddress()); }