UNIFIED MODELLING

LANGUAGE
Yogiek Indra Kurniawan, S.T., M.T.
Rekayasa Perangkat Lunak
Program Studi Informatika
Universitas Jenderal Soedirman
Yogiek@unsoed.ac.id
Unified Modelling Languange (UML)
• Metode dalam pemodelan secara visual yang digunakan sebagai sarana
perancangan/desain system berorientasi objek.
• Suatu Bahasa standar visualisasi, perancangan, dan pendokumentasian system
(blueprint) sebuah software

Yogiek@unsoed.ac.id
Use Case Diagram
• Salah satu jenis diagram UML
• Menggambarkan hubungan interaksi antara system dan aktof
• Mendeskripsikan interaksi antara si pengguna dengan sistemnya.

Yogiek@unsoed.ac.id
Yogiek@unsoed.ac.id
Contoh Use Case Diagram

Yogiek@unsoed.ac.id
Scenario Use Case
• Menggambarkan proses yang terjadi pada setiap use case
• Bagian yang penting : nama usecase, actor, kondisi awal, output, proses

Yogiek@unsoed.ac.id
 Identifikasi
Nomor 1
Nama Skenario Login
Aktor Admin, Member, dan Dokter
Kondisi Awal Sistem menampilkan halaman login
Tujuan Dapat melakukan hak akses sepenuhnya
Skenario
Aksi Aktor Reaksi Sistem
1. Aktor melakukan login pada view

2. Aktor memasukkan email dan password

pada halaman login

3. Melakukan validasi kelengkapan data yang telah dimasukkan

4. Jika salah akan memunculkan error pada halaman login
5. Jika bener menjalankan proses Login pada Login Controller
6. Menjalankan proses validate pada Login Model
7. Melakukan validasi untuk mengecek kesamaan data yang telah dimasukkan actor

8. Jika sama aktor akan di arahkan ke Landing Page

9. Jika salah akan mengirimkan error menuju Login Controller
10. Memunculkan pesan error pada halaman login

Yogiek@unsoed.ac.id
Sequence
• Diagram yang menjelaskan interaksi objek berdasarkan urutan waktu.
• Dapat menggambarkan urutan atau tahapan yang harus dilakukan untuk dapat
menghasilkan sesuatu, seperti yang tertera pada Use Case diagram.

Yogiek@unsoed.ac.id
Contoh

Yogiek@unsoed.ac.id
Activity Diagram
• Diagram yang memodelkan berbagai proses yang terjadi pada system.
• Seperti Flowchart

Yogiek@unsoed.ac.id
Symbol

Yogiek@unsoed.ac.id
Contoh

Yogiek@unsoed.ac.id
Yogiek@unsoed.ac.id
Class Diagram
• Menggambarkan kelas/Objek apa saja yang ada di dalam system.

Yogiek@unsoed.ac.id
Symbol

Yogiek@unsoed.ac.id
Yogiek@unsoed.ac.id
Kardinalitas

Yogiek@unsoed.ac.id
Yogiek@unsoed.ac.id
TERIMA KASIH.
MARI DISKUSI.
DATA FLOW
DIAGRAM
YOGIEK INDRA KURNIAWAN
ANALISA DAN DESAIN SYSTEM
YOGIEK@UNSOED.AC.ID
UNIVERSITAS JENDERAL SOEDIRMAN
DATA FLOW DIAGRAM

• Data Flow Diagram (DFD) adalah alat pembuatan model yang memungkinkan profesional
sistem untuk menggambarkan sistem sebagai suatu jaringan proses fungsional yang
dihubungkan satu sama lain dengan alur data, baik secara manual maupun komputerisasi.
• DFD ini sering disebut juga dengan nama Bubble chart, Bubble diagram, model proses,
diagram alur kerja, Diagram Alur Data (DAD) atau model fungsi.
• DFD adalah alat pembuatan model yang memberikan penekanan hanya pada fungsi sistem.
• DFD ini merupakan alat perancangan sistem yang berorientasi pada alur data dengan
konsep dekomposisi
KOMPONEN DATA FLOW DIAGRAM

• Yourdan dan DeMarco

• Gene dan Serson

TERMINATOR / ENTITAS LUAR

• Terminator mewakili entitas eksternal yang berkomunikasi dengan sistem yang sedang
dikembangkan. Biasanya terminator dikenal dengan nama entitas luar (external entity).
• Terminator dapat berupa orang, sekelompok orang, organisasi, departemen di dalam
organisasi, atau perusahaan yang sama tetapi di luar kendali sistem yang sedang dibuat
modelnya.
• Komponen terminator ini perlu diberi nama sesuai dengan dunia luar yang berkomunikasi
dengan sistem yang sedang dibuat modelnya, dan biasanya menggunakan kata benda,
misalnya Bagian Penjualan, Dosen, Mahasiswa
• Hubungan yang ada antar terminator yang satu dengan yang lain tidak digambarkan pada
DFD.
JENIS TERMINATOR

• Terminator Sumber (source) : merupakan terminator yang menjadi sumber.

• Terminator Tujuan (sink) : merupakan terminator yang menjadi tujuan data / informasi
sistem.
PROSES

• Komponen proses menggambarkan bagian dari sistem yang mentransformasikan input

menjadi output.
• Proses diberi nama untuk menjelaskan proses/kegiatan apa yang sedang/akan
dilaksanakan.
• Pemberian nama proses dilakukan dengan menggunakan kata kerja transitif (kata kerja
yang membutuhkan obyek), seperti Menghitung Gaji, Mencetak KRS, Menghitung Jumlah
SKS.
KESALAHAN DALAM PROSES

• Proses mempunyai input tetapi tidak menghasilkan output. Kesalahan ini disebut dengan
black hole (lubang hitam), karena data masuk ke dalam proses dan lenyap tidak berbekas
seperti dimasukkan ke dalam lubang hitam (lihat proses 1).
• Proses menghasilkan output tetapi tidak pernah menerima input. Kesalahan ini disebut
dengan miracle (ajaib), karena ajaib dihasilkan output tanpa pernah menerima input (lihat
proses 2).
DATA STORE

• Suatu data store dihubungkan dengan alur data hanya pada komponen proses, tidak
dengan komponen DFD lainnya.
• Alur data dari data store yang berarti sebagai pembacaan data
• Alur data ke data store yang berarti sebagai pengupdatean data
ATURAN DALAM DFD (DFD LEVEL 1)

1. Terminator tidak berhubungan langsung dengan terminator.

2. Data store tidak berhubungan langsung dengan data store.
3. Terminator tidak berhubungan langsung dengan data store.
4. Harus ada arus masuk dan keluar dari data store.
5. Harus ada arus masuk dan keluar dari proses.
PAKET DATA
JENIS DFD

• Diagram Alur Data Fisik (DADF)

