CIS-75 Home http://www.c-jump.com/CIS75/CIS75syllabus.htm

UML Use Cases and Requirements Modeling

1. Week 6, UML Use Cases
2. Use Case Example 1
3. Use Case Example 2
4. Use Case Example 3
5. Actor
6. Use Cases Revisited
7. Actors and Use Cases
8. Identifying Use Cases Through Actors
9. UML Actor
10. UML Use Case
11. Basic and Alternative Course of a Use Case
12. Basic/Alternative Course Example
13. Use Case Extension
14. Interrupt View of Extensions
15. Prioritizing Use Cases
16. Factors contributing to increased use case priority
17. Power of Use Cases
18. Requirements Modeling Samples and Templates
19. Use Case Diagrams
20. From Use Cases to Classes

1. Week 6, UML Use Cases

• Use case is a sequence of steps performed by the user when interacting with the system.

• Use cases are requirements.

• Primarily they are functional requirements that indicate what the system will do.

• Use cases are text documents, not diagrams, and use-case modeling is primarily an act of writing text, not drawing.

• However, the UML (see www.uml.org ) defines a use case diagram to illustrate the names of use cases and actors, as well as their relationships.

   

2. Use Case Example 1

•     LOG-IN ( to a computer system )
  

1. The user is prompted for the user name and for the password.

2. The system verifies the user's name and the password...

   • ...and if correct, displays the main menu.

3. If the user's name and/or password are not correct the system displays the error message...

   • ...after the user acknowledges the message by pressing a key,
     the system asks the user to enter the user's name and the password again.

    

3. Use Case Example 2

•     DEPOSIT ( of cash/check to a bank account )
  

1. When the customer selects deposit from the main menu...
   ...the system displays the numbers of all accounts of this customer.

2. After customer makes a selection of the account...
   ...the system asks for the amount of deposit.

3. After customer enters the amount...
   ...the system echoes the amount on the screen asking for confirmation.

4. After receiving the confirmation the envelop dispenser dispenses an envelop...
   ...the customer is asked to place the money/check in the envelope and place it in the deposit slot.

5. The system will print on the envelope the amount, the number of the account, and the time and date of the transaction.

    

4. Use Case Example 3

• Domain: telecommunication. Object: a switch device. Concepts supported: Message, Connection, Port, Dialog, Route, Protocol.

      SEND PACKET REQUEST ( some I/O device protocol )
  

1. The system detects the change of bit 6 from 0 to 1 at the memory location 0xA556BFFF.

2. The system places the address of the packet buffer in the memory location 0x000099BC.

3. The system places the count of packets in the buffer in memory location 0x000099BB.

4. The system sets bit 4 of the memory location 0x000099BA to 1.

    

5. Actor

• A role that the user plays when interacting with the system.

• Actors carry out use cases.

• Actors do not have to be human.

• Actor's actions are...

  • ...non-deterministic... unpredictable... and dangerous...

• Actors represent anything that has to exchange information with the system.

   

6. Use Cases Revisited

• While using the system, a use case represents
  behaviorally related sequences of transactions,
  performed by the user in a dialogue with the system.

• The user, playing a specific role, becomes an actor.

• Use cases represent

  • what takes place in the system for specific interaction with an actor.

  • a complete course of events initiated by an actor.

   

7. Actors and Use Cases

• Collection of all use cases specifies total system functionality.

• One actor will perform several use cases in the system.

• Use cases are identified through actors by analyzing what they should be able to do with the system.

• Use cases provide the means for incremental analysis of the system functionality.

   

8. Identifying Use Cases Through Actors

• The following questions can be asked:

  • What are the main tasks of the actor?

  • Does the actor need access to any system information?

  • Does the actor have to inform the system about any changes in the environment?

  • Does the actor need to be informed about unexpected events in the system?

   

9. UML Actor

10. UML Use Case

11. Basic and Alternative Course of a Use Case

• Each use case has

  • one basic course, and

  • possibly several alternative courses.

   

• The basic course specifies the most important chain of events -

  • - the chain of events giving the best understanding of the use case.

   

12. Basic/Alternative Course Example

• Automatic Teller Machine, "cash withdrawal" use case:

  • Basic course:

    • normal course of events...

  • Alternative courses:

    • no sufficient funds in the account...

    • no sufficient amount of cash in the ATM...

   

13. Use Case Extension

• Used to model extensions of other complete use cases.

• Use Case Extensions provide means to model:

  1. Optional parts of the use cases.

  2. Complex and alternative courses which seldom occur.

  3. Situations where several different use cases can be inserted into a use case.

   

14. Interrupt View of Extensions

• Extensions can be viewed as interrupts that occur at the place in the main use case, where the extension has to be inserted.

• The use case:

  1. Runs to the point where the extension is to be inserted.

  2. The extension is executed.

  3. When finished, the original course continues, as if nothing has happened.

   

15. Prioritizing Use Cases

• Use cases should be processed in order of their priority.

• The use cases of higher priority will contribute to the model
  before lower priority use cases are processed.

  • (This defines a first impact syndrome,
    where extremely common conditions are put first.)

   

16. Factors contributing to increased use case priority

• The candidates are:

  • Cases that were captured as primary elements of the business process.

  • Cases with lower cost impact.

  • Cases with increased revenue.

  • Cases that introduce high risk factors, such as

    • time critical, technology intensive, new technology, etc...

  • Cases promising...

    • ...high level of progress (in model construction phase)...

    • ...for least amount of effort (because of well known requirements.)

   

17. Power of Use Cases

• Help to focus on the problem.

• Provide a strong base for formulation of further models.

• Provide a quantitative metric of progress.

• Offer a disciplined way of developing the system and deal with its complexity.

• Are a great verification and validation tool.

   

18. Requirements Modeling Samples and Templates

• User Requirements Template (in Word format.)

• Sample User Requirements Document (in HTML format.)

• 'Minimal Sketch' Use Case Template (in Word format.)

• 'Fully Dressed' Use Case Template (in Word format.)

• System Dictionary Template (in Word format.)

• See also: articles about Stakeholder Analysis on the Web.

   

19. Use Case Diagrams

20. From Use Cases to Classes

• Analysis of use cases leads to discovery of classes and relationships.

• Validity of classes and their relationships can be questioned (tested)
  through analysis of use cases.