Slide 1 Systems Analysis and Design with UML Version 2.0, Second Edition Chapter 6: Functional Modeling

Slide 2 Objectives ■ Understand the rules and style guidelines for activity diagrams. ■ Understand the rules and style guidelines for use cases and use case diagrams. ■ Understand the process used to create use cases and use case diagrams. ■ Be able to create functional models using activity diagrams, use cases, and use case diagrams. ■ Become familiar with the use of use case points.

Slide 3 Business Process Modeling with Activity Diagrams Elements of an Activity Diagram Guidelines for Creating Activity Diagrams

Slide 4 BPM With Activity Diagrams A number of activities support a business process across several departments Activity diagrams model the behavior in a business process Sophisticated data flow diagrams Addresses Parallel concurrent activities and complex processes

Slide 5 Activity Diagram Example

Slide 6 Activity Diagrams Activity Diagrams can model: An entire system A Subsystems of a system A subsystem A use case A method

Slide 7 Activity Diagrams Activity diagrams are most helpful in defining subsystems or subprocesses of large systems (We do not hand in activity diagrams as a deliverable in this class.)

Slide 8 Activity Diagrams Components of the Activity Diagram Initial node Activity final node Activity nodes Flow/edges Forks, and Joins Conditions. Decisions, and Merges Partitions Sub-activity indicators Flow final

Slide 9 NEW Activity Diagram Components Represents the starting node Represents the ending node Activity or action Activity may have 1.M actions Represents objects participating ( can be omitted at first) Represents a decision point in flow Represents joining and forking of parallel activities

Slide 10 Creating Activity Diagrams 1. Since an activity diagram is used to model various granularity of processes – FIRST determine the context or scope of the activity being modeled. 2. Identify the initial node and final node to set the context of the scope. Initial node. The filled in circle is the starting point of the diagram. An initial node isn’t required although it does make it significantly easier to read the diagram. Activity final node. The filled circle with a border is the ending point. An activity diagram can have zero or more activity final nodes.

Slide 11 Creating Activity Diagrams Place The Initial Node In The Top-Left Corner. A initial node is modeled with a filled in circle. Place The Final Node at the Lower-Right Corner. A final node is modeled with a filled circle inside a clear circle.

Slide 12 Creating Activity Diagrams 3. Identify activity nodes needed in this process being modeled. Activity. The rounded rectangles represent activities that occur within the process being modeled. The example below is a simple enroll in the university use case. It is just a simple way to model this activity.

Slide 13 Creating Activity Diagrams Fill out enrollment forms Enroll in University Get help to fill out forms Attend Orientation Make Tuition Payment Place the activities in a somewhat sequential order of the flow of events within the process being modeled. Enroll in Seminar

Slide 14 Creating Activity Diagrams 4. Connect the activities with flows. Flow/edge. The arrows on the diagram.

Slide 15 Creating Activity Diagrams Fill out enrollment forms Enroll in University Get Help to fill out forms Attend Orientation Make Tuition Payment Enroll in Seminar

Slide 16 Creating Activity Diagrams 5. Add any forks, joins, decisions, or merges. Fork. A black bar with one flow going into it and several leaving it. This denotes the beginning of parallel activity Join. A black bar with several flows entering it and one leaving it. All flows going into the join must reach it before processing may continue. This denotes the end of parallel processing. Decision. A diamond with one flow entering and several leaving. The flows leaving include conditions although some modelers will not indicate the conditions if it is obvious. Merge. A diamond with several flows entering and one leaving. The implication is that one or more incoming flows must reach this point until processing continues, based on any guards on the outgoing flow.

Slide 17 Creating Activity Diagrams Fill out enrollment forms Enroll in University Get Help to Fill out forms Attend Orientation Make Tuition Payment Enroll in Seminar incorrect correct

Slide 18 USE-CASE DESCRIPTIONS

Slide 19 Key Ideas A use case illustrates the activities that are performed by users of a system. Use cases are logical models -- they describe the activities of a system without specifying how the activities are implemented.

Slide 20 Two Approaches Approaches to creating the two components of the use case include: 1. Create the use case description first and from it create the use case diagram. (text approach) 2. Create the use case diagram first, then create the use case diagram, and revise the diagram if needed after the description is written. (our approach)

Slide 21 What are Use-Case Descriptions? Describes use cases defined in the use case diagram. What the user can do How the system responds Use cases are building blocks for continued design activities.

