Scribd
Upload
6 views22 pages

Lecture 04 Use Case Modeling

The document discusses Object Oriented Analysis and Design (OOA/D), focusing on the core application logic layer, which remains consistent across technologies while other layers vary with new frameworks. It explains the concept of use cases, detailing their components, relationships, and the roles of actors involved in the system. Additionally, it outlines methods for describing use cases and their diagrams, emphasizing the iterative nature of use case modeling.

Uploaded by

owas khan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
6 views22 pages

Lecture 04 Use Case Modeling

The document discusses Object Oriented Analysis and Design (OOA/D), focusing on the core application logic layer, which remains consistent across technologies while other layers vary with new frameworks. It explains the concept of use cases, detailing their components, relationships, and the roles of actors involved in the system. Additionally, it outlines methods for describing use cases and their diagrams, emphasizing the iterative nature of use case modeling.

Uploaded by

owas khan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 22

Object Oriented Analysis and Design

Focus on OOA/D in the core


application logic layer?
• Other layers are usually very technology/platform
dependent.

• OO design of the core logic layer is similar across


technologies

• The design approach/patterns for the other layers


tends to change quickly as new frameworks or
technologies emerge
Use Case

• A use case describes functionality expected from the


system
• It covers a number of functions that are executed when
using this system.
• Depict the behavior of system, it appears outside the
user.
• Describe the functionality and users.
• Show the relationship between users and use cases.
• Show the relationship between users and also between
use cases.
• Illustrate the developers understanding of users
requirements.
Use Case
• A use case is a pattern of behavior that system exhibit.
• Use cases are sequence of actions that the user take on
system to get particular target.
• A use case is represented in following ways
Component of Use Cases:

• Use Case
• Actors
• System Boundary
• Relationships
Actor
• Actors is one the which interact with the system.
• Actor can be human and automated system.
• Actors are not part of system.
• Actor carryout the use cases and a single actor may
perform more than one use cases.
• Following notations are used to represent actor:
Types of Actor
• Active Actor:
 Initiate the execution of use case.
• Passive Actor:
 Providing functionality/Response in
execution of use case.
Types of Actor
• Primary Actor:
 Act on system.
 Initiate the interaction with system.
 Use the system to fulfill his needs.
 It get actual benefit from the execution of use
case.
• Secondary Actor:
 Is acted on/invoked by system.
 Help the system to fulfill his goals.
 It receives no direct benefit from execution of
system.
Primary and Supporting
Actors

For a use case context Show computer system actors


diagram, limit the use cases to with an alternate notation to
user-goal level use cases. human actors.

NextGen

«actor»
Process Sale Payment
Authorization
Service
Cashier
...

primary actors on supporting actors


the left on the right
System Boundary

• It is shown as rectangle.
• It helps to identify the responsibilities of system and what is
external versus internal.
• The external environment is represented only by actor.
Relationships
• Relationship is an association between use case and actor.
• There are several use case relationship.

Association
Include ------ ---
Extend ----
Generalization
Association
• It express that the actor communicates
with the system and uses a certain
functionality.
• Every actor must communicate with at
least one use case.
• Every use case must be in a relationship
with at least one actor.
• An association is always binary,
meaning that it is always specified
between one use case and one actor.
• Multiplicities may be specified for the
association ends.
• This means that more than one instance
of an actor is involved in the execution
of the use case.
Generalization
• Generalization is a relationship between a general use
case and a more specific use case that inherit and extend
features of it.
• Use cases are specialized version of other use cases.
• It is shown as solid line with hollow arrow point.
Generalization(Relationship between
Actors)

• Actor mostly have common properties and can be used by


various actors
• Actor may be depicted in an inheritance.

Transac
tion

Saving
Busines
accoun
s
t
Account
Relationship between Use cases

• Association

• Include

• Extend

• Generalization
Include Relationship
• Include relationship insert additional behavior into base use
case.
• Use cases that are included as a parts of other use cases.
• The base use case incorporates the behavior of another use
case at a location specified in the base.
• They are shown as dotted line with an open arrow and
keyword <<include>>.
Extend Relationship
• Extend relationship is used to indicate that use cases
conditionally adds behavior of another use case behavior at
one time.
• The base use case incorporates the behavior of another use
case at a certain points called extension point.
• They are shown as dotted line with an open arrow and
keyword <<extend>>.
Library Management
System

• Librarian can register members.


• Librarian can issue membership cards.
• Librarian can issue books to members.
• Members can return book to Librarian.
• Overdue return date will be charged with fine.
• Librarian can check availability of book.
• Librarian can maintain library books, i.e. add and edit book
data
• System generate reports regarding usability of books.
Describing Use Cases
• Alistair Cockburn presents a structured approach for the description
of use cases that contains the following information:
• Name
• Short description
• Precondition: prerequisite for successful execution
• Post condition: system state after successful execution
• Error situations: errors relevant to the problem domain
• System state on the occurrence of an error
• Actors that communicate with the use case
• Trigger: events which initiate/start the use case
• Standard process: individual steps to be taken
• Alternative processes: deviations from the standard process
• Table 3.1
Describing Use Cases
Use Cases Diagram,
Purpose

Use Class
Requirement diagram
Case
document

Activity
diagram

• Use cases are developed at a level of


abstraction. Sequence
• Use Case modeling is an iterative and diagram
incremental process.
State Space
diagram

You might also like