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