MIS 510 Week Five

UML and Systems
Analysis
MIS3502: Application Integration and Evaluation
Paul Weinberg
weinberg@temple.edu
Presentation by David Schuff and Paul Weinberg
Review: What is Systems
Analysis and Design?

Systems Analysis

Analysis of complex, large-scale
systems and the interactions within
those systems
http://en.wikipedia.org/wiki/Systems_analysis

Systems Design

The process of defining the hardware
and software architectures,
components, models, interfaces, and
data for a computer system to satisfy
specified requirements
http://en.wikipedia.org/wiki/Systems_design
Notice that
they are not
the same!
Basically…

Systems Analysis is the process of
modeling the problem
Requirements-oriented
 What should we do?


Systems Design is the process of modeling
a solution
Functionality-oriented
 How should we do it?

Why model?
 Creating
a blueprint for an
application
 Before you start coding
 The idea is to minimize having to go
back and make changes later
Why consider SAD in a
programming course?
The
business
analysts
Analysis
The
development
team
Design
Development
What this means

A developer must be able to turn the design
into code

But a good analyst should be able to
understand all parts of system development
Conduct an analysis
 Develop a design
 Implement the design (coding)

Example: Bjork’s ATM
example

An Example of Object Oriented Design, An
ATM Simulation, Russell Bjork

http://www.mathcs.gordon.edu/local/courses/cs211/ATMExample/
What we’ll look at…
Analysis Models
Use case diagrams
Design Models
Class name
Customer
Attributes
name
Operations
findName()
Design class diagrams
:Controller :Customer
:Order
Use case descriptions
Activity diagrams
Interaction diagrams
All diagrams adapted from “Systems Analysis and Design in a Changing World”, 3rd Edition
Satzinger, Jackson, Burd, Thompson Publishing, 2004.
Problem Statement




What is the application supposed to accomplish?
Use words, not code
Be as descriptive as possible
Potential sources of information




Forms, reports
Engineering drawings
Real world object specifications
Interviews
Problem statement for ATM
application







Services one customer at a time
Must be able to handle 10 customers an hour
Customer inserts ATM card and enters PIN to begin
Transactions
 Cash withdrawals --- in $20 increments
 Deposits
 Transfers
 Balance inquiries
Immediate transaction validation with the bank
Standard error procedures
 Pin error, rejection due to inadequate balance
Reports
Use Case Diagram

Use case:
sequence of
events that
represents an
interaction
between the
user and the
system
Session
Customer
(actor)
Cash
Withdrawal
Deposit
Transfer
Partial list of use
cases from Bjork
example
Invalid PIN
Bank
(actor)
Narrative Problem
Statement - Use Cases

A use case is a logical sequence of events from the
users first interaction, to the desired outcome.

For each use scenario, and each user (actor) . . . a use
case describes




The services the system provides to the user
The sequence of events
The desired outcome
Users of systems can be



people
organizations
other systems
A Use Case for the ATM
From the Bjork website:
System startup . . .
User: System operator
Services: Load cash dispenser, start ATM
"The system is started when the operator
turns the switch on the panel to 'on'. The
operator will be asked to enter the amount
of money in the cash dispenser . . . "
Object Classes Are . . .




Tangible Things
 Airplane, ATM, person
Roles
 Professor, student
Incidents and interactions
 Purchase, withdrawal, flight
Specifications
 Aircraft characteristics: Weight, wingspan, max
speed
Notice that many objects are not physical. (e.g. transactions, like a
purchase, are not physical)
Identifying Potential Object Classes






Identify noun-phrases (nouns and related adjectives) in the
narrative descriptions
Eliminate duplicates (including plurals of items in the list)
Eliminate state information (e.g. terms like "completion")
Eliminate synonyms
Assure that the classes are abstractions that a user would
recognize (Not implementation tools)
Determine whether actors not in the class list should be. Check to
see if other actors need their services.
Naming Objects

