RNDS: Class analysis

1. RNDS: Class analysis CS 236700: Software Design Winter 2004-2005/T4

2. Reminder: Homework bonus program • Report a bug • Report a programming challenge

3. RNDS: The story so far • Problem description • SRS • Use case model • SDD • Class design • Sequence, Collaboration, Deployment • Detailed class design • Coding • Design patterns

4. The mission Identify key classes • Identifying a class = defining its responsibility/concern/role • Ideally, responsibility is not shared • Choosing the classes is a critical issue - will influence the future • Just like the interaction children at the kindergarten • Defining responsibility requires thinking about the methods • But, we will try not to define methods at this stage

5. The process • Identify objects • Identify corresponding classes • Refinements

6. Looking for classes (1/2) • A partial list with overlaps • Nouns in the of description • Algorithms (verbs) • May be classes, not just methods • Then an “er” suffix is added (Painter) • Recurring services • VectorOfInts, StringIterator • Complex services • Databases, Sockets, Concurrency • Functions which accept the same formal arguments • A process made up of an ordered sequence of actions • An “initialize-do” process • A “mode” behavior • Several polymorphic classes, one for each mode Assuming that most developers think in procedural terms

7. Looking for classes (2/2) • A partial list with overlaps (cont’d) • Stateful behavior • GUI entities: • Concrete components: panels, lists, labels, … • Logical components: “screen” • Highly popular library services • String, System.out • All sorts of Values • Distinguish between values of identical type but different roles • Standard toolkit • Log, assertion, Message box, program configuration

8. Some class issues (1/2) • Interface principle • Design for interface • “I will write a Hash-table class” – implementation • “I will write a Dictionary class” - interface • The interface of a class is not just the public methods/fields • A TreeIterator class is part of the interface of class Tree • Choose the smallest interface

9. Some class issues (2/2) • Is-a vs. has-a • A square is also a rectangle • A Square class cannot support all operations of a Rectangle class • => A Square class cannot be a sub-class of Rectangle • In RNDS • Should WP be a sub-class of Location? • Should SWP be a sub-class of WP? • Naming: nouns only

10. Compiler helping the developer (1/4) • Will this program terminate properly? int read(float nums[], int count) { int i, j = 0; for(i = 0; i < count; ++i) { scanf(“%f“, nums + j); if(nums[j] >= 0) ++j; } return j; } void compute(float nums[], int count) { int i; for(i = 0; i < count; ++i) nums[i] = sqrt(nums[i]); } int main(int argc, char* argv[]) { float nums[20]; int n = 20; read(nums, n); compute(nums, 20); return 0; } • Murphy’s rule: “If a function can be misused, the developer will eventually misuse it” • This C program is error-prone • The author intended that the return value of read() will be passed to compute() • There is no way to force him to do so • This is a dangerous world, with no one to protect the poor developer… • The object-oriented world is much safer. • How can we make it safe (in C) ?

11. Compiler helping the developer (2/4) import java.io.*; import java.math.*; public class SquareRoots { private double[] nums_ = new double[20]; private int count_ = 0; public SquareRoots() throws Excepetion { BufferedReader r = new BufferedReader(new InputStreamReader(System.in)); for(int i = 0; i < nums_.length; ++i) { nums_[count_] = Double.valueOf(r.readLine()); if(nums_[count_] >= 0) count_ += 1; } } public void compute() { for(int i = 0; i < count_; ++i) nums_[i] = Math.sqrt(nums_[i]); } public static void main(String[] args) throws Exception { SquareRoots sr = new SquareRoots(); sr.compute(); } }

12. Compiler helping the developer (3/4) • The difference: C vs. OOP • In C • There’s no encapsulation • Compile time entities (structs) are not used as often as classes • => compiler assistance is much less common • In OOP • Methods are operations which the developer attaches to data • Two types may hold the same type of data but have different operations • A wise developer creates a world of classes where it is difficult/impossible to invoke the wrong method

13. Compiler helping the developer (4/4) • Summary (compiler helping the developer) • By creating compile-time entities (classes) one can convert run-time errors to compile-time errors • Compiler errors are our friends! • A rich population of classes • Beware of population explosion: If the population is too complex the developer makes wrong design decisions

14. Cross-cutting concerns (1/2) • Some services are relevant to some/all parts of the program • E.g.: Error handling, Output formatting • Thus, it is possible to come-up with several different decompositions • Developer must select one of many possible decompositions • This challenge is addressed by AOSD • Aspect Oriented Software Development • The AspectJ programming language

15. Cross-cutting concerns (2/2) • Here are two possible decompositions of RNDS • …nonetheless, there is also a third decomposition • Suitable for transaction management

16. UI vs. Algorithms • Let’s divide a program into two parts • User interface (usually: GUI) • Algorithms • Represent the rules of the domain/market (problem space) • Business logic • Make sure the program produces correct results • What can you (the developer) change ? • Changes in the UI are a sensitive issue • Changes in the algorithms can be made freely (as long as the produced results are correct) • On the other hand: your boss/client will tell you to modify the UI frequently • People always think of new ways to use existing software • Web-interface, thin client, command line, etc… • The way the domain/market behaves rarely changes • Expect your algorithms to be utilized in new ways • => Almost always separate the UI from the algorithms in your decomposition

17. First step: Identifying objects • The key question: Which objects do you “see” in the RNDS system? • We can take a look at the use case diagram (next slide)…

18. RNDS: Use case diagram

