1. 1 RNDS: Use cases CS 236700: Software Design Winter 2004-2005/T3

2. 2 Homework bonus program  Report a bug  Report a programming challenge

3. 3 Problem description: RNDS (1/3)  RNDS: Replicated Navigation Data Store A formation of Aircrafts + A ground station A single flight plan (FP) made up of several way-points (WP) A single steering point (SWP) Requirements: Allow flight-plan editing Allow setting of the current SWP Display Info Distance to SWP Heading to SWP Heading correction to SWP

4. 4 Problem description : RNDS (2/3)  Interoperability with existing systems A GPS device Provides: Position, time, speed, current heading A communication layer (CL) Supports various communication protocols Broadcasting, Send-reply, … Preconfigured with relevant “addresses”: Formation’s aircrafts Ground station

5. 5 Problem description : RNDS (3/3)  More requirements Human interaction thru GUI Data (WPs, FP, SWP) should be consistent Reliability (99% up time ?) Software platform: Java/Embedded Windows NT Hardware configuration is uniform Same setup in the ground station and the aircrafts  Boundaries A single RNDS system is the software components running on a single computer (either at the aircraft or at the ground station) Other RNDS instances (reachable thru CL) are considered to be identical peers => In the typical settings (four aircrafts + a ground station) there are five RNDS systems working concurrently.

6. 6 The mission Write the use-case specifications for the SRS document SRS = Software Requirements Specification Describes the functionality the system will provide Written from the client’s perspective Defines the developer’s obligation to the client Must be approved by the client Who is the client ? Many times someone from within the organization

7. 7 SRS Document  SRS Template SRS Template  Glossary Primary actor Principal actor that interacts with the system to fulfill a goal Secondary actor A non primary actor Active actor Initiates interaction with the system Passive actor A non-active actor Function points

8. 8 Actors  Who can interact with our system? Pilots Ground station operator Is he really different than a pilot? GPS Communication Layer Administrator? Mission planner? Flight commander? Operating System? File system?

9. 9 “User Level Activities”  The key question: What can a user “do” with the RNDS? Enter a new WP Remove a WP Change a WP Add a WP to the FP Remove a WP from the FP Change the current SWP  The standard set of operations on a data item: Create Change Delete Lookup

10. 10 Other activities  What about non-human actors? The system communicates with its peers thru the CL The system reads current position from the GPS

11. 11 The list of use-cases (1/2) 1.Add a new WP 2.Delete a WP 3.Edit a WP 4.Add a WP to the FP 5.Remove a WP from the FP 6.Change SWP 7.Show Info 8.Read GPS data 9.Receive updates 10.Send updates

12. 12 The list of use-cases (2/2)  Q: Can we have a “calculate-info” use case?  The answer depends on The client The description of the problem The SRS author Anyway, it seems like an Implementation detail The Use cases: 1.Add a new WP 2.Delete a WP 3.Edit a WP 4.Add a WP to the FP 5.Remove a WP from the FP 6.Change SWP 7.Show Info 8.Read GPS data 9.Receive updates 10.Send updates The Use cases: 1.Add a new WP 2.Delete a WP 3.Edit a WP 4.Add a WP to the FP 5.Remove a WP from the FP 6.Change SWP 7.Show Info 8.Read GPS data 9.Receive updates 10.Send updates  The bottom line: The client must understand the SRS document The client must approve the SRS document

13. 13 Use case diagram (1/2)

14. 14 Use case diagram (2/2)  NavInfoChange can generalize 6 of the use cases

15. 15 The list of use-cases - updated  Change Navigation Info  Add a new WP  Delete a WP  Edit a WP  Add a WP to the FP  Remove a WP from the FP  Change SWP  Show Info  Read GPS data  Receive updates  Send updates

16. 16 “User Level Activities” – again (1/3)  The key question: what can a user “do” with the GUI ? A picture worth 1000 words 1.He can start an action: New WP, Delete WP, Change SWP, … These actions are already covered (see previous slide) 2.He can read the directions This is the “ShowInfo” use case 3.He can scroll the WP list 4.He can scroll the FP list 5.He can show/hide various parts of the display Run RndsGui

17. 17 “User Level Activities” – again (2/3) …So, the user can also scroll the display Q: Is it possible for the ShowInfo use-case to handle scrolling? A: No NavInfoChange uses ShowInfo for refreshing the display “Refresh” and “scroll” are distinct The same goes for showing/hiding parts of the display The solution: Rename ShowInfo to RefreshInfo Add a ChangeVisibleInfo use-case Will handle scrolling, showing/hiding, … We can also define a generalization hierarchy: ChangeVisibleInfo – The general use-case Scroll, Show, Hide – More specific use-cases Reflecting GUI interaction in the SRS document…

18. 18 “User Level Activities” – again (3/3) What about the order of the FP ? We should add an up/down facility => Adding a new specialization of NavInfoChange Run RndsGui

19. 19 Final list of use-cases 1.Change Navigation Info 2.Add a new WP 3.Delete a WP 4.Edit a WP 5.Add a WP to the FP 6.Remove a WP from the FP 7.Change SWP 8.Change FP order 9.Refresh Info 10.Change visible info 11.Read GPS data 12.Receive updates 13.Send updates

20. 20 Final use-case diagram

21. 21 UC Description Name: “EditWP” Actors: User, CL Goal: Change the position an existing WP Reference to requirements: … Pre-conditions Number of WPs >= 1 System displays the list of WPs Description 1.User selects a WP 2.System displays the WP’s details 3.User enters new details and submits 4.The system updates all peers by invoking the “SendUpdates” use-case 5.The display is refreshed by invoking the “RefreshInfo” use-case Post-conditions The position of the selected WP has changed in all RNDS systems. Variations 4,5 - The WP is removed by another RNDS system => Operation stops 4,5 - The WP position is changed by another RNDS system => Operation stops Excpetions 6 -Not all peers could be updated => A partial success message is displayed

22. 22 “Holes” (1/2)  Is it possible that the guy who described the problem was not doing a good job?  What did he forget to mention?  What definitions are missing?  What is WYSIWYG ? What You See Is What You Get  What is IKIWISI ? I’ll Know It When I See It

23. 23 “Holes” (2/2)  IKIWISI is evil Changes at an early stage are usually made by a combination of the “cut”, “copy”, and “paste” keys Changes towards the end of the development cycle call for a major redesign-rewrite-retest process Thus, the later the change the more it costs  Nonetheless, many times requirements do change in a very late stage Sometimes, IKIWISI yields better result than careful pre- planning Especially in the holy-land !!  The bottom line Not everything can be predicted An impeccable requirement document is a fairy-tale Accept the change

24. 24 Dealing with late changes  Some techniques Understanding the client’s needs Avoiding hard-coded values Avoiding hard-coded decisions/assumptions Deja vu reduction Increased locality, modularity Representing “things” as classes Adding levels of abstractions  On the other hand, beware of over-engineering.  Anyway, these techniques are out of the scope of this lecture