1 / 32

RNDS: Class analysis

RNDS: Class analysis. CS 236700: Software Design Winter 2004-2005/T4. Reminder: Homework bonus program. Report a bug Report a programming challenge. RNDS: The story so far. Problem description SRS Use case model SDD Class design Sequence, Collaboration, Deployment

india-osborn
Télécharger la présentation

RNDS: Class analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related