1 / 24

RNDS: Use cases

RNDS: Use cases. CS 236700: Software Design Winter 2004-2005/T3. Homework bonus program. Report a bug Report a programming challenge. Problem description: RNDS (1/3). RNDS: Replicated Navigation Data Store A formation of Aircrafts + A ground station

elias
Download Presentation

RNDS: Use cases

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: Use cases CS 236700: Software Design Winter 2004-2005/T3

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

  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. 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. 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. 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. SRS Document • 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. 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. “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. 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. The list of use-cases (1/2) • 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

  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: • 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 • The bottom line: • The client must understand the SRS document • The client must approve the SRS document

  13. Use case diagram (1/2)

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

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

  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. “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. Final list of use-cases • 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 • Change FP order • Refresh Info • Change visible info • Read GPS data • Receive updates • Send updates

  20. Final use-case diagram

  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 • User selects a WP • System displays the WP’s details • User enters new details and submits • The system updates all peers by invoking the “SendUpdates” use-case • 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. “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. “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. 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

More Related