• Diagram Alur Data Logika (DADL)
PENGGAMBARAN DFD

• Identifikasi terlebih dahulu semua entitas luar yang terlibat di sistem.

• Identifikasi semua input dan output yang terlibat dengan entitas luar.
• Buat Diagram Konteks (diagram context) / Buat Diagram Level Zero
• Buat Diagram Level Satu
• DFD Level Dua, Tiga, …
DIAGRAM KONTEKS / DFD LEVEL 0

• Diagram ini adalah diagram level tertinggi dari DFD yang menggambarkan hubungan
sistem dengan lingkungan luarnya.Tentukan nama sistemnya., tentukan batasan sistemnya.
tentukan terminator apa saja yang ada dalam system,‰
tentukan apa yang diterima/diberikan terminator dari/ke sistem.
KAMUS DATA

• Katalog fakta tentang data dan kebutuhan-kebutuhan informasi dari suatu sistem
informasi
• Definisi dari sebuah data
KAMUS DATA

Simbol Uraian
= Terdiri dari, mendefinisikan, diuraikan menjadi, artinya
+ Dan
() Opsional (boleh ada atau boleh tidak ada)
{} Pengulangan
[] Memilih salah satu dari sejumlah alternatif, seleksi
** Komentar
@ Identifikasi atribut kunci
| Pemisah sejumlah alternatif pilihan antara simbol [ ]
CONTOH KAMUS DATA

• Dosen = @nip + nama

@nip = 1 {angka} 16
angka = [ 0-9 ]
• Nama = Gelar + Nama_awal + Nama_tengah + Nama_akhir .
Gelar = | Tuan | Nyonya | Nona | Doktor | Profesor
Nama_awal = karakter_valid
Nama_awal = karakter_valid
Nama_tengah = karakter_valid
Nama_akhir = karakter_valid
Karakter_valid = [ A-Z | a-z | 0-9 | ‘ | – | | ]
P-SPEC (PROCESS SPECIFICATION)

• Digunakan untuk memberikan rincian atas proses yang ada di dalam DFD
• P-spec memberikan gambaran detail tentang proses di dalam DFD
• Terdiri dari minimal nama proses, kode proses, input, output, dan
body/deskripsi/algoritma.
CONTOH P-SPEC

• Nama proses : login (1.0)

• Input : username dan password
• Output : user valid / non valid
• Deskripsi proses :
input username dan password
if username dan password ada di tabel user
then user valid dan masuk ke sistem
else
user non valid, beri warning dan kembali ke halaman login
THANK YOU
FLOWCHART
YOGIEK INDRA KURNIAWAN
ANALISA DAN DESAIN SYSTEM
YOGIEK@UNSOED.AC.ID
UNIVERSITAS JENDERAL SOEDIRMAN
 PEDOMAN PEMBUATAN FLOWCHART

• FLOWCHART DIGAMBARKAN DARI HALAMAN ATAS KE BAWAH DAN DARI KIRI KE KANAN.
• AKTIVITAS YANG DIGAMBARKAN HARUS DIDEFINISIKAN SECARA HATI-HATI DAN DEFINISI INI
HARUS DAPAT DIMENGERTI OLEH PEMBACANYA.
• KAPAN AKTIVITAS DIMULAI DAN BERAKHIR HARUS DITENTUKAN SECARA JELAS.
• SETIAP LANGKAH DARI AKTIVITAS HARUS DIURAIKAN DENGAN MENGGUNAKAN DESKRIPSI
KATA KERJA
 PEDOMAN PEMBUATAN FLOWCHART

• SETIAP LANGKAH DARI AKTIVITAS HARUS BERADA PADA URUTAN YANG BENAR.
• SIMBOL KONEKTOR HARUS DIGUNAKAN DAN PERCABANGANNYA DILETAKAN PADA HALAMAN
YANG TERPISAH
• GUNAKAN SIMBOL-SIMBOL FLOWCHART YANG STANDAR.
 SISTEM FLOW CART
SIMBOL – SIMBOL YANG DI PAKAI FLOW CART :

: pengolah / proses

: Input data dari kartu

: Input data dari keyboard / manual input

: Input / output ke / dari pita magnetic

: Input dari kartu plong

: Output kertas / printer / dokumen

: Disket ( input / output )

: File computer

: Hard disk
: Sambungan ke halaman berikutnya

: Masih dalam satu halaman

: Intruksi Percabangan

: Arus Informasi

: Hubungan komunikasi
: File storage off line

: Start / mulai proses

: Manual Operation
: Input / output

: Persiapan / nilai awal

: Pre-defined Process

: Display / tampilan dalam layar

 JENIS FLOWCHART

• FLOWCHART SISTEM (SYSTEM FLOWCHART)

• FLOWCHART PAPERWORK / FLOWCHART DOKUMEN (DOCUMENT FLOWCHART)
• FLOWCHART SKEMATIK (SCHEMATIC FLOWCHART)
• FLOWCHART PROGRAM (PROGRAM FLOWCHART)
• FLOWCHART PROSES (PROCESS FLOWCHART)
 FLOWCHART SYSTEM

• FLOWCHART SISTEM MERUPAKAN BAGAN YANG MENUNJUKKAN ALUR KERJA ATAU APA YANG
SEDANG DIKERJAKAN DI DALAM SISTEM SECARA KESELURUHAN DAN MENJELASKAN URUTAN
DARI PROSEDUR-PROSEDUR YANG ADA DI DALAM SISTEM.
FLOWCHART PAPERWORK / FLOWCHART DOKUMEN

• FLOWCHART PAPERWORK MENELUSURI ALUR DARI DATA YANG DITULIS MELALUI SISTEM.
FLOWCHART PAPERWORK SERING DISEBUT JUGA DENGAN FLOWCHART DOKUMEN.
• KEGUNAAN UTAMANYA ADALAH UNTUK MENELUSURI ALUR FORM DAN LAPORAN SISTEM DARI
SATU BAGIAN KE BAGIAN LAIN BAIK BAGAIMANA ALUR FORM DAN LAPORAN DIPROSES,
DICATAT DAN DISIMPAN.
 FLOWCHART SKEMATIK

• FLOWCHART SKEMATIK MIRIP DENGAN FLOWCHART SISTEM YANG MENGGAMBARKAN SUATU

SISTEM ATAU PROSEDUR.
• FLOWCHART SKEMATIK INI BUKAN HANYA MENGGUNAKAN SIMBOL-SIMBOL FLOWCHART
STANDAR, TETAPI JUGA MENGGUNAKAN GAMBAR-GAMBAR KOMPUTER, PERIPHERAL, FORM-
FORM ATAU PERALATAN LAIN YANG DIGUNAKAN DALAM SISTEM.
• FLOWCHART SKEMATIK DIGUNAKAN SEBAGAI ALAT KOMUNIKASI ANTARA ANALIS SISTEM
DENGAN SESEORANG YANG TIDAK FAMILIAR DENGAN SIMBOL-SIMBOL FLOWCHART YANG
KONVENSIONAL.
 FLOWCHART PROGRAM