Slide 22 Types of Use-Cases Overview versus detail ■ The use case represents an important business process. ■ The use case supports revenue generation or cost reduction. ■ Technology needed to support the use case is new or risky and therefore will require considerable research. Essential versus real

Slide 23 Data Dictionary Use Case Documentation Name ID Requirement Number Description Primary Actor Secondary Actor(s) Pre-condition Post-condition Trigger Normal Scenario … Extensions … Use Case Description

Slide 24 CREATING USE-CASE DESCRIPTIONS

Slide 25 Use Case A major process performed by the system that benefits an actor(s) in some way Models a dialogue between an actor and the system Represents the functionality provided by the system

Slide 26 Use Case Diagram 1. Project team gathers requirements from the users about functionality of the system to be built. 2. Project team prepare: a) Use case diagram b) Use case description for each use case in the use case diagram 3. Analysts create class diagrams.

Slide 27 Elements of a Use-Case Description Use Case NameIDREQ# Description Primary and Secondary Actors: Pre-conditions Post-conditions Trigger Normal scenario Extensions

Slide 28 Elements of a Use-Case Description Use Case Name:ID:Importance Level: Primary Actor:Use Case Type: Stakeholders and Interests: Brief Description: Trigger: Relationships: (Association, Include, Extend, Generalization) Normal Flow of Events: Subflows: Alternate/Exceptional Flows: While there are many variations, our use case description is explained in this weeks lecture.

Slide 29 Use-case Description General Contents for description Use-case name should be a verb-noun phrase ID (ID Number) REQ# (Requirement Number) Description Typically a single sentence that describes the essence of the use case

Slide 30 Use-case Description Primary actor Person or thing that starts the execution of the use case Secondary actor People who have an interest in the use case Together often known as “stakeholders”

Slide 31 Pre-condition The necessary conditions that have to be met before the use case can be performed When writing a precondition, you are making a simple assertion statement about the current state of the world when this use case opens. The mistake in writing preconditions is writing something that is often, but not always, true.

Slide 32 Pre-condition Examples User is logged on. Customer has been validated. The system has already located the customer’s policy information.

Slide 33 Post-conditions The state of the system after the use case is performed The value delivered to the actor These statements state what interests that are satisfied after a successful conclusion of the use case.

Slide 34 Triggers Specifies the event that gets the use case started. It precedes the first step of the scenario.

Slide 35 Examples of Triggers Trigger: Customer inserts card. Trigger: Customer calls in complaint.

Slide 36 Normal Scenario Path that an end user is mostly likely to follow Goal is to satisfy the stakeholders’ interests

Slide 37 Normal Scenario Every scenario is written as a sequence of goal-achieving actions of the various actors. 3 kinds of action steps: An interaction between two actors A validation step to protect an interest of a stakeholder An internal change to satisfy an interest of a stakeholder

Slide 38 Normal Scenario 1. Clerk enters insured’s policy number or else name and date of incident. 2. System populates available policy information and indicates claim is matched to policy. 3. Clerk enters basic loss information. 4. System confirms there are no competing claims and assigns a claim number. 5. Clerk continues entering loss information specific to claim line. 6. Clerk has System pull other coverage information from other computer systems. 7. Clerk selects and assigns an Adjuster. 8. Clerk confirms he/she is finished. 9. System saves and triggers acknowledgement to be sent to Agent.

Slide 39 Normal Scenario Each statement is written to show a simple, active action. These statements are written as a soccer match: Person 1 kicks ball to person 2 Person 2 dribbles ball Person 2 kicks ball to person 3

Slide 40 Heuristics Write each step in “SVDPI” form Clarify initiator and receivers of action (actors involved) Try to keep each step at the same level of abstraction Ensure a sensible set of steps Apply KISS principle liberally Write repeating instructions after the set of steps to be repeated.

Slide 41 Guidelines: Action Steps Show clearly “Who Has the Ball” Establish at all times who has possession of the statement (who has the ball) Example:  Customer puts in the ATM Card.

Slide 42 Guidelines: Action Steps Write from a bird’s eye view Do not write as the system looking out to the world, rather write as an onlooker to the system.

Slide 43 Guidelines: Action Steps Write from a bird’s eye view Example:  (Bad) Get ATM Card and PIN number.  (Good) The customer puts in the ATM card and PIN. Example:  (Bad) Deduct amount from account balance.  (Good) The system deducts the amount from the account balance.

