Lecture 7 - Use Case Modelling PDF

System Analysis and Design By Dr. Marwa Hussien Mohamed Information Systems dept. Faculty of Computer Science and Information Systems  Lecture 7 Use Case Analysis Learning Objectives Explain the purpose of use cases in the analysis phase of the SDLC. Describe the various parts of a use...

System Analysis and Design By Dr. Marwa Hussien Mohamed Information Systems dept. Faculty of Computer Science and Information Systems  Lecture 7 Use Case Analysis Learning Objectives Explain the purpose of use cases in the analysis phase of the SDLC. Describe the various parts of a use case and the purpose of each part. Explain the process used to create a use case. Describe how use cases contribute to the functional requirements. Describe how use cases inform the development of test plans. In the Previous Lecture we Learned… The systems analysts sat down with users and try to express what the system should do. This was a challenge for the users for several reasons. 1. Users may not know what is and is not possible for the system to do, as they don’t understand the capabilities and limitations of information systems technologies. 2. Users may have difficulty describing new ways to redesign business processes. 3. Commonly, users describe things they think they want from the new system, but not the real needs for the new system. 4. Users often found it difficult to learn the process and data modeling languages used by the analysts. Next, we discuss how to presented those requirements in the form of use-case and activity diagrams and use-case descriptions 4 Use Cases A use case is a formal way of representing the way a business system interacts with its environment. It illustrates the activities performed by the users of the system. Use-case modeling is an external or functional view of a business process in that it shows how the users view the process rather than the internal mechanisms by which the process and supporting systems operate. Use cases can document the current system (i.e., as-is system) or the new system being developed (i.e., to-be system). Creating use cases helps ensure that users’ insights are explicitly incorporated into the new system. 5 Activity Diagram An activity diagram can be used for any type of process-modeling activity. Process models depict how a business system operates. They illustrate the processes or activities that are performed and how objects (data) move among them. A process model can be used to document a current system (i.e., as-is system) or a new system being developed (i.e., to-be system), whether computerized or not. 6 From Requirements to Functional Models Now begin the process of turning the requirements into functional models Models are logical; i.e., independent of how they are implemented (manual or computerized) Develop use-cases from the requirements Use-case: how a business system interacts with its environment Includes a diagram and a description to depict the discrete activities that the users perform Develop activity diagrams from the use-cases These model the business processes or how a business operates Used to illustrate the movement of objects (data) between activities 7 Business Process Identification with Use Cases and Use-case Diagrams The first step for modeling business processes with use cases and the use-case diagram. An analyst can employ use cases and the use-case diagram to better understand the functionality of the system at a very high level. A use-case diagram provides a simple, straightforward way of communicating to the users exactly what the system will do, a use- case diagram is drawn when gathering and defining requirements for the system. The use-case diagram can encourage the users to provide additional high-level requirements. A use-case diagram illustrates in a very simple way the main functions of the system and the different kinds of users that will interact with it. 8 Use Case Diagram – Example (Appointment system) 9 Elements of Use Case Diagrams 10 Elements of Use Case Diagrams 11 Use Case Diagram – Example 12 Use Case Diagram – Example 13 Identifying the Major Use Cases 1. Review the requirements definition, to help the analyst to get a complete overview of the underlying business process being modeled. 2. Identify the subject’s boundaries, to help the analyst to identify the scope of the system. However, as we work through the development process, the boundary of the system most likely will change. 3. Identify the primary actors and their goals. The primary actors involved with the system comes from a list of stakeholders and users. Identifying the tasks that each actor must perform. For example, does the actor need to create, read, update, delete, or execute any information currently in the system, are there any external changes of which an actor must inform the system, or is there any information that the system should give the actor? 14 Identifying the Major Use Cases 4. Identify the business processes and major use cases. Identifying only the major use cases at this time prevents the users and analysts from forgetting key business processes and helps the users explain the overall set of business processes for which they are responsible. 5. Carefully review the current set of use cases. Split some of them into multiple use cases or merge some of them into a single use case, if needed. Identifying use cases is an iterative process, with users often changing their minds about what a use case is and what it includes The trick is to select the right size so that you end up with 3 to 9 use cases in each system. 15 Creating a Use-Case Diagram There are four major steps in drawing a use-case diagram. 1. First, place and draw the use cases on the diagram. These are taken directly from the major use cases previously identified. Special use-case associations (include, extend, or generalization) are also added to the model. Be careful in laying out the diagram (ordering of the use cases in the diagram). There should be no more than three to nine use cases on the model so the diagram is as simple as possible. 2. Second, the actors are placed and drawn on the diagram. Place the actors near the use cases to minimize the number of lines that cross on the diagram. 3. Third, the subject boundary is drawn. This forms the border of the subject, separating use cases (i.e., the subject’s functionality) from actors. 4. Fourth, add associations by drawing lines to connect the actors to the use cases with which they interact. 16 Example – A Library Management System Please Refer to the book Page 162, 163 – 4th edition 17 Business Process Modeling With Activity Diagrams Business processes consist of a number of activities Activity diagrams depict the sequence of these activities Diagrams are abstract and describe processes in general They model behavior independent of objects Can be used for any type of process 18 Elements of an Activity Diagram 19 Elements of an Activity Diagram 20 Elements of an Activity Diagram 21 Activity Diagram for the Manage Appointments Use Case 22 Activity Diagram for Making a School Lunch Box 23 Guidelines for Drawing the Activity Diagram 1. Set the context or scope of the activity being modeled and give the diagram an appropriate title. 2. Identify the activities, control flows, and object flows that occur between the activities. 3. Identify any decisions that are part of the process being modeled. 4. Identify any prospects for parallelism in the process. 5. Draw the activity diagram. 24 Creating an Activity Diagram Choose a business process identified previously Review the requirements definition and use-case diagram Review other documentation collected thus far Identify the set of activities used in the business process Identify control flows and nodes Identify the object flows and nodes Lay out & draw the diagram (minimize crossing lines) 25 Example – Borrow Book Activity Diagram 26 Business Process Documentation with Use Cases and Use-Case Descriptions Use-case diagrams provided a view of the basic functionality of the business processes contained in the evolving system. Activity diagrams is providing a more-detailed graphical view of the underlying activities that support each business process. Use-case descriptions provide a means to more fully document the different aspects of each individual use case. They contain all the information needed to document the functionality of the business processes. Depicts activities performed by the users Describe basic functions of the system: What the user can do How the system responds Use cases are building blocks for continued design activities Each use-case describes 1 and only 1 function 27 Elements of a Use-Case Description - Overview Information Identifies the use case and provides basic background information about the use case. Name: should be a verb–noun phrase (e.g., Make Old Patient Appt). ID number: provides a unique way to find every use case. The use-case type: is either overview or detail. The primary actor: the person that starts the execution of the use case. The primary purpose of the use case is to meet the goal of the primary actor. Brief description: a single sentence that describes the essence of the use case. The importance level: can be used to prioritize the use cases. Stakeholder(s): that have an interest in the use case. Trigger: the event that causes the use case to begin. External trigger, such as a customer placing an order or the fire alarm ringing, Temporal trigger, such as a book being overdue at the library or the need to pay the rent. 28 Example: Use-Case Description - Overview Information 29  Use-case relationships explain how the use case is related to other use cases and users. 1. An association relationship documents the communication that takes place between the use case and the actors that use the use case. 2. An include relationship represents the mandatory Elements of a inclusion of another use case (the breaking up of a complex use case into several simpler ones). Use-Case 3. An extend relationship represents the extension of the functionality of the use case to incorporate optional Description - behavior. 4. The generalization relationship allows use cases to Relationships support inheritance. 30 Elements of a Use-Case Description – Flow of Events 1. Normal flow: includes only steps that normally are executed in a use case. The steps are listed in the order in which they are performed. 2. Sub-flows: decomposed normal flows to simplify the use-case 3. Alternate or exceptional flows: those not considered the norm 31 Example: Use-Case Description – Flow of Events 32 Example: Use-Case Description – Make Old Patient Appointment 33 Creating Use-Case Descriptions 1. Pick a high priority use-case and create an overview: List the primary actor Determine its type (overview or detail; essential or real) List all stakeholders and their interests Determine the level of importance of the use-case Briefly describe the use-case List what triggers the use-case List its relationship to other use-cases 2. Fill in the steps of the normal flow of events required to complete the use-case 3. Ensure that the steps listed are not too complicated or long and are consistent in size with other steps 4. Identify and write the alternate or exceptional flows 5. Carefully review the use-case description and confirm that it is correct 6. Iterate over the entire set of steps again 34 Example: Borrow Book Use-Case Description 35 Example: Borrow Book Use-Case Description 36 Verifying & Validating a Use-Case Use-cases must be verified and validated before beginning structural and behavioral modeling Utilize a walkthrough: Perform a review of the models and diagrams created so far Performed by individuals from the development team and the client (very interactive) Facilitator: schedule and set up the meeting Presenter: the one who is responsible for the specific representation being reviewed Recorder to take notes and especially to document errors 37 Rules for Verification & Validation 1. Ensure one recorded event in the flows of the use-case description for each action/activity on the activity diagram 2. All objects in an activity diagram must be mentioned in an event of the use-case description 3. The sequence of the use-case description should match the sequence in the activity diagram 4. One and only one description for each use-case 5. All actors listed in a use-case description must be shown on the use-case diagram 6. Stakeholders listed in the use-case description may be shown on the use-case diagram (check local policy) 7. All relationships in the use-case description must be depicted on the use-case diagram 8. All diagram-specific rules must be enforced 38 Modified Use Case Diagram for Appointment System 39 Tune Source – Case Study After analyzing the requirements definition document, the system analysts identify the major use cases (be careful to thought how to structure the use cases). Thinking carefully about these requirements, we can see that there are three significant triggering events: A customer arrives at the site to search and/or browse music selections; a customer selects a tune to download and buy; and the marketing department wishes to create special promotions. 40 Tune Source – Case Study First use case: When a customer arrives at the site, he or she will normally browse a predefined category of music (1.1) or enter a search for a particular title, artist, or genre of music (1.2). If the customer has visited the site and created entries on a Favorites list or has purchased any tunes in the past, the display of tunes on the site will be tailored to the customer’s interests (3.1, 3.3). The customer may select one or more music samples to which to listen (1.3, 3.1). The customer may add tunes to his Favorites list at any time (1.4). 41 UC-1: Search and browes tunes 42 Tune Source – Case Study Second use case: A customer triggering the purchase process, is kept separate from the search and browse event, although both events involve the customer. Purchasing involves gathering information about the customer (2.1), the music selection (2.2), and the method of payment (2.1, 2.3) and verifies the payment information (2.4) before the download process is triggered. 43 UC-2: Purchase tunes 44 Tune Source – Case Study Third use case: on a periodic basis, customer Favorites lists and purchase records are reviewed by the marketing department so that promotions and Web specials can be developed (3.2). Targeted promotions are created for when customers revisit the site (3.3). Specific e-mails will be directed to customers, offering additional special promotions (3.4). 45 UC-3: Promote tunes 46 Tasks to do this week Hand in: Choose appropriate requirement gathering technique(s). Prepare requirement document (Functional and non-functional). Prepare: Draw the Use cases Diagram using any online drawing tools. For some of the Use cases, Draw the activity diagram using online drawing tool. Make Use-Case description for (at least) 3 main use cases in your system. Suggested Tools: https://yuml.me/ online.visual-paradigm.com smartdraw www.edrawsoft.com › software-diagrams www.draw.io 47