• FLOWCHART PROGRAM MERUPAKAN KETERANGAN YANG LEBIH RINCI TENTANG BAGAIMANA

SETIAP LANGKAH PROGRAM ATAU PROSEDUR SESUNGGUHNYA DILAKSANAKAN.
• FLOWCHART INI MENUNJUKKAN SETIAP LANGKAH PROGRAM ATAU PROSEDUR DALAM
URUTAN YANG TEPAT SAAT TERJADI.
• PROGRAMMER MENGGUNAKAN FLOWCHART PROGRAM UNTUK MENGGAMBARKAN URUTAN
INSTRUKSI DARI PROGRAM KOMPUTER.
 FLOWCHART PROCESS

• FLOWCHART PROSES MERUPAKAN TEKNIK PENGGAMBARAN REKAYASA INDUSTRIAL YANG

MEMECAH DAN MENGANALISIS LANGKAH-LANGKAH SELANJUTNYA DALAM SUATU PROSEDUR
ATAU SISTEM
THANK YOU
IMPLEMENTATION
YOGIEK INDRA KURNIAWAN
REKAYASA PERANGKAT LUNAK
UNIVERSITAS JENDERAL SOEDIRMAN
TUJUAN PEMBELAJARAN

• Mahasiswa mampu menjelaskan prinsip-prinsip implementasi perangkat lunak :

1. Makna dan tujuan implementasi
2. Perencanaan implementasi
3. Hal penting dalam implementasi
4. Persiapan dokumentasi
5. Installasi / konversi sistem baru dari sistem lama
6. Evaluasi sistem baru
7. Lingkungan pemrograman
8. Programming Style
REFERENSI

• Pressman, RS., 2008, Software Engineering: A Practitioner’s Approach, New

York: McGraw-Hill
• Sommerville, I, 2007, Software Engineering, Addsion Wesley
 WATERFALL MODEL

Planning

(Requirement)
Analysis
Design

Implementation

Integration and
Testing

Operation and
Maintenance
PROTOTYPE MODEL
RAPID APPLICATION DEVELOPMENT
EVOLUTIONARY MODEL (INCREMENTAL)
EVOLUTIONARY MODEL SPIRAL
AGILE METHODOLOGY
REUSE BASED MODEL
MAKNA DAN TUJUAN IMPLEMENTASI

 Merupakan tahap besar di akhir produksi PL

 Tahap ini merupakan proses pembuatan kode program berdasarkan
platform dan kesepakatan dengan customer.
 Merupakan tahap transformasi dari hasil desain ke dalam program
yang dapat dijalankan pada komputer yang akan digunakan di
dalam sistem.
 Baik buruknya implementasi sangat tergantung pada baik buruknya
hasil final dari tahap desain
 Melibatkan pengintegrasian semua komponen rancangan sistem
termasuk PL dan konversi ke sistem operasi.
PROSES IMPLEMENTASI

 Perencanaan
 Eksekusi
RENCANA IMPLEMENTASI

 Merupakan formulasi rinci dan representasi grafik mengenai cara

pencapaian implementasi sistem yang akan dilaksanakan

 Tim implementasi yg terlibat:

• Manajer dan beberapa staff
• Profesional sistem yang merancang sistem
• Perwakilan Vendor
• Pemakai Primer
• programmer
• Teknisi
CONTOH RENCANA IMPLEMENTASI
HAL PENTING DALAM IMPLEMENTASI
1. Persiapan Tempat
 Diperlukan dokumentasi, yang perlu dipersiapkan : (
• Ruang, listrik , pengujian burn in / simulasi pada vendor)
2. Pelatihan Personil
3. Cakupan Pelatihan
4. Program Pelatihan
5. Teknik dan Alat Bantu Pelatihan
6. Software untuk pelatihan interaktif
7. Persiapan / pembuatan dokumen
8. Konversi File & Sistem
DOKUMENTASI
• Tujuan dokumentasi:
1. Pelatihan
2. Penginstruksian
3. Pengkomunikasian
4. Penetapan standar kinerja
5. Pemeliharaan sistem
6. Referensi historis
• Dokumentasi yang perlu dipersiapkan :
1. Dokumen pemakai
2. Dokumen Sistem
3. Dokumen Perangkat lunak
4. Dokumen operasi
BIAYA IMPLEMENTASI
KONVERSI SISTEM LAMA KE SISTEM BARU

• Konversi Langsung
Sistem yang lama langsung digantikan dengan sistem yang baru
• Konversi Paralel
Sistem lama masih dijalankan sambil menjalankan sistem baru
• Konversi Phase In
Sistem lama digantikan secara berangsur-angsur sedikit demi sedikit
• Konversi Pilot
Sistem baru dilakukan secara segmentasi bagian per bagian
METODE KONVERSI LANGSUNG

• Konversi ini baik dilakukan jika :

 Sistem baru tidak menggantikan sistem lama
 Sistem lama sepenuhnya tidak bernilai
 Sistem baru bersifat kecil/sederhana
 Rancangan sistem baru sangat berbeda dari sistem lama
METODE KONVERSI PARALEL

• Memberikan proteksi yang tinggi dari kegagalan sistem baru

• Biaya yang dibutuhkan cukup besar karena kedua sistem harus berjalan
bersama-sama
METODE KONVERSI PHASE-IN

 Sistem baru di implementasikan sedikit demi sedikit untuk

menggantikan sistem lama
 Sistem harus disegmentasi
 Perlu biaya tambahan utk membangun interface temporer dg
sistem lama
 Proses implementasi membutuhkan waktu yang panjang
METODE KONVERSI PILOT

 Perlunya segmentasi organisasi

 Resiko lebih rendah dibandingkan metode konversi langsung
 Biaya lebih rendah dibanding metode paralel
 Cocok digunakan apabila adanya perubahan prosedur,
HardWare, dan SoftWare
KONVERSI FILE DATA

 Keberhasilan konversi sistem sangat tergantung pada seberapa

jauh profesional sistem menyiapkan konversi file data yang
diperlukan di dalam sistem baru

 Konversi/Modifikasi Meliputi:
 Format file
 Isi file
 Media penyimpanan
METODE DASAR KONVERSI

1. Konversi File Total

• Dapat digunakan pada ke-4 metode konversi sistem
2. Konversi File Gradual
 Lebih banyak digunakan utk metode paralel dan phase-in
 Selama konversi file perlu diperhatikan prosedur kendali untuk
memastikan integrasi data
 Prosedur kendali untuk masing2 file berbeda
 Suatu transaksi diterima dan dimasukkan ke dalam sistem
 Program mencari file master baru untuk record yang akan
