rekayasa perangkat lunak plpg
TRANSCRIPT
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 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
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 tingkat-tingkat yang merepresentasikan aliran informasi yang bertambah dan fungsi ideal.
Pemodelan Fungsional dan Aliran Informasi (Analisis Terstruktur)
KasirPelanggan
Cash Register
lingkup/konteks perangkat lunak
sumber/tujuan data (entitas eksternal)
Aplikasi Cash Register:
2 4
5
Data yang menjadi masukan PL
1. Menyerahkan barang2. Mencatat data penjualan3. Memberikan pembayaran4. Mencatat data pembayaran5. Mencetak struk6. Menerima struk, barang,
dan kembalian
Data yang menjadi keluaran PL
1 3
6
Pemodelan Fungsional dan Aliran Informasi (Analisis Terstruktur)
Aplikasi Cash
RegisterKasir
penjualan
pembayaran
struk
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
e3 [t_process > t_user]
e4 [t_process ≤ t_user]
e6 [t_process > t_user]
e1 [nil]
e2 [t_process ≤ t_user]
S5Pre(S3)BackgroundDL(“eMule-installer.exe”, “http://sourceforge.net”, t_process > 10 )Post(S6)
S2
Pre(S1 Ú S3)NormalDL(“eMule-installer.exe”, “http://sourceforge.net”, t_user <= 10 )Post(S4)
S3
Pre(S1)Retry(“eMule-installer.exe”, “http://sourceforge.net”, t_user <= 10 )Post(S2 Ú S5)
e5 [true]
S1
Pre(Initial())Get(“eMule-installer.exe”, “http://sourceforge.net”, t_user <= 10 )Post(S2 Ú S3)
e7 [true]
S4
Pre(S2)SaveTo(“eMule-installer.exe”, “http://sourceforge.net”, MyDirectory, true )Post(End)
S6
Pre(S5)SendEmail(“eMule-installer.exe”, [email protected], true )Post(End)
Model to Design
Entity-Relationship
DiagramData
Dictionary
State-TransitionDiagram
Data FlowDiagram
procedural design
interface design
architectural design
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. Lingkup SistemII. Desain DataIII. Desain ArchitecturalIV. Desain AntarmukaV. Desain ProseduralVI. Catatan KhususVII. 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
Pemodelan Fungsional dan Aliran Informasi (Analisis Terstruktur)
KasirPelanggan
Cash Register
lingkup/konteks perangkat lunak
sumber/tujuan data (entitas eksternal)
Aplikasi Cash Register:
2 4
5
Data yang menjadi masukan PL
1. Menyerahkan barang2. Mencatat data penjualan3. Memberikan pembayaran4. Mencatat data pembayaran5. Mencetak struk6. Menerima struk, barang,
dan kembalian
Data yang menjadi keluaran PL
1 3
6
Pemodelan Fungsional dan Aliran Informasi (Analisis Terstruktur)
Aplikasi Cash
RegisterKasir
penjualan
pembayaran
struk
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.
KasirPelangga
n
Workstation
Workflow Penjualan Barang
1. Menyerahkan barang
1
1. barang yang dibeli
1. Catat data penjualan
2
2. penjualanEntry Penjualan Barang X
Kode Barang BRG-101= kode_brg
BasisData
3
3. Barang = @kode_brg + nama_brg + harga + stok
Nama Barang KERTAS A4 80 GR.
Harga (Rp.) 27,500
Banyaknya 2
Jumlah (Rp.) 55,000
+ banyak
Rekam
1. Baca kode barang
2. Cari dan tampilkan data barang
4. Hitung dan tampilkan jumlah
5. Rekam data penjualan ke basis data; update stok barang
4
4. Jual = @no_faktur + @kode_brg + banyak
3. Baca banyak barang
Diagram Aliran Data (DAD)
1Catat Data Penjualan
penjualanKasir Barang
Jual
Kamus Data
Spesifikasi Proses
Sketsa Tampilan Layar
47
Entry Penjualan Barang X
Kode Barang BRG-101
Nama Barang KERTAS A4 80 GR.
Harga (Rp.) 27,500
Banyaknya 2
Jumlah (Rp.) 55,000
Rekam
1. Akhiri penjualan
Pembayaran
1. Hitung dan tampilkan total
Entry Pembayaran X
Total (Rp.) 55,000
Jumlah Bayar
1. Memberikan pembayaran
5
5. uang
2. Catat data pembayaran; cetak struk
6
6. pembayaran
60,000
= jml_bayar
2. Baca jumlah bayar3. Hitung dan tampilkan jumlah kembalian
Kembali 5,000
4. Rekam data pem- bayaran ke basis data
Cetak Struk
7
7. Bayar = @no_faktur + tanggal + total
5. Cetak struk
8
8. struk = no_faktur + tanggal + {nama_brg + harga + banyak + jumlah} + total + bayar + kembali
2. Menerima struk, barang dan kembalian
9
9. struk, barang dan kembalian
2Catat Data
Pembayaran & Cetak Struk
total
pembayaran
Bayar
struk
total = no_faktur + {kode_brg + nama_brg + harga + banyak} + total
Workflow Pembayaran
KasirPelangga
n
Workstation
BasisData
Diagram Aliran Data (DAD)
1Catat Data Penjualan
penjualanKasir Barang
Jual
Kamus Data
3. Barang = @kode_brg + nama_brg + harga + stok
1. barang yang dibeli
2. penjualan = kode_brg + banyak
4. Jual = @no_faktur + @kode_brg + banyak
Spesifikasi Proses
Sketsa Tampilan Layar
Pemodelan Fungsional dan Aliran Informasi (Analisis Terstruktur)
Data Store1. Barang = @kode_brg + nama_brg + harga + stok2. Bayar = @no_faktur + tanggal + total3. Jual = @no_faktur + @kode_brg + banyak
Data Flow1. pembayaran = jml_bayar2. penjualan = kode_brg + banyak3. struk = no_faktur + tanggal + {nama_brg + harga + banyak + jumlah} + total + bayar + kembali4. total = no_faktur + {kode_brg + nama_brg + harga + banyak} + total
Pemodelan Fungsional dan Aliran Informasi (Analisis Terstruktur)
Proses 1: Catat Data Penjualan1. Baca kode barang2. Cari dan tampilkan data barang3. Baca banyak barang; Hitung dan tampilkan jumlah4. Rekam data penjualan ke basis data; Update stok barang
Proses 2: Catat Data Pembayaran & Cetak Struk1. Hitung dan tampilkan total2. Baca jumlah bayar; Hitung dan tampilkan jumlah kembalian3. Rekam data pembayaran ke basis data4. Cetak struk
Pemodelan Fungsional dan Aliran Informasi (Analisis Terstruktur)
Dari DFD yang sudah dibuat, identifikasi data yang akan diolah:
Data transaksi penjualan Data transaksi pembayaran Data barang
Tentukan data mana yang mewakili entitas: Penjualan, pembayaran event Barang things
Tentukan relasi antar entitas.
Pemodelan Fungsional dan Aliran Informasi
ERD (versi Peter Chen)
BARANG
PENJUALAN
PEMBAYARAN
dijual-pd dilunasi-dg
1
n 1
1
Pemodelan Fungsional dan Aliran Informasi
ERD (versi James Martin (Conceptual Data Model)
BARANG
PENJUALAN
PEMBAYARAN
dijual-pd
dilunasi-dg
Data Flow Diagrams Symbols
Source/ Sink
0.0Process
DATA STORE
Data Flow Lines
DeMarco & Yourdon
Logical Data Flow Diagrams – show the data flow, structure, and requirements of a new system
Physical Data Flow Diagrams – show how the current system flows
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
Design – to create, fashion, execute, or construct according to plan
Data Flow Diagrams Symbols
Source/ Sink
0.0Process
DATA STORE
Data Flow Lines
DeMarco & Yourdon
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
Source/ Sink
0.0Process
DATA STORE
Data Flow Lines
DeMarco & Yourdon
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
Source/ Sink
0.0Process
DATA STORE
Data Flow Lines
DeMarco & Yourdon
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
Source/ Sink
0.0Process
DATA STORE
Data Flow Lines
DeMarco & Yourdon
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.
The lines are labeled to provide clarity and meaning to the data moving through the system.
Data Flow Diagrams Levels
Source/ Sink
0.0Process
DATA STORE
Data Flow Lines
DeMarco & Yourdon
0.0Process Source/ SinkSource/ Sink
Data FlowData Flow
Data Flow
2.0ProcessData Flow
Source/ SinkSource/ SinkData Flow
1.0Process
3.0Process
Data Flow
Data Flow
Data FlowData Flow
Data Flow
Context Level DFD
Level 1 DFD
Data Flow Diagrams Levels
Source/ Sink
0.0Process
DATA STORE
Data Flow Lines
DeMarco & Yourdon
1.2Process
1.1Process
Data Flow
Data Flow
DATA STORE
Data Flow
Level 2 DFD (and on)Source
Source
Sink
Prepared by: yourname
Date: 01/01/2002
Level 2 DFD
Project Name
1.2Process
1.1Process
Data Flow
Data Flow
DATA STORE
Data Flow
Prepared by: yourname
Date: 01/01/2002
Level 2 DFD
Project Name
1.2Process
1.1Process
Data Flow
Data Flow
DATA STORE
Data Flow
Prepared by: yourname
Date: 01/01/2002
Level 2 DFD
Project Name
1.2Process
1.1Process
Data Flow
Data Flow
DATA STORE
Data Flow
Data Flow Diagrams LevelsPrepared by: yourname
Date: 01/01/2002
Context Level DFD
Project Name
0.0Process Source/ SinkSource/ Sink
Data FlowData Flow
Data Flow
Prepared by: yourname
Date: 01/01/2002
Level 1 DFD
Project Name
2.0ProcessData Flow
Source/ SinkSource/ SinkData Flow
1.0Process
3.0Process
Data Flow
Data Flow
Data FlowData Flow
Data Flow
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
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 )
Example
The operations of a simple lemonade stand will be used to demonstrate the creation of dataflow diagrams.
Creating Data Flow Diagrams
1. Create a list of activitiesExample
Think through the activities that take place at a lemonade stand.
Customer OrderServe ProductCollect PaymentProduce ProductStore Product
Creating Data Flow Diagrams
Example
Also think of the additional activities needed to support the basic activities.
Customer OrderServe ProductCollect PaymentProduce ProductStore ProductOrder Raw MaterialsPay for Raw MaterialsPay for Labor
1. Create a list of activities
Creating Data Flow Diagrams
Example
Group these activities in some logical fashion, possibly functional areas.
Customer OrderServe ProductCollect Payment
Produce ProductStore Product
Order Raw MaterialsPay for Raw Materials
Pay for Labor
1. Create a list of activities
Creating Data Flow Diagrams
0.0Lemonade
SystemEMPLOYEECUSTOMER
PayPayment
Order
Context Level DFD
Example
Create a context level diagram identifying the sources and sinks (users).
Customer OrderServe ProductCollect Payment
Produce ProductStore Product
Order Raw MaterialsPay for Raw Materials
Pay for Labor
VENDOR
PaymentPurchase Order
Production Schedule
Received GoodsTime Worked
Sales Forecast
2. Construct Context Level DFD(identifies sources and sink)
Product Served
Creating Data Flow Diagrams
Level 1 DFD
Example
Create a level 1 diagram identifying the logical subsystems that may exist.
Customer OrderServe ProductCollect Payment
Produce ProductStore Product
Order Raw MaterialsPay for Raw Materials
Pay for Labor
3. Construct Level 1 DFD (identifies manageable sub processes )
2.0Production EMPLOYEEProduction
Schedule
1.0Sale
3.0Procure-
ment
Sales Forecast
Product Ordered
CUSTOMER
Pay
Payment
Customer Order
VENDOR
Payment
Purchase Order Order Decisions
Received Goods
Time Worked
Inventory
Product Served
4.0Payroll
Creating Data Flow Diagrams
Level 2 DFD
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 )
1.3Produce
Sales Forecast Sales ForecastPayment
Customer OrderServe ProductCollect Payment
Produce ProductStore Product
Order Raw MaterialsPay for Raw Materials
Pay for Labor
1.1Record Order
Customer Order
ORDER
1.2Receive Payment
PAYMENT
Severed Order
Request for Forecast
CUSTOMER
Creating Data Flow Diagrams
Level 2 DFD
Example
Create a level 2 decomposing the processes in level 0 and identifying data stores.
4. Construct Level 2 (continued)
Customer OrderServe ProductCollect Payment
Produce ProductStore Product
Order Raw MaterialsPay for Raw Materials
Pay for Labor
2.1Serve
Product
Product Order
ORDER
2.2Produce Product
INVENTORTY
Quantity Severed
Production Schedule
RAW MATERIALS
2.3Store
Product
Quantity Produced & Location Stored
Quantity Used
Production Data
Creating Data Flow Diagrams
Level 2 DFD
Example
Create a level 2 decomposing the processes in level 0 and identifying data stores.
4. Construct Level 2 (continued)
Customer OrderServe ProductCollect Payment
Produce ProductStore Product
Order Raw MaterialsPay for Raw Materials
Pay for Labor
3.1Produce Purchase
Order
Order DecisionPURCHASE
ORDER
3.2Receive
Items
Received Goods
RAW MATERIALS
3.3Pay
Vendor
Quantity Received
Quantity On-Hand
RECEIVED ITEMS
VENDOR
Payment Approval
Payment
Creating Data Flow Diagrams
Level 2 DFD
Example
Create a level 2 decomposing the processes in level 0 and identifying data stores.
4. Construct Level 2 (continued)
Time Worked
Customer OrderServe ProductCollect Payment
Produce ProductStore Product
Order Raw MaterialsPay for Raw Materials
Pay for Labor
4.1Record Time
Worked
TIME CARDS
4.2Calculate
Payroll
Payroll Request
EMPLOYEE
4.3Pay
Employee
Employee ID
PAYROLL
PAYMENTS
Payment Approval
Payment
Unpaid time cards
Process Decomposition
4.1Record Time
Worked
4.2Calculate
Payroll
4.3Pay
Employee
3.1Produce Purchase
Order
3.2Receive
Items
3.3Pay
Vendor
2.1Serve
Product
2.2Produce Product
2.3Store
Product
1.1Record Order
1.2Receive Payment
2.0Production
1.0Sale
3.0Procure-
ment
4.0Payroll
0.0Lemonade
System
Level 1 Level 2Context Level