B.

Chakraborty
 Normally client’s requirements are loosely
defined, fuzzy and ambiguous.
 A Use Case is a case or situation where
intended system is used to fulfill one or more
user’s requirements
 Each use case captures a piece of functionality
that the system provides
 Use cases are at the heart of the model as they
affect and guide all of the other elements of the
system’s design.
 Logical View Process View

Use Case View

Physical View Development View

Phillippe Krutchen’s 4+1 View Model

 Logical View:
 Describes the abstract descriptions of a system's
parts.
 Used to model what a system is made up of and how
the parts interact with each other.
 The types of UML diagrams that typically make up
this view include class, object, state machine and
interaction diagrams.
 Process View:
 Describes the processes within the system.
 It is particularly helpful when visualizing what must
happen within the system.
 This view typically contains activity diagrams.
 Development View:
 Describes how the system's parts are organized into
modules and components.
 It is very useful to manage layers within the system's
architecture
 This view typically contains package and component
diagrams.
 Physical View:
 Describes how the system's design, as described in
the three previous views, is then brought to life as a
set of real-world entities.
 The diagrams in this view show how the abstract
parts map into the final deployed system.
 This view typically contains deployment diagrams.
 Use Case View:
 Describes functionality of the system being modeled
from the perspective of the outside world.
 This view is needed to describe what the system is
supposed to do.
 All of the other views rely on the use case view to
guide them that's why the model is called 4+1.
 So, this is a good starting point of system analysis.
 This view typically contains use case diagrams,
descriptions and overview diagrams.
 The Online Shopping System shall allow a
general visitor or a member of the system to
choose any number specific items from the
shop's offers, get detail of the chosen items,
select and put the items in a cart, order the
items to be sent to his/her address. Purchaser
may pay online or pay on delivery.
Additionally, system should allow registration
of the visitor to become member, create a wish
list for future purchase.
 Identify Actors:
 Actors are the “things”, which interact with the
system but are not part of the system.
 An actor might be a person or could be a third
party’s system i.e. anything interacting with the
system.
 However, the actor can not be modified by the
system and the system cannot control its internal
working, but are essential for the interaction with the
system
 Represent Actors:
 Sticky figure, or
 Rectangle with <<Actor>>
stereotype.
 Give proper meaningful name
Member
of the actor, understandable to
both client and the system
Stereotype
designers.
 Stereotypes signify a special use <<Actor>>

or intent and can be applied to Member

almost any element of UML.

 Generalized
Actor
 Refining Actors:
Visitor
 Analyst may find some actors
are related to each other
 ‘Member’ may be derived from
Specific
the generalized actor ‘Visitor’ Actor
 ‘Admin’ may be more specific
than ‘Member’ Member

Generalization
Arrow
More
Specific
Actor
Admin
 Use Cases
 Once the actors are recognized, assemble exact
model of those interactions.
 From user’s requirement, find cases where the
system is being used to complete a specific job for an
actor.
 A use case from user’s perspective is a complete use
of the system.
 There will be some interaction with the system as
well as some output from that interaction.
 Use Cases
 Use case is something that provides some
measurable result to the user or an external system.
 Represent Use Case
 Use case is represented by an oval shape with the
name of the process inside the oval.

UserLogIn
 Communication Line
 Shows the actors participation with specific use
cases.
 An actor may communicate with more than one use
case.
 One use case may be interacted with more than one
actor.
 Direction of flow of data is not normally not shown
as type of information exchange is detailed in the use
case’s description.
 Communication Line

Visitor
UserLogIn

Admin

Member
 System Boundaries
 Though there is an implicit separation between
actors (external to system) and the uses cases
(internal to system) and that marks system's
boundary, UML does provide another small piece of
notation to make things more specific.
 System Boundaries

Online Shopping System

Visitor
UserLogIn

Admin

Member
 Use Case Documentation
 Description
 Flow of Event
 Basic Flow
 Alternative Flow
 Pre-Conditions
 Post-Conditions
 Use Case Documentation (Possible Extension)
 Trigger
 Actors
 Primary Actors
 Secondary Actors
 Remarks
 Online Shopping System

Visitor
UserLogIn

Admin

Member
 Online Shopping System

Visitor
UserLogIn

Admin

Member
 Online Shopping System

Visitor UserCredentials

UserLogIn

Admin

Member
 Online Shopping System

UserSignIn

UserCredentials

Visitor

UserLogIn

Admin

Member
 Online Shopping System

Create
UserSignIn Credentials

UserCredentials

Visitor Check
Credentials

UserLogIn
Admin

Member
 Online Shopping System

Create
UserSignIn Credentials

UserCredentials

Visitor Check
Credentials

UserLogIn
Admin
Admin
Login
Member
 Online Shopping System

Create
UserSignIn Credentials
Visitor

User SignIn will reauire UserCredentials

CheckCredentials to check
whether user is already a
member or not Check
Credentials

UserLogIn
Admin
Admin
Login
Member
 A visitor to the OLS system is the one whoever
visits the system on line. No logging action is
expected for a visitor. So, a visitor initially get
identity code for the session as its session code,
generated by the system.

 A visitor may sign in the system to change its

state to a member. For that proper signing in
process has to be triggered by the visitor. After
signing in, the visitor is automatically
converted to the member status.
 However, if a visitor is already a member, then
he / she can trigger log in process. Then for the
rest of the session, member will be identified
by the member code, and referred to by
registered first name of the member

 Admin would also be taken as visitor initially.

However logging in as an administrator,
he/she will be updated to the status of Admin
and rest of the session all privileges for Admin
will be made available to Admin.