Upload presentasi
Presentasi sedang didownload. Silahkan tunggu
1
Rekayasa perangkat lunak (rpl)
SEMESTER PENDEK 2015/2016 Rekayasa perangkat lunak (rpl) Betha Nurina Sari,M.Kom
2
PERTEMUAN 9-10 Pemodelan Hasil Analisis Kebutuhan
3
Membangun Model Analisis
Elemen-elemen model analisis Elemen-elemen berbasis skenario Fungsional—memproses narasi untuk fungsi software Use-case—gambaran interaksi antara aktor dan sistem Elemen-elemen berbasis Class Dipengaruhi oleh skenario Elemen-elemen Perilaku/Behavioral State diagram Elemen-elemen berorientasi aliran Data flow diagram Elemen-elemen berorientasi obyek
4
Berbasis Skenario : Use-Cases
Sekelompok skenario pengguna yang menggambarkan alur penggunaan sistem Setiap skenario digambarkan dari sudut pandang “aktor”, seseorang atau piranti yang berinteraksi dengan PL dalam berbagai cara Setiap skenario menjawab pertanyaan-pertanyaan berikut : Siapa aktor primer dan sekunder ? Apa tujuan aktor ? Prekondisi apa yang harus ada sebelum cerita dimulai? Apa tugas atau fungsi utama yang dilakukan oleh aktor ? Ekstensi apa yang harus diperhatikan ketika cerita digambarkan?
5
Use-Case Diagram
6
Berbasis Perilaku : State Diagram
7
PERANCANGAN SOFTWARE Proses untuk mendefinisikan suatu model atau rancangan sistem dengan menggunakan teknik dan prinsip tertentu sedemikian sehingga model atau rancangan tersebut dapat diwujudkan menjadi Perangkat Lunak. Proses mendefinisikan arsitektur PL, komponen, modul, antarmuka, pendekatan pengujian, serta data untuk memenuhi kebutuhan yang sudah ditentukan sebelumnya. Proses bertahap dimana semua kebutuhan yang ada diterjemahkan menjadi suatu cetak biru yang akan digunakan untuk mengkonstruksi sistem. [Pressman, 2001]
8
Strategi Perancangan Top Down Bottom Up Organizational
Struktur proses perancangan dipengaruhi oleh faktor- faktor non teknis yang timbul dari faktor organisasi pemakai peangkat lunak Blue Print Menggunakan strategi perancangan yang standar untuk beberapa masalah yang memiliki kesamaan paradigma
9
3 Karakteristik Evaluasi Perancangan
Perancangan harus mengimplementasi-kan keseluruhan kebutuhan eksplisit dan mengakomodasi semua kebutuhan implisit yang diinginkan Perancangan harus menjadi panduan yang dapat dibaca, dipahami bagi programmer dan penguji PL Perancangan harus memberikan suatu gambaran lengkap mengenai PL
10
Perancangan Sistem Proses Perancangan
Serangkaian langkah iteratif yang memungkinkan desainer menggambarkan semua aspek sistem yang dibangun Model Perancangan Ekivalen rencana arsitek untuk sebuah rumah. (yang dibuat untuk perangkat sistem memberikan berbagai pandangan yang berbeda tentang program komputer
11
OBJEK PERANCANGAN Data Arsitektur perangkat lunak Antarmuka pemakai
Struktur tabel basis data / file data Struktur data internal Arsitektur perangkat lunak Structure chart Struktur menu program Antarmuka pemakai Spesifikasi program (algoritma)
12
TRANSFORMASI MODEL ANALISIS - PERANCANGAN
Diagram Konteks DFD level 1, 2, … Kamus Data Spesifikasi Proses E-R Diagram Model Perancangan Rancangan Data Arsitektur PL (Structure Chart) Antarmuka Pemakai Spesifikasi Program (Algoritma) 2 3 1 4
13
PERANCANGAN BASIS DATA
Transformasi Diagram E-R (conceptual data model, CDM) menjadi model relasi (skema relasi, tabel relasi). Penentuan atribut relasi sesuai dengan kamus data yang telah dibuat. Normalisasi. Pendefinisian struktur tabel. Pembuatan relasi antar tabel (physical data model, PDM)
14
CONTOH STRUKTUR TABEL BASIS DATA
Tabel Penjualan Fungsi : Menyimpan data transaksi penjualan Jenis : Tabel Transaksi Primary Key : No_Faktur+Kode_Brg Foreign Key : Kode_Brg Struktur Tabel : No. Nama Field Jenis Lebar Keterangan 1 No_Faktur String 10 Nomor Faktur 2 Kode_Brg 8 Kode Barang 3 Hrg_Jual Long Integer Harga jual barang saat transaksi 4 Kuantitas Integer 5 Banyaknya (kuantitas) barang
15
CONTOH RELASI ANTAR TABEL
16
ARSITEKTUR PERANGKAT LUNAK
Gambaran bagaimana elemen/komponen fungsional perangkat lunak disusun, diorganisasi dan distrukturkan sehingga: Hubungan antar elemen/komponen dapat dijelaskan. Interface yang menghubungkan elemen/komponen dapat didefinisikan. Wujud dan penempatan elemen/komponen dalam tempat penyimpanan sekunder secara fisik dapat ditetapkan.
17
Aliran Transformasi Mentrasformasikan data eksternal ke bentuk internal diidentfikasi sebagai aliran masuk, terjadi transisi, data masuk dilewatkan melalui pusat transformasi dan bergerak keluar melalui jalur keluar.
18
Aliran Transaksi
19
CONTOH ARSITEKTUR PERANGKAT LUNAK
Modul Pemanggil Arsitektur Perangkat Lunak (Structure Chart) Kelola Data Induk Model Analisis (DFD level atomik) Proses 2.0 Proses 1.0 Tambah Data Barang Tambah Data Supplier id_barang rec_barang id_supplier rec_supplier supplier Modul-modul atomik (procedure, function) Baca Id_Barang Rekam Barang Baca Id_Supplier Rekam Supplier
20
STRUCTURE CHART (1) : PASCAL
Modul A memanggil modul B dengan data x dan y sebagai parameternya. Modul B mengirimkan data p dan q sebagai return value ke modul A. Procedure A; Var p, q : Real; Procedure B(x, y : Real); Begin p := ... { manipulasi nilai p } q := ... { manipulasi nilai q } End; B(x, y); { call procedure B } Potongan kode program dalam bahasa Pascal
21
STRUCTURE CHART (2) : PHP
FormInput.html FormInput <html> ... <form method=post action=Rekam.php> </html> Rekam Rekam.php id id <? // Rekam.php function getId() { } function saveId(id) { id = getId(); saveId(id) ?> getId saveId
22
PERANCANGAN ANTARMUKA PEMAKAI
Secara fisik antarmuka pemakai yang dirancang adalah tampilan layar (form, halaman web). Jenisnya dapat berupa: Menu pilihan Form isian (entry) Penyajian informasi (report, query) Kotak dialog, jika diperlukan Fasilitas bantuan (Help), jika diperlukan
23
IDENTIFIKASI RANCANGAN ANTARMUKA PEMAKAI
Ada data yang diberikan oleh pemakai ke PL Ada interaksi antara pemakai dengan PL Harus ada user interface untuk Tambah Data Barang! Tambah Data Barang X Lihat kamus datanya!!! id_barang = kode_ brg + nama_brg + satuan + jenis + hrg_beli + hrg_jual + jml_stok + kode_sup
24
PENULISAN SPESIFIKASI PROGRAM
Deskripsi prosedural (algoritma) untuk semua modul-modul program yang menjadi elemen-elemen struktural dari arsitektur perangkat lunak: Prosedur Fungsi Merupakan penjelasan lebih rinci dan teknis dari spesifikasi proses. Ditulis dengan menggunakan notasi pseudo-code, atau notasi yang mirip dengan bahasa pemrograman yang digunakan.
25
SPESIFIKASI PROGRAM ( DELPHI LIKE )
SPESIFIKASI PROSES SPESIFIKASI PROGRAM ( DELPHI LIKE ) Proses 1.1 Tambah Data Barang Begin While data barang masih ada Do Baca identitas barang Verifikasi If not valid Then tulis pesan Else rekam ke tabel barang End Procedure btnRekamBarangClick Kamus { Deklarasi variabel; TEdit, TDBLookupCombo, TTable terdefinisi } eKode, eNama, eSatuan, eJenis, eHrgBeli, eHrgJual, eJmlStok: TEdit DBLookupCombo1: TDBLookupCombo TabelBarang, TabelSupplier: TTable Algoritma { Buka tabel barang dan supplier } TabelBarang.Open TabelSupplier.Open { Baca identitas barang melalui komponen TEdit dan validasi } { Rekam ke tabel barang } TabelBarang.Append TabelBarang.FieldByName('Kode_Brg').AsString := eKode.Text TabelBarang.FieldByName('Nama_Brg').AsString := eNama.Text TabelBarang.FieldByName('Satuan').AsString := eSatuan.Text TabelBarang.FieldByName('Jenis').AsInteger:=StrToInt(eJenis.Text) TabelBarang.FieldByName('Hrg_Beli').AsInteger:=StrToInt(eHrgBeli.Text) TabelBarang.FieldByName('Hrg_Jual').AsInteger:=StrToInt(eHrgJual.Text) TabelBarang.FieldByName('Jml_Stok').AsInteger:=StrToInt(eJmlStok.Text) TabelBarang.FieldByName('Kode_Sup').AsString := DBLookupCombo1.Value; TabelBarang.Post
26
PERTEMUAN 11-12 UML (Unified Modeling Language)
27
UML mempunyai 9 diagram, yaitu;
Diagram Use Case Diagram Class Diagram Package Diagram Object Diagram Sequence Diagram Collaboration Diagram StateChart Diagram Activity Diagram Deployment
28
Diagram Use Case Diagram Use Case menggambarkan apa saja aktifitas yang dilakukan oleh suatu sistem dari sudut pandang pengamatan luar. yang menjadi persoalan itu apa yang dilakukan bukan bagaimana melakukannya. Diagram Use Case dekat kaitannya dengan kejadian-kejadian. Kejadian (scenario) merupakan contoh apa yang terjadi ketika seseorang berinteraksi dengan sistem.
29
untuk lebih memperjelas lihat gambaran suatu peristiwa untuk sebuah klinik kesehatan :
“Pasien menghubungi klinik untuk membuat janji (appointment) dalam pemeriksaan tahunan. Receptionist mendapatkan waktu yang luang pada buku jadwal dan memasukkan janji tersebut ke dalam waktu luang itu.” gb 1. Contoh Kegiatan Pasien yang membuat janji
30
Fungsi Diagram Use Case
Menjelaskan fasilitas yang ada (requirements) Use Case baru selalu menghasilkan fasilitas baru ketika sistem di analisa, dan design menjadi lebih jelas. Komunikas dengan klien Penggunaan notasi dan simbol dalam diagram Use Case membuat pengembang lebih mudah berkomunikasi dengan klien-kliennya. Membuat test dari kasus-kasus secara umum Kumpulan dari kejadian-kejadian untuk Use Case bisa dilakukan test kasus layak untuk kejadian-kejadian tersebut.
31
Diagram Class Diagram Class memberikan pandangan secara luas dari suatu sistem dengan menunjukan kelas- kelasnya dan hubungan mereka. Diagram Class bersifat statis; menggambarkan hubungan apa yang terjadi bukan apa yang terjadi jika mereka berhubungan.
32
Diagram Class Setiap diagram Class memiliki Class (kelas), association, dan multiplicity. Sedangkan navigability (alur arah) dan role (kegiatan) merupakan optional (tidak diharuskan). Diagram Class dapat dibagi 2 yaitu : Diagram Package Diagram Object
33
Gb.2 Contoh Diagram Class Transaksi Pembelian Barang
34
Diagram Package Untuk mengatur pengorganisasian diagram Class yang kompleks, dapat dilakukan pengelompokan kelas-kelas berupa package (paket-paket). Package adalah kumpulan elemen-elemen logika UML.
35
Gambar di bawah ini mengenai model bisnis dengan pengelompokan kelas-kelas dalam bentuk paket-paket : Gb.3 Contoh Diagram Package
36
Diagram Object Ada jenis khusus dari diagram Class yaitu diagram Object. Kegunaannya untuk penjelasan yang sedikit dengan relasi yang sulit, khususnya relasi rekursif
37
Lihat gambar dibawah, diagram Class kecil menunjukkan bahwa ‘department’ dapat mengandung banyak ‘department’ yang lain. Setiap tingkatan pada diagram berpengaruh pada single instance (bagian tunggal). Nama bagian digarisbawahi dalam diagram UML. Untuk Class name (nama kelas) maupun instance name (nama bagian) bisa mengambil dari diagram Object selama arti diagram tersebut masih jelas.
38
Diagram Sequence Diagram sequence merupakan salah satu diagram yang bersifat dinamis yang menjelaskan bagaimana suatu operasi itu dilakukan; message (pesan) apa yang dikirim dan kapan pelaksanaannya. Diagram ini diatur berdasarkan waktu. Obyek-obyek yang berkaitan dengan proses berjalannya operasi diurutkan dari kiri ke kanan berdasarkan waktu terjadinya dalam pesan yang terurut.
39
Di bawah ini adalah diagram Sequence untuk pembuatan Hotel Reservation
Di bawah ini adalah diagram Sequence untuk pembuatan Hotel Reservation. Obyek yang mengawali urutan message adalah ‘aReservation Window’. Gambar 6. Contoh Diagram Sequence ‘Pemesanan kamar di Hotel’.
40
Diagram Collaboration
Diagram Collaboration juga merupakan diagram interaction / bersifat dinamis. Diagram membawa informasi yang sama dengan diagram Sequence, tetapi lebih memusatkan atau memfokuskan pada kegiatan obyek dari waktu pesan itu dikirimkan.
41
Gb.7 Contoh diagram collaboration “Pemesanan kamar hotel”
42
Diagram Collaboration
Kotak kegiatan obyek diberi label dengan nama kelas atau obyek (atau keduanya). Nama kelas dibatasi dengan colons /titik dua ( : ). Setiap pesan pada diagram Collaboration mempunyai angka yang terurut. Pesan yang tingkatannya tertinggi adalah angka 1. Pesan yang berada pada tingkat yang sama memiliki prefix yang sama, namun suffix berbeda bergantung pada posisinya; hanya untuk angka 1, 2, dan seterusnya.
43
Diagram StateChart Behaviors dan state dimiliki oleh obyek. Keadaan dari suatu obyek bergantung pada kegiatan dan keadaan yang berlaku pada saat itu. Diagram StateChart menunjukan kemungkinan dari keadaan obyek dan proses yang menyebabkan perubahan pada keadaannya.
44
Diagram Deployment dan Component
Untuk lebih jelas, contoh yang digunakan model diagram untuk login yang merupakan bagian dari online banking system. Logging in terdiri atas masukan Input social security number dan personal id number yang berlaku, lalu memutuskan kesahan dari informasi tersebut.
45
Logging in dapat dibagi menjadi empat tahapan proses, yaitu : - Getting SSN (masukkan ssn) - Getting PIN (masukkan PIN) - Validating (periksa kesahannya) - Rejecting (keluar) Gambar 8. Contoh Diagram StateChart ‘Sistem Perbankan secara Online’
46
Diagram Activity Pada dasarnya diagram Activity sering digunakan oleh flowchart. Diagram ini berhubungan dengan diagram Statechart. Diagram Statechart berfokus pada obyek yang dalam suatu proses (atau proses menjadi suatu obyek), diagram Activity berfokus pada aktifitas-aktifitas yang terjadi yang terkait dalam suatu proses tunggal. Jadi dengan kata lain, diagram ini menunjukkan bagaimana aktifitas-aktifitas tersebut bergantung satu sama lain.
47
Diagram Activity Sebagai contoh, perhatikan proses yang terjadi. “Pengambilan uang dari bank melalui atm.” Ada tiga aktifitas kelas (orang, dan lainnya) yang terkait, yaitu : Customer, ATM, and Bank. Proses berawal dari lingkaran start hitam pada bagian atas dan berakhir di pusat lingkaran stop hitam/putih pada bagian bawah.
48
Aktivitas digambarkan dalam bentuk kotak persegi
Aktivitas digambarkan dalam bentuk kotak persegi. Lihat gambar di bawah ini, agar lebih jelas : Gambar 9. Contoh Diagram Activity ‘Pengambilan Uang melalui ATM’
49
Diagram Deployment dan Component
Component adalah sebuah code module (kode-kode module). Diagram Component merupakan fisik sebenarnya dari diagram Class. Diagram Deployment menerangkan tentang konfigurasi fisik software dan hardware.
50
Gambar 10 menerangkan hubungan sekitar komponen software dan hardware yang berperan dalam ruang lingkup real estate. Gambar 10. Contoh Diagram Deployment ‘Sistem Real Estate’
51
Diagram Deployment dan Component
Fisik hardware berbentuk seperti node-node. Setiap komponen merupakan bagian dari node. Pada gambar komponen berbentuk dua kotak tersusun yang terletak di sebelah kiri atas.
52
NEXT 27 Juli Pertemuan 13-14 : Pengujian Software
1 Agustus : Presentasi Perancangan Software 3 Agustus : Presentasi Pengujian software 8 Agustus : UAS
Presentasi serupa
© 2024 SlidePlayer.info Inc.
All rights reserved.