diupdate oleh transaksi tersebut. jika record tersebut ada maka
pengupdatean record selesai
KLASIFIKASI FILE

 File Master
 File Transaksi
 File Index
 File Tabel
 File Backup
TAHAPAN IMPLEMENTASI

• Struktur dekomposisi, struktur data, dan identitas

dipilih dan
dikerjakan sampai prosedur desain mudah untuk ditata ulang dalam
sebuah implementasi
• Level abstraksi pada desain, misal class, modul, algoritma, struktur
data, dan tipe data harus diwujudkan dalam implementasi
• Antarmuka antar komponen sistem perangkat lunak harus diwujudkan
secara jelas pada tahap implementasi
• Kode program tersebut harus dapat dicek konsistensinya pada setiap
objek dan operasinya secara langsung menggunakan kompilator
KRITERIA LINGKUNGAN PEMROGRAMAN

1. Modularity (Modularitas)
2. Dokumentasi Nilai Pada Bahasa Pemrograman
3. Struktur Data Dalam Bahasa Pemrograman
4. Struktur Aliran Pengendali
5. Efisiensi
6. Integritas
7. Portability ( multiplatform )
PROGRAMMING STYLE

• Menulis sebuah program adalah seni dan merupakan proses yang

kreatif.
• Gaya pemrograman pada programmer mempengaruhi tingkat
kemudahan pembacaan program yang dibuatnya.
• Gaya pemrograman yang baik sangat didukung dari tahap desain dan
perencanaan implementasi yang baik.
TERIMA KASIH
 Pengujian Perangkat Lunak

Yogiek Indra Kurniawan

Rekayasa Perangkat Lunak
Informatika, Universitas Jenderal Soedirman
yogiek@unsoed.ac.id
 Tujuan Pembelajaran
• Mahasiswa mampu menjelaskan dan menerapkan
pengujian perangkat lunak
 Topik Pembelajaran
• Pengujian Perangkat Lunak
• Pengujian unit
• Pengujian integrasi
• Blackbox Testing
• Whitebox Testing
• User Acceptance Testing
 Referensi
• Roger S. Pressman. “Software Engineering : A Practitioner’s
Approach – Seventh Edition”, McGraw-Hill, New York. 2010.
• Ian Sommerville. “Software Engineering, 6th edition”. 2001.
• Software Engineering Body of Knowledge (SWEBOK). 2004
• Computing and Information Science. Software Engineering Slides.
Cornell University. 2009
• Edward Yourdon, Modern Structured Analysis, 1st edition, 1988
• Kendall, System Analysis and Design, 8th edition, 2013
 Waterfall methodology
Planning

(Requirement)
Analysis
Design

Implementation

Testing

Maintenance
Prototyping Methodology
 Testing Strategy

System engineering

Analysis modeling
Design modeling

Code generation Unit test

Integration test

System test
 Terminologi
•● Reliability: Ukuran kesuksesan yang digunakan untuk mengukur
kesesuaian antara perilaku yang terjadi dengan perilaku yang
diinginkan.
•● Failure: Penyimpangan perilaku yang diamati dengan perilaku yang
kehendaki.
•● Error: Keadaan di mana sistem berada pada suatu keadaan, jika
sistem terus melakukan proses akan dapat mengakibatkan terjadinya
failure. Manifestasi dari fault
•● Fault (bug/defect) penyebab (mekanis atau algoritmis) dari suatu
error. Kesalahan desain atau koding ..
Terminologi - Error
Algorithmic Fault
Mechanical Fault
 Kehandalan Perangkat Lunak
● Upaya meningkatkan ....
– Fault Avoidance
Pencegahan/Penghindaran
– Fault Detection
Deteksi/Penemuan
– Fault Tolerance
Dapat diterima
Kehandalan Perangkat Lunak Cont.
 Definisi
● Pengujian perangkat lunak (bahasa Inggris: software
testing) merupakan suatu investigasi yang dilakukan
untuk mendapatkan informasi mengenai kualitas dari
produk atau layanan yang sedang diuji (under test).
● Pengujian perangkat lunak memberikan pandangan
mengenai perangkat lunak secara obyektif dan
independen.
– bermanfaat dalam operasional bisnis untuk
memahami tingkat risiko pada implementasinya.
Karakteristik Pengujian Perangkat Lunak
●
Operable
– Bekerja dengan baik (kualitasnya baik), mudah untuk di
testing
●
Observable
– Keluaran yang salah dengan mudah
diidentifikasi; kesalahan internal secara
otomatis terdeteksi
●
Controllable
– Bagian dan variabel perangkat lunak dapat
dikontrol langsung oleh tester
●
Decomposable
– Perangkat lunak ini dibangun dari modul
independen yang dapat diuji secara
9
independen
Karakteristik Pengujian Perangkat Lunak Cont.
●
Simple
– Program ini harus menunjukkan kesederhanaan
fungsional, struktural, dan kode
●
Stable
– Perubahan yang terjadi pada perangkat
lunak selama pengujian jarang dan tidak
membatalkan tes yang ada
●
Understandable
– Desain arsitektur dapat dipahami dengan
baik; dokumentasi tersedia dan terorganisir
 Tujuan Pengujian
●
Menemukan kesalahan (fault) sebanyak
mungkin dari perangkat lunak yang diuji
● Membuat perangkat lunak yang diuji, setelah
perbaikan dilakukan, menjadi perangkat lunak
yang berkualitas
●
Melakukan pengujian secara efektif dan
efisien
●
Mengumpulkan kesalahan yang terjadi dan
menggunakannya untuk tindakan preventif
Pengujian Perangkat Lunak
Pengujian Perangkat Lunak - Pelaku
 Strategi Pengujian
● Big Bang
Pengujian perangkat lunak secara
keseluruhan, setelah seluruh komponen
perangkat lunak selesai dibuat
●
Incremental
Pengujian secara bertahap
Incremental
Metode Pengujian Perangkat Lunak
● Black-box testing
– Mengetahui fungsi tertentu suatu produk yang telah dirancang
untuk dijalankan, menguji untuk melihat apakah
fungsi sepenuhnya bisa beroperasi dan bebas dari error.
– Test dilakukan termasuk interface perangkat lunak
– Tidak peduli dengan struktur logis internal dari perangkat lunak
● White-box testing
– Mengetahui kerja internal dari suatu produk, tes yang semua
operasi internal dilakukan sesuai dengan spesifikasi dan semua
komponen internal telah dieksekusi
– Melibatkan test yang berkonsentrasi pada pemeriksaan
detail prosedural
– Logical patch perangkat lunak diuji
– Uji kasus latihan dari kondisi dan loop tertentu
 Functional (Black Box)
