Systems Analysis and Design
3. System Analysis
Romi Satria Wahono
romi@romisatriawahono.net
http://romisatriawahono.net/sad
WA/SMS: +6281586220090
1
Romi Satria Wahono
•
•
•
•
•
•
•
•
SD Sompok Semarang (1987)
SMPN 8 Semarang (1990)
SMA Taruna Nusantara Magelang (1993)
B.Eng, M.Eng and Ph.D in Software Engineering from
Saitama University Japan (1994-2004)
Universiti Teknikal Malaysia Melaka (2014)
Research Interests: Software Engineering,
Intelligent Systems
Founder dan Koordinator IlmuKomputer.Com
Peneliti LIPI (2004-2007)
Founder dan CEO PT Brainmatics Cipta Informatika
2
Contents
1. Introduction
2. Project Planning
3. System Analysis
4. System Design
5. System Implementation
3
Recap
• Identifying the business value of the new
project is a key to success
• The system request describes an overview of
the proposed system.
• The feasibility study is concerned with
insuring that technical, economic, and
organizational benefits outweigh costs and
risks
• Project estimation methods: simply method,
function point and use case point
4
3. System Analysis
5
Learning Objectives
1. Understand how to create a requirements definition
2. Become familiar with requirements analysis
techniques
3. Understand when to use each requirements analysis
technique
4. Understand how to gather requirements using
interviews, JAD sessions, questionnaires, document
analysis, and observation
5. Understand when to use each requirementsgathering technique
6. Understand the system analysis and design using
UML
6
SDLC and Deliverables
Planning
(System Proposal)
Implementation
Analysis
(New System)
(System Specification)
Design
(System Specification)
7
Requirement Gathering
8
What is a Requirement
• Business Requirement
• Statement of what the system must do
• Focus on what the system must do, not how
to do it
• There are 2 kinds of requirements
1. Functional
2. Nonfunctional
9
Functional Requirement
• Defines the functions of the system must
carry out
• Specifies the process that must be performed
• Examples:
• Diagrams:
• Activity Diagrams
• Use Case Diagrams
• Problem Statements:
• Must search for inventory
• Must perform these calculations
• Must produce a specific report
10
Nonfunctional Requirements
Deals with how the system behaves:
1. Operational – Physical/technical
environment
2. Performance – Speed and reliability
3. Security – Who can use the system
4. Cultural & Political – Company policies,
legal issues
11
12
Requirement Gathering Methods
1.
2.
3.
4.
5.
Document Analysis
Interviews
Joint Application Design (JAD)
Questionnaires
Observation
13
1. Document Analysis
• Provides clues about the "formal" existing AsIs system
• Typical documents
• Forms
• Reports
• Policy manuals
• Look for user additions to forms
• Look for unused form elements
• Do document analysis before interviews
14
2. Interviews
• Most commonly used technique
• Very natural
• If you need to know something, you ask someone
• Five basic steps:
1.
2.
3.
4.
5.
Selecting interviewees
Designing interview questions
Preparing for the interview
Conducting the interview
Post-interview follow-up
15
3. Joint Application Design (JAD)
• Allows project managers, users, and
developers to work together
• May reduce scope creep by 50%
• Avoids requirements being too specific or
too vague
• Include 10 to 20 users
• Tend to last 5 to 10 days over a three week
period
16
JAD Meeting Room
JPEG Figure 5-5 Goes Here
17
4. Questionnaire
1. Selecting participants
• Using samples of the population
2. Designing the questionnaire
• More important than interview questions
• Prioritize questions to grab attention
• Distinguish between
• Fact-oriented questions (specific answers)
• Opinion questions (agree – disagree scale)
• Test the questionnaire on colleagues
18
4. Questionnaire
3.
Administering the questionnaire
•
•
•
•
•
•
Need to get good response rate
Explain its importance & how it will be used
Give expected response date
Follow up on late returns
Have supervisors follow up
Promise to report results
4. Questionnaire follow-up
• Send results to participants
19
5. Observation
• Users/managers often don’t remember
everything they do
• Validates info gathered in other ways
• Behaviors change when people are watched
• Keep low profile, don’t change the process
• Careful not to ignore periodic activities
• Weekly … Monthly … Annual
20
Selecting the Appropriate Techniques
Interviews
JAD
Questionnaires
Document
Analysis
Observation
Type of
Information
As-Is
Improve.
To-Be
As-Is
As-Is
Improve. Improve.
To-Be
As-Is
As-Is
Depth of
Information
High
High
Medium
Low
Low
Breadth of
Information
Low
Medium
High
High
Low
Integration
of Info.
Low
High
Low
Low
Low
User
Medium
Involvement
High
Low
Low
Low
Cost
LowMedium
Medium
Low
21
Low
LowMedium
Business Process Analysis
22
Business Process Analysis Steps
23
Business Process Analysis Strategies
1. BPA (Business Process Automation)
2. BPI (Business Process Improvement)
3. BPR (Business Process Reengineering)
24
Business Process Automation
• Makes almost no changes to business
processes
• Just makes them more efficient
• Improves efficiency by automating the
business processes
• Least impact on users
• They do the same things, just more efficiently
25
Business Process Improvement
• Goal is to improve the business processes
• Change what the users do, not just how
efficiently they do it
• Changes to business process must be decided
first
• Decisions to change the business processes
cannot be made by the analyst
26
Business Process Reengineering
“Fundamental rethinking and radical redesign
of business processes to achieve dramatic
improvements…”
• Throw away everything
• Start with a blank page
• Appealing, but very expensive and risky
27
Strategy Comparation
Business
Process
Automation
Business
Process
Improvement
Business
Process
Reeingineering
Potential Business
Value
Low-Moderate
Moderate
High
Project Cost
Low
Low-Moderate
High
Breadth of
Analysis
Narrow
Narrow-Moderate
Very Broad
Risk
Low
Low-Moderate
Very High
28
Barriers to Requirements
Gathering
29
Barriers to Requirements Elicitation
1. The "Yes, But" Syndrome
2. The "Undiscovered Ruins" Syndrome
3. The "User and the Developer" Syndrome
30
The "Yes, But" Syndrome
For whatever reason, we always see two immediate,
distinct, and separate reactions when the users see
the system implementation for the first time.
1. "Wow, this is so cool; we can really use this, what
a neat job" and so on.
2. "Yes, but, hmmmmm, now that I see it, what
about this ... ? Wouldn't it be nice if . . . ?
Whatever happened to . . . ?“
31
The "Yes, But" Syndrome
• The "Yes, But" syndrome is human nature and is an
integral part of application development.
• We should plan to avoid or significantly reduce this
syndrome by applying techniques that get the "Buts"
out early.
• In so doing, we elicit the "Yes, But" response early, and
we then can begin to invest the majority of our
development efforts in software that has already
passed the "Yes, But" test.
32
The "Undiscovered Ruins" Syndrome
• In many ways, the search for requirements is like a
search for undiscovered ruins.
• The more you find, the more you know remain.
• You never really feel that you have found them all, and
perhaps you never will.
• Indeed, software development teams always struggle
to determine when they are done with requirements
elicitation. When have they found
• all the requirements
• or at least enough requirements?
33
The "User and the Developer" Syndrome
• Communication gap between the user and the
developer.
• Users and developers are typically from different
worlds, may even speak different languages, and
have different backgrounds, motivations, and
objectives.
34
The "User and the Developer" Syndrome
Reasons for this problem and some suggested solutions
35
Key Points
• Requirements elicitation is complicated by three
endemic syndromes.
• The "Yes, But" syndrome stems from human nature
and the users' inability to experience the software
as they might a physical device.
• Searching for requirements is like searching for
"Undiscovered Ruins"; the more you find, the more
you know remain.
• The "User and the Developer" syndrome reflects
the profound differences between these two,
making communication difficult.
36
Analysis and Design using UML
37
Analysis Design Paradigm and Diagrams
1.
2.
3.
Data-oriented  DFD
Process-oriented  Flowchart
Object-oriented (data + process)  UML
38
Sejarah UML
Booch, Jacobson, Rumbaugh
• In the 90s many people
creating OO diagramming languages
• Three different ones created by Grady Booch, Ivar
Jacobson, James Rumbaugh
• Joined forces with
Rational (company) to
create Unified Modeling
Langauge (UML)
39
Sejarah UML
2011  UML 2.4
40
What is the UML?
• UML: Unified Modeling Language
• UML can be used for modeling all processes
in the development life cycle and across
different implementation technologies
(technology and language independent)
• UML is the standard language for visualizing,
specifying, constructing, and documenting
the artifacts of a software-intensive system
• UML is a communication tool – for the team,
and other stakeholders
41
The Triangle of Success in Software Dev.
Notation:
Standard
Process:
Tools:
CustomerOriented
Methodology
Support
Standard and
Process
42
UML Tools
• Rational Rose
• Visual Paradigm
• Enterprise Architect
• Microsoft Visio
• Star UML
• Netbeans UML Plugin
43
UML 2.0 Diagrams
UML version 2.0 has 14 diagrams in 2 major
groups:
1. Structure Diagrams
2. Behavior Diagrams
44
UML 2.0 Diagram
45
UML Structure Diagrams
Represent the data and static
relationships in an information system
1.
2.
3.
4.
5.
6.
Class Diagram
Object Diagram
Package Diagram
Deployment Diagram
Component Diagram
Composite Structure Diagram
46
Structure Diagrams
1. Class Diagrams
• Common vocabulary used by analyst and users
• Represent things (employee, paycheck,…)
• Shows the relationships between classes
2. Object Diagrams
• Similar to class diagrams
• Instantiation of a class diagram
• Relationships between objects
3. Package Diagrams
• Group UML elements together to form higher level
constructs
47
Structure Diagrams
4. Deployment Diagrams
•
•
Shows the physical architecture and software
components of system
For example, network nodes
5. Component Diagrams
•
•
Physical relationships among software components
Example – Client/Server (Which machines run which
software)
6. Composite Structure
• Illustrates internal structure of a complex class
48
UML Behavior Diagrams
1.
2.
3.
4.
Depict the dynamic relationships among the
instances or objects that represent the
business information system
Activity Diagram
Sequence Diagram
Communication Diagram
Interaction Diagram
5.
6.
7.
8.
49
Timing Diagram
Behavior State Machine
Protocol State Machine
Use Case Diagrams
Behavior Diagrams
1. Activity Diagrams
•
•
Model processes in an information system
Example: Business workflows, business logic
2. Interaction Diagrams
•
Shows interaction among objects
3. Sequence Diagrams
•
Time-based ordering of the interaction
4. Communication Diagrams
•
Communication among a set of collaborating objects of
an activity
50
Behavior Diagrams
5.
Interaction Diagrams
•
6.
Overview of flow of control of a process
Timing Diagrams
•
7.
Show how an object changes over time
State Machines
•
•
8.
Examines behavior of one class
Models the different states and state transitions an
object can experience
Use-Case Diagrams
•
•
Shows interaction between the system and
environment
Captures business requirements
51
UML Problems
1. UML is modeling notation, it is not a
development process or a methodology
• UML driven development process?
2. UML is too complex, difficult to understand
quickly
• Should we use all UML diagrams?
52
UML Process (EA Sparx)
1. Display the boundary of a system and its
major functions using use cases and actors
2. Model the organization’s business process
with activity diagram
3. Illustrate use case realizations with sequence
diagrams
4. Represent a static structure of a system using
class diagrams
5. Reveal the physical implementation
architecture with deployment diagrams
53
UML Process (EA Sparx)
1.
2.
3.
4.
5.
Use Cases Diagram
Activity Diagram
Sequence Diagram
Class Diagram
Deployment Diagrams
54
UML Process (Kendal, 2011)
1. A use case diagram, describing how the system is used.
Analysts start with a use case diagram
2. An activity diagram, illustrating the overall flow of
activities. Each use case may create one activity diagram
3. Sequence diagrams, showing the sequence of activities
and class relationships. Each use case may create one or
more sequence diagrams
4. Class diagrams, showing the classes and relationships.
Sequence diagrams are used to determine classes
5. Statechart diagrams, showing the state transitions. Each
class may create a statechart diagram, which is useful
for determining class methods
55
56
(Kendall and Kendall, 2011)
UML Process (Barclay, 2004)
57
System Analysis and Design with UML
1. System Analysis
1.
Business Process Identification

