Unified Process and Use Case Diagrams Lecture Notes 2

1.12 Object Oriented Analysis and Design 1.4.2 Use Case Diagrams The diagrams which visualizes the use cases are called use case diagrams. This was introduced by Jacobson in 1994. The use case diagram is a part of UML. One of the projects in which use cases are involved are • Keeping each one on an index card and • Sorting the cards into piles to show what needed building in each iteration Example We can see the use cases for a financial trading system. Actors An actor is a role that a user plays with respect to the system. There are four actors in the above diagram • Trading manager • Trader • Salesperson and • Accounting System This can be also known as role but as far as system is concerned, all play the same role. A user may play more than one role. Unified Process and Use Case Diagrams 1.13 For example, • A senior trader any play the trading manager role and also the role of a trader. • A trader may also be a salesperson Actors carry out use cases. A single actor may perform many use cases and a use case may have several actors performing it Actors are most useful than the use cases. It is easier to arrive at a list of actors first and then try to workout the use cases for each other. Actors need not be human beings though they are represented as stick figures in the use case diagram. An actor can also be a external system that needs some information from the current system. Some people show every external system or human actor on the use case diagram. Others prefer to show the initiator of the use case. In some situations, we can track the actors later like. The system may need configuring for various kinds of users. Here each kind of user is an actor and use cases show what each actor needs to do. Tracking who wants use cases can help us to negotiate priorities among various actors. Some use cases don‟t have clear links to specific actors. Example:- In a utility company one of the use cases is to send out bill. Here no ser requests a bill or no customer is objecting if the doesn‟t get the bill. The best guess of the actor is given by the Billing Department. One way to identify use cases is external events. 1.4.3 Use Case Relationship Links exist between actors and use cases. In addition to that several kinds of relationship exist between use cases like 1) Include 2) Use case Generalization 3) Extend Include When we have a chunk of behavior that is similar across more than one use case and we don‟t want to copy the description of the behavior. Example: Both Analyze Risk and Price Deal require to value the deal. Instead of having a fair chunk of writing and copying it again, we can write a separate value Deal use case and refer it from the original use cases. Use Case Generalization When we have one use case that is similar to another use cases but does a bit more then we use, use case generalization. 1.14 Object Oriented Analysis and Design Example: The basic use case is capture Deal. One special case is when the limit is exceeded ie., the maximum amount the trading organization has established for a particular customer. Extend The third relationship called as extend is similar to generalization but with more rules to it. The extending use case may add behavior to the base use case, but it must declare certain “extension points” and the extending use case may add additional behavior only at those extension points. Extend Relationship A use case may have many extension points and an extending use case may extend one or more of these extension points. Apply the following rules Use include when you are repeating yourself in two or more separate use cases and you want to avoid repetition. Use generalization when you are describing a variation on normal behavior and you wish to describe it casually. Use extend when you are describing a variation on normal behavior and you wish to use the more controlled form, declaring your extension points in your base use case. Business and System Use Cases Two different use cases are there. They are • System Use Case • Business Use Case A system use case is dealing with the interaction with the software. Business use case discusses how a business responds to a customer or an event. Unified Process and Use Case Diagrams 1.15 Useage of Use Case Most of the use cases will be generated during the phase of the project but they will be unconverted as we proceed the project. Every use case is a potential requirement and, we can plan it only after we capture a requirement. Use cases represent an external view of the system. During a recent OOPSLA panel discussion, several use case experts said that for a 10 person year project, they would expect around a dozen use cases. These are base use cases, each use case would have many scenario and many variant use cases. 1.5 CASE STUDY - THE NEXTGEN POS SYSTEM INCEPTION Inception is the initial short step to establish a common vision and basic scope for the project. Inception deals with “Environment the product scope, vision and business case”. The purpose of inception is • To collect enough information to establish a common vision. • To decide if moving forward is feasible. 1.5.1 Use cases The use cases are text stories used to discover and record requirements. Use cases influence many aspect of a project. They are input to artifacts. The use cases also influence.  Analysis  Design  Implementation  Project management  Test artifacts 1.16 Object Oriented Analysis and Design The influence of UP artifacts is shown in the following figure. Figure 1.13 Sample UP Artifacts Relationships 1.5.2 Definitions (1) Actors Something with behaviour, such as A person (identified by role) Computer system Unified Process and Use Case Diagrams 1.17 or organization is called an actor Example: Cashier (2) Scenario A scenario is a specific sequence of actions and interactions between actors and the system. It is called use case instance. Example: Scenario of successfully purchasing items with cash. Scenario of failing to purchase items because of credit payment denial. Use Case Use case is a collection of related success and failure scenarios that describes an actor using a system to support a goal. Example: Main success scenario: A customer arrives at a shop to return items. The cashier uses POS system and records returned items. Alternative scenarios If customer paid credit and if return to the credit account is rejected, pay the customer with cash. If the item is not found, notify the cashier to enter manually etc. Thus RUP (Rational Unified Process) defines use case as “A set of use case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor”. 1.6 USE CASE MODELING Use cases and Use case Model Use Cases are text documents and not diagrams. Use case modeling is primarily an act of writing text, not drawing diagrams. Use cases are requirements Functional or Behavior Use cases emphasize the user goals and perspectives. 1.18 Object Oriented Analysis and Design The strength of use cases is the ability to scale both up and down in terms of • Sophistications and • Formality 1.6.1 Three kinds of Actors An actor is anything with behavior including the System Under Discussion (SUD) when it calls upon services of other systems. Actors are roles played not only by people but by organization. Example: • Software • Machines In relation to SUD there are three types of actors Primary actor Supporting actor Offstage actor (1) Primary actor It has user goals fulfilled by using services of SUD. Example: Cashier Finds user goals that drive use cases (2) Supporting actor It provides services to SUD. Example: Automated payment authorization (3) Offstage actor It has an interest in the behavior of use cases but not primary or supporting. Example: A government tax agency. Use case formats There are different formats for use cases like Brief • Brief • Casual • Fully dressed Unified Process and Use Case Diagrams • One paragraph summary of main success scenario. • It is written during early requirements analysis. • It is written to get a quick sense of subject and scope • 1.19 It can be written in a few minutes. Example: Process sale (given previously) Casual  Informal paragraph format  It involves multiple paragraphs that cover various scenarios. Example: Handle Returns Fully dressed • • Detailed steps are written. Supporting sections like preconditions are present. Example: Next Gen case study Processed sale, Fully Dressed style More detailed and structured style is given in fully dressed format. During the requirement analysis, 10% of the critical use cases are written in this format. The design and programming then starts on the most significant use cases or scenarios. Many templates are available for detailed use cases. The popular format template is given by Alistair Cockburn. The template is shown below Use case section Comment Use case Name Start with a verb Scope System under design Level “user-goal” or “subfunction” Primary Actor Calls on the system to deliver its services Stakeholders & interest Who cares about use case? What do they want? Preconditions What must be true on start, and worth telling the reader? Success Guarantee What must be true on successful completion, and worth telling the reader. 1.20 Object Oriented Analysis and Design Main Success scenario A typical, unconditional happy path scenario of success. Extensions Alternate scenarios of success or failure Special requirements Related non-functional requirements. Technology and data variations list Varying input methods and data formats Frequency of occurrence Influences investigation, testing and timing of implementation Miscellaneous Such as open issues This template can be used to the NextGen casestudy and the detailed illustration is shown below. The detailed branching scenarios are illustrated. Use Case UC1: Process Sale Scope: NextGen POS application Level: user goal Primary Actor: Cashier Stakeholders and Interests: • Cashier: Wants accurate, fast entry, and no payment errors, as cash drawer shortages are deducted from his/her salary. • Salesperson: Wants sales commissions updated. • Customer: Wants purchase and fast service with minimal effort. Wants easily visible display of entered items and prices. Wants proof of purchase to support returns. • Company: Wants to accurately record transactions and satisfy customer interests. Wants to ensure that Payment Authorization Service payment receivables are recorded. Wants some fault tolerance to allow sales capture even if server components (e.g., remote credit validation) are unavailable. Wants automatic and fast update of accounting and inventory. • Manager: Wants to be able to quickly perform override operations, and easily debug Cashier problems. • Government Tax Agencies: Want to collect tax from every sale. May be multiple agencies, such as national, state, and county. • Payment Authorization Service: Wants to receive digital authorization requests in the correct format and protocol. Wants to accurately account for their payables to the store. Preconditions: Cashier is identified and authenticated. Success Guarantee (or Postconditions): Sale is saved. Tax is correctly calculated. Accounting and Inventory are updated. Commissions recorded. Receipt is generated. Payment authorization approvals are recorded.