Slide 44 Guidelines: Action Steps Show the process moving forward Do not make the use case lengthy  Typically a use case should be no longer than 9 actions steps in the primary scenario If there is a problem decreasing the length of the statement, ask “Why is the actor doing that?”

Slide 45 Guidelines: Action Steps Show the actor’s intent, not the movements Bad example: 1. System asks for name. 2. User enters name. 3. System prompts for address. 4. User enters address. 5. User clicks “OK’. 6. System presents user’s profile.

Slide 46 Guidelines: Action Steps Show the Actor’s Intent, Not the Movements Good example: 1. User enters name and address. 2. System presents user’s profile.

Slide 47 Guidelines: Action Steps Include a “Reasonable” Set of Actions Transactions have four parts:  Primary actor sends request and data to system  System validates request and the data  The system alters its internal state  The system responds to the actor with the result.

Slide 48 Guidelines: Action Steps “Validate”; don’t “check whether” Don’t state in an action step “Check Whether” Use an affirmative statement “Validates” If you check whether, the next statement typically has an if condition statement following.

Slide 49 Guidelines: Action Steps “Validate”; don’t “check whether” Bad example: 1. The system checks whether the password is correct. 2. If it is, the system presents the available actions for the user. Good example: 1. The system validates that the password is correct. 2. The system presents the available actions for the user.

Slide 50 Guidelines: Action Steps Optionally mention the timing Timing typically is obvious and doesn’t need to be mentioned; however, there may be a time that it does need to be mentioned As soon as the user has…the system will… At any time between steps 3 and 5, the user will…

Slide 51 Guidelines: Action Steps Do steps x-y until condition If one step is being repeated, put the repetition right after the statement If several steps are being repeated, put the repetition statement before or after the block of steps

Slide 52 Guidelines: Action Steps Do steps x-y until condition 1. The user selects one or more products. 2. The user searches through various product catalogs until he/she finds the one he/she wants to use.

Slide 53 Guidelines: Action Steps Do steps x-y until condition 1. Customer supplies either account identifier or name and address. 2. System brings up the customer’s preference information. 3. User selects an item to buy, marks it for purchase. 4. System adds the item to the customer’s “shopping cart.” Customer repeats steps 3-4 until indicating that he/she is done. 5. Customer purchases the items in the shopping cart.

Slide 54 Extension Mini-use case Is added on to a primary scenario Minimizes the number of use cases needed Warning: “You never have a conditional statement in a use case.” Extensions blatantly contradict this statement.

Slide 55 Sample Extension 4. User has the system save the document. … Extensions: 4a. System autodetects the need to save: 4a1. Save Document 4b. Save fails: 4b1. Display Error Message

Slide 56 How to Write Extensions Extensions can be failures, exceptions, or alternative ways of accomplishing the primary scenario’s goal. Example: Primary scenario expects user to save file by clicking save. Instead, user does nothing and an auto-save function saves the file.

Slide 57 Guidelines for Extension Writing Say only what was detected. Don’t write “User forgot pin number” Write “Wrong pin number detected.” or “No pin number entered.” Conditions often followed by colon:

Slide 58 Example of Extension … 7. User has PAF save the work. 8…. Extensions: 7a. Save Fails: 7a1…whatever should happen next.

Slide 59 Extensions as Separate Use Cases Trigger is the extension condition. Goal is either to complete the goal of the high-level use case or correct the error. Becomes an > use case

Slide 60 Use Case Example Client Financial Officer Capture deal

Slide 61 Poorly Written Normal Scenario 1. Enter the client name and bank account 2. Check that they are valid 3. Enter number of shares to buy & share ID 4. Determine price 5. Check limit 6. Prepare order to NYSE 7. Store confirmation number and give it to client

Slide 62 Rewrite of the Poorly Written Normal Scenario 1. The client enters his/her name and bank account. 2. The system validates that the name and bank account are valid. 3. The client enters the number of shares to buy and share ID. 4. The system determines the price. 5. The system check the limit for this client 6. The financial officer prepares the order to NYSE. 7. The financial officer enters the confirmation number for the order in the system. 8. The system stores the confirmation number and gives it to the client

Slide 63 Example of Use Case Use Case: Buy Stock Online Precondition: User already has PAF open Trigger: User selects “buy stocks” over the web

Slide 64 Example of Use Case Normal Scenario: 1 PAF gets name of web site (E*Trade, Schwab, etc.) to use from user. 2PAF opens web connection to the site, retaining control 3 User browses and buys stock from the web site 4 PAF intercepts responses from the web site and updates the user’s portfolio 5 PAF shows the user the new portfolio standing

