Upload
elias
View
35
Download
2
Embed Size (px)
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
1
RNDS: Use casesRNDS: Use cases
CS 236700: Software Design
Winter 2004-2005/T3
2
Homework bonus programHomework bonus program Report a bug Report a programming challenge
3
Problem description: RNDS (1/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 editingAllow setting of the current SWPDisplay Info
• Distance to SWP • Heading to SWP• Heading correction to SWP
4
Problem description : RNDS (2/3)Problem description : RNDS (2/3) Interoperability with existing systems
A GPS deviceProvides: 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)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 missionThe mission
Write the use-case specifications for the SRS document
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 DocumentSRS Document
SRS Template Glossary
Primary actorPrincipal actor that interacts with the system to fulfill a goal
Secondary actorA non primary actor
Active actor
Initiates interaction with the system Passive actor
A non-active actor Function points
8
ActorsActors 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”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 activitiesOther 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)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
The list of use-cases (2/2)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 WP2. Delete a WP3. Edit a WP4. Add a WP to the FP5. Remove a WP from the FP6. Change SWP7. Show Info8. Read GPS data9. Receive updates10. Send updates
The Use cases:1. Add a new WP2. Delete a WP3. Edit a WP4. Add a WP to the FP5. Remove a WP from the FP6. Change SWP7. Show Info8. Read GPS data9. Receive updates10. 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)Use case diagram (1/2)
14
Use case diagram (2/2)Use case diagram (2/2) NavInfoChange can generalize 6 of the use cases
15
The list of use-cases - updatedThe 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)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
““User Level Activities” – again (2/3)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)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-casesFinal list of use-cases1. Change Navigation Info2. Add a new WP3. Delete a WP4. Edit a WP5. Add a WP to the FP6. Remove a WP from the FP7. Change SWP8. Change FP order9. Refresh Info10.Change visible info11.Read GPS data12.Receive updates13.Send updates
20
Final use-case diagramFinal use-case diagram
21
UC DescriptionUC 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
““Holes” (1/2)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)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 changesDealing 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