2.
Use Case Diagram
Business Process Modeling

3.
Activity Diagram or Business Process Modeling Notation (BPMN)
Business Process Realization

Sequence Diagram (Buat untuk setiap use case dengan menggunakan pola Boundary-Control-Entity)
2. System Design
1.
Program Design
1.
2.
3.
2.
3.
Class Diagram (Gabungkan Boundary-Control-Entity Class dan susun story dari sistem yang dibangun)
Package Diagram (Gabungan class yang sesuai, boleh menggunakan pola B-C-E)
Deployment Diagram (arsitektur software dari sistem yang dibangun)
User Interface Design (Buat UI design dari Boundary Class)
Entity-Relationship Model (Buat ER diagram dari Entity Class)
58
Case Study: ATM System
59
ATM System
60
ATM System
Layar
Kotak Kartu
Kotak Uang
Kotak Kuitansi
61
Masukkan PIN:
Kotak Kartu
Kotak Uang
Kotak Kuitansi
62
Menu Utama
1. Melihat Saldo
2. Mentransfer Uang
3. Mengambil Uang
4. Logout
Kotak Kartu
Kotak Uang
Kotak Kuitansi
63
Menu Melihat Saldo
1. Saldo anda adalah ….
Kotak Kartu
Kotak Uang
Kotak Kuitansi
64
Menu Mentransfer Uang
1. No Account Penerima:
Kotak Kartu
Kotak Uang
Kotak Kuitansi
65
Menu Mentransfer Uang
1. Jumlah uang yang dikirim:
Kotak Kartu
Kotak Uang
Kotak Kuitansi
66
Menu Mentransfer Uang
1. Uang berhasil terkirim
Kotak Kartu
Kotak Uang
Kotak Kuitansi
67
Menu Mengambil Uang
1. Jumlah uang yang diambil:
Kotak Kartu
Kotak Uang
Kotak Kuitansi
68
Menu Mengambil Uang
Uang berhasil diambil
Kotak Kartu
Kotak Uang
Kotak Kuitansi
69
Use Case Diagram
uc UCD - Sistem ATM
Sistem ATM
Memasukkan Kartu
«include»
Mengecek Saldo
Pengguna
Mentransfer Uang
Melakukan Logout
Mengambil Uang
70
Memasukkan PIN
Use Case Diagram (Alternatif)
uc Sistem ATM
Sistem ATM
Memasukkan Kartu
Memasukkan PIN
«include»
Melihat Saldo
«extend»
Mengirim Uang
Pengguna
«extend»
Admin
Memilih Transaksi
«extend»
Mengambil Uang
Mengganti Kotak
Deposit
Melakukan Logout
71
Activity Diagram: Memasukkan Kartu
act AD1 - Memasukkan Kartu
Pengguna
Sistem ATM
Mulai
Menyiapkan Kartu
Memv alidasi Kartu
Memasukkan Kartu
kartu valid?
tidak
Mengeluarkan Kartu
ya
Menampilkan MenuPIN
Selesai
72
Activity Diagram: Memasukkan PIN
act AD2 - Memasukkan PIN
Pengguna
Sistem ATM
Mulai
tidak
Memasukkan PIN
Memv alidasi Account
pin valid?
lebih dari 3x?
tidak
ya
ya
Memblokkir Kartu
Menampilkan MenuUtama
Selesai
73
Activity Diagram: Mengecek Saldo
act AD3 - Mengecek Saldo
Pengguna
Sistem ATM
Mulai
Memilih Mengecek Saldo
di Menu Utama
Memproses Pengecekan
Saldo
Menampilkan Saldo di
Menu Saldo
Selesai
74
Activity Diagram: Mentransfer Uang
act AD4 - Mentransfer Uang
Pengguna
Sistem ATM
Mulai
Memilih Mentransfer Uang
di Menu Utama
tidak
Memv alidasi Account
Tuj uan
Memasukkan Account
Tuj uan
Account Tujuan Valid?
Memasukkan Jumlah
Uang yang dikirim
ya
tidak
Menghitung Kecukupan
Saldo Pengirim
Saldo Cukup?
ya
Mentransfer Uang
Selesai
75
Activity Diagram: Mengambil Uang
act AD5 - Mengambil Uang
Pengguna
Sistem ATM
Mulai
Memilih Menu Mengambil
Uang di Menu Utama
tidak
Mengecek Ketercukupan
Saldo
Memasukkan Jumlah
Uang
Saldo Cukup?
ya
Memproses Pengambilan
Uang
Mengeluarkan Uang di
Kotak Uang
Mengambil Uang di Kotak
Uang
Selesai
76
Activity Diagram: Melakukan Logout
act AD6 - Melakukan Logout
Pengguna
Sistem ATM
Mulai
Memilih Keluar di Menu
Utama
Memproses Logout
Mengeluarkan Kuitansi
Mengeluarkan Kartu
Mengambil Kuitansi
Mengambil Kartu
Selesai
77
Sequence Diagram: Memasukkan Kartu
sd SD1 - Memasukkan Kartu
Pengguna
KotakKartu
ProsesValidasiKartu
memasukanKartu()
validasiKartu()
alt kartu v alid?
tampilkan()
[ya]
[tidak]
mengeluarkanKartu()
(from 1 Use Case Diagram)
78
MenuPIN
Type of Class
1. Boundary Class
•
Class yang berhubungan dengan actor (user
interface)
2. Control Class
•
Class yang berhubungan dengan pemrosesan,
komputasi, penghitungan, dsb
3. Entity Class
•
Class yang berhubungan dengan data (flat file or
database)
79
Sequence Diagram: Memasukkan PIN
sd SD2 - Memasukkan PIN
Pengguna
MenuPIN
ProsesValidasiAccount
Account
memasukkanPIN()
validasi(id, pin)
getIDLogin()
getPIN()
alt PIN v alid?
tampilkan()
[ya]
[tidak]
alt lebih dari 3x?
tampilkan()
[tidak]
[ya]
blokirAccount()
errorKartuDiblokir()
(from 1 Use Case Diagram)
80
Login
MenuUtama
Sequence Diagram: Mengecek Saldo
sd SD3 - Mengecek Saldo
Pengguna
MenuUtama
ProsesMengecekSaldo
Account
Balance
memilihMengecekSaldo()
lihatSaldo(id)
getIDBalance()
getSaldo()
setTransaksi(tgl, jenis)
tampilkanHasil(saldo)
(from 1 Use Case Diagram)
81
Transaksi MenuMengecekSaldo
Sequence Diagram: Mentransfer Uang
sd SD4 - Mentransfer Uang
Pengguna
MenuUtama
MenuMentransferUang
ProsesMentransferUang
Account
pengirim:Balance penerima:Balance Transaksi
memilihMentransferUang()
tampilkan()
memasukkanJumlahUang()
memasukkanAccountTujuan()
transferUang(id, jumlah)
getIDBalance()
getSaldo()
alt saldo cukup?
setSaldo(saldo)
[ya]
setSaldo(saldo)
setTransaksi(tgl, jenis)
tampilkanUangBerhasilDikirim()
[tidak]
tampilkanErrorSaldoTidakCukup()
82
Sequence Diagram: Mengambil Uang
d SD5 - Mengambil Uang
Pengguna
MenuUtama
MenuMengambilUang
ProsesMengambilUang
Account
Balance
memilihMengambilUang()
from 1 Use Case Diagram)
tampilkan()
memasukkanJumlah()
ambilUang(id, jumlah)
getIDBalance()
getSaldo()
alt saldo cukup?
setSaldo(saldo)
[ya]
keluarkanUang(jumlah)
setTransaksi(tgl, jenis)
TampilkanUangBerhasilDiambil()
[tidak]
TampilkanErrorSaldoTidakCukup()
83
Transaksi
KotakUang
Sequence Diagram: Melakukan Logout
sd SD6 - Melakukan Logout
Pengguna
MenuUtama
MenuLogout
ProsesLogout
KotakKuitansi KotakKartu
memilihKeluar()
tampilkan()
logout()
keluarkanKuitansi()
keluarkanKartu()
tampilkanTelahKeluar()
(from 1 Use Case Diagram)
84
Class Diagram
class CD - Sistem ATM
ProsesValidasiAccount
KotakUang
Login
mengakses
KotakKuitansi
mengakses
memiliki
melakukan
memiliki
ProsesMengecekSaldo
MenuMengecekSaldo
melakukan
MenuPIN
SistemATM
+
Account
lihatSaldo() : void
memiliki
mewarisi
menampilkan
Balance
MenuMentransferUang
ProsesMentransferUang
memiliki
melakukan+
+
+
mewarisi
MenuUtama
m_Account: Account
m_Balance: Balance
m_Transaksi: Transaksi
KotakKartu
mewarisi
MenuMengambilUang
melakukan
+
+
ProsesMentransferUang()
transferUang() : void
mewarisi
melakukan
ProsesValidasiKartu
ProsesMengambilUang
MenuLogout
melakukan
ProsesLogout
85
+
+
+
m_Account: Account
m_Balance: Balance
m_Transaksi: Transaksi
+
+
ambilUang() : void
ProsesMengambilUang()
Transaksi
Deployment Diagram (3 Tier)
deployment DD Sistem ATM
Application Serv er
Rich Client
Web Container
EJB Container
«artifact»
JSP
«artifact»
JFC
«artifact»
SessionBean
DBMS
«artifact»
MySQL
«artifact»
JSF
«artifact»
JVM
«artifact»
Zend Optimizer
«artifact»
Serv let
86
Data Model
87
User Interface Design
88
User Interface Design (Netbeans)
89
Business Process Identification
90
System Analysis and Design with UML
1. System Analysis
1.
Business Process Identification