Slide 65 Example of Use Case Extensions: 3a. Web failure of any sort during setup: 3a1. System reports failure to user with advice, backs up to previous step. 3a2. User either backs out of this use case or tries again.

Slide 66 Steps to Creating Use Case Descriptions and Diagram Identify the major use cases 1. Identify the system’s boundaries 2. List the primary actors 3. List all the goals (functionality) that the actors have in relation to the system 4. Identify and write the overview descriptions of major use cases 5. Review current use cases

Slide 67 Steps to Creating Use Case Descriptions and Diagram Expand a major use case 1. Choose one of the use cases to expand 2. Start filling in the details (on the use- case description) for this chosen use case 3. Write the normal flow of events of the use case 4. Write any needed extensions (subflows or alternate flows) 5. For each extension, list how the actor and/or system should react

Slide 68 Steps to Creating Use Case Descriptions and Diagram Review the Major Use Cases in detail Create the Use-case diagram 1. Draw the system boundary 2. Place the use cases on the diagram 3. Place the actors on the diagram 4. Draw the relationships

Slide 69 USE-CASE DIAGRAMS

Slide 70 Syntax for Use-Case Diagram

Slide 71 The Use-Case Diagram for Appointment System

Slide 72 Use-Case Diagram with Specialized Actor

Slide 73 Extend and Include Relationships

Slide 74 CREATING USE-CASE DESCRIPTIONS AND USE- CASE DIAGRAMS

Slide 75 Major Steps in Writing Use- Cases Case Diagrams Identify the major use-cases Expand the major use-case Confirm the major use-cases Create the use-case diagram

Slide 76 Identifying the Major Use- Cases Identify the system’s boundaries List the primary actors List the goals of each primary actor Identify and write the major use- cases Carefully review use-cases

Slide 77 Writing Effective Use-Case Descriptions

Slide 78 Expand the Major Use- Cases Choose one major use-case to expand Fill in details on the use-case template Fill in the steps of the normal flow of events Normalize the size of each step Describe alternate or exceptional flows Simplify and organize as necessary

Slide 79 Confirm the Major Use Cases Review the current set Consider semantics and syntax Helpful to involve the users Iterate the entire set of steps until all use cases are defined

Slide 80 Create the Use-Case Diagram Start with system boundary Place elements in order to be easy to read Place actors on the diagram Conclude by connecting actors to use cases by lines

Slide 81 Selecting the Appropriate Techniques Interviews JAD Questionnaires Document Observation Analysis Type of As-Is As-Is As-Is As-Is As-Is Information Improve. Improve. Improve. To-Be To-Be Depth of High High Medium Low Low Information Breadth of Low Medium High High Low Information Integration Low High Low Low Low of Info. User Medium High Low Low Low Involvement Cost Medium Low- Low Low Low- Medium Medium

Slide 82 USE-CASE ESTIMATION

Slide 83 Use Case Estimation Points Function Point analysis has long been a technique for estimating a system at an early stage of the project. Use Case Points are similar and aid in estimating the effort of each use case.

Slide 84 Refining Project Size with Case Points For EACH USE CASE: Determine Unadjusted Actor Weighting Table Obtain Unadjusted Use Case Weight Total Compute value of Unadjusted Use Case Points

Slide 85 Refining Project Size with Case Points Determine Unadjusted Actor Weight by classifying actors  Simple – have a well defined interface  Average actors – have a well defined interface from another system (TCP/IP, SQL, etc)  Complex Actors – typically end users communicating with an interface (GUI)

Slide 86 Refining Project Size with Case Points Obtain Unadjusted Use Case Weight by determining the number of unique transactions the use case must address.  Simple is 1-3 transactions  Average is 4-7 transactions  Complex is >7 transactions

Slide 87 Refining Project Size with Case Points Compute value of Unadjusted Use Case Points  This is simply the sum of the unadjusted actor weight total and the unadjusted use case total. At this point you are ready to adjust your points (one of the more difficult tasks)

Slide 88 Refining Project Size with Case Points The Adjusted Use Case Points will be discussed in the next class. For Now we will be satisfied with the unadjusted or Raw Use Case Points

Slide 89 Expanding the Domain Additional resources regarding use-cases and many other object-oriented development topics can be found at:

Slide 90 Summary Use-case descriptions are the basis for further analysis and design. They are created based on 7 guidelines and 13 steps. Use-case diagrams present a graphical overview of the main functionality of a system.