Avoid roles or states in the names
(e.g. ATM dispensing cash)
Testing Potential Classes

Objects instantiated from the classes must have the
same set of attributes . . .



Objects must have attributes




Dog licenses and vehicle licenses cannot be in the same
class
However, they can both be derived from the same class
Social security number is not a class, it is only a name
Social security account is a class
"Or" must be avoided in defining the class
The objects formed from a class must be more than a
list . . . The class must be definable
Static Class Relationships

Static relationships
 Inheritance: Class a is derived from class b
 Association, e.g.
President runs an airline
There are many students in one University
There may be many Universities associated with
one student.
 Aggregation (Special case of association): class a "is
comprised of" Class b, e.g.
A building has rooms
A course has 5 sections
Associations and aggregations are coded the same way.
Static Class Relationships in the Unified
Modeling Language (UML)
Aggregation
Inheritance
University
Animal
Dog
Cat
School
Static Class Relationships in the Unified
Modeling Language (UML) - Continued
Associations
*
1
Section
Professor
*
*
1
Course
*
Association relationships possible:
1 * --- One to many
* * --- Many to many
1 1 --- One to one
What are the specific associations in this example?
Static Class Relationships in the Unified Modeling
Language (UML) - Continued
Inheritance and
Associations in the
same diagram
Person
*
1
Section
Professor
*
*
1
Course
*
Exercise

Consider the following list of ATM classes
Bank
Card Reader
Session
Keyboard
Transaction
Display
Withdrawal
Cash Dispenser
Envelope Acceptor
Operator Panel
Deposit
Transfer
Inquiry



Are there any inheritance relationships?
Do any classes contain other classes?
Are there any other associations --- what are they?
Draw a UML representation of the relationships.
Review: Bjork's UML definition.
Completing the Static Class
Definitions

Determine and define attributes of
each class
Give an example of a field belonging to the
cash dispenser.
Dynamic class behavior
(public methods)
State of an object --- Values of all
attributes at a specific time
 Methods --





Respond to events
Handle requests from other objects
Send requests to other objects by calling
their methods
May return values --- Accessor methods (i.e.
have a non-void return value)
May modify state of an object --- Mutator
methods (i.e. may have a void return value)
A first step in establishing
public methods




Start with a use case or state diagram
Construct a sequence of steps required of
objects to complete the sequence of events
associated with each use case.
For each step
 Service description
 Object requesting the service (client)
 Object fulfilling the service
 Next object (or objects) involved in
completing the sequence
Identify methods for each object to perform the
services.
Sequence of Steps for a
Withdrawal

Withdrawal transaction
 ATM --> Card Reader checkForCardInserted()
 ATM --> Session startSession()
 Session --> Keyboard readPin()
 Session --> Keyboard readMenuChoice()
 Session --> WithDrawalTransaction
getTransactionSpecifics()
 WithDrawalTransaction --> Bank initiateWithdrawal
(cardNumber,PIN,ATM number, serial, from, amount)
Some of these steps require instantiation of new
objects by adding them to ArrayLists . . . others do not.
What is an example of this?
Following the state diagram for a session, what's next?
Next step: From model to
program . . .





Inheritance relationships coded as :
Relationships
 1:1 becomes instantiation of the related class
 1:* becomes instantiation of a ArrayList or array
containing the related class
Public Methods are determined from each
sequence of steps for major uses.
The methods are associated with specific classes.
Additional implementation classes
 GUI design and classes
 Data base and other technology-related classes
Design class diagrams


Shows the attributes and
methods of each class
Get the object names
and attributes from the
noun-phrase analysis


What is the object?
Get the methods from
the activity diagram

What should it do?
Class DepositTransaction
toAccount
Amount
DepositTransaction(session, atm, bank)
getTransactionSpecificsFromCustomer()
sendToBank()
finishApprovedTransaction()
Activity
diagram
Show which
activities
occur during
a use case
 This is for the
