REKAYASA PERANGKAT LUNAK
Dr. Ratna Wardani
Prodi PTI Fakultas Teknik
Universitas Negeri Yogyakarta
Pendidikan dan
Latihan Profesi
Guru
Materi
1
• Tentang Kurikulum
2
• Rekayasa Perangkat
Lunak
3
• Tools Pengembangan
TENTANG KURIKULUM
IEEE Computing Curricula 2005
•
Pembagian Domain Keilmuan
•
Rekayasa Perangkat Lunak
•
Kata Kunci
•
Level SMK di bidang RPL
•
Pemahaman yang salah tentang RPL
•
Apa yang Dipelajari dalam RPL
•
Kendala
•
REKAYASA PERANGKAT LUNAK
Tahapan Proses RPL
• Tahap umum:
– Definisi: Apa yang akan dibangun
• Analisis sistem
• Perencanaan Proyek
• Analisis Kebutuhan
– Pengembangan: Bagaimana membangunnya
• Desain perangkat lunak
• Pemrograman / Coding
• Pengujian perangkat lunak
– Pemeliharaan: Bagaimana berdaptasi terhadap
perubahan
• Koreksi
• Adaptasi
• Peningatan
Analisis Sistem
Analisis Sistem
• Elemen:
Analisis Sistem



Data Dictionary : deskripsi semua objek data dalam
S/W
Entity Relationship Diagram : notasi pemodelan data
yang menggambarkan hubungan antar objek data
Data Flow Diagram : model fungsional, dengan
tujuan



menunjukkan transformasi data saat data bergerak melalui
sistem
menunjukkan fungsi-fungsi yg mentransformasi aliran data
State Transition Diagram : model tingkah laku, yg
menunjukkan transisi state/tingkah laku sistem akibat
kejadian eksternal
Analisis Sistem
Pemodelan Data
• ERD memungkinkan perekayasa S/W mengidentifikasi objek
data dan hubungannya menggunakan notasi grafis (data yg
dimasukkan, disimpan, ditransformasi dan dihasilkan suatu
aplikasi)
• ERD hanya berfokus pada data dan bersifat independen thd
proses yg mentransformasikan data tersebut
• Model data terdiri dari tiga informasi utama :
– Objek data
– Atribut
– Hubungan
Objek Data
• Objek data adalah representasi dari hampir semua
informasi gabungan yg harus dipahami perangkat lunak
• Objek data dapat berupa entitas eksternal, benda, event,
unit organisasional, tempat atau suatu struktur
• Deskripsi objek data menghubungkan objek data dg
semua atributnya
• Objek data dihubungkan satu sama lain berdasarkan
konteks masalah yg dianalisis
• Objek data hanya mengenkapsulasi data, tidak ada
referensi pd sebuah objek data ke operasi yg bekerja pada
data
Atribut
• Atribut menentukan properti suatu objek data
• Atribut digunakan untuk
 menamai sebuah contoh dari objek data
 Menggambarkan contoh
 Membuat referensi ke contoh lain pada tabel yang lain