2.
Use Case Diagram
Business Process Modeling

3.
Activity Diagram or Business Process Modeling Notation (BPMN)
Business Process Realization

Sequence Diagram
(Buat untuk setiap use case dengan menggunakan pola Boundary-Control-Entity)
2. System Design
1.
Program Design
1.
2.
3.
2.
3.
Class Diagram (Gabungkan Boundary-Control-Entity Class dan susun story dari sistem yang dibangun)
Package Diagram (Gabungan class yang sesuai, boleh menggunakan pola B-C-E)
Deployment Diagram (arsitektur software dari sistem yang dibangun)
User Interface Design (Buat UI design dari Boundary Class)
Entity-Relationship Model (Buat ER diagram dari Entity Class)
91
Use Case Diagram
92
Use Case Diagrams
• Summarized into a single picture
• All of the use cases for the part of the
system being modeled
• Use case represents the discrete activities
performed by the user
• Use Case Diagram tells what the system
will do
• Good for communicating with users
93
Syntax for an Use Case Diagram
• Actor
• person or system that derives benefit
from and is external to the subject
• Use Case
• Represents a major piece of system
functionality
• Association Relationship
• Include Relationship
• Extend Relationship
• Generalization Relationship
94
<<includes>>
<<extends>>
Use Case
• A major piece of
system functionality
Use Case
• Can extend other
Use Cases
• Placed inside system boundary
• Labeled with descriptive
verb - noun phrase
95
System Boundary
• Includes the name
Boundary
of the system
inside or on top
• Represents the
scope of the system
• Actors are outside the scope of the system
96
Actor
• A person or another
system that interacts
with the current system
• A role, not a specific user
• Provides input,
receives output, or both
97
actor
Actor/Role
Association Relationship
• Links actor and the Use Case
• Shows two-way communication
• If one-way, arrows are used
• * is for "multiplicity of the Association"
*
*
98
Extends Relationship
• Extends Use Case to include Optional
behavior
• Arrow points from the extension Use Case to
the base Use Case
extend
Make Payment
Arrangement
extend
99
Make
Appointment
Include Relationship
• Include one Use Case from within another
• Arrow points from base Use Case to the
included Use Case
include
Make New
Patient Appointment
include
100
Create New
Patient
Generalization Relationship
• A specialized Use Case to a more
generalized Use Case
• Arrow points from specialized to general
Use Case
Make Old
Appointment
Make
Appointment
101
Use Case Diagram for Appointment System
102
Use Case Diagram with Specialized Actor
103
Extend and Include Relationships
104
Studi Kasus: ATM System
105
ATM System
106
ATM System
Layar
Kotak Kartu
Kotak Uang
Kotak Kuitansi
107
Masukkan PIN:
Kotak Kartu
Kotak Uang
Kotak Kuitansi
108
Menu Utama
1. Melihat Saldo
2. Mentransfer Uang
3. Mengambil Uang
4. Logout
Kotak Kartu
Kotak Uang
Kotak Kuitansi
109
Menu Melihat Saldo
1. Saldo anda adalah ….
Kotak Kartu
Kotak Uang
Kotak Kuitansi
110
Menu Mentransfer Uang
1. No Account Penerima:
Kotak Kartu
Kotak Uang
Kotak Kuitansi
111
Menu Mentransfer Uang
1. Jumlah uang yang dikirim:
Kotak Kartu
Kotak Uang
Kotak Kuitansi
112
Menu Mentransfer Uang
1. Uang berhasil terkirim
Kotak Kartu
Kotak Uang
Kotak Kuitansi
113
Menu Mengambil Uang
1. Jumlah uang yang diambil:
Kotak Kartu
Kotak Uang
Kotak Kuitansi
114
Menu Mengambil Uang
Uang berhasil diambil
Kotak Kartu
Kotak Uang
Kotak Kuitansi
115
Use Case Diagram
uc UCD - Sistem ATM
Sistem ATM
Memasukkan Kartu
«include»
Mengecek Saldo
Pengguna
Mentransfer Uang
Melakukan Logout
Mengambil Uang
116
Memasukkan PIN
Use Case Diagram (Alternatif)
uc Sistem ATM
Sistem ATM
Memasukkan Kartu
Memasukkan PIN
«include»
Melihat Saldo
«extend»
Mengirim Uang
Pengguna
«extend»
Admin
Memilih Transaksi
«extend»
Mengambil Uang
Mengganti Kotak
Deposit
Melakukan Logout
117
Exercise: Business Process Identification
1. Lihat kembali System Request yang
sudah anda buat
2. Lakukan business process
identification dengan membuatkan
Use Case Diagram untuk System
Request tersebut
118
Exercise: Systems Analysis and Design
• Lakukan sistem analysis and design yang menghasilkan diagram:
1.
Use Case Diagram
• Pilih salah satu aplikasi di bawah:
1.
Aplikasi Rental Mobil
7.
Aplikasi Penjualan Buku Online
2.
Aplikasi Pengelolaan Klinik
8.
Aplikasi Penjualan Tiket Kereta Online
3.
Aplikasi Pengelolaan Apotik
9.
Aplikasi Manajemen Universitas Online
4.
Aplikasi Pengelolaan Service Mobil
10. Aplikasi Penjualan Laptop Online
5.
Aplikasi Penjualan Motor
11. Aplikasi Perpustakaan Digital
6.
Aplikasi Pengelolaan Perpustakaan
12. Aplikasi Pengelolaan Project Software
119
Business Process Modeling
120
System Analysis and Design with UML
1. System Analysis
1.
Business Process Identification