● Functional (Black Box)
– Fokus pada output yang dihasilkan dengan
memberikan input dan kondisi eksekusi
– Membandingkan kesesuaian output dengan
spesifikasi kebutuhan fungsional
 Functional (Black Box) Cont.

● Berfokus pada persyaratan fungsional dan domain informasi

dari perangkat lunak
● Digunakan selama tahap akhir dari pengujian setelah white
box testing telah dilakukan
● Tester mengidentifikasi serangkaian kondisi masukan yang
sepenuhnya akan melaksanakan semua persyaratan
fungsional untuk program
● Memenuhi uji kasus berikut:
– Mengurangi, dengan jumlah lebih besar dari satu, jumlah
uji kasus tambahan harus dirancang untuk mencapai
pengujian yang wajar
– Mampu memberitahukan tentang keberadaan atau tidak
adanya kelas kesalahan, yang terkait hanya dengan
tugas tertentu.
Pertanyaan yang Bisa di Jawab oleh Black-box Testing

●
Bagaimana validitas fungsional diuji?
● Bagaimana perilaku dan performa sistem diuji?
● Apa kelas input akan membuat uji kasus yang
baik?
●
Apakah sistem sangat sensitif terhadap nilai
input tertentu?
● Data dan volume data tingkat apa yang
dapat ditolerir sistem?
● Efek apa yang akan dimiliki terhadap kombinasi
spesifik dari data yang ada pada sistem operasi?
 Structural (White Box)
●
Menguji dengan
memperhatikan
mekanisme internal
sistem
●
Menguji untuk
memastikan operasi
internal berjalan sesuai
spesifikasi
●
Semua komponen diuji
 White-box Testing

●
Menggunakan bagian struktur kontrol desain tingkat
komponen untuk memperoleh desain uji kasus
●
Uji kasus
– Menjamin bahwa semua jalur independen dalam
sebuah modul telah dieksekusi minimal sekali
– Latihan semua logical decisions pada sisi true dan false
– Jalankan semua loop pada batas mereka dan dalam
batas-batas operasional mereka
– Latihan struktur data internal untuk
memastikan validitasnya

“Mengintai Bug di sudut dan berkumpul dibatasnya”

Aktifitas Pengujian Perangkat Lunak
Aktifitas Pengujian Perangkat Lunak Cont.
Unit Testing
 Point
● Tujuan :
– Mengetahui pengujian unit perangkat lunak (Unit
Testing).
– Mengetahui jenis-jenis unit testing.

● Outline
– Pengertian Unit Testing
– Pengujian Statis
– Pengujian White Box
Aktifitas Pengujian
 Unit Testing
● Pengujian unit (komponen) secara terisolir menguji di
luar program yang menggunakan unit ini.
• Memeriksa apakah suatu individual program unit
(subprogram, object class, package, module)
memiliki perilaku yang benar.
 Unit Testing Cont.
TIPE PENGUJIAN
● Pengujian Statis (Static Testing)
– Pengujian terhadap satu unit tanpa melakukan
eksekusi terhadap unit tersebut
● Pengujian Dinamis (Dynamic Testing)
– Pengujian dengan mengeksekusi unit dengan
menggunakan data uji.
– White Box dan Black Box
 Static Testing Cont.
TIPE PENGUJIAN
– Code Walktrough
– Code Inspection
 Static Testing Cont.
● Code Walktrough
– Kode program dan dokumentasi di-review oleh tim
– Fokus ada pada kode program
– Informal
– Dipimpin oleh programmer
 Static Testing Cont.
● Code Inspection
– Kode program dan dokumentasi di-review oleh tim dengan
suatu daftar rujukan
● Definisi dan struktur data

● Algoritma

●
Interface antar komponen
●
Prakiraan unjuk kerja program penggunaan memori,
kecepatan pengolahan
– Fokus ada pada kode program
– Informal
– Dipimpin oleh moderator BUKAN programmer
 Static Testing Cont.
● Langkah-langkah Code Inspection:
– Tim reviewer bertemu untuk melakukan review
awal → overview kode dan tujuan
– Masing-masing anggota tim bekerja secara
individu melakukan inspeksi program dan
dokumentasi → mencatat fault yang ditemukan
– Tim reviewer bertemu untuk melakukan diskusi
terhadap temuan masing-masing
INTEGRATION
dan SYSTEM
TESTING
 Point
● Tujuan
– Mengetahui pengujian perangkat lunak
● Integration

● System.

– Mengetahui jenis-jenis System testing

● Outline
– Pengujian Integrasi
– Pengujian Sistem
● Functional Testing
● Performance Testing
● Acceptance Testing
● Installation Testing
Aktifitas Pengujian Sistem
 INTEGRATED TESTING
● Fokus deteksi fault pada sekelompok komponen/unit,
seperti fungsi, kelas, packages.
● Dua atau lebih komponen diintegrasikan dan diuji.
● Jika tidak ada, maka komponen lain ditambahkan
dan diuji.
● Pendekatan:
– Bottom-up testing
– Top-down testing
– Sandwich Testing
 BOTTOM UP INTEGRATION
•● Sub sistem pada lapisan terbawah dalam hirarki
pemanggilan diuji secara indivual.
•● Kemudian sub sistem yang diuji adalah sub sistem yang
memanggil sub sistem yang diuji sebelumnya.
•● Dilakukan secara berulang sampai semua sub sistem di uji.
• Butuh Test Driver:
●
• –Rutin yang memanggil sub sistem yang diuji dan
memberikan test case
BOTTOM UP INTEGRATION Cont.
 TOP DOWN INTEGRATION
● Munguji lapisan atas atau sub sistem pemanggil
terlebih dahulu.
● Mengkombinasikan semua sub sistem yang dipanggil
oleh sub sistem yang telah diuji dan melakukan
pengujian terhadap sub sistem yang hasil kombinasi
tadi.
● Dilakukan secara berulang sampai semua sub sistem
di uji.
● Butuh Test stub :
– Program atau fungsi yang mensimulasikan simulates
aktivitas sub sistem yang ‘hilang’ dengan merespons
panggilan sub sistem pemanggilan dan mengembalikan
data simulasi.
TOP DOWN INTEGRATION Cont.
 SANDWICH TESTING
● Kombinasi pendekatan top-down strategy dan bottom-up.
● Sistem dipandang memiliki 3 lapis.
– Lapis target
– Lapis di atas target
– Lapis di bawah target
● Bagaimana menentukan lapisan target jika ada lebih 3
lapisan ?
– Heuristic: mencoba meminimalisir jumlah stub dan
drivers
SANDWICH TESTING Cont.
MODIFIED SANDWICH TESTING
● Test secara paralel:
– Lapisan tengah (middle layer) dengan driver dan
stub
– Top layer dengan stub
– Bottom layer dengan driver
● Test secara paralel:
– Top layer mengakses middle layer (top layer
menggantikan driver)
– Bottom diakses oleh middle layer (bottom layer
menggantikan stub)
MODIFIED SANDWICH TESTING
Cont.
LANGKAH INTEGRATION TESTING
 SYSTEM TESTING
