9/22/2020
MASTER OF INFORMATION TECHNOLOGY
MASTER OF INFORMATION TECHNOLOGY Traditional Approach vs OO Approach
MIT 1204 Eg. A Library System-Lending Scenario
Entities
• Librarian enters the borrower id.
• System checks whether borrower Member
id exist.
• Check for Overdue Books. Member , LendingDetails
• Check Over limit Member, LendingDetails
Systems Analysis and Modelling • Enter copy id
Lecture 6
• Check Copy Borrowable Copy, Book
• Librarian Confirm Borrowing
Prof. Kapila. Dias 2020
• Update Borrowed Copy details
UNIVERSITY OF COLOMBO SCHOOL OF COMPUTING LendingDetails
366
Traditional Approach vs OO Approach Understanding OOAD Process
Eg. A Library System-Lending Scenario (Typical Approach)
Classes
• Librarian enters the borrower id.
• Gather Requirements – What problem you are
going to solve
• System checks whether borrower Member
id exist. • Describe the application – using actors, use
• Check for Overdue Books. Member , LendingDetails cases and narratives
• Check Over limit • Identify the main objects – use narratives
Member, LendingDetails
• Enter copy id • Describe the Interactions – object interactions
• Check Copy Borrowable Copy, Book , sequence diagrams
• Librarian Confirm Borrowing • Create the Class Diagram- map objects to
• Update Borrowed Copy details classes
LendingDetails
367 368
Gathering Requirements An Introduction to Use-Case Modeling
• Functional Requirements : What does it do? • The process of modeling a system’s functions
(Features, Capabilities) in terms of
eg. Program must allow receipts to be • business events
generated by e-mail • who initiated the events
• Non-Functional Requirements : What else? • how the system responds to those events
• Legal (eg. Banking System laws one needs to • An approach that facilitates user-centered
comply with) development
• Performance Requirements : eg Response time
etc. Respond to requests in 2 seconds.
369 370
1
9/22/2020
User-Centered Development and Use-
An Introduction to Use-Case Modeling
Case Modeling
User-centered development – a process of systems
development based on understanding the needs of
the stakeholders and the reasons why the system • Originally conceived by Dr. Ivar Jacobson in
should be developed. 1986.
• Proved to be a valuable aid in meeting the
Use-case modeling – the process of modeling a challenges of determining what a system is
system’s functions in terms of business events, who required to do from a user and stakeholder
initiated the events, and how the system responds perspective.
to those events. • A best practice for defining, documenting
• Use-case modeling has roots in object-oriented and understanding of an information
modeling. system’s functional requirements.
• Popular in non-object development
environments because of its usefulness in
communicating with users.
371 372
An Introduction to Use-Case Modeling System concepts for Use-Case Modeling
Use-case diagram
• Benefits • Depicts the interactions between the system and external
systems / users.
• Facilitates and encourages user involvement • Graphically describes who will use the system and in what
• Provides a tool for capturing functional ways the user expects to interact with the system
requirements
• Provides an aid in estimating project scope,
effort and schedule UseCase1
• Provides a tool for requirements traceability
• Provides a framework for driving the system Actor1 UseCase2
development project Actor3
UseCase1
Actor2
373 374
System concepts for Use-Case Modeling System concepts for Use-Case Modeling
• Use Cases • Scenario – Purchase Items
Needs three things - Customer Reviews items in the Shopping Cart
Title – What is the goal? Short phrase with - Customer provides payment and shopping information
an active verb. - System validate payment Information and respond with
confirmation of order
Actor – Who desires it? - System will send confirmation of order details to customer
Scenario – How is it accomplished? in an email.
Online
375 376
2
9/22/2020
User Story User Story Card (Front)
http://www.agilemodeling.com/artifacts/userStory.htm
Simpler and shorter way of describing a scenario from a user
perspective. Popular with Agile Methods
Format: Expresses something
As a <type of user>
I want <goal>
that
So that <Reason> a user of the system
User Story Points
Eg. As a Bank Customer wants to be able to do. a relative indication of how
I want to change my PIN online long it will take a pair of
So that I do not want to go the Bank programmers to implement
A team at Connextra developed the traditional user-story the story.
template in 2001
377 378
User Story Card (Back)
Use Story
As a (late riser), I want (to get my breakfast quickly)
in order (to catch the train)
• Can break this into number of more detailed stories about real
requirements
As a (late riser), I want (a four-slice toaster)
in order (to make breakfast quicker)
And
I want (a folding bike) in order (to get to the station
quicker)
What are Epics ,Themes?
379 380
User Stories used in Agile Development What information User Story may contain?
381 382
3
9/22/2020
User Stories
• User stories are about needs. It’s something
that the user needs to do in his day-to-day job.
• User stories are easy for users to read. When
you write a user story, write something that
anyone can understand, in the language of the
users.
• A User story is independent of the other user
stories
383 384
System concepts for Use-Case Modeling
System concepts for Use-Case Modeling
Use-case narrative
• Use Cases
• A textual description of the business event and
• A behaviorally related sequence of steps
how the user will interact with the system to both automated and manual for the purpose
accomplish the task. of completing a single business task.
• Use active voice. • Describe system functions from the
eg. System validates Member-ID perspective of external users in a manner
they understand.
385 386
System concepts for Use-Case Modeling System concepts for Use-Case Modeling
What is a Use Case? • Use Cases
It
is a typical interaction between a user • Represented graphically by a horizontal ellipse
and a computer system. with the name of the use case appearing
They are the primary elements in above, below, or inside the ellipse.
software development.
They represent the functionality provided
by the system. i.e. what capabilities will be Use Case Symbol
provided to an actor by the system.
388
387
4
9/22/2020
System concepts for Use-Case Modeling System concepts for Use-Case Modeling
• Actors
The collection of Use Cases for a system • Anyone or anything that needs to interact with
constitute all the defined ways the system
the system to exchange information.
may be used.
• Represented graphically as a stick figure labeled
How to capture Use Cases?
with the name of the role the actor plays.
By talking to typical users and discussing things
that they might want to do with the system.
eg. Borrowing of books , Returning of books
etc. (Library System) Actor Name
389 390
System concepts for Use-Case Modeling Actors
There are primarily four types of Actors
• Actors
• An Actor may
➢ Only input information to the system.
➢ Only receive information from the system. - Primary Business Actors
➢ Input and receive information to and from the system.
• Typically they are found in the problem
- Primary System Actor
statement and by conversations with customers - External Server Actor
and domain experts.
eg. Librarian in a Library System - External Receiver Actor
Bank
391 392
Types of Actors Types of Actors Cont…
• Primary Business Actors – Benefits from the
execution of use cases by receiving some • External Server Actor
thing measurable. eg. Credit bureau authorizing the charging
eg. Employee receiving a pay cheque. by a credit card.
• Primary System Actors - Directly Interfaces • External Receiver Actor
with the system to trigger an event.
eg. Warehouse receiving a package order
eg. Grocery Clerk – Scan customer buying
to prepare a shipment.
Items .
393 394
5
9/22/2020
Use Case Diagram Use Case Diagram
Introduced by Jacobson (1994)
to visualize use cases. <<extend>>
• Relationships
<<Communicates>> <<include>> • Depicted as a line between two symbols
Actor on the use-case diagram
<<include>> • Meaning of the relationship differs
<<depens on>> depending on how the lines are drawn and
type of symbols they connect.
395 396
Multiplicity of an Actor/Use Case (UML 2.5)
Use Case Diagram
• Required actor may be explicitly denoted using multiplicity
1 or greater.
• Relationships
• UML 2.5 also allows actor to be optional.
• Associations (also called <<Communicates>>)
• A relationship between an actor and a use case • Multiplicity 0..1 of actor means that the actor may or may
in which an interaction occurs between them not participate in any of their associated use cases.
• Modeled as a solid line connecting the actor and
the use case
• May be bidirectional or unidirectional
• UML 2.5 allows multiplicity
397 398
Multiplicity of an Actor / Use Case (UML 2.5) Use Case Diagram
• When a use case has an association to an • Relationships
actor with a multiplicity that is greater than • Extend <<extend>>
one at the actor end, it means that more than • <<extend>> provides a way to insert new behaviour
one actor instance is involved in the use case. into an existing use case.
• The extension use case extends the functionality of
the original use case.
• Shows optional behavior of a Use Case
• Depicted as an arrow headed line (either
solid/dashed)
399 400
6
9/22/2020
Use Case Diagram Use Case Diagram
base use case
• Relationships
Return book
• Extend Extension
Use Case
<<extend>>
Refer Catalogue
Borrow book Issue fine
Librarian
Place
New
Order
extension use case
401 402
Use Case Diagram Use Case Diagram
• Relationships
• Relationships <<include>>
• Uses (or include)
• Include • Another use case uses or includes the abstract use case.
• The base use case explicitly incorporates the behavior
of another use case. ChangeEmployeeDetails
• The relationship between the abstract use case and use
case that uses it.
Manager
Abstract use case: a use case that reduces redundancy among
two / more other use cases by combining the common steps ViewEmployeeDetails FindEmployee
found in those cases. Details
DeleteEmployeeDetails
403 404
Use Case Diagram Use Case Diagram
• Relationships <<depends on>>
• Relationships
• Depends on
• Depends on
• A relationship between use cases indicating that one
use case cannot be performed until another use case
has been performed.
• e. g. banking business – use case ‘ Make a Withdrawal’ cannot Establish
Bank Account
be performed until the use case ‘Make a Deposit’ has been
Make a
executed.
Deposit
Make a
Withdrawal
405 406
7
9/22/2020
Use Case Diagram Use Case Diagram
• Relationships Search library
• Generalization • Relationships inventory
• A relationship between actors created to simplify • Inheritance
Customer
the drawing when an abstract actor inherits the Apply for
role of multiple real actors membership
Check out
books
Visitor Search library Patron
inventory
Visitor
Apply for
Check out membership
Patron books
407 408
Include, extend and generalization Compared
Use Case Diagram
• System Boundary
• A Box drawn around the Use Cases to denote the
boundary of the system being modeled.
• Refer to as the Subject in UML 2.
409 410
Use Case Modelling : Exercise
Process of Requirements Use Case Modelling Vending Machine
• Objective
• analyze enough requirements information to prepare a
model that communicates what is required from a user
perspective Fanta Coke Tea
• It is free of specific details about how the system will be
built and implemented.
• Steps required to produce a model
• Identify business actors
• Identify business requirements use cases
• Construct use-case model diagram
• Document business requirements use-case narratives
Use Case model should also identify the System Insert Money Get Can
Boundary
Identify Actors, Use Casesgkad
and Draw a Use Case Diagram
411 412
UCSC