Rekayasa Perangkat Lunak Plpg

REKAYASA PERANGKAT LUNAK

Dr. Ratna WardaniProdi PTI Fakultas Teknik

Universitas Negeri Yogyakarta

Pendidikan dan Latihan Profesi Guru

• Tentang Kurikulum1

• Rekayasa Perangkat Lunak2

• Tools Pengembangan3

Materi

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 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


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


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


Aplikasi Cash

RegisterKasir

penjualan

pembayaran

struk


• 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 pembayaran 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


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


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


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.


ERD (versi Peter Chen)

BARANG

PENJUALAN

PEMBAYARAN

dijual-pd dilunasi-dg

1

n 1

1


ERD (versi James Martin (Conceptual Data Model)

BARANG

PENJUALAN

PEMBAYARAN

dijual-pd

dilunasi-dg

TOOLS PENGEMBANGAN

Data Flow Diagram

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


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.


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.


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……


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


Date: 01/01/2002

Level 2 DFD

Project Name

1.2Process

1.1Process

Data Flow

Data Flow

DATA STORE

Data Flow


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


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 )


Lemonade Stand Example


Steps:



3. Construct Level 1 DFD (identifies manageable sub processes )


Example

The operations of a simple lemonade stand will be used to demonstrate the creation of dataflow diagrams.


1. Create a list of activitiesExample

Think through the activities that take place at a lemonade stand.

Customer OrderServe ProductCollect PaymentProduce ProductStore Product


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



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



0.0Lemonade

SystemEMPLOYEECUSTOMER

PayPayment

Order

Context Level DFD

Example

Create a context level diagram identifying the sources and sinks (users).




Pay for Labor

VENDOR

PaymentPurchase Order

Production Schedule

Received GoodsTime Worked

Sales Forecast


Product Served


Level 1 DFD

Example

Create a level 1 diagram identifying the logical subsystems that may exist.




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


Level 2 DFD

Example

Create a level 2 decomposing the processes in level 0 and identifying data stores.


1.3Produce

Sales Forecast Sales ForecastPayment




Pay for Labor

1.1Record Order

Customer Order

ORDER

1.2Receive Payment

PAYMENT

Severed Order

Request for Forecast

CUSTOMER


Level 2 DFD

Example


4. Construct Level 2 (continued)




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


Level 2 DFD

Example






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


Level 2 DFD

Example



Time Worked




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


Lemonade Stand Example

END

Rekayasa Perangkat Lunak Plpg

Documents

Transcript of Rekayasa Perangkat Lunak Plpg