Notes on use case diagram and narratives PDF

Preview

Summary

Lecture notes - use case diagram and narratives...

Description

Dr. Vandana Ramachandran

University of Utah

Systems Analysis and Design

Use case diagram 

Use case diagrams look a certain way – they are drawn in UML notation.



The UCD is a visual description of the main functionalities that the user can invoke or perform using the system.



Actors can be PRIMARY or SECONDARY

o 



If there is an external system, depict that as a secondary actor (also a stick figure).

In most cases, your primary actors will be associated with many use cases directly. These are called PRIMARY use cases. The actor may choose to perform one or more of the primary use cases (the order is irrelevant here) when interacting with the system. For example, the bank customer can be directly associated with the following use cases - create an account, edit an account, log in to account, pay bills, set up auto pay, etc.

o

Associations between a primary use case and an actor are solid lines with no arrowheads

o

Be careful to not draw a flow chart. A primary actor should be directly connected to multiple primary use case (don’t worry about the order of operations). Consider each main task that the user can do as separate primary use cases

o

Use case diagrams DO NOT indicate sequence. There is no flow logic – It is not correct to show your actor connected directly only with the log in use case, because the user has to first log in. If included as one of the main use cases, the primary actor would be connected to log in and other use cases directly.

Primary use cases can be connected to other SECONDARY use cases through the “include” or “extend” dashed arrows.

o

If the system need to do additional steps to satisfy actors’ primary goals, then indicate that with secondary use cases.

o

Use cases cannot be connected to each other using associations (simple dashes).

o

The “include” dashed arrow points from the primary use case to the secondary use case, and is used to indicate that a primary use case will always execute the secondary use case.

Dr. Vandana Ramachandran o

University of Utah

Systems Analysis and Design

The “extend” dashed arrow points from the extending use case to the base use case, and is used to indicate that a secondary use case may be used to help the primary (base) use case under some circumstances (when there is a special error or condition for instance).



If a use case is not directly associated with an actor, then that actor cannot directly invoke that use case functionality, and can only do so indirectly by going through another use case.



All use cases names are verbs and have to be written from the perspective of the focal system.



o

All external systems are black boxes to us and we do not model any use cases for external systems. For example, if an external system sends data to our focal system, the use case should be ‘get data’ and not ‘send data’

o

Remember, even though some technical formats (such as http, json, MySQL) are mentioned here, you should avoid them on a use case diagram (as these may change).

o

Use cases can be re-used. If the same use case is needed by multiple other use cases, then do not create duplicate use cases, re-use them.

The generalization-specialization relationship is a solid white arrowhead pointing to the parent from child use cases. It indicates that there are some common or shared steps among multiple child use cases that are removed and placed in a parent use case. o Steps/tasks/actions that are common to multiple use cases are placed in the parent use case, and are inherited by all child use cases. This is a tricky relationship, and you will get better at identifying this with experience. o

The same logic applies to actor generalization (you may have specialized actors that inherit from a generalized actor). A patient actor may have a new patient and old patient actor as specializations – used to show that some tasks are common to all patients, and some subset of tasks can only be performed by a specialized actor).

o

How to choose between parent-child vs includes relationship between use cases? 



Typically the parent consists of tasks that will not be performed separately on their own. The parent will only be invoked in association with one of the child use cases. On the other hand, if the common steps can be performed on their own and separate from other use cases, then an includes relationship is more appropriate than parent-child.

Dr. Vandana Ramachandran

University of Utah

Systems Analysis and Design

o 

A use case scenario is a series of use cases or a single pathway through the UCD that help achieve a user’s goal. For example for the example shown in the class sides on the clinic appointment system, o One user scenario is that of an old patient making an appointment, followed by making an edit to their insurance information and finally making payment arrangements o Notice how the three use cases described above are connected on the UCD example.



Don’t forget a system boundary

Dr. Vandana Ramachandran

University of Utah

Systems Analysis and Design

General comments for use case narratives 

Please use a template. I have provided you one to use (find it on canvas)



Do not expand on Login in the narratives. It is a trivial function, rather focus on other more important system features. Okay to show it on the UCD.



If you have a pre-condition that assumes log in, don’t list log in as the first step in your use case, rather the first step should be the trigger that invokes the particular use case (e.g., user requests to print document, user hits the submit button, user sends a query string, etc.).



Variations in success flow – indicate alternate manner(s) in which that use case can be executed successfully. For example, for the print document use case – the basic/happy flow step is to print document to printer. An alternate success path could be the user prints to pdf writer. But an alternate success path would not be user creates a new document.



If you “include” a use case, then also list it in the related use cases section. Conversely, you only need to list use cases in the related section if they are being included or extended in the basic/happy flow.



Make sure use case names are VERBS not NOUNS



Number the steps on the happy path of the use case



In the variations in success flow section, you need to number the steps to indicate which step in the happy path the said step is an alternate variation for. Same with alternate paths (extensions).



Do NOT expand out data contents. For example, an example step on your case narrative might be: User will provide account information But not: User will provide information on first name, last name, address, account number, state acct opened in etc (this information will go in the ERD not on use cases)



Avoid and do not use specific implementation details such as “user will click on a button to send information”. This is an implementation level detail that should be left until the Design phase. Rather you can state “user sends information to the system” without worrying about the technical details of whether there will be a button or some other sort of interface....