• Contoh : objek data manusia, memiliki atribut : nama,
alamat, umur, tinggi badan.
• Rangkaian atribut yang sesuai untuk suatu objek data
ditentukan melalui pemahaman konteks masalah
Hubungan
• Objek data dihubungkan satu dan lainnya dengan berbagai
cara
• Contoh : Antara dua objek data buku dan toko buku dapat
dibangun suatu hubungan berdasarkan konteks perangkat
lunak yg akan dibangun (dg object-relationship pairs) :
–
–
–
–
toko buku memesan buku
toko buku menampilkan buku
toko buku menjual buku
toko buku mengembalikan buku
Kardinalitas
• Kardinalitas merupakan spesifikasi dari sejumlah peristiwa
dari satu objek yg dapat dihubungkan ke sejumlah
peristiwa dari objek lain
• Dua objek dapat dihubungkan sebagai :
– Satu-ke-satu : suatu kejadian dari objek A dapat berhubungan dg
satu dan hanya satu kejadian dari objek B dan sebaliknya
– Satu-ke-banyak : satu kejadian dari objek A dapat berhubungan dg
satu atau lebih kejadian dari objek B, tetapi satu kejadian dari
objek B dapat berhubungan dg hanya satu kejadian dari objek B
– Banyak-ke-banyak : sebuah kejadian dari objek A dapat
berhubungan dg satu atau lebih kejadian dari objek B, dan satu
kejadian dari objek B dapat berhubungan dg satu atau lebih
kejadian dari objek A
Pemodelan Fungsional dan Aliran Informasi
• DFD merupakan teknik grafis yang menggambarkan aliran
informasi dan transformasi yang diaplikasikan pada saat data
bergerak dari input menjadi output.
• DFD memberikan suatu mekanisme bagi pemodelan
fungsional dan pemodelan aliran data
• DFD dapat menyajikan perangkat lunak pada setiap tingkat
abstraksi, karena DFD dapat dipartisi ke dalam tingkattingkat yang merepresentasikan aliran informasi yang
bertambah dan fungsi ideal.
Pemodelan Fungsional dan Aliran Informasi
(Analisis Terstruktur)
Aplikasi Cash Register:
Data yang menjadi masukan PL
3
1
2
6
Pelangga
n
1. Menyerahkan barang
2.
3.
4.
5.
6.
Mencatat data penjualan
Memberikan pembayaran
Mencatat data pembayaran
Mencetak struk
Menerima struk, barang, dan
kembalian
4
5
C as h R e g is te r
Kasir
Data yang menjadi
keluaran PL
sumber/tujuan data
(entitas eksternal)
lingkup/konteks
perangkat lunak
Pemodelan Fungsional dan Aliran Informasi
(Analisis Terstruktur)
penjualan
pembayaran
Kasir
struk
Aplikasi Cash
Register
Pemodelan Tingkah Laku
• STD merepresentasikan tingkah laku sistem dengan
menggambarkan keadaan dan kejadian yang menyebabkan
sistem mengubah keadaan
• Dalam STD, suatu aksi diambil sebagai akibat dari suatu
kejadian khusus
Pemodelan Tingkah Laku
e1 [nil]
S1
e2 [t_process ≤ t_user]
e3 [t_process > t_user]
Pre(Initial())
Get(“eMule-installer.exe”, “http://
sourceforge.net”, t_user <= 10 )
Post(S2 Ú S3)
S3
S2
Pre(S1 Ú S3)
NormalDL(“eMule-installer.exe”,
“http://sourceforge.net”, t_user
<= 10 )
Post(S4)
e4 [t_process ≤ t_user]
Pre(S1)
Retry(“eMule-installer.exe”,
“http://sourceforge.net”, t_user
<= 10 )
Post(S2 Ú S5)
e5 [true]
e6 [t_process > t_user]
S4
Pre(S2)
SaveTo(“eMule-installer.exe”,
“http://sourceforge.net”,
MyDirectory, true )
Post(End)
S5
Pre(S3)
BackgroundDL(“eMuleinstaller.exe”, “http://
sourceforge.net”, t_process >
10 )
Post(S6)
e7 [true]
S6
Pre(S5)
SendEmail(“eMule-installer.exe”,
ratna@uny.ac.id, true )
Post(End)
Model to Design
procedural
design
EntityRelationship
Diagram
Data Flow
Diagram
interface design
Data
Dictionary
architectural design
State-Transition
Diagram
data design
Model to Design

Data design
 mengubah model informasi (entity relationship
diagram dan
data dictionary) menjadi struktur data

Architectural design
 berisi hubungan antar elemen dalam program

Interface design
 menjelaskan bagaimana komunikasi di

dalam
perangkat lunak, dengan sistem, dan dengan manusia yang
menggunakannya.
Sebuah interface mengandung maksud sebuah aliran informasi.
Model to Design

Procedural design
 mengubah elemen struktural dari arsitektur
program menjadi deskripsi prosedural dari
komponen perangkat lunak
Model to Design

Sebuah desain harus menunjukkan organisasi secara hirarkis

Sebuah desain harus bersifat modular; jadi, sebuah perangkat
lunak seharusnya dapat dibagi-bagi secara lojik menjadi
beberapa elemen yang melakukan fungsi atau subfungsi
secara spesifik

Sebuah desain harus mengandung abstraksi data dan
prosedural

Sebuah desain harus mengarah pada modul-modul (prosedur
atau subrutin) yang menunjukkan karakteristik fungsional
Model to Design

Sebuah desain harus mengarah pada antarmuka
yang mengurangi kompleksitas hubungan antar
modul dan dengan lingkungan luar

Sebuah desain harus diturunkan menggunakan
metode yang berulang yang diarahkan oleh informasi
yang dihasilkan pada tahap analisis perangkat lunak
Model to Design