19. RNDS Objects (1/2) • CL Controller • GPS Controller • A collection of all way-points • A collection of way-points in the flight-plan • Way points (held by the collections) • Location (held by a Way Point) • Current SWP • Navigation model – holds all abovementioned objects • Navigation model update – synchronizes the nav. data

20. RNDS Objects (2/2) • Visibility state • Dispatcher • User Request • Manager of the WP GUI • Manager of the FP GUI • Manager of the directions GUI • Standard GUI Objects: Two JList objects, several JTextFeilds, … So, Let’s define possible classes for these objects…

21. Solving challenges • Algorithmic challenges • Consistent Shared Data (CSR) • Anything else? • Q: How will we solve the CSR challenge? • (Answer: see next slide)

22. CSR • The idea: • Decomposing the shared data into “atoms”: Items • Each Item will have a globally unique id • GUID • All copies of an item have the same id • Thus, a change made to an item in one RNDS, can be correctly duplicated to the other peers • Item deletion is treated as a special case of an item change • Each item will hold a 5 cell vector specifying its update number in each of the RNDS systems • When an RNDS system changes an item, it increases the corresponding update number • AKA: Vector Clock • => two copies of the same items can be compared to determine which is the most updated copy • If comparison is ambiguous we have a conflict - must be solved some other way • Human decision • Predefined priority

23. K8 K8 K8 K8 K8 K8 K8 K8 K8 Data-b Data-a Data-a Data-e Data-e Data-d Data-c Data-b Data-c 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 2 2 1 1 2 2 2 2 0 0 0 0 0 0 0 0 0 3 3 0 0 1 2 1 0 0 CSR – example 1 Aircraft 2 Aircraft 4 Connection lost Connection established Comparing <0,0,2,0,1> with <0,0,2,0,3>

24. K8 K8 K8 K8 K8 K8 K8 K8 K8 Data-b Data-f Data-d Data-c Data-a Data-c Data-b Data-a Data-e 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 2 1 2 2 1 2 2 2 0 0 0 0 0 0 0 0 0 2 0 0 0 0 1 1 3 1 CSR – example 2 Aircraft 2 Aircraft 4 Connection lost Connection established Comparing <0,0,3,0,1> with <0,0,2,0,3>

25. CSR: Implications • (Additional RNDS objects): • Item objects • Unique Key • Vector Clock • Data store – a collection of item objects • All Navigation data: (flight plan, way-points, …) should be items/collections of items stored in the data store

26. RNDS classes – 1st draft (1/6) • GPS • GpsController • The GPS that the system “sees” • Hardware independent • Updates the system when the GPS readout is changed • IGpsDevice – An interface describing the functionality provided by the hardware dependent GPS object • GpsDeviceA/B/C.. – implementations of IGpsDevice for specific GPS products • IGpsListener – An interface allowing another object to be notified when the GPS data has changed.

27. RNDS classes – 1st draft (2/6) • CL • ClController • The CL that the system “sees” • Hardware independent • Allows an update to be sent/received • Provides a fair, single-sender protocol • Provides send result status – specifying which peers did not receive the message • Notifies the system when an update is received • IClDevice – An interface describing the functionality provided by the hardware dependent CL object • ClDeviceA/B/C.. – implementations of IClDevice for specific CL products • IClListener – An interface allowing another object to be notified when an update is received. • ISendable – An interface. Represents a single unit of data that can be sent/received

28. RNDS classes – 1st draft (3/6) • Navigation info classes • Location – Represents a 3D geographical position • Item – An abstract class representing a shared “piece” of data. Implements the ISendable interface • Key – A globally unique value (GUID) • Vector clock ? • Let’s use an array of integers • DataStore – Maps a key to an Item. Supports lookup, add, replace, iteration. • WayPoint – Location + additional description details (name, …). A sub-class of Item • (The objects) • Items • Key • Vector Clock • Data Store • A collection of all way-points • A collection of way-points in the flight-plan • Way points • Location • Current SWP • Navigation model • Navigation model update

29. RNDS classes – 1st draft (4/6) • Navigation info classes (cont’d) • Navigator – Holds the SWP + current GPS readout. Computes distance/heading. • VectorOfWayPoints – An ordered collection of WayPoint objects • WayPointRegistry -All defined way-points. Supports add/remove • FlightPlan – Represents the FP. Supports add/remove/up/down • NavModel – A “packaging” for the flight plan, SWP, WPs • Model update ? • An iterator over a collection of Item • (The objects) • Items • Key • Vector Clock • Data Store • A collection of all way-points • A collection of way-points in the flight-plan • Way points • Location • Current SWP • Navigation model • Navigation model update

30. RNDS classes – 1st draft (5/6) • GUI • IWPGuiManager, IFPGuiManager, IDirectionsGuiManager - Interfaces for the various parts of the screens • StdWPGuiManager, StdFPGuiManager, StdDirectionsGuiManager – Default implementations of these three Interfaces • Visibility state class ? • No – Will be handled internally by the the StdGuiManager… classes • Class GuiManager – A packaging for all the other managers.

31. RNDS classes – 1st draft (6/6) • Misc • Dispatcher – a focal point for initiating all use-cases. Creates all top-level objects • User Request class ? • No – Each request will have a corresponding method in Dispatcher

32. Comparing two classes • ISendable vs. Item • Item – An abstract class representing a shared “piece” of data. Implements the ISendable interface • ISendable – An interface. Represents a single unit of data that can be sent/received • Q: Do we really need two different classes? • A: No