•● Dilakukan setelah komponen-komponen
diintegrasikan.
•● Menjamin bahwa sistem yang lengkap sesuai
dengan kebutuhan fungsional dan non fungsional
sistem.
•● Pada tahap ini fault yang terjadi pada komponen
telah teridentifikasi dan dikoreksi.
 SYSTEM TESTING Cont.
● Functional Testing
● Performance Testing
● Acceptance Testing
● Installation Testing
 FUNCTIONAL TESTING
● requirements testing → menguji fungsionalitas
sistem.
● Pada esensinya sama dengan pengujian Blackbox
● Test cases dirancang dari dokumen analisis
kebutuhan (mis. user manual) dan berfokus pada
kebutuhan dan fungsi utama (mis. Use Cases)
● Pengujian dilakukan dengan memiliki test yang
relevan pada pengguna dan memiliki peluang yang
besar untuk menemukan failure.
 PERFORMANCE TESTING
•● Menemukan perbedaan antara goal (kebutuhan
non fungsional) yang ditentukan pada saat
pengembangan sistem dengan yang
diimplementasikan dalam sistem.
 PERFORMANCE TESTING Cont.
● Jenis test:
– Stress testing – menguji apakah sistem dapat
merespons banyak request yang datang secara
bersamaan.
– Volume testing – menguji sistem dengan
memberi data uji yang sangat besar/banyak.
– Security testing – menguji keamanan sistem
(menemukan security faults). Menggunakan
hacker untuk menguji sistem.
 PERFORMANCE TESTING Cont.
● Jenis test:
– Timing testing – mengevaluasi waktu tanggap
(response times) dan waktu untuk melakukan
sebuah fungsi
– Environmental test – menguji toleransi terhadap
lingkungan seperti panas, kelembaban, gerak
– Quality testing – pengujian keandalan, maintain-
ability dan availabilitas sistem
– Recovery testing – pengujian terhadap
tanggapan sistem terhadap adanya kesalahan
atau ketiadaan data.
 ACCEPTANCE TESTING Cont.
● Tujuan : menunjukkan bahwa bahwa sistem sudah siap
untuk pemakaian operasional.
● Pilihan test dibuat oleh client/sponsor
● Banyak test dapat diambil dari integration testing
● Dilakukan oleh client, bukan developer.
● Kebanyakan bug dalam perangkat lunak biasanya
ditemukan oleh client setelah sistem digunakan, bukan
oleh developer atau testers → test tambahan (Pilot Test
atau Field Test)
 PILOT TESTING
● Alpha test:
– Client menggunakan perangkat lunak di tempat
pengembang (development environment).
– Perangkat lunak digunakan dalam setting terkendali,
pengembang selalu siap untuk memperbaiki kesalahan
yang terjadi.
● Beta test:
– Dilakukan tempat pengguna(lingkungan yang sebenarnya).
– Pengembang tidak ada
– Perangkat lunak digunakan dalam lingkungan yang
sebenarnya (target environment).
 INSTALLATION TESTING
•● Sistem di install pada target environment dan
dievalusi.
•● Mengulangi test cases yang dieksekusi selama
functional dan performance testing dalam target
environment.
•● Beberapa kebutuhan mungkin tidak bisa diuji dalam
development environment sehingga perlu dibuat test
cases yang baru.
Ada Pertanyaan?
Terima Kasih
SOFTWARE DEVELOPMENT
LIFE CYCLE
Yogiek Indra Kurniawan, S.T., M.T.
Rekayasa Perangkat Lunak
Program Studi Informatika
Universitas Jenderal Soedirman
Yogiek@unsoed.ac.id
SDLC
• SDLC adalah proses untuk membangun sebuah software.
• SDLC terdiri dari rencana terperinci yang menjelaskan bagaimana
mengembangkan, memelihara, mengganti dan mengubah atau meningkatkan
perangkat lunak tertentu.
• Siklus ini mendefinisikan metodologi yang digunakan untuk meningkatkan
kualitas perangkat lunak dan proses pengembangan software secara keseluruhan.

Yogiek@unsoed.ac.id
Fungsi SDLC
• Sebagai sarana komunikasi antara tim pengembang dengan pemegang
kepentingan.
• Membagi peranan dan tanggung jawab yang jelas antara pengembang, desainer,
analis bisnis, dan manajer proyek.
• Memberikan gambaran input dan output yang jelas dari satu tahap menuju tahap
selanjutnya.

Yogiek@unsoed.ac.id
SDLC
Planning

Requirement
Analysis

Design

Implementation

Integration and
Testing
Operation and
Maintenance
Yogiek@unsoed.ac.id
Metodologi Pengembangan Software
• Metodologi pengembangan perangkat lunak atau metodologi pengembangan
sistem adalah suatu kerangka kerja yang digunakan untuk menstrukturkan,
merencanakan, dan mengendalikan proses pengembangan suatu sistem
informasi.
• Metode Waterfall
• Metode Prototype
• Metode RAD
• Metode Agile
• Metode Scrum
• dll

Yogiek@unsoed.ac.id
Waterfall
• Model yang menekankan pada fase yang berurutan dan sistematis.
• Dianalogikan seperti air terjun yang mana setiap proses dikerjakan secara
berurutan tanpa mendahului proses lainnya

Yogiek@unsoed.ac.id
Prototype
• Merupakan metode yang berawal dari komunikasi dengan client untuk
mengidentifikasi kebutuhan.
• Setelah kebutuhan diketahui maka prototype dibuat.
• Client akan mengevaluasi dan memberikan feedbacknya terhadap prototype.
• Dari feedback yang diterima, prototype akan mengalami perubahan-perubahan
hingga sesuai dengan permintaan dan kebutuhan client.

Yogiek@unsoed.ac.id
Rapid Application Development
• Rapid application development adalah metode yang berfokus pada
pengembangan aplikasi secara cepat, melalui pengulangan dan feedback
berulang-ulang.

Yogiek@unsoed.ac.id
Incremental
• Model pengembangan sistem pada software engineering berdasarkan
requirement software yang dipecah menjadi beberapa fungsi atau bagian
sehingga model pengembangannya secara bertahap

Yogiek@unsoed.ac.id
Spiral
• Model proses software evolusioner yang merangkai sifat iteratif dari prototipe
dengan cara kontrol dan aspek sistematis dari model sekuensial linier

Yogiek@unsoed.ac.id
Extreme Programming
• Model yang menyederhanakan berbagai tahapan dalam proses pengembangan
tersebut sehingga menjadi lebih adaptif dan fleksibel.