Proses desain tidak boleh mengalami “tunnel
vision”
Desain harus dapat dilacak ke model analisis
Tidak melakukan desain pada hal yang sama
berulang-ulang
Desain harus merepresentasikan masalah pada
keadaan nyata
Desain harus memperlihatkan keseragaman dan
integrasi
Model to Design




Desain harus terstruktur untuk mengatisipasi adanya
perubahan
Desain bukan coding, coding bukan desain
Penilaian kualitas desain harus dilaksanakan pada
saat desain tersebut dibuat
Desain harus di-review untuk meminimasi kesalahan
konseptual
Konsep Desain








Abstraksi
Modularitas
Arsitektur software
Hirarki kontrol
Pembagian struktural
Data struktur
Software procedure
Penyembunyian informasi
Dokumentasi Desain
I.
II.
III.
IV.
V.
VI.
VII.
Lingkup Sistem
Desain Data
Desain Architectural
Desain Antarmuka
Desain Prosedural
Catatan Khusus
Appendix
Data Design

Mengubah objek data yang didefinisikan pada
model analisis menjadi struktur data yang ada
dalam perangkat lunak

Atribut yang dimiliki objek data, hubungan di
antara objek data, dan penggunaannya dalam
program, semuanya mempengaruhi pemilihan
struktur data
Architectural Design



Menggunakan karakteristik aliran informasi dalam model
analisis untuk menghasilkan struktur program
Sebuah data flow diagram dipetakan menjadi struktur
program menggunakan dua pendekatan :
 Transform mapping
 Transaction mapping
Transform mapping : diterapkan untuk sebuah aliran data
yang menunjukkan batas yang jelas antara data yang
masuk dan yang keluar
Architectural Design

DFD dipetakan menjadi sebuah struktur yang
mengalokasikan kontrol menjadi input, pemorsesan, dan
output bersama dengan hirarki modul

Transaction mapping : diterapkan jika sebuah item
informasi menyebabkan percabangan

DFD dipetakan menjadi sebuah struktur yang
mengalokasikan kontrol menjadi sebuah substruktur yang
mendapatkan dan mengevaluasi sebuah transaksi
Interface Design

Meliputi antarmuka program internal dan
eksternal serta desain untuk antarmuka pengguna