2.
Use Case Diagram
Business Process Modeling

3.
Activity Diagram or Business Process Modeling Notation (BPMN)
Business Process Realization

Sequence Diagram (Buat untuk setiap use case dengan menggunakan pola Boundary-Control-Entity)
2. System Design
1.
Program Design
1.
2.
3.
2.
3.
Class Diagram (Gabungkan Boundary-Control-Entity Class dan susun story dari sistem yang dibangun)
Package Diagram (Gabungan class yang sesuai, boleh menggunakan pola B-C-E)
Deployment Diagram (arsitektur software dari sistem yang dibangun)
User Interface Design (Buat UI design dari Boundary Class)
Entity-Relationship Model (Buat ER diagram dari Entity Class)
121
Business Process Modeling with
Activity Diagrams
122
BPM With Activity Diagrams
• A number of activities support a
business process across several
departments
• Activity diagrams model the behavior in
a business process
123
Syntax for an Activity Diagram
124
Activity Diagram Example
125
Creating Activity Diagrams
1. Set the context or scope of the activity
being modeled
2. Identify the activities and control/object
flows between activities
3. Identify any decisions made
4. Look for opportunities for parallelism
5. Draw the diagram
126
Business Process Modeling with
BPMN
127
128
129
130
131
Credit Application
132
Purchase Request
133
Shipment Process of a Hardware Retailer
134
The Pizza Collaboration
135
Order Fulfillment and Procurement
136
Studi Kasus: ATM System
137
Activity Diagram: Memasukkan Kartu
act AD1 - Memasukkan Kartu
Pengguna
Sistem ATM
Mulai
Menyiapkan Kartu
Memv alidasi Kartu
Memasukkan Kartu
kartu valid?
tidak
Mengeluarkan Kartu
ya
Menampilkan MenuPIN
Selesai
138
Activity Diagram: Memasukkan PIN
act AD2 - Memasukkan PIN
Pengguna
Sistem ATM
Mulai
tidak
Memasukkan PIN
Memv alidasi Account
pin valid?
lebih dari 3x?
tidak
ya
ya
Memblokkir Kartu
Menampilkan MenuUtama
Selesai
139
Activity Diagram: Mengecek Saldo
act AD3 - Mengecek Saldo
Pengguna
Sistem ATM
Mulai
Memilih Mengecek Saldo
di Menu Utama
Memproses Pengecekan
Saldo
Menampilkan Saldo di
Menu Saldo
Selesai
140
Activity Diagram: Mentransfer Uang
act AD4 - Mentransfer Uang
Pengguna
Sistem ATM
Mulai
Memilih Mentransfer Uang
di Menu Utama
tidak
Memv alidasi Account
Tuj uan
Memasukkan Account
Tuj uan
Account Tujuan Valid?
Memasukkan Jumlah
Uang yang dikirim
ya
tidak
Menghitung Kecukupan
Saldo Pengirim
Saldo Cukup?
ya
Mentransfer Uang
Selesai
141
Activity Diagram: Mengambil Uang
act AD5 - Mengambil Uang
Pengguna
Sistem ATM
Mulai
Memilih Menu Mengambil
Uang di Menu Utama
tidak
Mengecek Ketercukupan
Saldo
Memasukkan Jumlah
Uang
Saldo Cukup?
ya
Memproses Pengambilan
Uang
Mengeluarkan Uang di
Kotak Uang
Mengambil Uang di Kotak
Uang
Selesai
142
Activity Diagram: Melakukan Logout
act AD6 - Melakukan Logout
Pengguna
Sistem ATM
Mulai
Memilih Keluar di Menu
Utama
Memproses Logout
Mengeluarkan Kuitansi
Mengeluarkan Kartu
Mengambil Kuitansi
Mengambil Kartu
Selesai
143
Exercise: Business Process Modeling
1.
2.
3.
Lihat kembali System Request dan Use
Case Diagram yang sudah anda buat
Lakukan business process modeling
dengan membuatkan Activity Diagram
untuk setiap Use Case yang dibuat
Yang harus dibuat: System Request,
Feasibility Analysis, Project Size
Estimation (FP) (DOC dan XLS), Use Case
Diagram, Activity Diagram (EAP)
144
Exercise: Systems Analysis and Design
• Lakukan sistem analysis and design yang menghasilkan diagram:
1.
2.
Use Case Diagram
Activity Diagram
• Pilih salah satu aplikasi di bawah:
1.
Aplikasi Rental Mobil
7.
Aplikasi Penjualan Buku Online
2.
Aplikasi Pengelolaan Klinik
8.
Aplikasi Penjualan Tiket Kereta Online
3.
Aplikasi Pengelolaan Apotik
9.
Aplikasi Manajemen Universitas Online
4.
Aplikasi Pengelolaan Service Mobil
10. Aplikasi Penjualan Laptop Online
5.
Aplikasi Penjualan Motor
11. Aplikasi Perpustakaan Digital
6.
Aplikasi Pengelolaan Perpustakaan
12. Aplikasi Pengelolaan Project Software
145
Business Process Realization
146
System Analysis and Design with UML
1. System Analysis
1.
Business Process Identification