deposit use
case


The
customer
initiates the
transaction
Customer
ATM
Bank
Choose deposit
Ask which type
of account
Choose account
type
Ask deposit amount
Choose deposit
amount
Send customer
information to bank
Incorrect PIN?
yes
no
Incorrect PIN
exception
Transaction
failed
Transaction
completed
no
Approve
transaction
yes
Credit customer
account
Working from the design class
diagram


The DepositTransaction
class will have
 Two attributes
 Four methods
We can tell from this what
methods the class will
have but not what they do
 Refer to the use cases,
activity diagrams, and
interaction diagrams for
detail
Class DepositTransaction
toAccount
Amount
DepositTransaction(session, atm, bank)
getTransactionSpecificsFromCustomer()
sendToBank()
finishApprovedTransaction()
Interaction Diagrams
Show how the objects in the application
“use” each other
 Which methods are called
 What data is returned

ATM application:
Deposit Use Case
(self)
getTransactionSpecificsFromCustomer()
Customer
:ATM
Session
(session, atm, bank)
:Session
:DepositTransaction
:Bank
DepositTransaction
(session, atm, bank)
sendToBank()
(approval)
checkIfCashAvailable(amount)
(confirmation)
initiateDeposit(account, amount)
(confirmation)
finishApprovedTransaction()
(confirmation)
Fitting everything together
Customer
Session
Customer
(actor)
ATM
Customer
Bank
:ATM
Cash
Withdrawal
Bank
(actor)
Deposit
Transfer
:Session
:DepositTransaction
A deposit transaction is started from within a session when the customer chooses
deposit from the menu of possible transaction types. The customer chooses a type of
account to deposit to (e.g. checking) from a menu of possible accounts, and then
chooses a dollar amount by typing it on the keyboard. The system sends the
customer's card number, PIN, chosen account and amount to the bank, which either
approves or disapproves the transaction. If the transaction is approved, the machine
accepts an envelope from the customer containing cash and/or checks and then
issues a receipt. (If the customer does not insert the envelope within a specified period
of time, this operation times out and the deposit transaction is aborted.) If the
transaction is disapproved due to an incorrect PIN, the Incorrect PIN extension is
executed. All other disapprovals are reported to the session, which initiates the Failed
Transaction Extension. The bank is notified whether or not an approved transaction
was completed in its entirety by the machine; if it is completed then the bank
completes crediting the customer's account for the amount - contingent on manual
verification of the deposit envelope contents by an operator later.
Choose deposit
Ask which type
of account
toAccount
Amount
Choose account
type
Send customer
information to bank
yes
Transaction
completed
no
no
Approve
transaction
yes
Credit customer
account
DepositTransaction
(session, atm, bank)
sendToBank()
Incorrect PIN?
Incorrect PIN
exception
Transaction
failed
Session
(session, atm, bank)
DepositTransaction(session, atm, bank)
getTransactionSpecificsFromCustomer()
sendToBank()
finishApprovedTransaction()
(approval)
checkIfCashAvailable(amount)
(confirmation)
initiateDeposit(account, amount)
(confirmation)
finishApprovedTransaction()
(confirmation)
Invalid PIN
Use case diagram
List of all use cases
in the application
:Bank
Class DepositTransaction
Use case
descriptions
Textual description
of what happens in
each use case
Scenarios
Activity diagram
Picture of the
activities
described in
each use case
Design class
diagrams
Interaction
diagram
List of all methods
and attributes in
each object
Diagram of how the
objects work
together for each
use case
Objects
Integration and UML: Web
Services
We’ll be working with
this application later in
the course
 It uses the MSN Live
Search web service to
search the web
 Microsoft’s web service
is a distributed object

Things to think about
What if you have to code something not
accounted for in the design diagrams?
 Does the diagram have to match the code
exactly?
 What does it mean when…

…additional detail is required?
 …specified methods go unused?
 …different sequencing is required?


Download Report