Rekayasa Perangkat Lunak (1). pdf
halaman : 1
Rekayasa Perangkat Lunak
BAB IV
PEMODELAN ANALISIS
Pada tingkat teknik, rekayasa perangkat lunak dimulai dengan serangkaian tugas pemodelan yang
membawa kepada suatu spesifikasi lengkap dari persyaratan representasi dan representasi desain yang
komprehensip bagi perangkat lunak yang dibangun.
4.1. Elemen Model Analisis
Model analisis harus dapat mencapai tiga sasaran utama yakni untuk :
•
•
•
Menggambarkan apa yang dibutuhkan untuk pelanggan
Membangun dasar bagi pembuatan desain perangkat lunak
Membatasi serangkaian persyaratan yang dapat divalidasi begitu perangkat lunak dibangun.
Brahmantyo- Pemodelan Analisis
halaman : 2
Rekayasa Perangkat Lunak
Untuk mencapai sasaran tersebut dibuatlah model analisis yang berisi:
•
Data Dictionary
Penyimpanan yang berisi deskripsi dari semua obyek data yang dikonsumsi atau diproduksi
•
•
oleh perangkat lunak.
Entity Relationship Diagram (ERD)
Menggambarkan hubungan antara obyek data.
Data Flow Diagram (DFD)
o Memberikan indikasi mengenai bagaiman data ditransformasi pada saat data bergerak
melalui sistem
•
•
o Menggambarkan fungsi-fungsi (dan sub fungsi) yang mentransformasikan aliran data.
State Transition Diagram
Menunjukkan bagaimana sistem bertingkah laku sebagai akibat dari kejadian eksternal.
Control Specification (CSPEC)
Informasi tambahan mengenai aspek kontrol dari perangkat lunak
4.2. Pemodelan Data
Untuk dapat menjawab sebagai berikut :
•
•
•
•
Bagaimana komposisi dari masing-masing obyek data dan atribut apa yang menggambarkab
obyek tersebut?
Dimana obyek saat ini berada?
Bagaimana hubungan antara masing-masing obyek data dan obyek lainnya?
Bagaimana hubungan antara obyek dengan proses yang mentransformasikannya?
Digunakan Entity Relational Diagram (ERD)
4.2.1. Obyek Data, Atribut dan Hubungan
•
Obyek Data
Adalah representasi dari hamper semua informasi gabungan yang harus dipahami oleh
perangkat lunak
Brahmantyo- Pemodelan Analisis
halaman : 3
Rekayasa Perangkat Lunak
•
Atribut
Menentukan property suatu obyek data dan mengambil salah satu dari tiga karakteristik yang
berbeda.
o Menamai sebuah contoh dari obyek data
o Menggambarkan contoh
•
o Membujat referensi ke contoh yang lain pada tabel yang lain.
Hubungan
Obyek data disambungkan satu dengan lainnya dengan berbagai macam cara.
4.2.2. Kardinalitas dan Modalitas
Kardinalitas
Model data harus dapat merepresentasikan jumlah peristiwa dari obyek di dalam hubungan yang
diberikan
o Satu ke satu (1:1)
Misalnya: seorang suami hanya dapat memiliki satu istri, dan seorang istri hanya mempunyai
satu suami.
o Satu ke banyak (1:N)
Misalnya: seorang ibu dapat memiliki banyak anak, tetapi seorang anak hanya dapat memiliki
satu ibu.
o Banyak ke banyak (M:N)
Misalnya: seorang paman dapat memiliki banyak keponakan, sementara itu seorang keponakan
dapat memiliki banyak paman.
Modalitas
Modalitas dari suatu hubungan adalah nol bila tidak ada kebutuhan eksplisit untuk hubungan yang
terjadi atau hubungan itu bersifat opsional. Modalitas bernilai satu jika suatu kejadian dari hubungan
merupakan perintah.
Brahmantyo- Pemodelan Analisis
halaman : 4
Rekayasa Perangkat Lunak
4.2.3. Entity Relational Diagram
Pada mulanya digunakan untuk desain sistem database relational dan telah dikembangkan oleh
yang lainnya. Serangkaian komponen utama diidentifikasikan untuk ERD: obyek data, atribut,
hubungan dan berbagai tipe indicator. Tujuan utama dari ERD adalah untuk mewakili obyek data dan
hubungan mereka.
4.3. Pemodelan Fungsional dan Aliran Informasi.
Informasi ditransformasikan pada saat dia mengalir melalui sebuah sistem berbasis komputer.
Sistem tersebut menerima input dengan berbagai cara dan menghasilkan suatu output. Akibatnya kita
dapat menciptakan suatu model aliran bagi setiap sistem berbasis komputer tanpa melihat ukuran dan
kompleksitasnya.
4.3.1. Diagram Aliran Data/ Data Flow Diagram (DFD)
Merupakan sebuah teknik grafis yang menggambarkan aliran informasi dan transformasi yang
diaplikasikan pada saat data bergerak dari input menjadi output.
Dikenal juga dengan sebutan grafik aliran data atau buble chart.
Brahmantyo- Pemodelan Analisis
halaman : 5
Rekayasa Perangkat Lunak
Komponen-komponen DFD :
o Proses
o External entity
o Data Flow
o Data Store
Proses
o Simbol proses adalah :
o
Proses menunjukkan apa yang dikerjakan oleh sistem
o
Setiap proses memiliki nama yang unik dan nomor yang ditempatkan dalam simbol.
File atau Data Store
o Simbol :
o File atau Data Store adalah tempat penyimpanan data
o Proses dapat menempatkan data ke dalam data store atau mengambil / mendapatkan data store
o Setiap data store mempunyai nama yang unik
External Entity
CUSTOMERS
Simbol :
External entity adalah di luar sistem, tetapi mereka merupakan salah satu bagian yang memberikan
input data ke dalam sistem atau digunakan oleh output sistem
Source : External entity yang memberikan input data ke dalam sistem
Sinks : External entity yang menggunakan data sistem
Data Flow
Simbol :
Ö
anak manah menunjukkan arah aliran
Aliran data pada sistem :
antara dua proses
Brahmantyo- Pemodelan Analisis
halaman : 6
Rekayasa Perangkat Lunak
dari sebuah data store ke sebuah proses
dari sebuah proses ke sebuah data store
dari sebuah source ke sebuah proses
dari sebuah proses ke sebuah sink
Menggambarkan Sistem Dengan Dataflow Diagram
Langkah awal adalah membuat “DIAGRAM KONTEKS”
Diagram konteks : DFD di mana sistem terdiri dari satu proses
Pada tahap ini terlihat semua external entity yang berinteraksi dengan sistem dan data flow, antara
external entity dan sistem
Contoh :
BUDGET ALLOCATION
DEPARTEMENTS
REQUEST
REJECTED
NG
DI T
S
EN
SP QUE
RE
REQUEST FOR
SPECIAL
APPROVAL
BUDGET
MONITORING
SYSTEM
MANAGEMENT
TO AL
E OV
S
N PR
PO AP
S
RE IAL
EC
SP
SPENDING
SUMMARIES
PART ORDER
DELIVERY ADVICE
SUPPLIER
DELIVERY ADVICE
SUPPLIER
Diagram Konteks
Budget monitoring system
System berinteraksi dengan 3 external entity, yaitu :
DEPARTEMENTS
MANAGEMENTS
SUPPLIERS
Aliran data utama dari Departements adalah “Spending Request”.
Sebagai tanggapan dari sistem, Departemen menerima “Rejected Request” atau aliran data
“Delivery Advice”
Management menerima data flow “Request For Special Approval”, yang kemudian
memberikan respons
Brahmantyo- Pemodelan Analisis
halaman : 7
Rekayasa Perangkat Lunak
Management juga mengirim data flow “Budget Allocation” ke sistem dan mendapatkan data
flow “Spending Summaries”
Supplier menerima data flow “Part Order” dan mengembalikan data flow “Supplier Delivery
Advice”
Setelah mendapatkan “Diagram Konteks”, langkah selanjutnya adalah membuat DFD yang
memperlihatkan proses dari sistem utama, yang dinamakan dengan TOP LEVEL DFD
2
SETUP
BUDGET
DEPARTEMENTS
BUDGET
ALLOCATION
NG
DI T
EN ES
SP QU
RE ED
CT T
JE ES
RE QU
RE
ALLOCATED
BUDGET
RE
1
CHECK
FUNDING
IAL
EC
P
S
OR AL
T FROV
S
E P
QU AP
4
PROVIDE
SPENDING
SUMMARIES
RESPONSE TO
SPECIAL APPROVAL
DEPARTEMENT
ACCOUNTS
D
VE
O ST
PR UE
AP EQ
R
SUSPENDED
REQUEST
SPENDING
SUMMARIES
MANAGEMENT
3
CLASSIFY
EXPENDITUR
TYPE
ACCOUNTS
R
ED
D T
R
O ES
EC QU
E
R
DELIVERY ADVICE
PART ORDER
SUPPLIERS
5
ORGANIZE
SUPPLIER
SUPPLIER DELIVERY ADVICE
Top Level DFD dari Diagram Konteks
Top level DFD memperlihatkan berbagai proses yang membentuk sistem
Setiap proses mempunyai sebuah nama unik dan nomor proses
Dari DFD di atas kita lihat bahwa data flow “Spending Request” dari Departements menuju ke
proses “Check Funding”. Proses “Check Funding” melihat “Allocated Budget” dan
menetapkan apakah izin khusus diperlukan dari management untuk diteruskan ke permintaan.
Data flow “Approved Request” menuju ke proses “Classify Expenditure”, dan kemudian
dimasukkan pada data store “Departemental-Accounts” dan “Type-Accounts”.
Brahmantyo- Pemodelan Analisis
halaman : 8
Rekayasa Perangkat Lunak
Akhirnya, jika diperlukan, “Part Order” untuk menetapkan bagian ( part ) semula dalam
“Spending Request” diurus oleh supplier.
Dua proses lainnya : “Setup Budget” dan “Provide Spending Summaries”
Kita dapat memperluas setiap proses pada Top Level DFD. Sebagai contoh diambil proses “Classify
Expenditure”
AP
PR
OV
RE
ED
QU
ES
T
3.1
CLASSIFY
EXPENSE
BY TYPE
TYPE
ACCOUNTS
CL
AS
RE SIFIE
QU
D
ES
T
3.2
UPDATE
TYPE
ACCOUNT
TE
DA
T
UP
ES
QU
E
R
DEPARTEMENTAL
ACCOUNTS
ED
RD T
O
C
S
RE QUE
RE
3.4
UPDATE
DEPARTEMENTAL
RECORD
3.3
SUM
TOTAL
T
ES
QU
RE TAL
TO
Brahmantyo- Pemodelan Analisis
halaman : 9
Rekayasa Perangkat Lunak
D
VE
O ST
PR UE
AP EQ
R
= Dept_no + Request_no +
(Amount + Descrip.)
3.1
CLASSIFY
EXPENSE
BY TYPE
= Dept_no +
Request_no +
(Amount + Type)
D
IE
IF T
SS ES
U
LA
C EQ
R
Amend the expense docket
reading the description for
each request item and
classifying it by type
For each request item irv request docket
* get ACCOUNT for TYPE from store TYPE_ACCOUNTS
* sum TOTAL_AMOUNT = TOTAL_AMOUNT + AMOUNT
* write TYPE_ACOUNT back to store TYPE_ACOUNTS
3.2
UPDATE
TYPE
ACCOUNT
KETERANGAN
TYPE ACCOUNTS
= Type + Total - Amount
U
R PD
EQ A
U TE
ES
T
DESKIPSI DATA STORE
DESKRIPSI PROSES
DESKRIPSI DATA FLOW
= DEPT_NO request
+ REQUEST_NO +
(AMOUNT)
3.3
SUM
TOTAL
For each requesition
REQUEST_SUM = REQUEST_SUM + AMOUNT
= DEPT_NO + TOTAL_EXP
R
EQ
TO UE
TA ST
L
DEPARTEMENTAL ACCOUNTS
R
R
EC
EQ OR
U DE
ES D
T
3.4
UPDATE
DEPARTEMENTAL
RECORD
= DEPT_NO + REQUEST_NO
+ REQUEST_SUM
Get departement accounts for DEPT_NO from data
store DEPARTEMENTAL-ACCOUNTS
TOTAL_EXP = TOTAL_EXP + REQUEST_TOTAL
write departemental accounts back to data store
= DEPT_NO + REQUEST_NO
+ REQUEST_SUM
Data Flow Diagram yang baik :
Ketiadaan dari struktur flowchart
Penyimpanan data
Penamaan yang baik
Perbedaan antara Flowchart dan Data Flow Diagram :
Flowchart terdiri dari box-box yang mendeskripsikan :
Komputasi
Decision / Keputusan
Iterasi
Loop
Brahmantyo- Pemodelan Analisis
halaman : 10
Rekayasa Perangkat Lunak
Data Flow Diagram bukan Flowchart program dan tidak mempunyai elemen kontrol
DFD yang baik harus :
Tidak mempunyai aliran data yang split up ke dalam sejumlah aliran data lain
PROFIT
SALES
DATA
COMPUTE
INCOME
LOSS
Tidak mempunyai garis yang berpotongan
Tidak terdapat iterasi antara 2 proses ; 1 proses dengan dirinya sendiri
SALES
GET NEXT
DOCKET
DOCKET
ADD TO DAILY
SALES
TOTAL SALES
AMOUNT
ASK FOR
MORE
Tidak mengandung aliran data yang berfungsi sebagai signal untuk mengaktifkan suatu proses
END OF MONTH
PREPARE
MONTHLY
INVOICE
TRANSACTIONS
INVOICE
Brahmantyo- Pemodelan Analisis
halaman : 11
Rekayasa Perangkat Lunak
Bagaimana membuat : Decisions dan Interactive Control
Decisions dalan DFD
INVENTORY-RECORD = ITEM_NO + QTY_HELD
UNMET-REQUEST = REQ_NO + ITEM_NO + QTY_NEEDED
CHECK
ITEM
AVAILABILITY
UNVAILABLE NOTE
DELIVERY NOTE
EM
IT
ST
UE
Q
RE
= REQ_NO + ITEM_NO + QTY_NEEDED
find INVENTORY_RECORD with ITEM_NO in
INVENTORY_RECORD = ITEM_NO in ITEM-REQUEST
if QTY_HELD in INVENTORY_RECORD < QTY_NEEDED in
ITEM-REQUEST then write UNMET_REQUEST send
UNAVAILABLE NOTE else send DELIVERY NOTE
Perulangan dalam DFD
SALES DOCKET
COMPUTE
DAILY
SALES
= ITEM_NO +
QTY_SOLD + PRICE
TOTAL SALES
= DAILY_SALES_TOTAL
REPEAT FOR ALL SALESDOCKET
BEGIN
SALES_AMOUNT = QTY_SOLD * PRICE
DAILY_SALES_TOTAL = DAILY_SALES_TOTAL + SALES_AMOUNT
END
SEND 'TOTAL SALES'
Penyimpanan Data
Data store tidak boleh membuat “elemen data” baru
Proses juga tidak dapat membuat data baru ; hanya mengambil data dan mengeluarkannya ke
dalam sebuah bentuk data baru
Beberapa contoh kesalahan penggunaan prinsip penyimpanan data :
Brahmantyo- Pemodelan Analisis
halaman : 12
Rekayasa Perangkat Lunak
1.
PU
RC
H
= ITEM_NAME + QTY
AS
ED
_IT
E
PRICE_LIST
M
RETRIEVE
ITEM
PRICE
RE
= ITEM_NAME + ITEM_PRICE
TR
IEV
E_
ITE
M
COMPUTE
DISCOUNT
CUSTOMERS
Item data QTY hilang setelah melalui proses “Retrieve-Item Price”
2.
AVERAGE DISK
TRANSFER TIME
DISK ACCESS
SPECIFICATION
COMPUTE
DISK
UTILIZATION
CHANNEL USE
PER DAY
“Channel Use Per Day” Ö output
Tetapi tidak ada informasi masukkan tentang jumlah disk yang masuk setiap hari
3.
memerlukan data
KERJA /
OPERASI
DEPARTEMEN
informasi
Gunakanlah nama-nama yang berarti,
baik untuk data flow, maupun proses.
Pada contoh tersebut penamaan untuk
data flow dan proses tidak jelas.
Beberapa petunjuk dalam pemakaian nama ( penamaan )
1. Penamaan “Proses”
Nama proses harus frase tunggal dan dapat mendeskripsikan suatu proses dalam sebuah kalimat
Nama proses harus mendefinisikan kegiatan / aksi yang spesifik
Contoh :
Mengedit
Menghitung gaji mingguan
Brahmantyo- Pemodelan Analisis
Rekayasa Perangkat Lunak
Menghitung diskon pada pesanan
halaman : 13
dan lain-lain
Jika suatu proses menangani beberapa proses, maka harus dipecah menjadi beberapa proses
2. Penamaan Data Store
Gunakan nama yang khas / spesifik
Ingat bahwa setiap data store hanya berisi satu set struktur data
Contoh
Machine_Schedules and Parts_Used
Æ
pisahkan ke dalam 2 data store
3. Penamaan Data Flows antara Proses
Gunakan 1 kata / frase. Contoh : “Kuitansi” , “Cek” , dan sebagainya
Jangan menggunakan nama yang sama untuk setiap data flow
Lihat gambar :
Pada ( a ) data flow “Invoice” yang masuk ke “Edit Invoice” , keluar “Invoice” Ö Jangan
pakai nama yang sama.
Output dari “Make Payment” adalah “Cheque”. “Cheque” juga dipakai untuk data flow
yang menghubungkan external entity “Customer” dan proses “Receive Payment”. Bedakan
nama kedua data flow tersebut !!!!
DFD ( b ) memperbaiki beberapa kesalahan pada DFD ( a )
Brahmantyo- Pemodelan Analisis
halaman : 14
Rekayasa Perangkat Lunak
SUPPLIER
CHEQUE
MAKE
RECEIVE
PAYMENT
PAYMENT
ER
_N
O
UN AM
E
T
+
APPROVED
ACCOUNT
INVOICES
= ACCOUNT_NO + AMOUNT
+ SUPPLIER_NAME
APP
RO
V
E
IC
VO
IN
VERIFY
ED
IN
VO
CUSTOMER
ACCOUNT_NO +
PL
I
AM
AMOUNT
INVOICE
SUPPLIER +
AMOUNT
INVOICE
EDIT
SU
P
CHEQUE
ICE
INVOICE
APPROVE
INVOICE
PAYMENT
gambar ( a )
Æ
SUPPLIER
SUPPLIER
MAKE
RECEIVE
CUSTOMER
CHEQUE
PAYMENT
PAYMENT
CHEQUE
ER
_N
O
UN AM
E
T
+
ACCOUNT_NO +
PL
I
AM
AMOUNT
SUPPLIER +
AMOUNT
INVOICE
EDIT
INVOICE
SU
P
APPROVED
ACCOUNT
INVOICES
= ACCOUNT_NO + AMOUNT
+ SUPPLIER_NAME
ED
APP
RO
V
ED
IT
ED
IN
VO
CUSTOMER
IN
ICE
E
IC
VO
VERIFY
VERIFIED
APPROVE
INVOICE
INVOICE
PAYMENT
gambar ( b )
Pembuatan Aliran Material
DFD digunakan untuk aliran informasi, bukan aliran material. Tetapi kadang-kadang aliran material
diperlukan. Caranya ????
Brahmantyo- Pemodelan Analisis
halaman : 15
Rekayasa Perangkat Lunak
MEMPERSIAPKAN
CATATAN PENGIRIMAN
PENGIRIMAN
TOKO
MENCATAT
PENGIRIMAN
TEMPAT
RUANG MESIN
ALIRAN FISIKAL
LOKASI FISIKAL
DARI AKTIFITAS
Brahmantyo- Pemodelan Analisis
Rekayasa Perangkat Lunak
BAB IV
PEMODELAN ANALISIS
Pada tingkat teknik, rekayasa perangkat lunak dimulai dengan serangkaian tugas pemodelan yang
membawa kepada suatu spesifikasi lengkap dari persyaratan representasi dan representasi desain yang
komprehensip bagi perangkat lunak yang dibangun.
4.1. Elemen Model Analisis
Model analisis harus dapat mencapai tiga sasaran utama yakni untuk :
•
•
•
Menggambarkan apa yang dibutuhkan untuk pelanggan
Membangun dasar bagi pembuatan desain perangkat lunak
Membatasi serangkaian persyaratan yang dapat divalidasi begitu perangkat lunak dibangun.
Brahmantyo- Pemodelan Analisis
halaman : 2
Rekayasa Perangkat Lunak
Untuk mencapai sasaran tersebut dibuatlah model analisis yang berisi:
•
Data Dictionary
Penyimpanan yang berisi deskripsi dari semua obyek data yang dikonsumsi atau diproduksi
•
•
oleh perangkat lunak.
Entity Relationship Diagram (ERD)
Menggambarkan hubungan antara obyek data.
Data Flow Diagram (DFD)
o Memberikan indikasi mengenai bagaiman data ditransformasi pada saat data bergerak
melalui sistem
•
•
o Menggambarkan fungsi-fungsi (dan sub fungsi) yang mentransformasikan aliran data.
State Transition Diagram
Menunjukkan bagaimana sistem bertingkah laku sebagai akibat dari kejadian eksternal.
Control Specification (CSPEC)
Informasi tambahan mengenai aspek kontrol dari perangkat lunak
4.2. Pemodelan Data
Untuk dapat menjawab sebagai berikut :
•
•
•
•
Bagaimana komposisi dari masing-masing obyek data dan atribut apa yang menggambarkab
obyek tersebut?
Dimana obyek saat ini berada?
Bagaimana hubungan antara masing-masing obyek data dan obyek lainnya?
Bagaimana hubungan antara obyek dengan proses yang mentransformasikannya?
Digunakan Entity Relational Diagram (ERD)
4.2.1. Obyek Data, Atribut dan Hubungan
•
Obyek Data
Adalah representasi dari hamper semua informasi gabungan yang harus dipahami oleh
perangkat lunak
Brahmantyo- Pemodelan Analisis
halaman : 3
Rekayasa Perangkat Lunak
•
Atribut
Menentukan property suatu obyek data dan mengambil salah satu dari tiga karakteristik yang
berbeda.
o Menamai sebuah contoh dari obyek data
o Menggambarkan contoh
•
o Membujat referensi ke contoh yang lain pada tabel yang lain.
Hubungan
Obyek data disambungkan satu dengan lainnya dengan berbagai macam cara.
4.2.2. Kardinalitas dan Modalitas
Kardinalitas
Model data harus dapat merepresentasikan jumlah peristiwa dari obyek di dalam hubungan yang
diberikan
o Satu ke satu (1:1)
Misalnya: seorang suami hanya dapat memiliki satu istri, dan seorang istri hanya mempunyai
satu suami.
o Satu ke banyak (1:N)
Misalnya: seorang ibu dapat memiliki banyak anak, tetapi seorang anak hanya dapat memiliki
satu ibu.
o Banyak ke banyak (M:N)
Misalnya: seorang paman dapat memiliki banyak keponakan, sementara itu seorang keponakan
dapat memiliki banyak paman.
Modalitas
Modalitas dari suatu hubungan adalah nol bila tidak ada kebutuhan eksplisit untuk hubungan yang
terjadi atau hubungan itu bersifat opsional. Modalitas bernilai satu jika suatu kejadian dari hubungan
merupakan perintah.
Brahmantyo- Pemodelan Analisis
halaman : 4
Rekayasa Perangkat Lunak
4.2.3. Entity Relational Diagram
Pada mulanya digunakan untuk desain sistem database relational dan telah dikembangkan oleh
yang lainnya. Serangkaian komponen utama diidentifikasikan untuk ERD: obyek data, atribut,
hubungan dan berbagai tipe indicator. Tujuan utama dari ERD adalah untuk mewakili obyek data dan
hubungan mereka.
4.3. Pemodelan Fungsional dan Aliran Informasi.
Informasi ditransformasikan pada saat dia mengalir melalui sebuah sistem berbasis komputer.
Sistem tersebut menerima input dengan berbagai cara dan menghasilkan suatu output. Akibatnya kita
dapat menciptakan suatu model aliran bagi setiap sistem berbasis komputer tanpa melihat ukuran dan
kompleksitasnya.
4.3.1. Diagram Aliran Data/ Data Flow Diagram (DFD)
Merupakan sebuah teknik grafis yang menggambarkan aliran informasi dan transformasi yang
diaplikasikan pada saat data bergerak dari input menjadi output.
Dikenal juga dengan sebutan grafik aliran data atau buble chart.
Brahmantyo- Pemodelan Analisis
halaman : 5
Rekayasa Perangkat Lunak
Komponen-komponen DFD :
o Proses
o External entity
o Data Flow
o Data Store
Proses
o Simbol proses adalah :
o
Proses menunjukkan apa yang dikerjakan oleh sistem
o
Setiap proses memiliki nama yang unik dan nomor yang ditempatkan dalam simbol.
File atau Data Store
o Simbol :
o File atau Data Store adalah tempat penyimpanan data
o Proses dapat menempatkan data ke dalam data store atau mengambil / mendapatkan data store
o Setiap data store mempunyai nama yang unik
External Entity
CUSTOMERS
Simbol :
External entity adalah di luar sistem, tetapi mereka merupakan salah satu bagian yang memberikan
input data ke dalam sistem atau digunakan oleh output sistem
Source : External entity yang memberikan input data ke dalam sistem
Sinks : External entity yang menggunakan data sistem
Data Flow
Simbol :
Ö
anak manah menunjukkan arah aliran
Aliran data pada sistem :
antara dua proses
Brahmantyo- Pemodelan Analisis
halaman : 6
Rekayasa Perangkat Lunak
dari sebuah data store ke sebuah proses
dari sebuah proses ke sebuah data store
dari sebuah source ke sebuah proses
dari sebuah proses ke sebuah sink
Menggambarkan Sistem Dengan Dataflow Diagram
Langkah awal adalah membuat “DIAGRAM KONTEKS”
Diagram konteks : DFD di mana sistem terdiri dari satu proses
Pada tahap ini terlihat semua external entity yang berinteraksi dengan sistem dan data flow, antara
external entity dan sistem
Contoh :
BUDGET ALLOCATION
DEPARTEMENTS
REQUEST
REJECTED
NG
DI T
S
EN
SP QUE
RE
REQUEST FOR
SPECIAL
APPROVAL
BUDGET
MONITORING
SYSTEM
MANAGEMENT
TO AL
E OV
S
N PR
PO AP
S
RE IAL
EC
SP
SPENDING
SUMMARIES
PART ORDER
DELIVERY ADVICE
SUPPLIER
DELIVERY ADVICE
SUPPLIER
Diagram Konteks
Budget monitoring system
System berinteraksi dengan 3 external entity, yaitu :
DEPARTEMENTS
MANAGEMENTS
SUPPLIERS
Aliran data utama dari Departements adalah “Spending Request”.
Sebagai tanggapan dari sistem, Departemen menerima “Rejected Request” atau aliran data
“Delivery Advice”
Management menerima data flow “Request For Special Approval”, yang kemudian
memberikan respons
Brahmantyo- Pemodelan Analisis
halaman : 7
Rekayasa Perangkat Lunak
Management juga mengirim data flow “Budget Allocation” ke sistem dan mendapatkan data
flow “Spending Summaries”
Supplier menerima data flow “Part Order” dan mengembalikan data flow “Supplier Delivery
Advice”
Setelah mendapatkan “Diagram Konteks”, langkah selanjutnya adalah membuat DFD yang
memperlihatkan proses dari sistem utama, yang dinamakan dengan TOP LEVEL DFD
2
SETUP
BUDGET
DEPARTEMENTS
BUDGET
ALLOCATION
NG
DI T
EN ES
SP QU
RE ED
CT T
JE ES
RE QU
RE
ALLOCATED
BUDGET
RE
1
CHECK
FUNDING
IAL
EC
P
S
OR AL
T FROV
S
E P
QU AP
4
PROVIDE
SPENDING
SUMMARIES
RESPONSE TO
SPECIAL APPROVAL
DEPARTEMENT
ACCOUNTS
D
VE
O ST
PR UE
AP EQ
R
SUSPENDED
REQUEST
SPENDING
SUMMARIES
MANAGEMENT
3
CLASSIFY
EXPENDITUR
TYPE
ACCOUNTS
R
ED
D T
R
O ES
EC QU
E
R
DELIVERY ADVICE
PART ORDER
SUPPLIERS
5
ORGANIZE
SUPPLIER
SUPPLIER DELIVERY ADVICE
Top Level DFD dari Diagram Konteks
Top level DFD memperlihatkan berbagai proses yang membentuk sistem
Setiap proses mempunyai sebuah nama unik dan nomor proses
Dari DFD di atas kita lihat bahwa data flow “Spending Request” dari Departements menuju ke
proses “Check Funding”. Proses “Check Funding” melihat “Allocated Budget” dan
menetapkan apakah izin khusus diperlukan dari management untuk diteruskan ke permintaan.
Data flow “Approved Request” menuju ke proses “Classify Expenditure”, dan kemudian
dimasukkan pada data store “Departemental-Accounts” dan “Type-Accounts”.
Brahmantyo- Pemodelan Analisis
halaman : 8
Rekayasa Perangkat Lunak
Akhirnya, jika diperlukan, “Part Order” untuk menetapkan bagian ( part ) semula dalam
“Spending Request” diurus oleh supplier.
Dua proses lainnya : “Setup Budget” dan “Provide Spending Summaries”
Kita dapat memperluas setiap proses pada Top Level DFD. Sebagai contoh diambil proses “Classify
Expenditure”
AP
PR
OV
RE
ED
QU
ES
T
3.1
CLASSIFY
EXPENSE
BY TYPE
TYPE
ACCOUNTS
CL
AS
RE SIFIE
QU
D
ES
T
3.2
UPDATE
TYPE
ACCOUNT
TE
DA
T
UP
ES
QU
E
R
DEPARTEMENTAL
ACCOUNTS
ED
RD T
O
C
S
RE QUE
RE
3.4
UPDATE
DEPARTEMENTAL
RECORD
3.3
SUM
TOTAL
T
ES
QU
RE TAL
TO
Brahmantyo- Pemodelan Analisis
halaman : 9
Rekayasa Perangkat Lunak
D
VE
O ST
PR UE
AP EQ
R
= Dept_no + Request_no +
(Amount + Descrip.)
3.1
CLASSIFY
EXPENSE
BY TYPE
= Dept_no +
Request_no +
(Amount + Type)
D
IE
IF T
SS ES
U
LA
C EQ
R
Amend the expense docket
reading the description for
each request item and
classifying it by type
For each request item irv request docket
* get ACCOUNT for TYPE from store TYPE_ACCOUNTS
* sum TOTAL_AMOUNT = TOTAL_AMOUNT + AMOUNT
* write TYPE_ACOUNT back to store TYPE_ACOUNTS
3.2
UPDATE
TYPE
ACCOUNT
KETERANGAN
TYPE ACCOUNTS
= Type + Total - Amount
U
R PD
EQ A
U TE
ES
T
DESKIPSI DATA STORE
DESKRIPSI PROSES
DESKRIPSI DATA FLOW
= DEPT_NO request
+ REQUEST_NO +
(AMOUNT)
3.3
SUM
TOTAL
For each requesition
REQUEST_SUM = REQUEST_SUM + AMOUNT
= DEPT_NO + TOTAL_EXP
R
EQ
TO UE
TA ST
L
DEPARTEMENTAL ACCOUNTS
R
R
EC
EQ OR
U DE
ES D
T
3.4
UPDATE
DEPARTEMENTAL
RECORD
= DEPT_NO + REQUEST_NO
+ REQUEST_SUM
Get departement accounts for DEPT_NO from data
store DEPARTEMENTAL-ACCOUNTS
TOTAL_EXP = TOTAL_EXP + REQUEST_TOTAL
write departemental accounts back to data store
= DEPT_NO + REQUEST_NO
+ REQUEST_SUM
Data Flow Diagram yang baik :
Ketiadaan dari struktur flowchart
Penyimpanan data
Penamaan yang baik
Perbedaan antara Flowchart dan Data Flow Diagram :
Flowchart terdiri dari box-box yang mendeskripsikan :
Komputasi
Decision / Keputusan
Iterasi
Loop
Brahmantyo- Pemodelan Analisis
halaman : 10
Rekayasa Perangkat Lunak
Data Flow Diagram bukan Flowchart program dan tidak mempunyai elemen kontrol
DFD yang baik harus :
Tidak mempunyai aliran data yang split up ke dalam sejumlah aliran data lain
PROFIT
SALES
DATA
COMPUTE
INCOME
LOSS
Tidak mempunyai garis yang berpotongan
Tidak terdapat iterasi antara 2 proses ; 1 proses dengan dirinya sendiri
SALES
GET NEXT
DOCKET
DOCKET
ADD TO DAILY
SALES
TOTAL SALES
AMOUNT
ASK FOR
MORE
Tidak mengandung aliran data yang berfungsi sebagai signal untuk mengaktifkan suatu proses
END OF MONTH
PREPARE
MONTHLY
INVOICE
TRANSACTIONS
INVOICE
Brahmantyo- Pemodelan Analisis
halaman : 11
Rekayasa Perangkat Lunak
Bagaimana membuat : Decisions dan Interactive Control
Decisions dalan DFD
INVENTORY-RECORD = ITEM_NO + QTY_HELD
UNMET-REQUEST = REQ_NO + ITEM_NO + QTY_NEEDED
CHECK
ITEM
AVAILABILITY
UNVAILABLE NOTE
DELIVERY NOTE
EM
IT
ST
UE
Q
RE
= REQ_NO + ITEM_NO + QTY_NEEDED
find INVENTORY_RECORD with ITEM_NO in
INVENTORY_RECORD = ITEM_NO in ITEM-REQUEST
if QTY_HELD in INVENTORY_RECORD < QTY_NEEDED in
ITEM-REQUEST then write UNMET_REQUEST send
UNAVAILABLE NOTE else send DELIVERY NOTE
Perulangan dalam DFD
SALES DOCKET
COMPUTE
DAILY
SALES
= ITEM_NO +
QTY_SOLD + PRICE
TOTAL SALES
= DAILY_SALES_TOTAL
REPEAT FOR ALL SALESDOCKET
BEGIN
SALES_AMOUNT = QTY_SOLD * PRICE
DAILY_SALES_TOTAL = DAILY_SALES_TOTAL + SALES_AMOUNT
END
SEND 'TOTAL SALES'
Penyimpanan Data
Data store tidak boleh membuat “elemen data” baru
Proses juga tidak dapat membuat data baru ; hanya mengambil data dan mengeluarkannya ke
dalam sebuah bentuk data baru
Beberapa contoh kesalahan penggunaan prinsip penyimpanan data :
Brahmantyo- Pemodelan Analisis
halaman : 12
Rekayasa Perangkat Lunak
1.
PU
RC
H
= ITEM_NAME + QTY
AS
ED
_IT
E
PRICE_LIST
M
RETRIEVE
ITEM
PRICE
RE
= ITEM_NAME + ITEM_PRICE
TR
IEV
E_
ITE
M
COMPUTE
DISCOUNT
CUSTOMERS
Item data QTY hilang setelah melalui proses “Retrieve-Item Price”
2.
AVERAGE DISK
TRANSFER TIME
DISK ACCESS
SPECIFICATION
COMPUTE
DISK
UTILIZATION
CHANNEL USE
PER DAY
“Channel Use Per Day” Ö output
Tetapi tidak ada informasi masukkan tentang jumlah disk yang masuk setiap hari
3.
memerlukan data
KERJA /
OPERASI
DEPARTEMEN
informasi
Gunakanlah nama-nama yang berarti,
baik untuk data flow, maupun proses.
Pada contoh tersebut penamaan untuk
data flow dan proses tidak jelas.
Beberapa petunjuk dalam pemakaian nama ( penamaan )
1. Penamaan “Proses”
Nama proses harus frase tunggal dan dapat mendeskripsikan suatu proses dalam sebuah kalimat
Nama proses harus mendefinisikan kegiatan / aksi yang spesifik
Contoh :
Mengedit
Menghitung gaji mingguan
Brahmantyo- Pemodelan Analisis
Rekayasa Perangkat Lunak
Menghitung diskon pada pesanan
halaman : 13
dan lain-lain
Jika suatu proses menangani beberapa proses, maka harus dipecah menjadi beberapa proses
2. Penamaan Data Store
Gunakan nama yang khas / spesifik
Ingat bahwa setiap data store hanya berisi satu set struktur data
Contoh
Machine_Schedules and Parts_Used
Æ
pisahkan ke dalam 2 data store
3. Penamaan Data Flows antara Proses
Gunakan 1 kata / frase. Contoh : “Kuitansi” , “Cek” , dan sebagainya
Jangan menggunakan nama yang sama untuk setiap data flow
Lihat gambar :
Pada ( a ) data flow “Invoice” yang masuk ke “Edit Invoice” , keluar “Invoice” Ö Jangan
pakai nama yang sama.
Output dari “Make Payment” adalah “Cheque”. “Cheque” juga dipakai untuk data flow
yang menghubungkan external entity “Customer” dan proses “Receive Payment”. Bedakan
nama kedua data flow tersebut !!!!
DFD ( b ) memperbaiki beberapa kesalahan pada DFD ( a )
Brahmantyo- Pemodelan Analisis
halaman : 14
Rekayasa Perangkat Lunak
SUPPLIER
CHEQUE
MAKE
RECEIVE
PAYMENT
PAYMENT
ER
_N
O
UN AM
E
T
+
APPROVED
ACCOUNT
INVOICES
= ACCOUNT_NO + AMOUNT
+ SUPPLIER_NAME
APP
RO
V
E
IC
VO
IN
VERIFY
ED
IN
VO
CUSTOMER
ACCOUNT_NO +
PL
I
AM
AMOUNT
INVOICE
SUPPLIER +
AMOUNT
INVOICE
EDIT
SU
P
CHEQUE
ICE
INVOICE
APPROVE
INVOICE
PAYMENT
gambar ( a )
Æ
SUPPLIER
SUPPLIER
MAKE
RECEIVE
CUSTOMER
CHEQUE
PAYMENT
PAYMENT
CHEQUE
ER
_N
O
UN AM
E
T
+
ACCOUNT_NO +
PL
I
AM
AMOUNT
SUPPLIER +
AMOUNT
INVOICE
EDIT
INVOICE
SU
P
APPROVED
ACCOUNT
INVOICES
= ACCOUNT_NO + AMOUNT
+ SUPPLIER_NAME
ED
APP
RO
V
ED
IT
ED
IN
VO
CUSTOMER
IN
ICE
E
IC
VO
VERIFY
VERIFIED
APPROVE
INVOICE
INVOICE
PAYMENT
gambar ( b )
Pembuatan Aliran Material
DFD digunakan untuk aliran informasi, bukan aliran material. Tetapi kadang-kadang aliran material
diperlukan. Caranya ????
Brahmantyo- Pemodelan Analisis
halaman : 15
Rekayasa Perangkat Lunak
MEMPERSIAPKAN
CATATAN PENGIRIMAN
PENGIRIMAN
TOKO
MENCATAT
PENGIRIMAN
TEMPAT
RUANG MESIN
ALIRAN FISIKAL
LOKASI FISIKAL
DARI AKTIFITAS
Brahmantyo- Pemodelan Analisis