2.
Use Case Diagram
Business Process Modeling

3.
Activity Diagram or Business Process Modeling Notation (BPMN)
Business Process Realization

Sequence Diagram
(Buat untuk setiap use case dengan menggunakan pola Boundary-Control-Entity)
2. System Design
1.
Program Design
1.
2.
3.
2.
3.
Class Diagram (Gabungkan Boundary-Control-Entity Class dan susun story dari sistem yang dibangun)
Package Diagram (Gabungan class yang sesuai, boleh menggunakan pola B-C-E)
Deployment Diagram (arsitektur software dari sistem yang dibangun)
User Interface Design (Buat UI design dari Boundary Class)
Entity-Relationship Model (Buat ER diagram dari Entity Class)
147
Sequence Diagram
148
Sequence Diagrams
• Illustrate the objects that participate in
a use case
• Show the messages that pass between
objects for a particular use-case over
time
149
Sequence Diagram Syntax
AN ACTOR
AN OBJECT
anObject:aClass
A LIFELINE
A FOCUS OF CONTROL
A MESSAGE
aMessage()
x
OBJECT DESTRUCTION
150
Sequence Diagram
1. Susun Sequence Diagram untuk setiap Use
Case yang dibuat
2. Mulai dari menarik Actor yang ada di Use
Case Diagram, lanjutkan dengan membuat
sequence detail dari berjalannya Use Case
Catatan: Objek dari Lifeline di Sequence Diagram akan
menjadi kandidat Class
151
Jenis Class
1. Boundary Class:
1. Class yang berinteraksi dengan aktor langsung (user
interface)
2. Form, input, UI ini masuk di sini
2. Control Class:
1. Class yang berhubungan dengan pemrosesan,
penghitungan, kalkulasi, komputasi, query, dst
3. Entity Class:
1. Class yang berhubungan dengan data, penyimpanan
data/file
152
Studi Kasus: ATM System
153
Sequence Diagram: Memasukkan Kartu
sd SD1 - Memasukkan Kartu
Pengguna
KotakKartu
ProsesValidasiKartu
memasukanKartu()
validasiKartu()
alt kartu v alid?
tampilkan()
[ya]
[tidak]
mengeluarkanKartu()
(from 1 Use Case Diagram)
154
MenuPIN
Sequence Diagram: Memasukkan PIN
sd SD2 - Memasukkan PIN
Pengguna
MenuPIN
ProsesValidasiAccount
Account
memasukkanPIN()
validasi(id, pin)
getIDLogin()
getPIN()
alt PIN v alid?
tampilkan()
[ya]
[tidak]
alt lebih dari 3x?
tampilkan()
[tidak]
[ya]
blokirAccount()
errorKartuDiblokir()
(from 1 Use Case Diagram)
155
Login
MenuUtama
Sequence Diagram: Mengecek Saldo
sd SD3 - Mengecek Saldo
Pengguna
MenuUtama
ProsesMengecekSaldo
Account
Balance
memilihMengecekSaldo()
lihatSaldo(id)
getIDBalance()
getSaldo()
setTransaksi(tgl, jenis)
tampilkanHasil(saldo)
(from 1 Use Case Diagram)
156
Transaksi MenuMengecekSaldo
Sequence Diagram: Mentransfer Uang
sd SD4 - Mentransfer Uang
Pengguna
MenuUtama
MenuMentransferUang
ProsesMentransferUang
Account
pengirim:Balance penerima:Balance Transaksi
memilihMentransferUang()
tampilkan()
memasukkanJumlahUang()
memasukkanAccountTujuan()
transferUang(id, jumlah)
getIDBalance()
getSaldo()
alt saldo cukup?
setSaldo(saldo)
[ya]
setSaldo(saldo)
setTransaksi(tgl, jenis)
tampilkanUangBerhasilDikirim()
[tidak]
tampilkanErrorSaldoTidakCukup()
157
(from 1 Use Case Diagram)
Sequence Diagram: Mengambil Uang
d SD5 - Mengambil Uang
Pengguna
MenuUtama
MenuMengambilUang
ProsesMengambilUang
Account
Balance
memilihMengambilUang()
from 1 Use Case Diagram)
tampilkan()
memasukkanJumlah()
ambilUang(id, jumlah)
getIDBalance()
getSaldo()
alt saldo cukup?
setSaldo(saldo)
[ya]
keluarkanUang(jumlah)
setTransaksi(tgl, jenis)
TampilkanUangBerhasilDiambil()
[tidak]
TampilkanErrorSaldoTidakCukup()
158
Transaksi
KotakUang
Sequence Diagram: Melakukan Logout
sd SD6 - Melakukan Logout
Pengguna
MenuUtama
MenuLogout
ProsesLogout
KotakKuitansi KotakKartu
memilihKeluar()
tampilkan()
logout()
keluarkanKuitansi()
keluarkanKartu()
tampilkanTelahKeluar()
(from 1 Use Case Diagram)
159
Exercise: Sequence Diagram
1. Lihat kembali System Request, Use
Case Diagram, dan Activity Diagram
yang sudah anda buat
2. Lengkapi diagram tersebut dengan
Sequence Diagram untuk setiap Use
Case yang dibuat
160
Exercise: Systems Analysis and Design
• Lakukan sistem analysis and design yang menghasilkan diagram:
1.
2.
3.
Use Case Diagram
Activity Diagram
Sequence Diagram
• Pilih salah satu aplikasi di bawah:
1.
Aplikasi Rental Mobil
7.
Aplikasi Penjualan Buku Online
2.
Aplikasi Pengelolaan Klinik
8.
Aplikasi Penjualan Tiket Kereta Online
3.
Aplikasi Pengelolaan Apotik
9.
Aplikasi Manajemen Universitas Online
4.
Aplikasi Pengelolaan Service Mobil
10. Aplikasi Penjualan Laptop Online
5.
Aplikasi Penjualan Motor
11. Aplikasi Perpustakaan Digital
6.
Aplikasi Pengelolaan Perpustakaan
12. Aplikasi Pengelolaan Project Software
161
Collaboration Diagram
162
Collaboration Diagrams
• Essentially an object diagram that shows
• Message passing relationships
• Instead associations
• Emphasize
• The flow of messages among objects
• Rather than timing and ordering of messages
163
Collaboration Diagram Syntax
AN ACTOR
AN OBJECT
anObject:aClass
AN ASSOCIATION
aMessage()
A MESSAGE
164
Example Collaboration Diagram
165
State Machine Diagram
166
Behavioral State Machines
• Some objects may change states often
• Some may change state and never change
back
• Patient: new  current  former
• This is seen in the cells of the CRUD matrix
167
Behavioral State Machines
• The behavioral state machine is a dynamic
model that shows this
• The behavioral state machine shows
• The different states of an object
• The events
• That cause the object to change from one state to
another
168
Components of Statechart Diagrams
• States
• Determined by the values of the attributes
• Events
• Changes the state of an object
• e.g. changes the values of attributes
169
Components of Statechart Diagrams
• Transitions
• Movement of an object from one state to another
• Often has a guard condition
• Actions
• Atomic process, takes "zero time"
• Activities
• Non-atomic, take a long time, can be started and
stopped
170
Statechart Diagram Syntax
aState
A STATE
AN INITIAL STATE
A FINAL STATE
anEvent
AN EVENT
A TRANSITION
171
Example Behavioral State Machine Diagram
172
Building Behavioral State Machine Diagrams
• Set the context
• Identify
• Initial state
• Final state
• All stable states
• Determine the order in which the object will pass
through stable states
• Identify the events, actions, and guard conditions
associated with the transitions
• Validate the diagram
173
Estimating Project Size with
Use Case Points
Gustav Karner (1993)
174
Actor and Use Case Weighting Tables
Unadjusted Actor Weighting (UAW)
Actor Type Description
Weighting Factor
Simple
External System with well-defined API
1
Average
External System using a protocolbased
interface, e.g., HTTP, TCT/IP, SQL
2
Complex
Human
3
Unadjusted Use Case Weighting (UUCW)
Use-Case Type Description
Weighting Factor
Simple
1-3 transactions
5
Average
4-7 transactions
10
Complex
More than 7 transactions
15
Unadjusted Use Case Points (UUCP) = UAW + UUCW
175
Technical Complexity Factors
Factor
Number
Description
Weight
T1
Distributed system
2.0
T2
Response time or throughput performance
objectives
1.0
T3
End-user online efficiency
1.0
T4
Complex internal processing
1.0
T5
Reusability of code
1.0
T6
Easy to install
0.5
T7
Ease of use
0.5
T8
Portability
2.0
T9
Ease of change
1.0
Technical Complexity Factor (TCF) = 0.6 + (0.01 * TFactor)
176
Environmental Complexity Factors
Factor
Number
Description
Weight
E1
Familiarity with system development process in use
1.5
E2
Application experience
0.5
E3
Object-oriented experience
1.0
E4
Lead analyst capability
0.5
E5
Motivation
1.0
E6
Requirements stability
2.0
E7
Part time staff
-1.0
E8
Difficulty of programming language
-1.0
Environmental Factor (ECF) = 1.4 + (-0.03 * EFactor)
177
Computing Use Case Points
• Adjusted Use Case Points (UCP) = UUCP * TCF * ECF
• Effort in Person Hours = UCP * PHM
178
Person Hour Multiplier (PHM)
If the sum of (number of Efactors ECF1 through
ECF6 assigned value < 3) and (number of
Efactors ECF7 and ECF8 assigned value > 3) ≤ 2
PHM = 20
Else If the sum of (number of Efactors ECF1
through ECF6 assigned value < 3) and (number
of Efactors ECF7 and ECF8 assigned value > 3) =
3 or 4
PHM 28
Else
Rethink project; it has too high of a risk for failure
179
Person Hour Multiplier (PHM)
• Let F1 = Number of ECF1 to ECF6 that are < 3
• Let F2 = Number of ECF7 and ECF8 that are > 3
• If F1 + F2 <= 2
PHM = 20
Else if F1 + F2 = 3 or 4
PHM = 28
Else
Scrap the project
180
Use Case Points in EA
181
182
Effort Estimation from PM Defined
Effort Estimation of Sistem ATM
UCP
PH
PM
PM
= 32
PHM = 20
= 20*32
= 640
= 640/8/22 = 3.6
= 640/10/26 = 2.4
(10 Jam/hari dan sabtu masuk )
TIME (M)
TIME (M)
TIME (M)
TIME (M)
= 3.0 * PM 1/3
= 3.0 * 3.4 1/3
= 4.5
= 3.9 (LEMBUR )
183
Budget (Custom Software)
Pekerjaan
Man-Month
Month
Budget
Total
Planning
2
1
5000.000
10.000.000
1
10.000.000
20.000.000
Analysis
Design
2
1
4000.000
32.000.000
Implementation
4
2
3000.000
24.000.000
Training
2
1
4000.000
8000.000
94.000.000
184
Budget (Generic Software)
Product
Total
LMS
10.000.000
Teleconference
2.000.000
Chatting
4.000.000
eLibrary
20.000.000
185
Exercise: Project Size Estimation
1. Lihat kembali Use Case Diagram, dan
Sequence Diagram yang telah anda buat
2. Estimasi Project Size, Effort dan Time dengan
menggunakan Use Case Point
186
Exercise: System Analysis untuk System Request
1.
2.
Lihat kembali System Request yang sudah
anda buat
Lakukan system analysis dengan membuat
diagram di bawah:
1.
2.
3.
3.
Use Case Diagram
Activity Diagram
Sequence Diagram
Buat project baru di Sparx EA, buat 3
package dengan nama sama dengan 3
diagram di atas
187
Referensi
1. Alan Dennis et al, Systems Analysis and Design with
UML 4th Edition, John Wiley and Sons, 2013
2. Kenneth E. Kendall and Julie E Kendall, Systems Analysis
and Design 8th Edition, Prentice Hall, 2010
3. Hassan Gomaa, Software Modeling and Design: UML,
Use Cases, Patterns, and Software Architectures,
Cambridge University Press, 2011
4. Gary B. Shelly and Harry J. Rosenblatt, Systems Analysis
and Design 9th Edition, Course Technology, 2011
5. Howard Podeswa, UML for the IT Business Analyst 2nd
Edition, Course Technology, 2009
6. Jeffrey A. Hoffer et al, Modern Systems Analysis and
Design 6th Edition, Prentice Hall, 2012
188