Presentation on theme: "Use Case Diagram in Detail"— Presentation transcript:
1Use Case Diagram in Detail CT1414February 2012By: Fatimah AlakeelReviwed by: Asma Alzaid
2use caseUse cases are technique for capturing functional requirements of a system.It describe the typical interaction between the users of the system and the system itself.A scenario is a sequence of steps describing an interaction between a actors and a System .An actor is something with behavior, such as a person (identified by role), computer system, or organization; for example, a cashier.
3Scenario Example (web based online store) The customer browses the catalog and adds desired items to the Shopping basket. When the customer wishes to pay, the customer describes the shipping and credit card information and confirms the sale . The System Checks the authorization and the credit card and confirms the sale both immediately and with a follow-up .
4Use CaseStart the use case by writing the main success scenario as a sequence number of step.Then take the other (alternative) scenario and write the as Extensions.
5Main Success Scenario Example Buy a Product Goal Level : Sea Level Main Success Scenario : 1 . Customer browses catalog and selects items to buy 2 . Customer goes to check out 3. Customer fills in shipping information (address ; next-day or 3-day delivery) 4. System presents full pricing information, including shipping 5 . Customer fills in credit card information 6 . System authorizes purchase 7 . System confirms sale immediately B . System sends confirming to customer Extensions : 3a : Customer is regular customer .1 : System displays current shipping, pricing, and billing information .2 : Customer may accept or override these defaults, returns to MSS at step 6 6a : System fails to authorize credit purchase .1 : Customer may reenter credit card information or may cancel
6Use Case Types and Formats Black-box use cases are the most common and recommended kind.They do not describe the internal workings of the system, its components, or design.The system is described as having responsibilities.Specify what the system must do (the functional requirements) without deciding how it will do it (the design).
7Black Box Style Example NotBlack-box styleThe system writes the sale to a database....or (even worse):The system generates a SQL INSERTstatement for the sale...The system records the sale.
8Use Case FormatFully dressed - the most elaborate. All steps and variations are written in detail, and there are supporting sections, such as preconditions and success guarantees.Brief - terse one-paragraph summary, usually of the main success scenario.Casual - informal paragraph format. Multiple paragraphs that cover various scenarios.
9Use Case Steps1. Choose the system boundary. Is it just a software application, the hardware and application as a unit, that plus a person using it, or an entire organization? 2. Identify the primary actors. Those that have user goals fulfilled through using services of the system. 3. For each, identify their user goals. Raise them to the highest user goal level that satisfies the EBP guideline. 4. Define use cases that satisfy user goals; name them according to their goal. Usually, user goal-level use cases will be one-to-one with user goals, but there is at least one exception, as will be examined.
10NameActorsAn actor is anything with behavior, including the system under discussion.3 kind of Actor:Primary actor-> has user goals fulfilled through using services of the system under discussion.Supporting actor-> provides a service to the system under discussion.Offstage actor -> has an interest in the behavior of the use case, but is not primary or supporting
11Using Use Case Diagrams Use case diagrams are used to visualize, specify, construct, and document the (intended) behavior of the system, during requirements capture and analysis.Provide a way for developers, domain experts and end-users to Communicate.Use case diagrams contain use cases, actors, and their relationships.
12Elements of Use Case Diagram: 2-Actor3-RelationshipsBetween use casesGeneralizationIncludeExtendBetween ActorsBetween use cases and actors
13Use CaseDo somethingSystem function (process – automated or manual). Named by verb.Each Actor must be linked to a use case,while some use cases may not be linked to actors.= Use Case
14Relationship Relationship can be: Between usecases Between Actors Between usecases and actors.
153.1 Relationships between Use Cases 1. Generalization - use cases that are specialized versions of other use cases.2. Include - use cases that are included as parts of other use cases. Contain the functionality of another use case as part of their normal processing.3. Extend - use cases that extend the behavior of other core use cases. Enable to factor variants.
161. Generalization The child use case inherits the behavior and meaning of theparent use case.The child may add to oroverride the behavior of its parent.parentchild
17More about Generalization registrationgraduatenon-graduate
18Generalization Example The actor Order Registry Clerk can instantiate the general use case Place Order. Place Order can also be specialized by the use cases Phone Order or Internet Order.
202. Includebaseincluded<<include>>The base use case explicitly incorporates the behavior of another use case at a location specified in the base.The included use case never stands alone. It only occurs as a part of some larger base that includes it.
21More about IncludeEnables to avoid describing the same flow of events several times by putting the common behavior in a use case of its own.updatinggradesoutputgeneratingverifyingstudent id<<include>>ניתוח מערכות מידע
22Include relationshipInclude relationship – a standard case linked to a mandatory use case.Example: to Authorize Car Loan (standard use case),a clerk must run Check Client’s Credit History (include use case).The standard UC includes the mandatory UC (use the verbto figure direction arrow).Standard use case can NOT execute without the include case tight coupling .Note: Visio calls this “uses” relationship.
23Reading use case diagram with Include relationship
253. Extendbaseextending<<extend>>The base use case implicitly incorporates the behavior of another use case at certain points called extension points.The base use case may stand alone, but under certain conditions its behavior may be extended by the behavior of another use case.
26More about ExtendEnables to model optional behavior or branching under conditions.Exam copy requestExam-grade appeal<<extend>>
27Extend relationship Extend relationship – linking an optional use case to a standard use case.Example: Register Course (standard use case) may haveRegister for Special Class (extend use case) – class fornon-standard students, in unusual time, with specialtopics, requiring extra fees…).The optional UC extends the standard UCStandard use case can execute without the extend case loose coupling.
293.2 Relationships between Actors Generalization.studentnon-graduategraduate
303.3 Relationships between Use Cases and Actors Actors may be connected to use cases by associations, indicating that the actor and the use case communicate with one another using messages.updatinggradesfaculty
31Example place phone call cellular network user receive conference call additional callusescheduler<<extend>>Cellular Telephone
33Each use case may include all or part of the following: Title or Reference Name - meaningful name of the UCAuthor/Date - the author of the UC and its creation dateModification/Date - last modification to the UC and its datePurpose - specifies the goal to be achieved by the UCOverview - short description of the use cases processesCross References - requirements referencesActors - agents which initiate or participate in the UCPre Conditions - must be true to allow the execution of the UCPost Conditions - will be set when the use use completes its execution normallyNormal flow of events - regular flow of activities of the UCAlternative flow of events - other flow of activities of the UCExceptional flow of events - unusual situationsImplementation issues - possible foreseen problems in the implementation of the UCUse Case DescriptionEach use case may include all or part of the following:Title or Reference Name - meaningful name of the UCAuthor/Date - the author and creation dateModification/Date - last modification and its datePurpose - specifies the goal to be achievedOverview - short description of the processesCross References - requirements referencesActors - agents participatingPre Conditions - must be true to allow executionPost Conditions - will be set when completes normallyNormal flow of events - regular flow of activitiesAlternative flow of events - other flow of activitiesExceptional flow of events - unusual situationsImplementation issues - foreseen implementation problems
35Example- Money Withdraw Use Case: Withdraw MoneyAuthor: ZBDate: 1-OCT-2004Purpose: To withdraw some cash from user’s bank accountOverview: The use case starts when the customer inserts his credit card into the system. The system requests the user PIN. The system validates the PIN. If the validation succeeded, the customer can choose the withdraw operation else alternative 1 – validation failure is executed. The customer enters the amount of cash to withdraw. The system checks the amount of cash in the user account, its credit limit. If the withdraw amount in the range between the current amount + credit limit the system dispense the cash and prints a withdraw receipt, else alternative 2 – amount exceeded is executed.Cross References: R1.1, R1.2, R7
36Example- Money Withdraw (cont.) Actors: CustomerPre Condition:The ATM must be in a state ready to accept transactionsThe ATM must have at least some cash on hand that it can dispenseThe ATM must have enough paper to print a receipt for at least one transactionPost Condition:The current amount of cash in the user account is the amount before the withdraw minus the withdraw amountA receipt was printed on the withdraw amountThe withdraw transaction was audit in the System log file
37Example- Money Withdraw (cont.) Typical Course of events:Actor ActionsSystem Actions1. Begins when a Customer arrives at ATM2. Customer inserts a Credit card into ATM3. System verifies the customer ID and status5. Customer chooses “Withdraw” operation4. System asks for an operation type7. Customer enters the cash amount6. System asks for the withdraw amount8. System checks if withdraw amount is legal9. System dispenses the cash10. System deduces the withdraw amount from account11. System prints a receipt13. Customer takes the cash and the receipt12. System ejects the cash card
38Example- Money Withdraw (cont.) Alternative flow of events:Step 3: Customer authorization failed. Display an error message, cancel the transaction and eject the card.Step 8: Customer has insufficient funds in its account. Display an error message, and go to step 6.Step 8: Customer exceeds its legal amount. Display an error message, and go to step 6.Exceptional flow of events:Power failure in the process of the transaction before step 9, cancel the transaction and eject the card
39Example- Money Withdraw (cont.) One method to identify use cases is actor-based:- Identify the actors related to a system or organization.- For each actor, identify the processes they initiate or participate in.A second method to identify use cases is event-based:- Identify the external events that a system must respond to.- Relate the events to actors and use cases.The following questions may be used to help identify the use cases for a system:What are tasks of each actor ?Will any actor create, store, change, remove, or read information in the system ?What use cases will create, store, change, remove, or read this information ?Will any actor need to inform the system about sudden, external changes ?Does any actor need to be informed about certain occurrences in the system ?Can all functional requirements be performed by the use cases ?
40אפיון וניתוח מערכות מידע - הרצאה 4 Moving onThe “things” that “live” inside the system are responsible for carrying out the behavior the actors on the outside expect the system to provide.To implement a use case, we create a society of classes that work together to carry out the behavior of the use case.
41How to create use case diagram 1. List main system functions (use cases) in a column:think of business events demanding system’s responseusers’ goals/needs to be accomplished via the systemCreate, Read, Update, Delete (CRUD) data tasks2. Draw ovals around the function labels3. Draw system boundary4. Draw actors and connect them with use cases (if more intuitive, this can be done as step 2)5. Specify include and extend relationships between use cases
42Elements of use case diagram Summary Connection between Actor and Use CaseBoundary of system<<include>>Include relationship between Use Cases (one UC mustcall another; e.g., Login UC includes User Authentication UC)<<extend>>Extend relationship between Use Cases (one UC callsAnother under certain condition; think of if-then decision points)
43Elements of use case diagram Summary nameUse case , starts with a verbnameActor can be human or other system