Yogiek@unsoed.ac.id
Agile
• Model development jangka pendek yang memerlukan adaptasi cepat dan
pengembangan terhadap perubahan dalam bentuk apapun

Yogiek@unsoed.ac.id
Scrum

Yogiek@unsoed.ac.id
Scrum
• Merupakan metode pengembangan agile yang meliputi aktivitas framework:
requirements, analysis, design, evolution, dan delivery.
• Aliran proses scrum berawal dari backlog.
• Backlog merupakan daftar kebutuhan atau fitur projek yang diprioritaskan. Item –
item dapat ditambahkan kedalam backlog sewaktu – waktu. Backlog yang diberi
prioritas akan dilakukan sprint. Sprints adalah unit kerja yang diperlukan untuk
mencapai kebutuhan yang didefinisikan di dalam backlog yang harus disesuaikan
dengan jangka waktu yang telah ditentukan sebelumnya (biasanya 30 hari). Setiap
hari, tim scrum akan mengadakan meeting selama 15 menit untuk mengetahui
progress dan kendala – kendala yang dialami. Setiap fungsi yang sudah
diimplementasikan (sudah melakukan sprint) akan didemonstrasikan dan dinilai
oleh client.

Yogiek@unsoed.ac.id
TERIMA KASIH.
MARI DISKUSI.
UNIFIED MODELLING
LANGUAGE
YOGIEK INDRA KURNIAWAN
ANALISA DAN DESAIN SYSTEM
YOGIEK@UNSOED.AC.ID
UNIVERSITAS JENDERAL SOEDIRMAN
2 BAHASAN

• UML
• Things
• Relationship
• Diagram
• Architecture View
• Use Case View
• Design View
• Process View
• Implementation View
• Deployment View
3 UML

• UML adalah bahasa graphical untuk visualisasi, spesifikasi, konstruksi dan

dokumentasi artifact system software [Booch].
• Spesifikasi: menunjukkan spesifikasi dari semua keputusan penting
analisis, desain dan implementasi
• Konstruksi: Forward Engineering & Reverse Engineering
• Dokumentasi: Project Planning, Release management
4 BLOCK UML

• Things
• Relationship
• Diagram
BLOCK UML – STRUCTURAL THINGS
5

1. Class

2. Interface
BLOCK UML - STRUCTURAL THINGS
6

3. Collaboration

4. Use-case
BLOCK UML - STRUCTURAL THINGS
7

5. Active Class

6. Component
8 BLOCK UML - STRUCTURAL THINGS

7. Node

WebServer
BLOCK UML - BEHAVIOURAL THINGS
9
• Interaction : perilaku dari sekumpulan object yang terdiri dari sekumpulan pertukaran pesan
dalam sebuah context utama untuk menyelesaikan sebuah tujuan khusus

display

• State Machine : perilaku yang menentukan urutan state-state sebuah object atau
sebuah interaksi yang terjadi selama masa hidupnya dalam merespon event

Idle Waiting
BLOCK UML - RELATIONSHIP
10

• Dependency
Panah dan label sifatnya optional

• Association

Aggregation
BLOCK UML - RELATIONSHIP
11

• Generalization

• Realization
12 POLYMORPHISME

• Polymorphisme adalah kemampuan untuk menyembunyikan implementasi-implementasi yang

berbeda didalam sebuah interface tunggal.
13 CONTOH POLYMORPHISME
INTERFACE
14

• Interface adalah pewujudan dari polymorphisme

15 REPRESENTASI INTERFACE DALAM UML
PACKAGE
16

• Package adalahmekanisme untuk menyusun elemen-elemen

menjadi kelompok-kelompok.
SUBSYSTEM
17

• Subsystem adalah kombinasi dari package dan class

• Subsystem merealisasikan satu atau lebih interface, dimana interface sebagai
pendefinisi perilakunya.
COMPONENT
18
• Component adalah bagian system yang dapat di-replace dan hampir independent. Component ini melaksanakan
fungsi yang jelas dalam suatu arsitektur.
• Sebuah component bisa berupa:
• Sebuah component source code
• Sebuah component run time
• Sebuah component executable
SUBSYSTEM DAN COMPONENT
19

• Component adalah realisasi phisic dari sebuah abstraksi dalam desain

• Subsystem dapat digunakan untuk merepresentasikan component dalam
sebuah desain
ASSOCIATION
20
• Association adalah hubungan semantic antara dua atau lebih classifier yang menetapkan hubungan antar
instance
• Association adalah hubungan structural yang menetapkan bahwa suatu object terhubung dengan object
lain
MULTIPLICITY
21
• Multiplicity adalah jumlah instance dari sebuh class yang berhubungan dengan satu instance class lain
• Untuk masing-masing association , ada dua keputusan multiplicity yang harus dibuat.
Contoh:
• Untuk masing-masing instance professor, ada beberapa course yang bisa ditawarkan
• Untuk masing-masing instance penawaran course, mungkin ada nol atau satu professor sebagai pengajarnya
22 PENANDA MULTIPLICITY
AGGREGATION
23

• Sebuah aggregation adalah bentuk khusus association yang memodelkan hubungan

whole-part antara sebuah aggregation(aggregation) dengan bagiannya.
RELATIONSHIP : DEPENDENCY
24

• Dependency adalah hubungan antara dua elemen dimana jika sebuah elemen
mengalami perubahan akan menyebabkan perubahan pada elemen yang lain
25 GENERALIZATION

• Generalization adalah hubungan diantara class-class dimana suatu class membagi struktur
dan atau behaviour dengan class yang lain
• Mendefinisikan hirarki abstraksi dimana sebuah subclass mewarisi sifat dari satu atau lebih
superclass → single inheritance, multiple inheritance
26 CONTOH SINGLE INHERITANCE
27 CONTOH MULTIPLE INHERITANCE
28 HAL-HAL YANG DIWARISKAN

• Sebuah subclass mewarisi atribut,operation dan relationship superclassnya.

• Sebuah subclass bisa :
• Menambah atribut, operation dan relationship
• Mendefinisikan ulang operation-operation
• Atribut, operation, dan relationship umum diperlihatkan pada level tertinggi didalam
hirarki
REALIZATION
29

• Sebuah classifier bertugas sesuai dengan perjanjian yang disetujui classifier lain.
• Realization dapat ditemui antara interface dan classifier yang merealisasikannya.
STEREOTYPE
30

• Stereotype mendefinisikan elemen model baru dalam model

elemen yang lain.
31 BLOCK UML - DIAGRAM

• Diagram adalah representasi graphic dari sekumpulan elemen. Direpresentasikan oleh graph yang
terhubung dimana vertices merupakan thing sedangkan arcs adalah behaviour
• Diagram yang umum :
• Use case Diagram
• Sequence Diagram; Collaboration Diagram
• Class Diagram; Object Diagram
• Statechart Diagram
• Activity Diagram
• Component Diagram
• Deployment Diagram
32 BLOCK UML - DIAGRAM