Desain antarmuka internal dan eksternal
diarahkan oleh informasi yang diperoleh dari
model analisis
SADT
Pemodelan Fungsional dan Aliran Informasi
(Analisis Terstruktur)
Aplikasi Cash Register:
Data yang menjadi masukan PL
3
1
2
6
Pelanggan
1.
2.
3.
4.
5.
6.
Menyerahkan barang
Mencatat data penjualan
Memberikan pembayaran
Mencatat data pembayaran
Mencetak struk
Menerima struk, barang, dan
kembalian
4
5
C as h R e g is te r
Kasir
Data yang menjadi
keluaran PL
sumber/tujuan data
(entitas eksternal)
lingkup/konteks
perangkat lunak
Pemodelan Fungsional dan Aliran Informasi
(Analisis Terstruktur)
penjualan
pembayaran
Kasir
struk
Aplikasi Cash
Register
Pemodelan Fungsional dan Aliran Informasi
(Analisis Terstruktur)
• Merupakan pemerincian (break down) dari Diagram Konteks:
level-1, 2, dst.
• Proses-proses yang akan dibuat harus sesuai dengan
deskripsi kebutuhan fungsionalnya.
• Alur dan urutan proses mengikuti mekanisme proses
pengolahan data yang nanti akan dilakukan oleh perangkat
lunak.
Workflow Penjualan Barang
1
Diagram Aliran Data (DAD)
2
3
B as is
D ata
W o rk s t a tio n
Pelanggan
Kasir
1. Menyerahkan
barang
1. Catat data
penjualan
Kasir
penjualan
1
Catat Data
Penjualan
4
1. Baca kode barang
2. Cari dan tampilkan Spesifikasi
data barang
Proses
3. Baca banyak barang
4. Hitung dan
tampilkan jumlah
5. Rekam data penjualan
ke basis data; update
stok barang
Kamus Data
1. barang yang dibeli
2. penjualan = kode_brg + banyak
3. Barang = @kode_brg + nama_brg + harga + stok
4. Jual = @no_faktur + @kode_brg + banyak
Barang
Jual
Sketsa Tampilan Layar
Entry Penjualan Barang
Kode Barang
BRG-101
Nama Barang
KERTAS A4 80 GR.
Harga (Rp.)
27,500
Banyaknya
2
Jumlah (Rp.)
55,000
Rekam
X
Workflow Pembayaran
5
Diagram Aliran Data (DAD)
6
7
B as is
D ata
9
Pelanggan
8
Kasir
penjualan
1
Catat Data
Penjualan
W o rk s t a tio n
pembayaran
Kasir
Spesifikasi
1. Hitung dan
tampilkan total
Proses
1. Memberikan
1. Akhiri
2. Baca jumlah bayar
pembayaran
penjualan
3. Hitung dan tampilkan
2. Menerima struk, 2. Catat data
jumlah kembalian
barang dan
pembayaran; 4. Rekam data pemkembalian
cetak struk
bayaran ke basis data
5. Cetak struk
Barang
struk
total
Jual
2
Catat Data
Pembayaran
& Cetak Struk
Bayar
Kamus Data
1. barang yang dibeli
2. penjualan = kode_brg + banyak
3. Barang = @kode_brg + nama_brg + harga + stok
4. Jual = @no_faktur + @kode_brg + banyak
5. uang
6. pembayaran = jml_bayar
7. Bayar = @no_faktur + tanggal + total
8. struk = no_faktur + tanggal + {nama_brg + harga + banyak
+ jumlah} + total + bayar + kembali
9. struk, barang dan kembalian
total = no_faktur + {kode_brg + nama_brg + harga + banyak} + total
Sketsa Tampilan Layar
X
Entry Penjualan
Barang
Entry
Pembayaran
Total
Kode (Rp.)
Barang
55,000
BRG-101
Nama Barang
Jumlah
Bayar
60,000
KERTAS A4 80 GR.
Harga
(Rp.)
Kembali
Banyaknya
27,500
5,000
2
Jumlah (Rp.)
55,000
Rekam
Cetak Struk
Pembayaran
47
Pemodelan Fungsional dan Aliran Informasi
(Analisis Terstruktur)
Pemodelan Fungsional dan Aliran Informasi
(Analisis Terstruktur)
Data Store
1. Barang = @kode_brg + nama_brg + harga + stok
2. Bayar = @no_faktur + tanggal + total
3. Jual = @no_faktur + @kode_brg + banyak
Data Flow
1. pembayaran = jml_bayar
2. penjualan = kode_brg + banyak
3. struk = no_faktur + tanggal + {nama_brg + harga + banyak + jumlah}
+ total + bayar + kembali
4. total = no_faktur + {kode_brg + nama_brg + harga + banyak} + total
Pemodelan Fungsional dan Aliran Informasi
(Analisis Terstruktur)
Proses 1: Catat Data Penjualan
1. Baca kode barang
2. Cari dan tampilkan data barang
3. Baca banyak barang;
Hitung dan tampilkan jumlah
4. Rekam data penjualan ke basis data;
Update stok barang
Proses 2: Catat Data Pembayaran & Cetak Struk
1. Hitung dan tampilkan total
2. Baca jumlah bayar;
Hitung dan tampilkan jumlah kembalian
3. Rekam data pembayaran ke basis data
4. Cetak struk
Pemodelan Fungsional dan Aliran Informasi
(Analisis Terstruktur)

Dari DFD yang sudah dibuat, identifikasi data yang
akan diolah:




Tentukan data mana yang mewakili entitas:



Data transaksi penjualan
Data transaksi pembayaran
Data barang
Penjualan, pembayaran  event
Barang  things
Tentukan relasi antar entitas.
Pemodelan Fungsional dan Aliran Informasi
ERD (versi Peter Chen)
BARANG
PEMBAYARAN
1
dijual-pd
1
n
PENJUALAN
1
dilunasi-dg
Pemodelan Fungsional dan Aliran Informasi
ERD (versi James Martin (Conceptual Data Model)
BARANG
PEMBAYARAN
dijualpd
dilunasi
-dg
PENJUALAN
TOOLS PENGEMBANGAN
Data Flow Diagram
Data Flow Diagrams Symbols
DeMarco & Yourdon
Source/
Sink
System Analysis and Design
System – a group of interrelated procedures
used for a business function, with an
identifiable boundary, working together for
some purpose.
Analysis – separation of a whole into its
component parts
0.0
Process
DATA STORE
Data Flow Lines
Design – to create, fashion, execute, or
construct according to plan
Physical Data Flow Diagrams – show how
the current system flows
Logical Data Flow Diagrams – show the data
flow, structure, and requirements of a new
system
Data Flow Diagrams Symbols
DeMarco & Yourdon
Source/
Sink
0.0
Process
DATA STORE
Data Flow Lines
Source/Sink – help to establish the
boundaries of the system. A source identifies
the origin of data inflow to the system. A sink
identifies the outflow of a system, many times
as information.
Sometimes referred to an entity, a source
may be a customer, vendor, employee, or
even another system. A single entity can be
both a source and a sink.
Data Flow Diagrams Symbols
DeMarco & Yourdon
Source/
Sink
0.0
Process
DATA STORE
Data Flow Lines
Processes – are the activities (manual and
automated) that transform the inputs,
transport data from process to process,
stores the data, and produce the outputs of a
system.
Processes are used on every DFD starting
with an over all process on the context level
diagram, the system. The system is then
decomposed until a primitive level is
obtained. The primitive level is the point in
which the relevant activities of a process are
identified.
Data Flow Diagrams Symbols
DeMarco & Yourdon
Source/
Sink
0.0
Process
DATA STORE
Data Flow Lines
Data Store – is the resting place of the data
in a system. A data store can be in the form
of paper, a disk file or any other media.
Normally the word ‘data’ does not appear in
the title of a data store. Some examples of
data stores are Customer Order, Payment,
Invoice, Time Card……
Data Flow Diagrams Symbols
DeMarco & Yourdon
Source/
Sink
Data Flow – is the data in motion. Data can
move from the outside (source) into a
process. Once the inside of a system data
must flow from place to place through a
process, the flow lines show this movement.
0.0
Process
The lines are labeled to provide clarity and
meaning to the data moving through the
system.
DATA STORE
Data Flow Lines
Data Flow Diagrams Levels
DeMarco & Yourdon
Context Level DFD
Source/
Sink
Source/ Sink
Data Flow
0.0
Process
Data Flow
Source/ Sink
Data Flow
Level 1 DFD
0.0
Process
1.0
Process
Data Flow
Data Flow
DATA STORE
Data Flow Lines
Source/ Sink
Data Flow
2.0
Process
Data Flow
Data Flow
Data Flow
3.0
Process
Data Flow
Source/ Sink
Data Flow Diagrams Levels
DeMarco & Yourdon
Source
Source/
Sink
Level 2 DFD (and on)
Data Flow
1.1
Process
0.0
Process
DATA STORE
Source
Data Flow
1.2
Process
DATA STORE
Data Flow Lines
Data Flow
Sink
Data Flow Diagrams Levels
Prepared by: yourname
Project Name
Project Name
Date: 01/01/2002
Context Level DFD
Prepared by: yourname
Date: 01/01/2002
Level 2 DFD
Data Flow
1.1
Process
Source/ Sink
Data Flow
0.0
Process
DATA STORE
Project Name
Source/ Sink
Data Flow
1.2
Process
Data Flow
Data Flow
Prepared by: yourname
Project Name
Data Flow
Date: 01/01/2002
Data Flow
1.1
Process
DATA STORE
Project Name
Source/ Sink
Data Flow
2.0
Process
Level 2 DFD
Data Flow
Data Flow
Data Flow
Source/ Sink
Data Flow
1.1
Process
Data Flow
3.0
Process
1.2
Process
Data Flow
1.0
Process
Data Flow
Date: 01/01/2002
Level 2 DFD
Level 1 DFD
Data Flow
Prepared by: yourname
DATA STORE
Data Flow
Data Flow
1.2
Process
Data Flow
Prepared by: yourname
Date: 01/01/2002
Creating Data Flow Diagrams
Steps:
1. Create a list of activities
2. Construct Context Level DFD
(identifies sources and sink)
3. Construct Level 1 DFD
(identifies manageable sub process )
4. Construct Level 2- n DFD
(identifies actual data flows and data stores )
Creating Data Flow Diagrams
Lemonade Stand Example
Creating Data Flow Diagrams
Example
The operations of a simple
lemonade stand will be used
to demonstrate the creation
of dataflow diagrams.
Steps:
1. Create a list of activities
2. Construct Context Level DFD
(identifies sources and sink)
3. Construct Level 1 DFD
(identifies manageable sub processes )
4. Construct Level 2- n DFD
(identifies actual data flows and data stores )
Creating Data Flow Diagrams
Example
1. Create a list of activities
Think through the activities
that take place at a lemonade
stand.
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
Creating Data Flow Diagrams
Example
1. Create a list of activities
Also think of the additional
activities needed to support
the basic activities.
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
Order Raw Materials
Pay for Raw Materials
Pay for Labor
Creating Data Flow Diagrams
Example
1. Create a list of activities
Group these activities in
some logical fashion,
possibly functional areas.
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
Order Raw Materials
Pay for Raw Materials
Pay for Labor
Creating Data Flow Diagrams
Example
2. Construct Context Level DFD
(identifies sources and sink)
Create a context level
diagram identifying the
sources and sinks (users).
Context Level DFD
Order
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
Order Raw Materials
Pay for Raw Materials
Pay for Labor
CUSTOMER
Sales Forecast
0.0
Lemonade Production Schedule EMPLOYEE
Pay
System
Product Served
Payment
Received Goods
Payment
VENDOR
Time Worked
Purchase Order
Creating Data Flow Diagrams
Example
Create a level 1 diagram
identifying the logical
subsystems that may exist.
3. Construct Level 1 DFD
(identifies manageable sub processes )
Level 1 DFD
1.0
Sale
Customer Order
Serve Product
Collect Payment
Product Ordered
Payment
CUSTOMER
Produce Product
Store Product
Pay for Labor
Product Served
Received Goods
VENDOR
Order Raw Materials
Pay for Raw Materials
Sales Forecast
Customer Order
Purchase Order
Production
Schedule
2.0
Production
EMPLOYEE
Inventory
3.0
Procurement
Payment
Order
Decisions
Pay
4.0
Payroll
Time Worked
Creating Data Flow Diagrams
Example
Create a level 2
decomposing the processes
in level 0 and identifying
data stores.
4. Construct Level 2- n DFD
(identifies actual data flows and data stores )
Level 2 DFD
CUSTOMER
Customer Order
ORDER
Customer Order
Serve Product
Collect Payment
1.1
Record
Order
Severed Order
Produce Product
Store Product
Order Raw Materials
Pay for Raw Materials
Pay for Labor
Payment
1.2
Receive
Payment
PAYMENT
Request for Forecast
1.3
Produce
Sales
Forecast
Sales Forecast
Creating Data Flow Diagrams
Example
Create a level 2
decomposing the processes
in level 0 and identifying
data stores.
4. Construct Level 2 (continued)
Level 2 DFD
Product Order
ORDER
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
Order Raw Materials
Pay for Raw Materials
Pay for Labor
2.1
Serve
Product
Quantity Severed
RAW
MATERIALS
Production
Schedule
2.2
Produce
Product
Production Data
2.3
Store
Product
Quantity Used
INVENTORTY
Quantity Produced &
Location Stored
Creating Data Flow Diagrams
Example
Create a level 2
decomposing the processes
in level 0 and identifying
data stores.
Customer Order
Serve Product
Collect Payment
4. Construct Level 2 (continued)
Level 2 DFD
Order Decision
3.1
Produce
Purchase
Order
PURCHASE
ORDER
Quantity On-Hand
Quantity
Received
Received
Goods
3.2
Receive
Items
Produce Product
Store Product
Payment Approval
Order Raw Materials
Pay for Raw Materials
3.3
Pay
Vendor
Pay for Labor
Payment
RAW
MATERIALS
RECEIVED
ITEMS
VENDOR
Creating Data Flow Diagrams
Example
Create a level 2
decomposing the processes
in level 0 and identifying
data stores.
Customer Order
Serve Product
Collect Payment
4. Construct Level 2 (continued)
Level 2 DFD
Time Worked
4.1
Record
Time
Worked
TIME CARDS
Employee ID
EMPLOYEE
Payroll Request
4.2
Calculate
Payroll
Produce Product
Store Product
Unpaid time cards
PAYROLL
Payment Approval
Order Raw Materials
Pay for Raw Materials
4.3
Pay
Employe
e
Pay for Labor
Payment
PAYMENTS
Process Decomposition
0.0
Lemonade
System
Context Level
1.0
Sale
1.1
Record
Order
1.2
Receive
Payment
2.0
Production
2.1
Serve
Product
2.2
Produce
Product
2.3
Store
Product
3.0
Procurement
3.1
Produce
Purchase
Order
3.2
Receive
Items
3.3
Pay
Vendor
4.0
Payroll
4.1
Record
Time
Worked
4.2
Calculate
Payroll
4.3
Pay
Employe
e
Level 1
Level 2
Creating Data Flow Diagrams
Lemonade Stand Example
END