• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Lecture04- Use Case Diagrams
 

Lecture04- Use Case Diagrams

on

  • 3,881 views

Use-Case Diagrams

Use-Case Diagrams

Statistics

Views

Total Views
3,881
Views on SlideShare
3,880
Embed Views
1

Actions

Likes
1
Downloads
144
Comments
0

1 Embed 1

http://www.slashdocs.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Lecture04- Use Case Diagrams Lecture04- Use Case Diagrams Presentation Transcript

    • Computer Engineering DepartmentObject Oriented Software Modeling and Design g CE 350 Abdel-Karim Al-Tamimi, Ph.D. altamimi@yu.edu.jo http://faculty.yu.edu.jo/altamimi Al-Tamimi 2011 © 1
    • Overview• Use case Diagrams Use-case Al-Tamimi 2011 © 2
    • Use-Case DiagramsUse Case Al-Tamimi 2011 © 3
    • Why We Use Use-case Diagrams Use case Al-Tamimi 2011 © 4
    • Why We Use Use-case Diagrams Use case• Answers the main questions about your system: – Who’s your system s for? Who s system’s – What must it do? – Why build it in the first place?• System users: Actors• System normal situations: use-cases Al-Tamimi 2011 © 5
    • Why We Use Use-case Diagrams Use case• Stay focus on your client s goals client’s• A good use case must represent the point of view of the people who will use or interact with the system• A complete set of use cases = system l f requirements Al-Tamimi 2011 © 6
    • Use-Case Diagram Use Case g g• A use-case model is a diagram or set of diagrams that together with some additional documentation show what the proposed software system is designed to do. A use case diagram consists of do use-case three main components: – Actors – Use-cases, and their communications – some additional documentation such as use-case descriptions for elaborating use cases and problem use-cases statements that are initially used for identifying use cases Al-Tamimi 2011 © 7
    • Use-Case Diagram: Actors Use Case• Usually represented with a stick figure• An actor may b y be: – People – Computer hardware and devices – External systems Al-Tamimi 2011 © 8
    • Use-Case Diagram: Actors Use Case• An actor represents a role that a user can play, but NOT a specific user• Primary actors are those who use the system’s main functions, deri ing f nctions deriving benefits from it directl directly. – Primary actors are completely outside the system and drive the system requirements – Primary actors use the system to achieve an observable user goal• Secondary actors play a supporting role to facilitate the primary actors to achieve their goals. – Secondary actors often appear to be more inside the system than outside – Secondary actors are usually not derived directly from the statement of requirements. Hence, the designer can have more freedom in specifying the roles of these actors – Usually found on the right of the system (primary on the left) Al-Tamimi 2011 © 9
    • Use-Case Diagrams: Actors Use Case• Actors are treated like classes and thus can be generalized Student MasterStudent BAStudent Al-Tamimi 2011 © 10
    • Use-Case Diagrams: Actors and l Goals1. Start by identifying the actors of the1 system2.2 See if the actors can be generalized or not3. Define the goals of the system and how they can b achieved using the systems’ h be hi d i h ’ actors4. Illustrate these goals and actors actions using use-case diagram(s) Al-Tamimi 2011 © 11
    • Use-case Diagram: Use-case Use case Use case• A use case describes a sequence of actions a system performs to yield an observable result or value to a f i ld b bl l l particular actor• Naming convention = verb + noun (or) verb + noun- phrase, h – e.g. withdraw cash• A good use case should: – Describe a sequence of transactions performed by a system that produces a measurable result (goal) for a particular actor – Describe the behavior expected of a system from a users perspective – Enable the system analyst to understand and model a system from a high-level business viewpoint – Represent the interfaces that a system makes visible to the external entities and the interrelationships between the actors and the system Al-Tamimi 2011 © 12
    • EBP Test for Use-Cases Use Cases• Elementary Business Process (EBP) is a term from the business process engineering field defined as:• A task performed by one person in one place at one time in response to a time, business event, which adds a measurable business value and leaves the data in a consistent state – E Approve Credit or Cancel O d E.g. A C dit C l Order Al-Tamimi 2011 © 13
    • Use-Case Diagram: Use-CaseUse Case Use Case Al-Tamimi 2011 © 14
    • Use-Case Diagram: Use-CaseUse Case Use Case Al-Tamimi 2011 © 15
    • Use-Case Diagram: Use-CaseUse Case Use Case Al-Tamimi 2011 © 16
    • Use-Case Diagram: ExampleUse Case System name Actor Use-case Use caseAssociation System boundary Al-Tamimi 2011 © 17
    • Use-Case Diagram: Example Use Case p• Let us consider a simple hotel information system for two types of customers: – Tour Group customers and Individual customers – Tour Group customers are those who have made reservations through a tour operator in advance, while I di id l customers make d hil Individual t k their reservations directly with the hotel – Both types of customers can book, cancel, o ypes o cus o e s ca boo , ca ce , check-in and check-out of a room by phone or via the Internet Al-Tamimi 2011 © 18
    • Use-Case Diagram: ExampleUse Case Al-Tamimi 2011 © 19
    • Structuring Use-cases with Relationships Use cases• In the p p g process of developing a use case model, we may discover that some use cases share common behaviors• Th There are also situations where some use l i i h cases are very similar but they have some additional behaviors• For example, Withdraw Money and Deposit Money both require the user to p y q log-on to an ATM system Al-Tamimi 2011 © 20
    • Structuring Use-cases with Relationships Use cases Use Case: Withdraw Money Use Case: Deposit Money Flow of Events: Flow of Events: 1. The user inserts an ATM card. The 1. The user inserts an ATM card. The system prompts the user to enter a y p p system prompts the user to enter a y p p password. password. 2. The user enters the password. The 2. The user enters the password. The system validates the user password. system validates the user password. .... .... …. …. …. …. Common Behavior Al-Tamimi 2011 © 21
    • Structuring Use-cases with Relationships Use cases Use Case: Withdraw Money Use Case: Deposit Money Flow of Events: Flow of Events: 1. 1 include (Login Account) 1. 1 include (Login Account) .... …. …. …. …. ….. Use Case: Login Account Flow of Events: 1. The user inserts an ATM card. The system prompts the user to enter a password. d 2. The user enters the password. The system validates the user password. Al-Tamimi 2011 © 22
    • The <<include>> Relationship p• Include relationships are used when two or more use cases share some common portion in a flow of events• Thi common portion is then grouped and This i i h d d extracted to form an inclusion use case for sharing among two or more use cases• Most use cases in the ATM system example, such as Withdraw Money, p , y, Deposit Money or Check Balance, share the inclusion use-case Login Account Al-Tamimi 2011 © 23
    • The <<include>> Relationship Withdraw Money (Base use case) Login Account (Included use case) Al-Tamimi 2011 © 24
    • The <<include>> Relationship• When to use include relationship: – The behavior of the inclusion use case is common to two or more use cases – The result of the behavior that the inclusion use case specifies, not the behavior itself, is , important to the base use case Al-Tamimi 2011 © 25
    • The <<include>> Relationship: Example Al-Tamimi 2011 © 26
    • The <<include>> Relationship: Example Al-Tamimi 2011 © 27
    • The <<extend>> Relationship• In UML modeling, you can use an extend modeling relationship to specify that one use case (extension) extends the behavior of another use case (base)• This type of relationship reveals details about a system or application that are typically hidden in a use case Al-Tamimi 2011 © 28
    • The <<extend>> Relationship• The extend relationship specifies that the incorporation of the extension use case is dependent on what happens when the base use case executes• The extension use case owns the extend relationship. You can specify several extend relationships for a single base use case Al-Tamimi 2011 © 29
    • The <<extend>> Relationship• While the base use case is defined independently and is meaningful by itself, the extension use case is not meaningful on its own• The extension use case consists of one or several behavior sequences (segments) that describe additional behavior that can incrementally augment the behavior of the base use-case• Each segment can b inserted i h be i d into the b h base use case at a different point, called an extension point Al-Tamimi 2011 © 30
    • The <<extend>> Relationship Withdraw Money (Base use case) Process Excess Amount (Extending use case) If conditional guard is true, extending flow is executed Al-Tamimi 2011 © 31
    • The <<extend>> Relationship• The extension use case can access and modify the attributes of the base use case; however, however the base use case is not aware of the extension use case and, therefore, cannot access or modify the attributes and operations of the extension use case Al-Tamimi 2011 © 32
    • The <<extend>> Relationship• You can add extend relationships to a model to show the following situations: – A part of a use case that is optional system behavior – A subflow i executed only bfl is d l under certain conditions – A set of behavior segments that may b inserted i a h be i d in base use case Al-Tamimi 2011 © 33
    • The <<extend>> Relationship Al-Tamimi 2011 © 34
    • The <<extend>> Relationship Al-Tamimi 2011 © 35
    • The <<extend>> Relationship Al-Tamimi 2011 © 36
    • Al-Tamimi 2011 © 37
    • The Generalization Relationship• A child use-case can inherit the behaviors, , relationships and communication links of a parent use-case (like Actor generalization)• In other words, it is valid to put the child use words use- case at a place wherever a parent use-case appears• Th relationship b t The l ti hi between th child use-case and the hild d the parent use-case is the generalization relationship• For example: suppose the ATM system can be used to pay bills. Pay Bill has two child use cases: Pay Credit Card Bill and Pay Utility Bill 38
    • The Generalization Relationship 39
    • The Generalization Relationship 40
    • Use-Case Scope Use Case• A use case must be initiated by an actor• When a use case is considered complete, there are no further inputs or outputs; the desired functionality has been performed, or an error has occurred• After a use case has completed, the system is in i i a state where the use case can b h h be started again, or the system is in an error state 41
    • Base Use-Case vs. Abstract Use-Case Use Case Use Case y y• Base use case – invoked directly by actor to achieve an observable goal• Abstract use case – invoked by other use cases and is not a complete goal f di l l from user’s perspective• e g withdraw cash (concrete use case) vs e.g. vs. login (abstract use case) 42
    • Use-Case ScopeUse Case 43
    • Use-Case ScopeUse Case 44
    • Summary of NotationsConstruct Description NotationUse-case A sequence of transactions performed by a system that produces a measurable result for a particular actorActor A coherent set of roles that users play when interacting with these use casesSystem The boundary between the physicalBoundary system and the actors who interact with the physical system 45
    • Summary of NotationsConstruct Description NotationAssociation The participation of an actor in a use case, i.e. an instance of an actor and instances of a use case communicating with each otherGeneralization A taxonomic relationship between a general use case and a more l d specific use case. The arrow head points to the general use caseExtendE t d A relationship b t l ti hi between an extension use case and a base use case, specifying how the behavior of the extension use case can be inserted into the behavior defined for the base use case. The arrow head points to the base use case 46
    • Summary of NotationsConstruct Description NotationInclude A relationship between a base use case and an inclusion use case, specifying how the behavior for the inclusion use case is inserted into the behavior defined for the base use case. The arrow head points to the inclusion use case 47
    • Resources• Chapter 3 from “Object-Oriented Object Oriented Technology: From diagram to code with Visual Paradigm for UML” UML• UML 2 for dummies, chapters 8-10• UML 2 certification guide, chapter 2 ifi i id h• Chapter 6 from “Applying UML and Patterns” Al-Tamimi 2011 © 48