Systems Analysis And Design Chapter 4. Use Case PDF

Systems Analysis and Design Chapter 4. Use Case  What is a use case? Use cases are a means of expressing user requirements. Use cases are used extensively in the analysis phase. A use case represents how a system interacts with its environment by illustrating the activities that are p...

Systems Analysis and Design Chapter 4. Use Case  What is a use case? Use cases are a means of expressing user requirements. Use cases are used extensively in the analysis phase. A use case represents how a system interacts with its environment by illustrating the activities that are performed by the users and the system’s responses. 2  What is a use case? The Use Case usually consists of both ◼ a use case diagram, and ◼ use case specification or description (narrative). Together they document how users expect to interact with the system and how the system would interact with other external systems. Use case specifications are easy for the users to understand, also flows easily into the creation of process models, the data model, and UML diagrams like activity diagrams, sequence diagrams and so on. A big part of the system analyst job is to determine what could be a use case and what is not a use case. 3  Use Case Diagram and Use Case specification(Description ) 4  ATM System Use Case diagram The view represented by a Use Case diagram for an ATM application, for example, would correspond to the main screen of an ATM and the menu options available at that level. 5  ATM System Use Case diagram The ATM system offers the user a set of options such as withdraw, deposit, inquire on balance, and transfer funds. Each option can be represented by a separate Use Case. The use case description will describe the various scenarios that could happen during that use case. The customer (outside the system) is associated with each of the Use Cases (within the system) that he plans to use. 6 Difference between a Requirement and Use Case A simple requirement documents a process, but a Use Case focuses on the goal of a process. Focusing on the process often leads to reproducing existing systems, rather than redesigning them, precisely because it focuses on “how” rather than “why”. It’s much more effective to know why you are building a specific feature instead of just building it blindly. This keeps you open to a variety of solutions, allowing and possibly encouraging you to take advantage of technological advances. For example, if you know that a user needs to be notified if the money in his account is not enough for withdrawal. Then you would have the freedom to notify him by a beep, an alert message or even a talking message. 7  Importance of a Good Use Case Define the scope of the project. Help reveal any missing requirement. Help the management of the project. Can be assigned to teams or individuals to be modeled, designed or implemented. Track the progress of the project by use cases delivered. Help construct tests for your system. 8  Use Case Diagram Notations Let’s consider the use requirement of the withdraw money from the ATM system, and let’s consider that this is the only requirement offered by the ATM system for now. A use case is represented by an ellipse(oval shape) with the name of the use case inside it. Now how this use case affecting the outside world. The withdraw money as a use case in the ATM system is communicating with the client from the outside world. Just a simple line or an arrow between the client and the use case will do the job. 9 Use Case Diagram Notations How to indicate that this use case is a part of the ATM system. We put the use case in a box around the use case and putting the title of the system “ATM”. 10  Detail About Each Notation The Use case A use case is an ellipse combined with a short name. If you want to provide details about a use case. Show the use case as a rectangle, with the use case oval in the top-right corner. Now, place the name of the use case in the top, in bold. You can now divide the classifier into compartments as needed. 11  Detail About Each Notation Actor An actor doesn’t have to be a human this is very important to know any external system or element outside of the use case that may trigger the use case or is a recipient of the use case results should be modeled as an actor. So, an actor represents one of the following: ◼ A role that a user can play with regard to the system, or ◼ An entity, such as another system or a database, that resides outside the system. The UML notation for an actor is a stick figure with a short descriptive name, in our case: the actor is the client. 12  Detail About Each Notation Actor An actor can also be represented as a user-defined icon to clearly distinguish between different types of actors. For example, you can show an external database system using a database icon. An actor can be involved with one or more than one use case and one use case can interact with one or more actors. 13  Detail About Each Notation The System To show your system's boundary on a use case diagram, draw a box around all of the use cases but keep the actors outside of the box. It's also good practice to name your box after the system you are developing, as shown for the ATM system. This technique is very useful in determining the scope and assignment of responsibilities when designing a system, subsystem, or a component. 14  Detail About Each Notation Association An actor is typically associated with one or more use cases. An actor can initiate the use case and the use case can provide the actor with results, or both. The association between an actor and a use case is drawn as a solid line. 15  Detail About Each Notation Association Typically, you read the use case diagrams from left to right, with actors initiating use cases on the left and actors that receive use case results on the right. But you don’t need to stick this rule, depending on the model or level of complexity, and the organization of the diagram to make it more readable, so it may make sense to group actors differently. 16  Detail About Each Notation Association Though not part of the official UML specification, it is common to see directional arrows on association lines to indicate who initiates communication with whom. Note that the arrows don't necessarily restrict the direction of information flow; they simply point from the initiator to the receiver of the communication. What happens after a use case begins execution is specified somewhere else outside the use case itself. 17 Stereotype 18  What Is A Stereotype The UML also provides some built-in extensions to the diagram notations. One such tool is called a stereotype. Stereotypes modify the meaning of an element and describe the element's role within your model. A stereotype sometimes has an associated icon, such as the stick-figure actor symbol. Once we see the stick figure in any diagram, we know we are talking about actors who communicate with our system. 19  What Is A Stereotype Sometimes, the stereotype is shown using double angle brackets. In our example, The client is represented as a role of an actor, so it is an actor with the name client, and it is specified using a name rather than an icon. 20  What Is A Stereotype There is no limit to the number of stereotypes with which an element can be associated; sometimes you may end up specifying more than one stereotype for a single element. The UML specification defines a set of "standard" or predefined stereotypes for each diagram, but you are free to define and use your own. 21 Generalization 22  Generalization Generalization is another name for object-oriented inheritance. Actors and use cases can be generalized like many other elements in UML. Actor generalization is typically used to pull out common requirements from several different actors to simplify modeling. For example, You may have different types of bank clients: regular clients, business clients, VIP clients, all with slightly different needs. However, the majority of the needs of the individual actors may overlap. You can factor out a generic client actor to capture the common functionality, and then specialize which is the opposite of generalize to identify the unique needs of each actor. 23  Generalization You represent actor generalization draw a solid line, with a closed arrow pointing from the specialized actor to the base actor. So, the arrow always point to the parent or base. The beauty of UML is that is a specific notation means something in a diagram, will always mean the same thing in every other diagram. So, from now on, whenever we see a closed white arrow, then we know we are talking about generalization or object-oriented inheritance. When you find that an actor is like another actor, then that’s a sign of a generalization. 24  Generalization Use cases also may be generalized as well. Specializations of a general use case introduce specific functionality. For example, a generic use case can be deposit money, and specialization of that use case can be deposit cash and deposit cheque. It is important to notice that even with use case generalization, you should still discuss functionality, not implementation. You represent use case generalization just like you do actor generalization: using a solid line, with a closed arrow pointing from the specialized use case to the base use case. So again, When you find that a use case is like another use case, then that’s a sign of "generalization". 25  Include If more than one use case share common functionality, it would be a better idea to create a shared, included use case. The best way to think of an include association is as the invocation of one use case by another use case, just like calling a function or invoking an operation within source code. It is quite common to introduce a use case that encapsulates common logic required by several use cases and to have that use case included by the ones that require it. 26  Include In our ATM example, the “Update Account” functionality is common to both the withdraw money and deposit money. So, we have separated out and made a standalone use case. You show use case inclusion using a dashed line with an open arrows or dependency pointing from the base use case to the included use case label the line with the keyword or stereotype. So, if we are to read the diagram, we would say that the withdraw money use case includes the Update Account use case and the deposit money use case includes the Update Account use case. The order we mention the use cases follow the arrow direction. 27  Include The use case that includes another use case is not consider complete on its own and it needs the included functionality to provide full functionality. Therefore, the included functionality isn’t considered optional; it is factored out simply to allow for reuse in other use cases. Also, the included use case is typically not complete on its own and is a required part of larger use cases. Note that the withdraw money use case can never be fulfilled without the Update Account functionality. 28  Extend UML provides the ability to plug in additional functionality to a base use case if specified conditions are met. So, if we withdraw money from an ATM there could be a situation where we ask for an amount that exceeds our current bank balance, in that case we must alert the user and display an error message. “Displaying an error message” can move to a separate use case, also for reuse. In this case the specified condition for the extension is an error occurred. You represent a use case extension by showing a dashed line, with an open arrow (dependency) pointing from the extension use case to the base use case and label the line with the keyword extend. 29  Extend So, if we are to read the diagram, we would say that the display error message use case extends the withdraw money use case. Again, the order we mention the use cases follow the arrow direction. 30  Extend Unlike the include use case, the use case that uses an extension should be complete on its own and only needs the extended functionality on specific situation. The withdraw money can be executed fully on its own if the error occurred condition or never happen. The extension use cases are typically smaller in scope and represent additional functionality, so they may not be useful outside the context of the base use case. 31 look at the full final version of our diagram and read it 32 look at the full final version of our diagram and read it A client interacts with the ATM system. There are different types of bank clients, regular clients, business clients and VIP clients. All clients can withdraw money and deposit money. While depositing money, the client can either deposit cash or deposit cheques. Both withdraw money and deposit money need to call or use the Update Account use case which interacts with the bank system. And sometimes need to call display error message use case if an error occurred. 33 Guidelines for Building a Quality Use Case Diagram Begin Use Case Names with a Strong Verb. (Example: Withdraw Money, Display error, and Deliver package) Use Domain Terminology when Naming Use Cases. (Example: Get Money is a generic name for a use case, but Withdraw Money reflects common domain terminology and therefore is more understandable) 34 Guidelines for Building a Quality Use Case Diagram Order Use Cases accordingly to importance, timing and/or sizing.(if you need to represent more than one use case in the same diagram, try to order the use cases in a way that has a meaning to the reader. Ex: most important or bigger use cases starting from the top left. As move down to the right, you can place less important use cases ) 35 Guidelines for Building a Quality Use Case Diagram Place your primary Actor(s) in the top- left corner of the diagram. (place the primary actor on the top left and place recipient actors on the right of the diagram) 36 Guidelines for Building a Quality Use Case Diagram Name Actors with Singular, Domain-Relevant Nouns. Using “client” as an ATM system actor is more meaningful than using “person” 37 Guidelines for Building a Quality Use Case Diagram Name Actors to Model Roles. A common mistake when naming actors is using people name or their job titles instead of the roles that the people fulfill. For example, you should use “System administrator” instead of “senior IT specialist”. 38 Guidelines for Building a Quality Use Case Diagram Use to Indicate System Actors. If you need to distinguish between person actors and system actors, you can use the >. 39 Guidelines for Building a Quality Use Case Diagram Actors Don’t Interact with One Another. If you find out that you need to make one actor interacts with another one, then this is an indication that there’s something wrong with the use case diagram. 40 Guidelines for Building a Quality Use Case Diagram Introduce an Actor Called “Time” to Initiate Scheduled Events. Certain events happen on a regular basis such as scheduled reports or periodic screen. In that case you can introduce an actor called "Time“, which is beyond the control of the system. 41 Guidelines for Building a Quality Use Case Diagram Avoid Meaningless System Boundary Boxes System, boundary boxes are optional. So, if it won’t add value to the reader, then don’t include it. 42 Guidelines for Building a Quality Use Case Diagram Avoid Arrowheads on Actor-Use Case Relationships. The arrowheads on actor-use case associations indicate who or what invokes the interaction. Indicate an arrowhead only when doing so provides significant value for the reader. 43 Guidelines for Building a Quality Use Case Diagram Place an Included Use Case to the Right of the Invoking Use Case. 44 Guidelines for Building a Quality Use Case Diagram Place an Extending Use Case Below the Parent Use Case. 45 Guidelines for Building a Quality Use Case Diagram Place an Inheriting Use Case Below the Base Use Case. 46 Guidelines for Building a Quality Use Case Diagram Place an Inheriting Actor Below the Parent Actor. 47 Use Case Description Elements Use Case specification 48 Use Case Description Elements Use Case specification Although the Use Case diagram provides a convenient view of the main features of a system, it is too concise to completely describe what users are expecting. So, it must be supported by a narrative, or a textual description that takes us to the next level of understanding. The use case specification is the narrative detailed description of a use case. The use case specification contains many elements or sections that describe a use case. 49  Use Case Description Elements Use Case specification Martin Fowler - a legend in the software industry states that "There is no standard way to write the content of a use case, and different formats work well in different cases”. So, if you search for use case descriptions templates, you will find a variety of them. Just pick whatever suits your business then tailor it whenever a need arises. 50  Use Case Specification Elements Here are the most important elements: ◼ Name of the use case ◼ Actors ◼ Preconditions ◼ Trigger ◼ Basic main flow of the use case ◼ Alternatives flow of the use case ◼ Post conditions 51  Use Case Specification Elements Use case specification is usually presented in a table containing the following rows: 52  Use Case Specification Elements we should start by the use case name then comes summary description: The goal of the use case and why this use case is important. Pre-conditions: describe a state of the system that must be true before you can execute the Use Case. These conditions should be verified to be true by the Use Case before doing anything else. If the conditions are not true, the actor is refused entry. Post-Conditions or guarantee : here we should explain what is the system's state if the use case executes successfully. And what the system's state should be if the use case fails to execute successfully.( Or in other words, what the use case promises after the execution of the use case) Actors : participating in the use case. Trigger: which list all the possible events that would cause the use case to launch. Main flow: The important steps in the use case's normal execution. Then comes alternatives or extensions A description of any alternative steps from the ones described in the Main Flow. 53  Use Case Description for the Withdraw Money use case 54  Use Case Description for the Withdraw Money use case 55  Use Case Description for the Withdraw Money use case 56  Use Case Description for the Withdraw Money use case Now we agree that we have 15 steps in the main flow. There’re more than one scenario that could happen other than the happy main scenario. The way to document the other scenarios is by reading the main flow as usual starting from step 1 and continue till we see the current step number appears in the alternative section, or the extension section followed by a letter or something in that case we jump from the current step in the main flow to the that step in the extension and continue reading from the extension part. 57  Use Case Description for the Withdraw Money use case Now we might face the situation were a normal step dispatches to more than one scenario, in that case we need to differentiate between the different paths by using the alphabet letters a, b, c…and so on. So, looking at our example let’s see how many scenarios total we have here. 58  Use Case Description for the Withdraw Money use case Extensions scenario At our example let’s see how many scenarios total we have here. The first one is the happy path from 1 till 15. The second scenario step 1 step 2 then we can jump now to step 2a then 2a1 that’s the scenario where the client enters a wrong card So if we read the second scenario together it will be 1. The customer enters their debit card into the ATM 2. The ATM verifies that the card is a valid bank card then we can jump now to the label 2a which means we have an invalid card the next step would be 2a1 ATM displays error message and 2a2 redirect to step 1.. go back to step 1 asking the customer to enter another card. 59  Use Case Description for the Withdraw Money use case Extensions scenario The following scenario we see in the extension that we have 2 scenarios that could happen at step 5 , 5a and 5b. ◼ The third scenario 1 2 3 4 5 5a 5a1 5a2 that’s the scenario if the card was reported stolen ◼ The fourth scenario 1 2 3 4 5 5b 5b1 and that’s the scenario if the user enters a wrong pin number scenario #5: 1 2 3 4 5 6 7 8 9 10 10a1 10a2 that’ the scenario if the ATM doesn’t have enough cash or if the amount required is higher than the allowable withdraw limit or if the amount required is less than the account balance. 60  Use Case Description for the Withdraw Money use case Extensions scenario scenario #6: 1 2 3 4 5 6 7 8 9 10 11 12 12a1 12a2 that’ the scenario when the Bank card is stuck in machine. scenario #7: from 1 till 13 then 13a1 13a2 13a3 that’ the scenario when the Customer fails to take their bank card. scenario #8: from 1 till 14 14a1 14a2 14a3 14a4 14a5 that’ the scenario when the Cash stuck in the machine. 61  Use Case Description for the Withdraw Money use case Extensions scenario scenario #9: from 1 till 15 then 15a1 15a2 15a3 15a4 that’ the scenario when the Customer fails to take their cash. scenario #10: Now this alternative star or asterisk *a means that there’s a scenario that could happen at any time, with any step that’s why the alternative step is marked with an asterisk and not a specific number. So, there could be a scenario 1 then *a or 1 2 then *a, 1 2 3 then *a and so on Same thing with *b *b scenario can happen at any step So we have a total of at least 11 scenarios or alternative paths. 62  Use Case Description for the Withdraw Money use case Extensions scenario So, we have a total of at least 11 scenarios or alternative paths, that is a lot. I want you to imagine if we wanted to write this use case the withdraw money in plain English language, how complicated and confusing that would be for anyone and for everyone actually. So, writing the user requirements in the form of use case specification really helped a lot in organizing what we want the system to achieve. Also, this way, it would make you think, what other scenarios that could happen at each step? 63 Building Use Cases 64  Building Use Cases we have talked about use case diagrams and use case specifications Let us now try to put some sort of a process to build the use cases. First, try to write what your software will do in plain English. This will help you put everything in context and not to forget major requirements. Try to tell the story of what your software wants to achieve and here we are not talking about Agile stories or anything. Just tell the story your software will do. Sometimes the user requirements which are the requirements that you received from the user can be used as a starting point. 65  Building Use Cases Next step: Identify and name your use cases from the narrations you just wrote down. Then draw a diagram indicating the use cases, as well as the primary and secondary actors, and try to determine the triggering actors and receiving actors. For each use case, Describe the use case briefly. try to give a single sentence outlining the purpose of the use case. If you cannot put the goal of the use case in a single sentence, then most probably this is not a good use case, and you might need to divide it into smaller use cases. 66  Building Use Cases The next step is to describe the main flow of the use case and some people call it the happy scenario. Put the main flow in steps 1, 2, 3, 4 indicating what should happen to achieve the goal of the use case. Make it more like a dialog between the system and the actors: the system does what and the actor does what in return. define appropriate pre- conditions and post- conditions for this flow of events. As part of making the flow of events more formal and precise, you should specify the conditions that must be true to enable this version of the story to occur which are called the preconditions. Also, you should specify the conditions that will be true after this flow of events finishes which are called the post conditions. 67  Building Use Cases Identify alternative, errors, exception scenarios to the main flow of events. Look at every line in the main flow and try to imagine what would go wrong at this step or what would the actor do differently at this step. We identify all the alternative paths, possible errors (and their consequences), and exceptional situations that the use case might encounter. After doing one or more use cases, try to look for similarities in the flow of events or in the alternatives or extensions and move them out for re-use as include use cases or extended use cases. 68  UML tool UMLet Brief introduction to the free, open-source UML tool UMLet available at http://www.umlet.com https://youtu.be/3UHZedDtr28 69 Introducing the "UMLet" UML Tool “UMLet” is a free, open-source UML tool with a simple user interface: draw UML diagrams fast, build sequence and activity diagrams from plain text, export diagrams to eps, pdf, jpg, svg, and clipboard, share diagrams using Eclipse, and create new, custom UML elements. UMLet runs stand-alone or as Eclipse plug-in on Windows, OS X and Linux. 70 Introducing the "UMLet" UML Tool “UMLet” Video Tutorial for Open-Source UML Tool “UMLet”: Basic Use and Custom Elements https://youtu.be/3UHZedDtr28 71 Introducing the "UMLet" UML Tool Click “Download” link in UMLet home page to go on the download page. 72 Introducing the "UMLet" UML Tool Download the “UMLet 15.0 stand-alone” 73 Introducing the "UMLet" UML Tool After downloading the “UMLet 15.0 stand- alone” version you simply need to unzipped the downloaded folder, and that set you are ready to go. 74 Introducing the "UMLet" UML Tool Let’s look about use case notations Let’s try to build some use cases together, double click on the use case object in the library on the right. 75 Introducing the "UMLet" UML Tool Let’s try to build some use cases together, double click on the use case object in the library on the right. You can change and edit all the text on the properties tab on the right bottom. 76 Introducing the "UMLet" UML Tool Now pick the generalization arrow is a dotted closed white arrow. Look the property of this arrow is lt=.>> you can change the type of the arrow just from the property, you can modify the arrow and you are ready to go. This is very time saver. Here we just used the dash lt=->> instead of the dot and the arrow became a solid line. 77 Introducing the "UMLet" UML Tool If we remove one of the greater than symbols(lt=->);so we have an open arrow. If we put a three greater than symbols,so we have a closed black arrow. 78 Introducing the "UMLet" UML Tool We can simply change the direction of the arrow by moving the dot or dash from one side to another (lt=