Lecture#04, use case diagram


Published on

Published in: Business, Technology
  • Be the first to comment

Lecture#04, use case diagram

  2. 2. INTRODUCTION  No system exists in isolation. Every interesting system interacts with human or automated actor that use that system for some purpose, and those actors expect that system to behave in a predictable way.  A USE CASE specifies the behavior of a system or a part of a system and is a description of a set of sequences of actions, including variants, that a system performs to yield an observable results of value to an actor.
  3. 3. USE CASEs & ACTORs  We apply use cases to capture the intended behavior of the system we are developing, without having to specify how that behavior will be implemented.  Use case provide a way for our developers to come to a common understanding with your system’s end user and domain experts.  In addition use cases serve to help validate our architecture and to verify our system as it evolves during development.  As we implement the system, these use cases are realized by collaborations whose elements work together to carry out each use case.
  4. 4. USE CASEs & ACTORs  A use case describes a set of sequences, in which each sequence represents the interaction of the things outside the system (its actor) with the system itself ( and its key abstraction).  These behaviors are in effect system-level functions that we use to visualize, specify, construct and document the intended behavior of our system during requirement capturing and analysis.  A use case represents the functional requirements of our system as a whole
  5. 5. USE CASEs & ACTORs  A use case involves the interaction of actors and the system.  An actor represents a coherent set of roles that users of use case play when interacting these use cases.  Actor can be human or they can be automated systems.  For example in modeling a bank, processing a loan involves, among other things, the interaction of customer and loan officer.
  6. 6. Use Case & Flow of Events  A use case specify what a system (subsystem, class or interface) does but it does not specify how it does it.  Modeling use cases we try to keep clear the separation of concerns between outside and inside view.  We specify the behavior of a use case by describing a flow of events in text clearly enough for an outsider to understand it easily.  Writing use cases, we specify the flow of events, we include how and when the use case starts and ends, when the use case interacts with the actors and what objects are exchanged, and the basic flow and alternative flows of the behavior.
  7. 7. Example of Use Case & Flow of Events  In the context of ATM system, consider the use case ValidateUser.  Main Flow of events:  The use case starts when the system prompts the customer for a PIN number. The Customer can now enter a PIN number via keypad. The Customer commits the entry by pressing the Enter button. The system then checks this PIN number to see if it is valid. If the PIN number is valid, the system acknowledges the entry, thus ending the use case.  Exceptional Flow of events:  The Customer can cancel a transaction at any time by pressing the Cancel button, thus restarting the use case. No changes are made to the Customer’s account.
  8. 8. Example of Use Case & Flow of Events  Exceptional Flow of events:  The Customer can clear a PIN number before committing it and reenter a new PIN number.  Exceptional Flow of events:  If the Customer enters an invalid PIN number, the use case restarts. If this happens three times in a row, the system cancel entire transaction, preventing the Customer from interacting with the ATM for 60 seconds.  Use Cases can be specified in a number of ways, including informal structured text (as in this example), formal structured text (with pre- and post-conditions), and with pseudo code.
  9. 9. Use Cases & Scenarios  An interaction diagram includes collaboration and sequence diagrams.  Typically first we describe the flow of events for a use case in text.  As we refine our understanding of the system, we want to also use interaction diagrams to specify these flows graphically.  Typically we use one sequence diagram to specify the use case’s main flow and variations of that diagram to specify a use case’s alternate or exceptional flows.
  10. 10. Use Cases & Scenarios  It is desirable to separate main versus alternate flows because a use case describes a set of sequences, not just single sequence, and it would be impossible to express all the details of an interesting use case in just a single sequence.  For example in a HR System, we might find a use case Hire Employee. This general business function might have many possible variations. we might hire a person from another company (the most common scenario); we might transfer a person from one division to another (common in international companies); or we might hire a foreign national (which involves its own special rule). So each of these variants can be expressed in different sequence.
  11. 11. Use Cases & Scenarios  Actually one use case (Hire Employee) describes a set of sequences in which each sequence in the set represents one possible flow through all these variations.  Each sequence of a use case is called a Scenario.  A scenario is a specific sequence of actions that illustrates behavior.  Scenarios are to use cases as instances are to classes, meaning that a scenario is basically an instance of a use case.  For each use case we will find primary scenario (which define essential sequences) and secondary scenarios (which define alternate sequences).
  12. 12. Organizing Use Cases  We organize use cases by specifying generalization, include, and extend relationships among them.  We apply these relationships in order to factor common behavior (by pulling such behavior from other use cases that it includes) and in order to factor variants (by pushing such behavior into other use cases that extend it).  Generalization among use cases is like generalization among classes. It means that the child use case inherits the behavior and meaning of the parent use case; the child may add to or override the behavior of its parent; and the child may be substituted any place the parent appears (both parent or child may have concrete instances).
  13. 13. Organizing Use Cases  For example, in a banking system, we might have the use case Validate User, which is responsible for verifying the identity of the user.  We might have its two specialized children of this use case Check Password and Retinal Scan. Both of these behave like Validate User and may be applied anywhere Validate User appears, yet both of which add their own behavior (the former by checking a textual password and the later by checking the unique retina patterns of the user.  Generalization is rendered as solid directed line with a large open arrowhead, just like generalization among classes.
  14. 14. Organizing Use Cases  An Include relationship between use cases means that the base use cases explicitly incorporates the behaviors of another use case at a location specified by base.  The include use case never stands alone, but it is only instantiated as a part of some larger base use case that includes it.  We can think of it as the base use case pulling the behavior from the supplier use case.  We might include relationship to avoid describing the same flow of events several times, by putting the common behavior in a common use case of its own (the use case that is included by the base use case).
  15. 15. Organizing Use Cases  An Extend relationship between use cases means that the base use case implicitly incorporates the behavior of another use case at a location specified indirectly by the extending use case.  The base use case may stand alone, but under certain conditions, its behavior may be extended by the behavior of another use case.  These base use case may be extended at certain point called the extension points.  We can think of extend as pushing the behavior to the base use case. Extend relationship is used to model the part of use case that the user may see as optional system function.
  16. 16. Organizing Use Cases  Using Extend relationship we separate optional behavior from mandatory one. Similarly we use it to model separate sub flow that is executed only under given conditions.
  17. 17. Organizing Use Cases Organizing use cases by extracting common behavior (though include relationships) and distinguishing variants (through extend relationship) is an important part of creating simple, balanced, and understandable set of use cases for a system.
  18. 18. USE CASE DIAGRAM  Use Case Diagram is one of five diagrams in UML for modeling the dynamic aspects of systems (Activity diagrams, Statchart diagram, Sequence diagram, Collaboration diagram & four other type of diagrams in UML for modeling dynamic aspects of a system).  Use case diagram show use cases, actors and their relationships to model the context of a system, subsystems, or a class or model the requirements of behavior of these elements.  Use Case diagram is central to model the behavior of a system.
  19. 19. USE CASE DIAGRAM…  Suppose someone hands you a box. On one side of that box there are some buttons and a small LCD panel. Moreover, the box is nondescript; you are not even given with a hint about how to use it. You could randomly punch buttons and see what happens, but you would be hard to pressed to figure out what that box does or how to use it properly unless you spent a lot of trial-and-error time.  Software intensive systems can be like that. If you are a user, you might be handed an application and told to use it. If the application follows normal conventions of operating system you are use to, you might be able to get it to do something useful after a fashion, but you’d never come to understand its more complex & subtle behavior that way.
  20. 20. USE CASE DIAGRAM…  Simply we apply use case diagram to visualize the behavior of a system so that users can comprehend how to use that element and so that developers can implement that element.
  22. 22. USE CASE DIAGRAM EXAMPLE Last slide Use Case diagram show the context of a Credit Card Validation System, with an emphasis on the actors that surround the system. We will find Customer, of which there are two kinds (Individual Customer and Corporate Customer). These actors are the roles that human play when interacting this system. In this context, there are also actors that represent other institutions, such as Retail Institution (with which a Customer performs a card transaction to buy an item or service) and Sponsoring financial institution (which serves as the clearinghouse for the credit card account). In the real world, these later two actors are likely software intensive systems themselves.
  23. 23. Questions…