• Use case diagram

Request Course Roster

Professor
Student
Set Course Offerings
Register for Courses

Billing System Maintain Curriculum

Registrar
33 BLOCK UML - DIAGRAM

• Relationship uses dan extend dalam use case diagram

<<uses>>
<<extends>>
Register for courses

<<uses>>
Register for Logon validation
Distance Learning courses

Maintain curriculum
34 BLOCK UML - DIAGRAM

• Use Case Realizations

35 BLOCK UML - DIAGRAM

• Use case Diagram

• Sequence Diagram; Collaboration Diagram

• Class Diagram; Object Diagram

• Statechart Diagram
• Activity Diagram

• Component Diagram
• Deployment Diagram
36 BLOCK UML - DIAGRAM

• Sequence Diagram

: Student registration registration math 101 math 101

form manager section 1
1: fill in info
2: submit
3: add course(Sue, math 01)
4: are you open?
5: are you open?
6: add (Sue)
7: add (Sue)
37 BLOCK UML - DIAGRAM

• Collaboration Diagram

course form :
1: set course info CourseForm
2: process

: Registrar 3: add course

aCourse : theManager :
CurriculumManager
Course
4: new course
38 BLOCK UML - DIAGRAM

• Use case Diagram

• Sequence Diagram; Collaboration Diagram

• Class Diagram; Object Diagram

• Statechart Diagram
• Activity Diagram

• Component Diagram
• Deployment Diagram
39 BLOCK UML - DIAGRAM

• Elemen-elemen pemodelan UML dalam class diagrams

• Class-class dengan struktur dan behaviournya
• Hubungan Association, aggregation, dependency, dan inheritance
• Penanda multiplicity dan navigation
• Nama-nama Role/ tugas
40 BLOCK UML - DIAGRAM

• Class diagram

RegistrationForm ScheduleAlgorithm

RegistrationManager
addStudent(Course, StudentInfo)
Course
name
RegistrationUser numberCredits
name
Student open()
addStudent(StudentInfo)
major

Professor
tenureStatus
CourseOffering
location
open()
addStudent(StudentInfo)
41 BLOCK UML - DIAGRAM

• Use case Diagram

• Sequence Diagram; Collaboration Diagram

• Class Diagram; Object Diagram

• Statechart Diagram
• Activity Diagram

• Component Diagram
• Deployment Diagram
42 BLOCK UML - DIAGRAM

• Statechart Diagram

Add student[ Count < 10 ]

Initialization Add student / Set count = 0 Open

[ Count = 10 ] ^Course
Report.Create report
Cancel course

Cancelled Closed
Cancel course
43 BLOCK UML - DIAGRAM

• Use case Diagram

• Sequence Diagram; Collaboration Diagram

• Class Diagram; Object Diagram

• Statechart Diagram
• Activity Diagram

• Component Diagram
• Deployment Diagram
44 BLOCK UML – DIAGRAM
ACTIVITY DIAGRAM
45 BLOCK UML - DIAGRAM

• Use case Diagram

• Sequence Diagram; Collaboration Diagram

• Class Diagram; Object Diagram

• Statechart Diagram
• Activity Diagram

• Component Diagram
• Deployment Diagram
46 BLOCK UML – DIAGRAM
COMPONENT DIAGRAM

Register.exe
Billing.exe
Billing
System Registrar.exe

People.dll
User
Course.dll
Course
Courses.dll
People.dll
Student Professor
Course Course
Offering
47 BLOCK UML - DIAGRAM

• Use case Diagram

• Sequence Diagram; Collaboration Diagram

• Class Diagram; Object Diagram

• Statechart Diagram
• Activity Diagram

• Component Diagram
• Deployment Diagram
48 BLOCK UML – DIAGRAM
DEPLOYMENT DIAGRAM

Registration Database

Main
Library Building

Dorm
PENGEMBANGAN S/W
49
• Pendekatan iterative
• Ada guidance untuk aktivitas dan
produk
• Process yang memfokuskan pada
arsitektur
• Use case sebagai acuan analisa dan
desain
• Model-model yang merupakan
abstraksi system
STRUKTUR PROSES- FASE LIFECYCLE
50
• RUP memiliki 4 fase
• Inception : mendefinisikan scope project
• Elaboration : merencanakan project, menentukan fitur, garis besar arsitektur
• Construction : membangun project
• Transition : menyerahkan produk ke end user
51 PROSES ITERASI
52 ARCHITECTURE VIEW
53 ARCHITECTURE VIEW

• Use Case View

• Analisa use case adalah teknik untuk meng-capture proses bisnis dari prespektif user.
• Aspek statis di-capture dalam use case diagram
• Aspek dinamis di-capture dalam interaction diagram, statechart diagram dan activity diagram
• Design View
• Meliputi class-class, interface, dan collaboration yang mendefinisikan vocabulary system
• Mendukung kebutuhan fungsional system
• Aspek statis di-capture dalam class diagram dan object diagram
• Aspek dinamis di-capture dalam interaction diagram, statechart diagram dan activity diagram
54 ARCHITECTURE VIEW

• Process View
• Meliputi thread dan pendefinisian proses-proses concurency dan syncronization
• Menunjukkan performance, scalability dan throughput
• Aspek statis dan dinamis di-capture dengan design view, tetapi lebih menekankan pada activ
class
• Implementation View
• Meliputi komponen dan file yang digunakan untuk menghimpun dan me-release system physic
• Menunjukkan configuration management
• Aspek statis di-capture dalam component diagram
• Aspek dinamis di-capture dalam interaction diagram, statechart diagram dan activity diagram
55 ARCHITECTURE VIEW

• Deployment View
• Meliputi node yang membentuk topologi hardware system
• Menunjukkan pendistribusian, delivery, dan pengistallan
• Aspek statis di-capture dalam deployment diagram
• Aspek dinamis di-capture dalam interaction diagram, statechart diagram, activity diagram
56 OVERVIEW OOAD

• Tujuan:
• Untuk merubah analisa kebutuhan menjadi desain system
• Untuk mengembangkan arsitektur system yang kuat
• Untuk menyesuaikan desain agar sesuai dengan lingkungan implementasi, dan mendesain untuk
perormance
57 PERBEDAAN ANALISA DAN DESAIN
Analisa
• Fokus pada pemahaman masalah
• Penyempurnaan desain
• Perilaku
• System structure
• Functional requirement
• Small model
Desain
• Fokus pada pemahaman solusi
• Operation dan Attribute
• Performance
• Mendekati code nyata
• Object Lifecycle
• Non-functional requirement
• Large model
58 WORKFLOW ANALISA DAN DESAIN
THANK YOU