Rekayasa perangkat lunak (rpl)

Slides:



Advertisements
Presentasi serupa
Catur Iswahyudi + Edhy Sutanta
Advertisements

KEBUTUHAN & SPESIFIKASI SOFTWARE
Bab 6 PERANCANGAN PERANGKAT LUNAK
UNIFIED MODELLING LANGUAGE
Perancangan Perangkat Lunak lanjutan Kuliah - 7
PEMODELAN ANALISIS Kuliah - 5
BPR – Tahap 1 (Persiapan)
Unified Modelling Language (UML)
BAB 2 METODE REKAYASA PERANGKAT LUNAK
13 KOMPONEN DIAGRAM UML & PROSES MODEL WATERFALL
Interaction Diagram.
Architecture dan design
PERANCANGAN PERANGKAT LUNAK
Analisis Model.
Analisis & Perancangan Sistem
Yang akan dipelajari Pengenalan UML Sejarah Singkat UML
Pertemuan 2 Konsep Aplikasi Berbasis Objek, UML dan Rational Rose
Analisa dan Desain dalam Penelitian
Rekayasa Perangkat Lunak Proses Rekayasa Perangkat Lunak
Keuntungan metodologi berorientasi objek.
UML (Unified Modelling Language)
OBJECTORIENTED ANALYSIS
Unified Modeling Language [UML]
UNIFIED MODELLING LANGUAGE
Rekayasa Perangkat Lunak UML (Unified Modelling Language)
Perancangan Sistem Dengan menggunakan UML
Visual Modelling Teguh Sutanto, S.Kom.,M.Kom.
Analisis Model.
REKAYASA PERANGKAT LUNAK
PERANCANGAN PERANGKAT LUNAK ( PL )
Object-Oriented Analysis (OOA)
Perancangan Sistem Dengan menggunakan UML
REKAYASA PERANGKAT LUNAK
ANALISIS DAN PERANCANGAN BERORIENTASI OBJEK
SE3414 RPL: Teknik Berorientasi Objek
Pemodelan objek.
PERANCANGAN SISTEM BERORIENTASI OBJEK DENGAN UML
Object oriented analyst and design
REKAYASA PERANGKAT LUNAK
KEBUTUHAN & SPESIFIKASI SOFTWARE
PEMODELAN SYSTEM BERORIENTASI OBYEK (UML)
PEMODELAN PROYEK (UML)
Pengenalan Analisa Desain
UNIFIED MODELLING LANGUAGE
Pengembangan Sistem Pertemuan 3.
Latihan Soal 1. Dalam membagun aplikasi tidak lepas dari SDLC(System Development Life Cycle), yang tidak masuk dalam kategori tahapan SDLC adalah a. Analisa.
DATA FLOW DIAGRAM.
FASE DESAIN.
Pengenalan UML.
REKAYASA PERANGKAT LUNAK
PEMODELAN OBJECT ORIENTED
REKAYASA PERANGKAT LUNAK Perancangan arsitektur perangkat lunak
Rekayasa perangkat lunak
Use Case Diagram.
KEBUTUHAN & SPESIFIKASI SOFTWARE
Perancangan Perangkat Lunak – Part 1
REKAYASA PERANGKAT LUNAK
PEMODELAN HASIL ANALISIS KEBUTUHAN FUNGSIONAL dengan menggunakan DATA FLOW DIAGRAM o l e h :
Analisis Model.
ANALISIS KEBUTUHAN PERANGKAT LUNAK
Unified Modelling Languange (UML)
Bab 5 activity diagram.
Perancangan Sistem Berorientasi Objek Dengan UML
PEMODELAN HASIL ANALISIS KEBUTUHAN FUNGSIONAL dengan menggunakan DATA FLOW DIAGRAM o l e h :
PERANCANGAN SISTEM Iwan Abadi, Ir., M.M. Analisis & Perancangan SI
Suplemen collaboration diagram component diagram
Pertemuan 6 Unified Modeling Language (UML)
KEBUTUHAN & SPESIFIKASI SOFTWARE
Pemrograman Terstruktur
PERANCANGAN SISTEM BERORIENTASI OBJEK DENGAN UML
Transcript presentasi:

Rekayasa perangkat lunak (rpl) SEMESTER PENDEK 2015/2016 Rekayasa perangkat lunak (rpl) Betha Nurina Sari,M.Kom

PERTEMUAN 9-10 Pemodelan Hasil Analisis Kebutuhan

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

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?

Use-Case Diagram

Berbasis Perilaku : State Diagram

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]

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

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

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

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)

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

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)

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

CONTOH RELASI ANTAR TABEL

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.

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.

Aliran Transaksi

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

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

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

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

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

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.

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

PERTEMUAN 11-12 UML (Unified Modeling Language)

UML mempunyai 9 diagram, yaitu; Diagram Use Case Diagram Class Diagram Package Diagram Object Diagram Sequence Diagram Collaboration Diagram StateChart Diagram Activity Diagram Deployment

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.

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

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.

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.

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

Gb.2 Contoh Diagram Class Transaksi Pembelian Barang

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.

Gambar di bawah ini mengenai model bisnis dengan pengelompokan kelas-kelas dalam bentuk paket-paket : Gb.3 Contoh Diagram Package

Diagram Object Ada jenis khusus dari diagram Class yaitu diagram Object. Kegunaannya untuk penjelasan yang sedikit dengan relasi yang sulit, khususnya relasi rekursif

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.

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.

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

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.

Gb.7 Contoh diagram collaboration “Pemesanan kamar hotel”

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.

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.

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.

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’

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.

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.

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’

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.

Gambar 10 menerangkan hubungan sekitar komponen software dan hardware yang berperan dalam ruang lingkup real estate. Gambar 10. Contoh Diagram Deployment ‘Sistem Real Estate’

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.

NEXT 27 Juli Pertemuan 13-14 : Pengujian Software 1 Agustus : Presentasi Perancangan Software 3 Agustus : Presentasi Pengujian software 8 Agustus : UAS