SDLC

Hanya dipergunakan di lingkungan Jurusan Teknik Informatika UB
DAFTAR PENYUSUN
• Fajar Pradana S.ST.,M.Eng
LEMBAR REVISI
Yang bertanda tangan dibawah ini :
Nama : ……………………………
NIK : …………………………….
Jabatan : …………………………….
Dengan ini menyatakan pelaksanaan Revisi Modul ……………………………. untuk Prodi ………………….,
telah dialksanakan dengan penjelasan sebagai berikut:
No Keterangan Revisi Tanggal Revisi Terakhir
1 Revisi Bagian Pertama …………………………….

LEMBAR PERNYATAAN
Yang bertanda tangan dibawah ini :
Nama :
NIP :
Jabatan : Ka. Lab Pembelajaran
Menerangkan dengan sesungguhnya bahwa modul praktikum ini telah direview dan akan digunakan
untuk pelaksanaan praktikum di Semester Genap Tahun Akademik 2017/2018 di Laboratorium
Pembelajaran Fakultas Ilmu Komputer
Malang, 22 Januari 2018
Mengetahui, Ka.Lab.
Koordinator KJFD …………………………….

PERATURAN LABORATORIUM
Setiap Mahasiswa Analisis dan Perancangan Sistem yang akan menggunakan Fasilitas Laboratorium,
WAJIB mematuhi Aturan sebagai berikut :
1. Tidak berambut gondrong untuk mahasiswa
2. Dilarang merokok dan makan minum didalam ruangan, dan membuang sampah pada
tempatnya
3. Dilarang menyimpan barang-barang milik pribadi di Laboratorium/Kelas tanpa seijin Fakultas
4. Dilarang menginap di Laboratorium/Kelas tanpa seijin Fakultas
5. Jam Kerja Laboratorium dan Ruang Riset adalah 07.30 WIB sampai 16.00WIB
6. Mahasiswa yang akan menggunakan Laboratorium dan atau ruang riset diluar jam kerja, harus
mengajukan ijin kepada Fakultas
Dekan
Malang, 22 Januari 2018
DAFTAR ISI
DAFTAR ISI............................................................................................................................................... 6
DAFTAR GAMBAR.................................................................................................................................... 7
Bab 0 : Running Modul............................................................................................................................ 8
Modul 1 : SOFTWARE DEVELOPMENT LIFE CYCLE ............................................................................ 10
Modul 2 : PEMODELAN...................................................................................................................... 13
Modul 3 : REKAYASA KEBUTUHAN .................................................................................................... 15
Modul 4 : PENULISAN KEBUTUHAN .................................................................................................. 21
Modul 5 : PEMODELAN KEBUTUHAN TERSTRUKTUR (PROSES) ........................................................ 24
Modul 6 : PEMODELAN KEBUTUHAN TERSTRUKTUR (DATA DAN BEHAVIOR) ................................. 28
Modul 7 : PROYEK DAN DEMOSTRASI PEMODELAN KEBUTUHAN TERSTRUKTUR ........................... 31
Modul 8 : PEMODELAN KEBUTUHAN BERORIENTASI OBJEK (USE CASE DIAGRAM) ........................ 33
Modul 9 : PEMODELAN KEBUTUHAN BERORIENTASI OBJEK (ANALISIS CLASS) ............................... 41
Modul 10 : PROYEK DAN DEMOSTRASI PEMODELAN KEBUTUHAN BERORIENTASI OBJEK ............ 45
Modul 11 : PEMODELAN PERANCANGAN TERSTRUKTUR (ARSITEKTUR MODUL) .......................... 47
Modul 12 : PEMODELAN PERANCANGAN BERORIENTASI OBJEK (SEQUENCE DIAGRAM).............. 57
Modul 13 : PEMODELAN PERANCANGAN BERORIENTASI OBJEK (CLASS DIAGRAM)..................... 60
Modul 14 : PROYEK DAN DEMOSTRASI PEMODELAN PERANCANGAN BERORIENTASI OBJEK ....... 67
DAFTAR GAMBAR
Gambar 1. Waterfall Model .................................................................................................................. 11

Gambar 2. Prototype Model ................................................................................................................. 11
Gambar 3. Entity Relationship Diagram ................................................................................................ 28
Gambar 4. Entity Relationship Diagram ................................................................................................ 29
Gambar 6. Class Diagram ...................................................................................................................... 34
Gambar 7. Contoh Class Diagram ......................................................................................................... 35
Gambar 8. DFD 1 ................................................................................................................................... 47
Gambar 9. DFD 2 ................................................................................................................................... 48
Gambar 10. DFD 3 ................................................................................................................................. 48
Gambar 11. DFD 3 ................................................................................................................................. 49
Gambar 12. DFD 4 ................................................................................................................................. 50
Gambar 13. DFD 5 ................................................................................................................................. 51
Gambar 14. DFD 5 ................................................................................................................................. 51
Gambar 15. Arsitektur Modul 1 ............................................................................................................ 52
Gambar 20. Sequence Diagram ............................................................................................................ 58
Gambar 21. Class Diagram .................................................................................................................... 61
Gambar 22. Hubungan Antar Class ....................................................................................................... 62
Gambar 23. Contoh Class ...................................................................................................................... 62
Gambar 24. Contoh Class 2 ................................................................................................................... 63
Bab 0 : Running Modul
0.1 Tujuan
Setelah mengikuti Running Modul mahasiswa diharapkan dapat:
1. Memahami peraturan kegiatan praktikum.
2. Memahami Hak dan Kewajiban praktikan dalam kegiatan praktikum.
3. Memhami komponen penilaian kegiatan praktikum.
0.2 Peraturan Praktikum

1. Praktikum diampu oleh Dosen Mata Kuliah Praktikum dan dibantu oleh Asisten
Laboratorium dan Asisten Praktikum.
2. Praktikum dilaksanakan di Ruang Laboratorium atau Kelas sesuai jadwal yang
ditentukan.
3. Praktikan wajib membawa modul praktikum, dan alat tulis
4. Praktikan wajib mengisi daftar hadir.
5. Durasi kegiatan praktikum = 170 menit, dengan rincian sebagai berikut:
a. 10 menit untuk penjelasan singkat tentang modul
b. 100 menit untuk pengayaan
c. 60 menit pembahasan
6. Praktikan wajib hadir minimal 75% dari seluruh pertemuan praktikum di lab. Jika
total kehadiran kurang dari 75% maka nilai Mata Praktikum = 0.
7. Praktikan yang datang terlambat :
• <= 30 menit : diperbolehkan mengikuti praktikum tanpa tambahan waktu Tes
Awal
• > 30 menit : tidak diperbolehkan mengikuti praktikum
8. Saat praktikum berlangsung, asisten praktikum dan praktikan:
• Wajib mematikan/ men-silent semua alat komunikasi(smartphone, tab, iPad,
dsb).
• Dilarang membuka aplikasi yang tidak berhubungan dengan praktikum yang
berlangsung.
• Dilarang mengubah setting software maupun hardware komputer tanpa ijin.
• Dilarang membawa makanan maupun minuman di ruang praktikum.
• Dilarang memberikan jawaban ke praktikan lain (pre-test, TP, jurnal, dan
post-test).
• Dilarang menyebarkan soal pre-test, jurnal, dan post-test.
• Dilarangmembuang sampah/sesuatu apapun di ruangan praktikum.
9. Setiap praktikan dapat mengikuti praktikum susulan maksimal 1 modul untuk satu
praktikum.
• Praktikan yang dapat mengikuti praktikum susulan hanyalah praktikan yang
memenuhi syarat sesuai ketentuan Institusi, yaitu rawat inap di Rumah Sakit
(menunjukkan bukti rawat inap dan resep obat dari RS), tugas dari Institusi
(menunjukkan surat dinas dari Institusi), atau mendapat musibah
(menunjukkan surat keterangan dari orangtua/ wali mahasiswa).
10. Pelanggaran terhadap peraturan praktikum ini akan ditindak secara tegas secara
berjenjang di lingkup Kelas, Laboratorium, Program Studi, Fakultas, hingga Institusi.
0.3 Penilaian Praktikum
1. Komponen Nilai Praktikum terdiri dari : Tugas Pendahuluan, Tes Awal, Keaktifan Praktikum,
dan Jurnal/Tugas Besar.
2. Seluruh komponen penilaian beserta pembobotannya ditentukan oleh dosen Mata
Praktikum
3. Penilaian permodul dilakukan oleh asisten praktikum, sedangkan nilai seluruh modul
diserahkan kepada Dosen Mata Praktikum.
4. Baik praktikan maupun asisten tidak diperkenankan meminta atau memberikan tugas
tambahan untuk perbaikan nilai.
5. Standar indeks dan range nilai ditentukan oleh Dosen Mata Praktikum
Modul 1 : SOFTWARE DEVELOPMENT LIFE CYCLE
1.1 Waktu Pelaksanaan Praktikum
Durasi kegiatan praktikum = 170 menit, dengan rincian sebagai berikut:
1.2 Tujuan
Setelah mengikuti praktikum ini mahasiswa diharapkan dapat:
1. Mahasiswa mampu memahami model-model proses dalam pengembangan PL
2. Mahasiswa mampu memahami karakteristik dari SDLC
3. Mahasiswa mampu fase-fase yang terdapat pada SDLC
1.3 Dasar Teori

SDLC (Systems Development Life Cycle, Siklus Hidup Pengembangan Sistem) atau
Systems Life Cycle (Siklus Hidup Sistem), dalam rekayasa sistem dan rekayasa perangkat
lunak, adalah proses pembuatan dan pengubahan sistem serta model dan metodologi
yang digunakan untuk mengembangkan sistem-sistem tersebut. Konsep ini umumnya
merujuk pada sistem komputer atau informasi. SDLC juga merupakan pola yang diambil
untuk mengembangkan sistem perangkat lunak, yang terdiri dari tahap-tahap:
rencana(planning),analisis (analysis), desain (design), implementasi (implementation), uji
coba (testing) dan pengelolaan (maintenance). Dalam rekayasa perangkat lunak, konsep
SDLC mendasari berbagai jenis metodologi pengembangan perangkat lunak.
Metodologi-metodologi ini membentuk suatu kerangka kerja untuk perencanaan dan
pengendalian pembuatan sistem informasi, yaitu proses pengembangan perangkat
lunak.
1.3.1 Waterfall Model

Waterfall model merupakan salah satu model klasik diantara model pada siklus
pengembangan rekayasa perangkat lunak yang secara luas dan telah banyak digunakan
dalam berbagai proyek pemerintahan maupun proyek perusahaan. Waterfall model
menekankan pada proses perencanaan di tahap awal dengan memastikan tidak adanya
kecacatan desain atau perancangan sebelum dilakukan tahapan pengembangan sistem
(Sommerville, 2011). Selain itu, dokumentasi dan perencanaan yang matang membuat
setiap proses pengembangan bekerja dengan baik. Sehingga dengan adanya
dokumentasi setiap proses yang terdefinisi dengan baik maka akan melahirkan kualitas
kontrol yang baik pula.
Gambar 1. Waterfall Model
1.3.2 Prototype Model

Prototype adalah suatu proses yang memungkinkan developer membuat sebuah
model software,metode ini baik digunakan apabila client tidak bisa memberikan
informasi yang maksimal mengenai kebutuhan yang diinginkannya. Seringkali seorang
customer sulit menentukan input yang lebih terinci, proses yang diinginkan dan output
yang diharapkan hal tersebut menyebabkan developer tidak yakin dengan efisiensi
alogoritma yang di buatnya, sehingga sulit dalam menyesuaikan sistem operasi, serta
interaksi manusia dan mesin yang harus diambil. Dalam hal seperti ini, pendekatan
prototype untuk software engineering merupakan langkah yang terbaik.
Gambar 2. Prototype Model

1.4 Tugas
1. Sebutkan dan gambarkan 5 jenis SDLC yang anda ketahui.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
2. Tuliskan kelebihan dan kelemahan pada masing-masing SDLC.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
Modul 2 : PEMODELAN
2.2 Tujuan
1. Mahasiswa mampu memahami konsep pemodelan
2. Mahasiswa mampu memahami Memahami proses dan metode pemodelan
2.3 Dasar Teori

Model adalah representasi abstrak dari sesuatu yang nyata ataupun yang tidak
nyata. Selain itu model merupakan representasi dari sebuah obyek, sistem atau ide
dalam bentuk yang berbeda dari aslinya. Model merupakan sebuah obyek yang dibuat
untuk merepresentasikan sesuatu untuk kemudahan pemahaman. Contoh: model
jembatan, model arus lalu lintas, model pesawat terbang, model proses pengembangan
PL.
Karakteristik model :
a. lebih mudah dan lebih cepat dibangun/dibuat
b. bisa untuk simulasi  memahami sebuah konsep
c. dapat berkembang/berubah sesuai dengan pemahaman kita tentang sebuah
konsep
d. dapat diseleksi yang perlu didetilkan atau diabaikan dari sebuah konsep
e. representasi dari sesuatu yang nyata ataupun tidak dari berbagai domain
Prinsip dalam pemodelan adalah Bersifat iteratif dan mengalami perubahan
bertahap dalam 3 dimensi: abstraksi, formalisasi dan tingkat detil informasi. Merupakan
abstraksi dari yang belum lengkap sampai menjadi lengkap dan konsisten (e.g. klas,
proses). Formalisasi sampai pada penggunaan notasi formal untuk kebutuhan
implementasi (e.g. OCL, pseudo-code). Detil informasi dari informasi yang umum sampai
menjadi detil (e.g. atribut dan operasi dari klas)
2.4 Tugas
1. Jelaskan proses dalam pemodelan perangkat lunak
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
2. Sebutkan dan gambarkan contoh-contoh pemodelan perangkat lunak
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
Modul 3 : REKAYASA KEBUTUHAN
3.2 Tujuan
1. Mahasiswa mampu memahami konsep rekayasa kebutuhan
2. Mahasiswa mampu memahami proses-proses dalam rekayasa kebutuhan
3. Mahasiswa mampu menerapkan rekayasa kebutuhan terhadap sebuah studi kasus
3.3 Dasar Teori

3.3.1 Konsep Rekayasa Kebutuhan
Kebutuhan adalah kondisi atau kemampuan yang dibutuhkan oleh user
untuk mengatasi suatu masalah atau untuk mencapai tujuan tertentu. Kondisi atau
kemampuan yang harus dimiliki oleh sistem untuk memenuhi sebuah kontrak, standar,
spesifikasi atau dokumen resmi yang ditetapkan. Kata rekayasa (engineering) sendiri
memiliki arti yaitu proses atau serangkaian kegiatan yang terstruktur untuk mengelola
serangkaian sumber daya sehingga membentuk suatu sistem yang memiliki nilai bagi
penggunanya.
Sommervile (2007) mengartikan bahwa rekayasa kebutuhan (software engineering)
sebagai suatu proses mewujudkan serangkaian layanan yang dibutuhkan oleh pelanggan
atas suatu sistem dan batasan-batasan yang harus dipenuhi ketika dibangun maupun
dioperasikan. Kebutuhan dikategorikan menjadi 3 jenis :
a. Kebutuhan Fungsional
b. Kebutuhan Non Fungsional
c. Usability
Proses rekayasa kebutuhan perangkat lunak terdiri dari beberapa aktifitas yaitu:
a. Elisitasi dan analisis kebutuhan
b. Spesifikasi kebutuhan
c. Validasi dan verifikasi kebutuhan
d. Manajemen kebutuhan
3.3.2 Elisitasi dan Analisis Kebutuhan
Elisitasi atau pengumpulan kebutuhan merupakan aktifitas awal dalam proses
rekayasa kebutuhan. Proses elisitasi kebutuhan dilakukan sebelum kebutuhan dapat
dianalisis, dimodelkan, atau ditetapkan. Elisitasi kebutuhan adalah sekumpulan aktifitas
yang ditujukan untuk menemukan kebutuhan suatu sistem melalui komunikasi dengan
pelanggan, pengguna sistem dan pihak lain yang memiliki kepentingan dalam
pengembangan sistem (Sommervile and Sawyer, 1997).
Pada aktivitas ini berbagai kebutuhan dari para pemangku kepentingan
dikumpulkan. Pemangku kepentingan (stakeholder) setiap adalah pihak yang memiliki
kepentingan terhadap proyek pengembangan perangkat lunak. Pemangku kepentingan
dapat diklasifikasikan sebagai berikut: pelanggan, pemilik modal, pemilik sistem,
pengguna, regulator, penyelia, pengembang, analis sistem, dan programmer.
Berikut ini merupakan langkah-langkah untuk elisitasi kebutuhan (Sommervile and
Sawyer, 1997):
1. Identifikasi orang-orang yang akan membantu menentukan kebutuhan dan
memahami organisasi. Menilai kelayakan bisnis dan teknis untuk sistem yang di
usulkan.
2. Menentukan lingkungan teknis (misalnya, komputasi arsitektur, sistem operasi,

kebutuhan telekomunikasi) kemana sistem atau produk akan ditempatkan.
3. Identifikasi ranah permasalahan, yaitu karakteristik lingkungan bisnis yang

spesifik ke ranah aplikasi
4. Menentukan satu atau lebih metode elisitasi kebutuhan misalnya wawancara,

discussion group, dan pertemuan tim.
5. Meminta partisipasi dari banyak orang sehingga dapat mereduksi dampak dari
kebutuhan yang bias yang bisa muncul dari sudut pandang yang berbeda dari
pemangku kepentingan.
6. Mengidentifikasi kebutuhan yang ambigu dan menyelesaikannya.
7. Membuat skenario penggunaan untuk membantu pelanggan/ pengguna

mengidentifikasi kebutuhan utama.
Contoh:
Deskripsikan pemangku kepentingan dari sistem layanan ATM suatu bank.
Jawab:
1. Nasabah Bank: yaitu orang yang menerima layanan sistem

2. Representatif dari bank lain: bank yang melakukan perjanjian timbal balik
penggunaan ATM untuk para nasabah
3. Manajer Bank: orang yang memperoleh informasi manajemen dari sistem
4. Administrator Basis data: orang yang bertanggung jawab untuk menggabungkan

sistem dengan basis data nasabah.
Dalam melakukan elisitasi terdapat beberapa teknik yang dapat membantu analis:
1. Wawancara, pada saat wawancara analis sistem memberikan beberapa

pertanyaan kepada pemangku kepentingan tentang sistem yang digunakan
(existing) dan sistem yang akan dikembangkan. Beberapa panduan yang perlu
diperhatikan pada saat wawancara adalah: pemilihan narasumber (interviewer)
yang potensial, membuat perjanjian dengan narasumber potensial, menyiapkan
struktur pertanyaan yang lengkap dan jelas, dan memilih orang yang
diwawancarai secara pribadi dan merekamnya.
2. Kuisioner, didesain dengan menggunakan standar kuisioner, kuisioner dikirim ke

lingkungan kerja end-user, dan struktur respon diringkas dalam statistik
distribusi.
3. Observasi, kegiatan ini dilakukan dengan mengunjungi lokasi pengamatan dan

merekam kejadian dalam lokasi pengamatan termasuk volume dan pengolahan
lembar kerja.
4. Prototyping, adalah versi awal dari sistem perangkat lunak yang digunakan untuk
mendemonstrasikan konsep, mencoba pilihan rancangan, dan secara umum,
mencari lebih jauh tentang kesalahan dan solusi yang dimungkinkan.
3.3.3 Spesifikasi Kebutuhan
Spesifikasi kebutuhan adalah proses untuk menjelaskan kebutuhan PL yang telah
didefinisikan sebelumnya secara lebih detil dan tepat yang akan menjadi dasar bagi
perancangan dan implementasi.
Contoh :
Definisi kebutuhan (requirement definition) :
1. PL harus mampu menyediakan sarana untuk menampilkan dan mengakses file-file yang
dibuat oleh tool yang lain. (SRS_PRJ_100)
Spesifikasi kebutuhan (requirement specification) :
1.1 Pengguna harus disediakan fasilitas untuk mendefinisikan tipe file. (SRS_PRJ_101)
1.2 Setiap tipe file direpresentasikan dengan ikon tertentu pada layar pengguna.
(SRS_PRJ_102)
3.3.4 Validasi dan verifikasi kebutuhan
Proses ini dilakukan untuk memastikan bahwa seluruh kebutuhan yang telah didapatkan
telah didefinisikan dan dispesifikasikan adalah benar, akurat dan lengkap. Parameter
validasi:
1. Validity, apakah sistem menyediakan semua fungsi yang mendukung semua yang
dibutuhkan oleh customer?
2. Consistency, apakah ada kebutuhan yang konflik?
3. Comprehensibility, apakah semua fungsi yang diinginkan customer sudah tercakup

didalamya? (kelengkapan)
Parameter verifikasi:
1. Readability
2. Testability
3. Completeness
4. Identifiability
5. Ambiguity
3.3.5 Manajemen kebutuhan
Aktifitas untuk melakukan kontrol terhadap kebutuhan yang sedang maupun telah
didefinisikan dan dispesifikasikan :
1. Identifikasi, bagaimana setiap kebutuhan dapat diidentifikasi dengan mudah (Cont. :

SRS_PRJ_XXX, IRS_PRJ_XXX)
2. Manajemen perubahan, bagaimana mekanisme untuk menangani perubahan

kebutuhan yang terjadi
3. Dokumentasi, SRS dan IRS sebagai deliverable, ECP, PCR
Tracking, penelusuran informasi yang berhubungan dengan sebuah kebutuhan

(sumber/asal, alokasi ke perancangan)
3.4 Tugas
Perhatikan studi kasus berikut ini:
Vario Advertising merupakan perusahaan biro iklan yang terletak di Jalan Soekarno
Hatta Malang. Vario didirikan pada tahun 2000. Awalnya perusahaan ini berkonsentrasi
pada periklanan untuk industri motor indonesia, yang sebagian besar pemasarannya di
daerah Jawa dan Bali. Namun seiring berjalannya waktu, perusahaan diperluas menuju
skala internasional dan memiliki klien di berbagai industri manufaktur dan jasa. Strategi
perusahaan bertujuan untuk terus tumbuh perlahan-lahan dan mengembangkan ke
pasar internasional.
Dalam menjalankan bisnisnya Vario Advertising bekerjasama dengan perusahaan
lain yang bisa disebut juga sebagai klien. Setiap kerjasama yang dilakukan oleh Vario
terdapat dokumentasi yang selalu dibuat dan disimpan secara baik. Disamping itu dalam
melakukan kerjasama biasanya dari pihak klien akan mengirimkan beberapa
perwakilannya untuk melakukan komunikasi dan koordinasi dengan Vario. Begitu juga
dengan Vario, mengirimkan wakilnya untuk melakukan koordinasi dengan klien.
Perwakilan dari vario memungkinkan bertanggung jawab pada klien yang berbeda dalam
pekerjaan yang berbeda pula. Tentunya hal seperti ini perlu dikelola secara benar agar
tiak overlap, baik target kerja, pengelolaan dana, dan penjadwalan kerja.
Untuk mendukung skala bisnis internasional, perusahaan memiliki strategi dengan
berfokus dalam membangun suatu sistem informasi guna membantu aktifitas proses
bisnis yang berjalan diperusahaan tersebut. Beberapa aktifitas dan kebutuhan yang
perlu didefinisikan dalam sistem tersebut terangkum sebagai berikut
Sistem mampu merekam detail informasi klien termasuk order layanan kampanye
iklan. Dalam perekaman informasi setiap klien, data terkait nama, alamat, kontak klien
harus masuk didalamnya. Selain itu dalam pencatatan informasi layanan order
kampanye iklan, harus terekam terkait judul kampanye, tanggal mulai dan selesai
pelaksanaan kampanye, estimasi biaya, biaya riil, dan tanggal pembayaran. Selanjutnya
setelah perekaman telah dilakukan maka sistem mampu menyediakan suatu fungsi
mencetak invoice bagi klien yang dapat dieksekusi oleh lebih dari satu akun staf yang
tersedia di sistem tersebut. Demikian pula dengan proses pembayaran yang dilakukan
oleh klien juga dapat dilayani oleh beberapa akun yang tersedia di sistem dan terekam
secara baik. Pada kebutuhan ini sistem nantinya juga perlu untuk merekam informasi
tentang staf yang ditugaskan untuk terlibat dalam proses produksi iklan beserta
kampanye iklan untuk tiap klien termasuk mencatat manager proyek yang terlibat dalam
kampanye. Selanjutnya sistem juga dapat mekakukan pengecekan status kampanye,
baik proses produksi hingga akhir pelaksaaan kampanye dan kesesuaian dengan biaya
yang tersedia.
Sistem mampu menyediakan fungsi bagi staf kreatif untuk merekam rincian proses
produksi iklan termasuk proses pengembangan konsep kampanye iklan. Rincian proses
produksi iklan yang dimaksud adalah kemampuan sistem untuk merekam catatan ide
detail untuk kampanye dan konsep iklan yang bisa diakses atau dilihat oleh staf lain
termasuk didalamnya informasi progress produksi hingga penjadwalan kampanye iklan
dimulai hingga selesai.
Sistem mampu menyediakan fungsi merekam detail informasi seluruh staf
perusahaan bagi staf. Detail informasi staf yang direkam antara lain pengelolaan data
staf kreatif dan staf administratif. Disamping itu juga sistem harus mampu untuk
menyediakan fungsi bagi staf keuangan dan manajer proyek untuk memberikan grade
nilai kepada staf dan mengakomodir proses pembayaran staf berdasarkan grade nilai
tersebut dan terekam dalam sistem. Selain itu sistem juga perlu mengakomodir fungsi
untuk menghitung bonus tahunan dari setiap staf berdasarkan kinerja .
Dalam sistem yang dibangun, perusahaan menginginkan data terkait dengan klien,
kampanye, iklan dan staf dapat diakses antar kantor yang berbeda dan untuk
kemudahan pengoperasian, sistem diharapkan dapat diakses menggunakan beberapa
bahasa yang berbeda pula.
Kerjakan soal-soal berikut ini dengan singkat dan jelas!
1. Tentukanlah domain permasalahan yang mungkin ditemukan di lapangan terkait dengan
studi kasus tersebut!
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
2. Tentukanlah pemangku kepentingan beserta dengan deskripsinya!
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
3. Susunlah pertanyaan-pertanyaan untuk melakukan elisitasi kebutuhan. Pertanyaan-

pertanyaan tersebut dikelompokan berdasarkan pemangku kepentingan yang terkait.
Selain itu tentukan juga metode apa yang cocok untuk melakukan elisitasi!
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
Modul 4 : PENULISAN KEBUTUHAN
4.2 Tujuan
1. Mahasiswa mampu memahami konsep rekayasa kebutuhan
2. Mahasiswa mampu memahami proses-proses dalam rekayasa kebutuhan
3. Mahasiswa mampu menerapkan rekayasa kebutuhan terhadap sebuah studi kasus
4.3 Dasar Teori

Dalam konteks penyusunan hendaklah menspesifikasi kebutuhan yang SMART.
Tujuannya bukanlah untuk membuktikan bahwa spesifikasi kebutuhan yang telah
ditetapkan sudah benar secara teknis (yaitu bahwa kebutuhan yang dinyatakan adalah
benar-benar yang dibutuhkan, tapi lebih kepada agar spesifikasi kebutuhan tersebut
dapat dicek dan diverifikasi kebenarannya dari aspek ekspresi (bukan isi)
1. Specific (spesifik)
Setiap kebutuhan harus menyebutkan tepat seperti yang dibutuhkan. Hindari

penggunaan asumsi dalam menginterpretasikan arti sebuah kalimat kebutuhan.
2. Measureable (terukur)
Suatu kebutuhan akan diuji nanti ketika selesai dibangun, sehingga penting untuk
menyusun kalimat kebutuhan yang terukur sehingga memudahkan dalam melakukan
pengujian.
3. Attainable (dapat dicapai)
Memastikan bahwa kebutuhan yang didefinisikan dapat dicapai sesuai dengan batas-
batas kekuatan dan pengetahuan manusia.
4. Realizable (dapat direalisasikan)
Suatu kebutuhan haruslah dapat direalisasikan dengan mempertimbangkan sumber

daya yang dimiliki.
5. Traceable/bounded (memiliki dimensi waktu/dapat dilacak)
Suatu kebutuhan hendaklah dapat diselesaikan atau direalisasikan dalam waktu yang
telah ditentukan. Dalam hal ini adalah sesuai dengan rencana proyek (project plan).
Selain itu kebutuhan juga perlu suatu mekanisme untuk menjustifikasi alasan
keberadannya. Kebutuhan mungkin muncul karena ada kebutuhan lainnya.
4.4 Tugas
1. Berdasarkan studi kasus Vario Advertising. Susunlah pernyataan kebutuhan sesuai

dengan konsep SMART. Kelompokan berdasarkan kategorinya: Kebutuhan Fungsional,
Kebutuhan Non Fungsional, dan Usability.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
2. Perhatikan dan analisis kebutuhan berikut ini:
a. “Sistem dapat melayani permintaan peminjaman ruang rapat secara bersamaan

dengan cepat.”
b. “Ketika modul X memanggil modul Z, berkas catatan pesannya diperbaharui.”
c. “Sistem tentunya dapat menyimpan dokumentasi rapat dalam format bervariasi,
seperti misalnya: JPG, TIF, BMP, dsb.”
Apakah kebutuhan tersebut telah memenuhi aspek Spesific (S) pada konsep SMART?
Jelaskan jawaban Anda kemudian perbaiki kebutuhan tersebut apabila belum memenuhi
aspek Specific (S).
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
a. “Sistem dapat melayani permintaan peminjaman ruang rapat secara bersamaan

dengan cepat.”
b. “Ketika modul X memanggil modul Z, berkas catatan pesannya diperbaharui.”
c. “Sistem tentunya dapat menyimpan dokumentasi rapat dalam format bervariasi,
seperti misalnya: JPG, TIF, BMP, dsb.”
Apakah kebutuhan tersebut telah memenuhi aspek Spesific (S) pada konsep SMART?
aspek Specific (S).
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
a. “Sistem dapat memproses data permohonan rapat dengan cepat dan akurat.”
b. “Besaran berkas yang diunggah pada dokumen notulensi rapat tidak terlalu besar
ukurannya.”
Apakah kebutuhan tersebut telah memenuhi aspek Measureable (M) pada konsep
SMART? Jelaskan jawaban Anda kemudian perbaiki kebutuhan tersebut apabila belum
memenuhi aspek Measureable (M).
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
a. “Sistem memiliki tingkat ketersediaan 100% dan dapat dihandalkan 100%.”

b. “Sistem akan bekerja 24 jam / hari serta 365 hari/ tahun tanpa berhenti.”
c. “Sistem dapat mengirimkan data maksimal 10 TB per detik.”
Apakah kebutuhan tersebut telah memenuhi aspek Attainable (A) pada konsep SMART?
aspek Attainable (A)
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
a. “Sistem akan memiliki ketersediaan ruang rapat 97%.”

Apakah kebutuhan tersebut telah memenuhi aspek Realizeable (R) pada konsep SMART?
aspek Realizeable (R).
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
Modul 5 : PEMODELAN KEBUTUHAN TERSTRUKTUR (PROSES)
5.2 Tujuan
1. Mahasiswa mampu memahami konsep pemodelan kebutuhan terstruktur
2. Mahasiswa mampu memodelakan dengan menggunakan DFD
5.3 Dasar Teori

5.3.1 Konsep Pemodelan Kebutuhan
Kebutuhan adalah kondisi atau kemampuan yang dibutuhkan oleh user
untuk mengatasi suatu masalah atau untuk mencapai tujuan tertentu. Kondisi atau
kemampuan yang harus dimiliki oleh sistem untuk memenuhi sebuah kontrak, standar,
spesifikasi atau dokumen resmi yang ditetapkan. Kata rekayasa (engineering) sendiri
memiliki arti yaitu proses atau serangkaian kegiatan yang terstruktur untuk mengelola
serangkaian sumber daya sehingga membentuk suatu sistem yang memiliki nilai bagi
penggunanya.
Pemodelan dalam pengembangan perangkat lunak bermaksud untuk
menggambarkan sistem dalam bentuk yang lebih mudah dipahami. Kebutuhan adalah
suatu hal dalam pengembangan perangkat lunak yang perlu dimodelkan. Tujuan dari
pemodelan kebutuhan antara lain adalah:
a. Menjelaskan apa saja kebutuhan dari pengguna,
b. Menjadi dasar dari pengembangan perangkat lunak,
c. Menjadi referensi dalam proses validasi kebutuhan. Pemodelan kebutuhan terdapat
dua pendekatan, yaitu pendekatan Terstruktur dan Berorientasi Objek. Terdapat
beberapa prinsip dalam memodelkan kebutuhan, antara lain adalah:
d. Model kebutuhan yang dibuat harus sesuai dengan kebutuhan pada domain
permasalahan, what bukan how.
e. Model kebutuhan harus bisa dilacak pada model perancangan yang dihasilkan pada
fase perancangan.
f. Model kebutuhan disajikan dengan lengkap dan mampu memperjelas pemahaman
secara utuh tentang domain permasalahan, fungsionalitas dan perilaku sistem.
g. Model kebutuhan hendaknya dapat mengurangi tingkat keterkaitan antar
modul/klas (kopling).
h. Model kebutuhan harus dapat memberikan nilai manfaat bagi seluruh stakeholder
i. Model kebutuhan direpresentasikan dalam notasi yang sederhana dan meniadakan
duplikasi, sehingga dapat dengan mudah dipahami oleh stakeholder.
5.3.2 Pemodelan Terstruktur

Konsep perancangan sistem dengan pendekatan terstruktur (Structural Analysis)
pertama kali diperkenalkan oleh Tom DeMarco pada tahun 1979. Tom DeMarco
menuliskan penjelasannya tentang pendekatan terstruktur pada bukunya yang berjudul
“Structured Analysis and System Specification”. Dalam buku tersebut penekanan
utamanya adalah pada proses spesifikasi struktur domain masalah.
Terdapat tiga hal yang diperhatikan dalam pemodelan kebutuhan dengan
pendekatan terstruktur, yaitu, pemodelan data, proses dan perilaku dari sistem.
Penggambaran data menggunakan Entity Relationship Diagram (ERD), penggambaran
proses menggunakan Data Flow Diagram/ Control Flow Diagram (DFD/CFD), dan
penggambaran perilaku menggunakan State Transition Diagram (STD). Terdapat juga
beberapa model yang melengkapi penjelasan ketiga model terdahulu seperti, Data
Dictionary (kamus data), PSPEC (Process Specification), dan CSPEC (Control
Specification).
5.3.3 Data Flow Diagram/ Control Flow Diagram (DFD/ CFD)

Data Flow Diagram/ Control Flow Diagram dapat digunakan untuk menggambarkan
dekomposisi proses dari sistem yang ada dalam rangka pengembangan sistem yang
baru. DFD/ CFD fokus pada peredaran data dari entitas ke proses, proses ke proses, dan
proses ke data store. Selain itu CFD juga dapat menggambarkan perilaku proses yang
terjadi pada sistem. DFD/ CFD memiliki beberapa level detail. Model yang paling tinggi
disebut sebagai Diagram Kontek (Context Diagram). Elemen-elemen model DFD/ CFD
adalah sebagai berikut:
1. Terminator/ External Entity
a. Representasi entitas eksternal
External Entity
b. Notasi: persegi panjang
c. Tidak memproses data
2. Data Flow
a. Representasi aliran data
b. Notasi: anak panah penuh
c. Umumnya satu arah
d. Hubungkan terminator, process dan storage
3. Control Flow
a. Representasi aliran kontrol proses
b. Notasi: anak panah putus2
c. Hubungkan terminator, process dan control bar
4. Process
a. Representasi aktifitas sistem 1
b. Notasi: lingkaran Proses A
c. Memproses data
5. Storage
a. Representasi tempat penyimpanan data
b. Notasi: dua garis paralel
c. Data flow in = diubah, data flow out = dibaca
6. Control Bar
a. Representasi spesifikasi kontrol
b. Notasi: garis tegak
5.4 Tugas
1. Buatlah Data Flow Diagram untuk kasus studi Vario Advertising pada Modul Praktikum
Rekayasa Kebutuhan.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
2. Buatlah process specification (P-Spec) dari DFD yang telah dibuat sebelumnya.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
3. Buatlah control specification (C-Spec) dari DFD yang telah dibuat sebelumnya.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
4. Buatlah data dictionary dari DFD yang telah dibuat sebelumnya.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
Modul 6 : PEMODELAN KEBUTUHAN TERSTRUKTUR (DATA DAN
BEHAVIOR)
6.2 Tujuan
2. Mahasiswa mampu memodelakan dengan menggunakan ERD dan STD
6.3 Dasar Teori

6.3.1 Entity Relationship Diagram
Terdapat beberapa pertanyaan yang dapat mempermudah dalam perancangan
model data, antara lain adalah:
• Apa objek data utama yang diproses oleh sistem?
• Bagaimana komposisi masing-masing objek data dan apa saja atributnya?
• Di mana objek-objek data tersebut saat ini berada?
• Apa hubungan antara masing-masing objek?
• Apa hubungan antara obyek dan proses yang mengubah mereka?
Komponen-komponen yang harus ada pada pemodelan data adalah entitas, atribut,
relasi, kardinalitas dan modalitas. Gambar 2.2 menggambarkan contoh gambaran entitas
dan relasinya.
Gambar 3. Entity Relationship Diagram
6.3.2 State Transition Diagram

State Transition Diagram adalah model yang menggambarkan tentang perilaku
sistem. STD menjelaskan perilaku sistem yang terkait dengan perubahan state yang
terjadi pada sistem. State adalah sebuah kondisi yang terlihat oleh pengguna atau user.
Dalam pembuatan STD, terdapat beberapa hal yang harus didefinisikan, antara lain
adalah State, Event, dan Action.
Untuk mempermudah dalam pembuatan STD, terdapat beberapa langkah:
1. Buatlah daftar state dari sistem yang terlihat oleh pengguna.
2. Tunjukkan bagaimana sistem melakukan transisi dari satu state ke state yang lain.
3. Definisikan event sebagai suatu kejadian yang memicu transisi antar state.
4. Definisikan action (aksi) yang dilakukan sistem.
6.4 Tugas
1. Perhatikan diagram berikut ini: ERD
Gambar 4. Entity Relationship Diagram
a. Menurut Anda, apakah ERD diatas sudah benar? Jelaskan jawaban Anda!
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
b. Jika terdapat kesalahan, lakukan analisis terhadap kesalahan yang terjadi pada ERD
tersebut dan gambarkan ulang hasil perbaikannya!
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
c. Setelah diperbaiki, amati dan jelaskan makna ERD tersebut dalam bahasa Anda sendiri
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
2. TPL airline adalah maskapai penerbangan terbaik di Indonesia. TPL airline dapat
melayani pelanggannya dengan baik, sehingga setiap tahun jumlah pelanggannya
semakin bertambah. Pada tahun 2007, pada saat pertama kali TPL airline terbentuk, TPL
airline telah memiliki 1000 pelanggan pada tahun pertama. Hingga pada tahun 2017 ini,
pelanggan TPL airline telah mencapai lebih dari 5000 pelanggan. Untuk meningkatkan
jumlah pelanggan, TPL airline membuat sistem reservasi tiket pesawat online sehingga
pelanggan yang ingin menggunakan jasa TPL airline dapat memesan dan mendapatkan
tiket tanpa harus datang ke loket TPL airline. Selain hal tersebut, TPL airline juga
memberikan promo khusus berupa diskon 20% bagi pelanggan yang membeli tiket lebih
dari lima.
a. Buatlah ERD dari kasus yang terdapat pada ilustrasi tersebut!
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
b. Buatlah State Transition Diagram dari kasus yang terdapat pada ilustrasi tersebut!
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
Modul 7 : PROYEK DAN DEMOSTRASI PEMODELAN KEBUTUHAN
TERSTRUKTUR
7.2 Tujuan
2. Mahasiswa mampu memodelkan dengan menggunakan DFD, ERD, dan STD dari studi
kasus yang diberikan
3. Mahasiswa mampu mempresentasikan hasil pemodelan kebutuhan
7.3 Tugas
Perhatikan deskripsi sistem berikut ini :
Sistem reservasi hotel adalah sistem yang berfungsi untuk membantu para calon
tamu dalam memesan kamar hotel. Tamu dapat mengisi formulir data diri, menentukan
tipe kamar dan dapat memberikan permintaan khusus. Permintaan khusus ini
menentukan ada atau tidaknya dan bagaimana tambahan fasilitas kamar yang
disediakan oleh pihak hotel. Kemudian sistem dapat memberikan informasi harga kamar
dari hotel kepada calon tamu. Setelah pemesanan dilakukan maka tamu akan
mendapatkan bukti pemesanan kamar hotel. Kemudian dari sisi pihak hotel, pihal hotel
akan mendapatkan detail data pemesanan kamar dan data diri tamu. Pihak hotel dapat
mempublikasikan informasi tentang kondisi kamar yang dapat dipesan. Pihak hotel
memiliki informasi tentang ketersediaan kamar yang menentukan pemesanan dapat
dilakukan atau tidak.
a. Gambarkan DFD dari studi kasus tersebut.
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
b. Gambarkan ERD dari studi kasus tersebut.

_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
c. Gambarkan STD dari studi kasus tersebut.
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
Modul 8 : PEMODELAN KEBUTUHAN BERORIENTASI OBJEK
(USE CASE DIAGRAM)
8.2 Tujuan
1. Mahasiswa mampu memahami konsep pemodelan kebutuhan berorientasi objek
2. Mahasiswa mampu memodelakan dengan menggunakan Use Case Diagram dan Use
Case Scenario
8.3 Dasar Teori

Pendekatan berorientasi objek merupakan suatu teknik atau cara pendekatan baru
dalam melihat permasalahan dari sistem (sistem perangkat lunak, sistem informasi, atau
sistem lainnya). Pendekatan berorientasi objek dipopulerkan pada akhir tahun 1980an –
1990an oleh Booch, Rumbaugh-OMT, Jacobson-OOSE, Coad dan Yourdon, Wirfs-Brock.
Pendekatan berorientasi objek akan memandang sistem yang akan dikembangkan
sebagai suatu kumpulan objek yang berkorespondensi dengan objek-objek dunia nyata.
Ada banyak cara untuk mengabstraksikan dan memodelkan objek-objek tersebut, mulai
dari abstraksi objek, kelas, hubungan antar kelas sampai abstraksi sistem. Saat
mengabstraksikan dan memodelkan objek ini, data dan proses-proses yang dipunyai
oleh objek akan dienkapsulasi (dibungkus) menjadi satu kesatuan.
Hal-hal yang perlu dilakukan dalam memodelkan berorientasi objek meliputi:
• Elisitasi kebutuhan customer
• Identifikasi skenario / use-case (use-case diagram)
• Identifikasi klas berdasarkan kebutuhan customer
• Identifikasi atribut dan operasi setiap klas
• Definisi struktur klas (class diagram)
• Definisi model relasi antar klas (collaboration/sequence diagram)
• Definisi perpindahan status sistem (statechart diagram)
Pada tahun 1996, bahasa yang digunakan untuk pemodelan berorientasi objek
dibuatlah UML (Unified Modeling Language). UML dibuat oleh Grady Booch, James
Rumbaugh dan Ivar Jacobson.
Kelebihan dari pemodelan berorientasi objek meliputi:
• Sangat natural, sesuai dengan cara berpikir manusia
• Dapat meningkatkan interaksi antara ahli domain masalah dengan analis
• Meningkatkan konsistensi hasil analisis
• Hal ini dikarenakan dengan pemodelan berorientasi objek, mampu
mengabstraksikan atribut hingga operasi dalam sebuah objek
• Konsep penurunan klas memberikan kemudahan dalam generalisasi objek
• Kemudahan dalam perubahan
• Terjaganya konsistensi model antara analisis dan perancangan
• Konsep reusability
KOMPONEN PADA PEMODELAN OO
Object
Menurut Rumbaugh definisi objek adalah sebuah konsep, abstraksi, atau sesuatu
yang memiliki batasan dan masalah utama serta bersifat tangible dan intangible
(sesuatu yang bisa diraba atau tidak). Karakteristik dari sebuah objek adalah memiliki
identity (identitas-pembeda), state (sekumpulan atribut) & behaviour (sekumpulan
operasi, aksi, servis).
Contoh dari objek pada sistem akademik adalah: Andi, Eko, Susi.
Notasi dari objek:
Nma Objek
Atribut2
Operasi2
Gambar 6. Class Diagram
Class
Menurut Yourdon, class (klas) adalah sebuah deskripsi dari satu atau lebih objek
yang memiliki kesatuan dari atribut dan layanan/operasi yang sama termasuk
bagaimana membuat objek baru dalam klas.
Fungsi dari sebuah klas adalah sebagai gambaran umum (template, blue-print) yang
menjelaskan sekumpulan objek yang memiliki kesamaan karakteristik (atribut dan
operasi) dan cetakan dari objek. Dimana sebuah kelas akan mempunyai sifat (atribut),
kelakuan (operasi), hubungan (relationship) dan arti. Dan suatu klas dapat diturunkan
dari kelas yang lain, dimana atribut dari kelas semula dapat diwariskan ke kelas yang
baru. Klas juga digunakan untuk menginstansiasi objek yang memiliki identitas yang
berbeda.
Contoh 1: Klas Mahasiswa  objek Andi, Eko, Susi
Klas memiliki bentuk abstract dan concrete. Dimana klas abstrak adalah klas yang
berasal dari sesuatu yang bersifat abstrak.
Contoh 2:
Gambar 7. Contoh Class Diagram
Pemodelan berorientasi objek juga berfungsi untuk menemukan domain masalah.

Langkah-langkah dalam menentukan objek dan klas adalah:
• Observasi langsung ke dunia industri atau lapangan (Observe first-hand)
• Secara aktif menggali permasalahan dengan pertanyaan apa, siapa,
bagaimana, kapan mengapa
• Selalu melihat hasil dari analisis berorientasi objek sebelumnya
• Melakukan perbandingan dengan sistem yang lain
• Sering membaca untuk mendapatkan informasi
Yang harus diperhatikan dalam menentukan objek dan klas adalah dengan
memperhatikan kata benda yang muncul pada domain masalah seperti:
• Struktur
Perhatikan relasi antar objek termasuk ke dalam jenis generalisasi atau
agregasi
• Sistem lainnya
Perlu diperhatikan juga sistem lain yang berinteraksi dengan sistem yang
akan dibangun
Sesuatu hal atau kejadian yang disimpan
Data, status atau kejadian yang harus disimpan dalam sistem
• Role played
Identifikasi peran manusia dalam sistem apakah berinteraksi langsung atau
tidak berinteraksi tetapi informasinya disimpan dalam sistem
• Lapangan
Informasi lokasi/posisi yang harus diingat oleh sistem
Identifikasi Atribut
Beberapa data (informasi data) yang dimiliki oleh setiap objek yang ada dalam klas
objek (Yourdan).
• Langkah dalam menentukan atribut:
• Identifikasi atribut umum (adjectives, possessives)
• Identifikasi atribut yang relevan dengan domain masalah
• Identifikasi atribut yang relevan dengan peran atau tanggung jawab dalam
sistem
• Restrukturisasi atribut sehingga atomic yang bisa memunculkan kemudahan
• Reposisi atribut yang sesuai dengan hirarki klas nya yang menyebabkan
terjadinya pewarisan klas
• Spesifikasi atribut seperti presisi, nilai default, batasan, dll.
Identifikasi Operasi/Layanan
Kegiatan spesifik/tertentu yang dilakukan oleh sebuah objek sendiri [Yourdon]
Langkah-langkah dalam mengidentifikasi operasi/layanan:
• Identifikasi tanggung jawab umum sebuah klas (verbs)
• Identifikasi operasi yang spesifik untuk domain masalah
• Identifikasi operasi yang relevan dengan peran atau tanggung jawab dalam
sistem
• Spesifikasi operasi yang berasal dari argumen, batasan/aturan,
logika/algoritma
8.3.1 Use Case Diagram

Use Case merupakan pemodelan untuk kelakuan sistem informasi yang akan dibuat.
Use Case menjelaskan perilaku sistem dari tampak luar dan menyediakan fungsi-fungsi
yang harus dipenuhi sistem sesuai dengan aktornya. Elemen-elemen yang ada pada use
case adalah actor dan use case. Actor adalah orang, proses atau sistem lain yang
berinteraksi dengan sistem informasi. Sedangkan use case merupakan fungsionalitas
yang disediakan sistem sebagai unit-unit yang saling bertukar pesan antar unit atau
aktor.
• Langkah-langkah dalam membuat use case:
• Identifikasi aktor
• Identifikasi use-case per aktor
• Simbol-simbol yang digunakan pada use case adalah:
Tabel 1. Simbol Use Case
No Simbol (Nama) Deskripsi
1 use case fungsionalitas yang disediakan sistem sebagai unit-unit

yang saling bertukar pesan antar unit/aktor. Biasanya
dinyatakan dengan menggunakan kata kerja awal di awal
frase nama use case.
Nama use case
2 aktor orang, proses atau sistem lain yang berinteraksi dengan

sistem informasi yang akan dibuat.
3 asosiasi komunikasi antar aktor/ use case yang berpartisipasi

pada use case atau use case memiliki interaksi dengan
aktor.
4 ekstensi/ extend relasi use case tambahan ke sebuah use case dimana use
case yang ditambahkan dapat berdiri sendiri walau tanpa
<<extend>>
use case tambahan itu
5 generalisasi hubungan generalisasi antara dua buah use case dimana

fungsi yang satu adalah fungsi yang lebih umum dari
lainnya
6 include relasi use case tambahan ke sebuah use case dimana use
case yang ditambahkan memerlukan use case ini untuk
<<include>>
menjalankan fungsinya atau sebagai syarat dijalankan use
case ini
8.3.2 Use Case Scenario

Setiap use case yang dibuat, dilengkapi dengan skenario. Skenario use case adalah
alur jalannya proses use case dari sisi aktor dan sistem. Bentuk skenario use case bisa
dilihat pada gambar di bawah ini:
Tabel 2. Usecase Scenario
Flow of events for the Select product use-case
Objective Allow customer to select a certain product to dispense
Actors Customer
Pre-condition Coin detected and valid

Main flow
The customer selects a button product.

The system displays an entry prompt of number of product to order.
Alternative flows If the selected product is not available, the system will display a
message “Your selected product is not available”.
If the selected product is available but there isn’t enough number to
order, the system will display a message “The number isn’t enough,
max. x”. X is the existing number of the product.
Post-condition The selected product dispensed as the number needed
Pada use case asosiasi, terdapat include dan extend seperti yang ditunjukkan pada
tabel 1. Include digunakan pada saat sebuah use case menggunakan use case lainnya
(functional decomposition). Penggunaan include sebagai sebuah fungsi yang berada
pada pernyataan masalah utama yang sangat rumit untuk diselesaikan sesegera
mungkin. Sehingga include wajib ada jika dibutuhkan sebuah fungsi agregasi untuk
sebuah fungsi yang lebih sederhana. Extend digunakan pada saat ada use case yang
ditambahkan dapat berdiri sendiri. Fungsi dari sebuah pernyataan permasalahan utama
perlu dilakukan sebuah perpanjangan. Sehingga bisa disimpulkan bahwa extend
menghubungkan use case untuk memiliki peran sebagai use case opsional.
Actor-Generalization
Dua atau lebih sub-aktor digeneralisikan dari super aktor. Sehingga sub-aktor
tersebut memiliki behavior/operasi/layanan dan atribut yang dimiliki oleh super aktor.
Super aktor harus berinteraksi dengan use case ketika semua sub-aktor berinteraksi
dengan cara yang sama. Sub-aktor harus berinteraksi dengan use case ketika interaksi
use case berbeda dengan super aktor.
Diagram klas atau class diagram menggambarkan struktur sistem dari segi
pendefinisian klas-klas yang akan dibuat untuk membangun sistem. Class yang ada pada
struktur sistem harus dapat melakukan fungsi-fungsi sesuai dengan kebutuhan sistem.
8.4 Tugas
1. Berdasarkan studi kasus : Vario Advertising, lakukan identifikasi aktor yang terlibat dalam
sistem dan buat pula daftar spesifikasi kebutuhan yang mampu menghubungkan peran
actor terhadap kebutuhan sistem.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
2. Berdasarkan studi kasus : Vario Advertising, buatlah usecase diagram berdasarkan peran
actor dan usecase scenario berdasarkan pandangan setelah membaca soal cerita di atas.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
Modul 9 : PEMODELAN KEBUTUHAN BERORIENTASI OBJEK
(ANALISIS CLASS)
9.2 Tujuan
2. Mahasiswa mampu melakukan analisis class diagram dan sequence diagram.
9.3 Dasar Teori

9.3.1 Class Diagram
Diagram klas atau class diagram menggambarkan struktur sistem dari segi
pendefinisian klas-klas yang akan dibuat untuk membangun sistem. Class yang ada pada
struktur sistem harus dapat melakukan fungsi-fungsi sesuai dengan kebutuhan sistem.
Class diagram memiliki node/klas dan relasi. Jenis relasi pada class diagram meliputi:
Tabel 3. Notasi Diagram Klas
No Simbol/Nama Deskripsi
1 Klas klas pada struktur sistem

nama_klas
+atribut()
+operasi()
2 Interface sama dengan konsep interface dalam

pemrograman berorientasi objek
3 asosiasi relasi antar klas dengan makna umum

4 asosiasi berarah relasi antar klas dengan makna klas yang satu
digunakan oleh klas yang lain
5 generalisasi relasi antar klas dengan makna generalisasi-

spesialisasi (umum-khusus)
6 agregasi relasi antar klas dengan makna semua bagian
7 kebergantungan/dependency relasi antar klas dengan makna kebergantungan

antar klas
9.3.1.1 Class Stereotype

Dalam sebuah diagram klas, dibutuhkan sebuah template agar diagram klas yang
dibuat sesuai dengan sistem yang akan dibangun. Berikut merupakan komponen yang
harus ada pada sebuah diagram klas:
9.3.1.2 Boundary class

Boundary class merupakan sebuah model dalam sistem yang menunjukkan
bagaimana sistem berinteraksi dan berkomunikasi antara sistem komputer dengan
aktor, tetapi tidak secara langsung menggambarkan implementasi dari antarmuka objek
secara spesifik. Boundary class berfungsi untuk mengidentifikasi antarmuka logis utama
antara user dengan sistem lain seperti perangkat lunak lain atau printer. Tugas utama
dari boundary class adalah untuk menterjemahkan informasi antar batasan sistem.
Boundary class merupakan bagian dari sistem dimana sebuah antarmuka akan
dipisahkan dengan Business logic.
9.3.1.3 Entity class

Entity class digunakan untuk memodelkan data dan behavior/operasi/layanan dari
konsep sistem sesungguhnya atau entitas. Seperti member, bank account, order,
employee. Bagian ini akan membutuhkan penyimpanan lebih untuk sebuah informasi.
Sebagai contoh detail dari mahasiswa yang akan disimpan sebagai record mahasiswa.
9.3.1.4 Control class

Control class berfungsi untuk menggambarkan koordinasi, urutan, transaksi dan
kontrol dari objek lain. Seperti halnya sebuah keterikatan antara elemen boundary dan
elemen entitas, yang bisa menggambarkan kebutuhan logis untuk mengatur berbagai
macam elemen dan interaksinya. Dibutuhkan minimal satu Control class untuk setiap
use case.
Contoh dari stereotype class dapat dilihat pada gambar di bawah ini:
<<control>>
<<boundary> <<boundary>>
Actor 1 >
Actor 2
<<entity>> <<entity>>
9.3.2 Sequence Diagram

Diagram sekuen menggambarkan perilaku objek pada use case dengan
mendeskripsikan waktu hidup objek dan message yang dikirimkan dan diterima antar
objek. Oleh karena itu harus diketahui objek-objek yang terlibat dalam sebuah use case
beserta metode-metode yang dimiliki klas yang diinstansiasi objek tersebut.
boundary entity control
Diagram sekuen yang dibuat minimal sebanyak pendefinisian use case yang memiliki
proses sendiri atau interaksi jalannya pesan sudah diidentifikasi. Elemen-elemen yang
ada pada diagram sekuen adalah objek, garis putus-putus dan pesan.
Fungsi dari tiap elemen dari diagram sekuen:
a. Objek: menggambarkan objek yang berinteraksi pesan. Wujud dari elemen ini adalah
kotak.
b. Dashed line atau garis putus-putus: menyatakan kehidupan sebuah objek dan
disebut sebagai lifeline.
c. Message/pesan: digambarkan dalam bentuk panah dengan garis horizontal yang
berfungsi melewatkan pesan dari objek ke objek yang lain sebagai tanda bahwa
objek tersebut melewati jalur hidupnya.
9.4 Tugas
1. Berdasarkan studi kasus : Vario Advertising, lakukan analisis sequence diagram termasuk
identifikasi objek-objek yang saling berinteraksi satu dengan yang lain berdasarkan
kebutuhan yang telah di definisikan sebelumnya !
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
2. Berdasarkan studi kasus : Vario Advertising, lakukan analisis class diagram termasuk
identifikasi objek-objek yang saling berinteraksi satu dengan yang lain berdasarkan
kebutuhan yang telah di definisikan sebelumnya !
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
Modul 10 : PROYEK DAN DEMOSTRASI PEMODELAN KEBUTUHAN
BERORIENTASI OBJEK
10.2 Tujuan
2. Mahasiswa mampu memodelkan dengan menggunakan use case diagram, use case
scenario, analisis class diagram, dan analisis sequence diagram dari studi kasus yang
diberikan
3. Mahasiswa mampu mempresentasikan hasil pemodelan kebutuhan.
10.3 Tugas
Perhatikan deskripsi sistem berikut ini :
Sistem reservasi hotel adalah sistem yang berfungsi untuk membantu para calon
tamu dalam memesan kamar hotel. Tamu dapat mengisi formulir data diri, menentukan
tipe kamar dan dapat memberikan permintaan khusus. Permintaan khusus ini
menentukan ada atau tidaknya dan bagaimana tambahan fasilitas kamar yang
disediakan oleh pihak hotel. Kemudian sistem dapat memberikan informasi harga kamar
dari hotel kepada calon tamu. Setelah pemesanan dilakukan maka tamu akan
mendapatkan bukti pemesanan kamar hotel. Kemudian dari sisi pihak hotel, pihal hotel
akan mendapatkan detail data pemesanan kamar dan data diri tamu. Pihak hotel dapat
mempublikasikan informasi tentang kondisi kamar yang dapat dipesan. Pihak hotel
memiliki informasi tentang ketersediaan kamar yang menentukan pemesanan dapat
dilakukan atau tidak.
a. Gambarkan Use Case Diagram dari studi kasus tersebut.
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
b. Buatlah Use Case Scenario dari studi kasus tersebut.

_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
c. Buatlah sequence diagram dari studi kasus tersebut.
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
d. Lakukan analisis class dari studi kasus tersebut.

_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
Modul 11 : PEMODELAN PERANCANGAN TERSTRUKTUR
(ARSITEKTUR MODUL)
11.2 Tujuan
1. Mahasiswa mampu memahami konsep pemodelan perancangan terstruktur
2. Mahasiswa mampu menerapkan langkah-langkah perancangan terstruktur
3. Mahasiswa mampu menyusun perancangan yang memenuhi parameter kualitas
perancangan
11.3 Dasar Teori

Pemodelan perancangan terstruktur adalah metode untuk memodelkan suatu
rancangan yang dibangun dengan pendekatan terstruktur. Pemodelan ini menggunakan
model DFD (Data Flow Diagram) sebagai dasar dalam mentransformasi (Transform
Mapping).
Langkah-langkah dalam melakukan Transform Mapping adalah sebagai berikut.
1. Review dan refine DFD sampai ke level paling bawah.
Pada proses ini, DFD pada level terbawah kemudian digabung menjadi satu
perspektif. Sebagai contoh DFD berikut.
6.3*
Sensor
Format for
information
display
Configuration Configuration
Information Sensor ID, type,
data location
6.2*
Assess Against
Setup
6.4*
Alarm data Generate Alarm
Signal Alarm type
Sensor ID, type Telephone

number
6.1
Read Sensor
6.5* Telephone
Sensor status Dial Phone Number tones
Gambar 8. DFD 1
Pada gambar satu terdapat lima proses dimana proses enam poin dua, tiga, dan lima
merupakan proses-proses yang harus didekomposisi. Sedangkan proses enam poin 1 dan
4 tidak perlu didekomposisi, sehingga hasil dekomposisinya menjadi seperti gambar
berikut.
Format ID, type,

location Sensor Dekomposisi
Configuration 6 9 Information
information Format display Generate Display
Proses 6.3
Configuration
data
Sensor ID, type, 7 Alarm type

Sensor Status location Generate alarm
signal
1
Read Sensor
Alarm data
2 Telephone
Sensor ID, tones
Acquire response
Type
info
3
Alarm cond code, Establish 8
Sensor ID, Alarm Generate pulses
timing information condition 4 to line
List of Select phone 5
number number Set up conn. To
Telephone phone net Tone ready Dekomposisi
Dekomposisi number Telephone number Proses 6.5
Proses 6.2
Gambar 9. DFD 2
2. Tentukan apakah DFD tsb. memiliki karakteristik tipe transform flow atau
transaction flow.
Untuk dapat menentukan karakteristik DFD memiliki tipe transform flow atau
transaction flow maka dapat kita lihat contoh DFD berikut.
Gambar 10. DFD 3

Pada gambar tiga merupakan DFD yang bertipe transform flow. Pada DFD ini
terdapat tiga bagian yaitu:
• Incoming flow : aliran/ jalur informasi eksternal masuk ke sistem untuk
ditransformasikan menjadi informasi internal,
• Transform center : pusat transformasi di dalam sistem yang akan me-trigger
informasi keluar dari sistem,
• Outgoing flow: aliran/ jalur informasi internal keluar dari sistem menjadi
informasi eksternal.
Gambar 11. DFD 3
Pada gambar tiga merupakan DFD yang bertipe transaction flow. Pada DFD ini
terdapat tiga bagian yaitu:
• Transaction: data tunggal yang me-trigger satu atau beberapa aliran data,
• Transaction center: penghubung antara aliran-aliran data hasil pen-trigger-an
dengan data trigger-nya,
• Action path: aliran/ jalur informasi hasil trigger.
Perbedaan mendasar dari kedua jenis DFD di atas adalah jika pada Transform Flow,
informasi dari incoming flow akan dirubah menjadi informasi internal dan akan diproses
oleh transform center untuk kemudian digunakan oleh outgoing flow. Sementara jika
pada transaction flow adalah informasi atau transaction akan menentukan action path
mana yang akan dilewati.
Jadi jika ada informasi kemudian berubah menjadi informasi lain maka kita bisa
gunakan transform flow. Sementara jika ada informasi yang sifatnya semacam kondisi
yang dapat mengaktifkan proses yang berbeda-beda maka sebaiknya kita pilih
transaction flow.
3. Tentukan batas antara incoming flow, transform center dan outgoing flow atau
incoming path/transaction, transaction center dan action path.
Untuk menentukan batas tentunya harus memahami proses dan informasi yang
dibuat. Jika sudah dapat menentukan jenis DFD yang dibuat selanjutnya dapat
menentukan batasnya. Sebagai contoh adalah gambar berikut.
Format ID, type,

location Sensor
Configuration 6 9 Information
information Format display Generate Display
Configuration
data
INCOMING FLOW
Sensor ID, type, 7 Alarm type

Sensor Status location Generate alarm
signal OUTGOING FLOW
1
Read Sensor
Alarm data
2 Telephone
Sensor ID, tones
Acquire response
Type
info
3
Alarm cond code, Establish 8
Sensor ID, Alarm Generate pulses
timing information condition 4 to line
List of Select phone 5
number number Set up conn. To
Telephone phone net Tone ready
number Telephone number
TRANSFORM
CENTRE
Gambar 12. DFD 4
4. Bangun first level factoring.

DFD yang sudah dipetakan pada gambar lima kemudian di transformasi menjadi
arsitektur modul (lihat gambar 5). Incoming Flow dibuat ke dalam modul sensor input
controller. Transform Center dibuat kedalam modul alarm conditions controller.
Outgoing Flow dibuat ke dalam modul alarm output controller.
Configuration
information 6 9
7
1
2
3
8
4
5
Monitor Sensor
Executive
Sensor Input Alarm Condition Alarm Output

Controller Controller Controller
Gambar 13. DFD 5
Untuk gambar enam kemudian juga dilakukan first level factoring menjadi arsitektur
modul yang tergambar pada gambar berikut.
User
System parameters
Command Raw
and data
Configuration
data
Formatted
Read user Command
Configuration
command type Read System Build
data
data configuration file
Configuration information
Configure
Invoke command
processing Start/stop
Configuration data
Activate/
deactive A/D Data
system
Display messages
Password and status
Configuration
data Display
Password information
Read
Password
Valid Password
Compare
Four Digits password with
file
Produce
Try Again message
invalid message
Invalid Password
Gambar 14. DFD 5

5. Bangun second level factoring.
Second level factoring adalah proses untuk memetakan proses-proses yang ada pada
masing-masing incoming flow, transform center, outgoing flow ke dalam bagian-bagian
pada modul yang sudah ada pada first level factoring. Sebagai contoh adalah gambar
berikut.
Monitor Sensor
Executive
Sensor Input Alarm Condition Alarm Output

Alarm Output Alarm Output Alarm Output Alarm Output Alarm Output Alarm Output
Controller Controller Controller Controller Controller Controller
Alarm Output Alarm Output Alarm Output

Gambar 15. Arsitektur Modul 1
Proses Second Level Factoring untuk contoh transaction flow kemudian menjadi
bentuk gambar berikut.
User interaction
interactive
Invoke command
Read user command
processing
System configuration Activate/deactive Password processing

controller system controller
Build configuration Compare password Password output

Ready system data Read Password
controller with file controller
Display message and Produce invalid

status message

6. Refine first iteration.
Proses selanjutnya adalah refine first iteration yaitu proses untuk membuat desain
menjadi sederhana, memiliki kohesifitas yang tinggi, tingkat kopling yang rendah dan
memiliki struktur yang mudah untuk diimplementasikan. Hasil dari first level factoring
kemudian diubah menjadi bentuk lebih sederhana pada gambar berikut.
Monitor Sensor
Executive
Sensor Input Establish alarm Alarm Output

Controller condition Controller
Alarm Output Set up conn to phone

Read Sensor Produce Display
Controller net
Generate pulse to line
• Incoming controller dihapus: data input tunggal, cukup sederhana.

• Transform controller dihapus dan digabung dalam satu modul: ada
penurunan tingkat kohesifitas.
• Format display dan generate display digabung: sederhana.
• Hasil first level factoring untuk gambar 10 menjadi bentuk yang lebih
sederhana tampak pada gambar berikut.
User Interaction
Executive
Invoke command
Read user command
processing
System Configuration Activate/deactive Password processing

controller system controller
System Configuration System Configuration System Configuration System Configuration System Configuration
controller controller controller controller controller
Setelah semua tahap dilalui, kemudian langkah terakhir adalah menggabung

keseluruhan arsitektur modul kedalam satu rangkaian arsitektur modul. Hasil
penggabungan arsitektur Software Safehome Security dapat dilihat pada gambar berikut.
Safe home
security
Monitor
Sensor
Executive
User Interaction
Executive
Establish Alarm
Sensor Input
alarm Output
Controller
condition Controller
Invoke
Read user
command
command Alarm
processing Produce Set up conn
Read Sensor Output
Display to phone net
Controller
System Password Generate

Activate/
Configuration processing pulse to line
deactive system
controller controller
System System System System System

Configuration Configuration Configuration Configuration Configuration
controller controller controller controller controller
Masing-masing modul kemudian berisi algoritma yang didapatkan dari

P-SPEC, C-SPEC pada masing-masing proses yang ada pada DFD.
Pseudocode
Pseudocode adalah metode penulisan bahasa inggris sederhana yang
merepresentasikan lojik algoritma pemrograman. Pseudo berarti tiruan, sedangkan Code
adalah kode program sehingga pseudocode bisa disebut sebagai kode tiruan dari
program sebenarnya yang dituliskan dalam standar bahasa inggris untuk mendekatkan
dengan perintah-perintah yang terdapat pada bahasa pemrograman. Setiap Pseudocode
akan selalu terdiri dari tiga bagian yaitu :
Judul (Header)
{Berisi Judul Algoritma/ method}
Kamus ( Deklarasi )
{Berisi Deklarasi Variabel atau Konstantan}
Algoritma ( Deskripsi )
{Berisi Inti Algoritma}
11.4 Tugas
1. Berdasarkan DFD yang telah dibuat untuk studi kasus: Vario Advertising tentukan karakteristik
DFD tersebut.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
2. Gambarkan batas-batas pada DFD tersebut sesuai dengan karakteristiknya!
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
3. Lakukan First Level Factoring!
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
4. Lakukan Second level factoring.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
5. Lakukan Refine First level factoring.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
Modul 12 : PEMODELAN PERANCANGAN BERORIENTASI OBJEK
(SEQUENCE DIAGRAM)
12.2 Tujuan
1. Mahasiswa mampu memahami konsep pemodelan perancangan berorientasi objek
2. Mahasiswa mampu mentransformasikan model kebutuhan kedalam model
perancangan OO dengan UML
12.3 Dasar Teori

Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar
sistem (termasuk pengguna, display, dan sebagainya) berupa message yang
digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu)
dan dimensi horizontal (objek-objek yang terkait). Sequence diagram biasa digunakan
untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai
respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang
men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara
internal dan output apa yang dihasilkan. Masing-masing objek, termasuk aktor, memiliki
lifeline vertikal. Message digambarkan sebagai garis berpanah dari satu objek ke objek
lainnya.
Pada fase desain berikutnya, message akan dipetakan menjadi operasi/ metoda dari
class yang akan dijelaskan pada sub bab berikutnya. Activation bar menunjukkan
lamanya eksekusi sebuah proses, biasanya diawali dengan diterimanya sebuah message.
Untuk objek-objek yang memiliki sifat khusus, standar UML mendefinisikan ikon khusus
untuk objek boundary, controller dan persistent entity.
Gambar 20. Sequence Diagram
12.4 Tugas
1. Berdasarkan analisis klas modul pemodelan kebutuhan OO, buatlah klas perancangan yang siap
untuk di implementasikan
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
2. Sesuaikan diagram sekuens sesuai dengan level perancangan
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
Modul 13 : PEMODELAN PERANCANGAN BERORIENTASI OBJEK
(CLASS DIAGRAM)
13.2 Tujuan
1. Mahasiswa mampu memahami konsep pemodelan perancangan berorientasi objek
2. Mahasiswa mampu mentransformasikan model kebutuhan kedalam model
perancangan OO dengan UML
13.3 Dasar Teori

Objek adalah gambaran dari entity, baik dunia nyata atau konsep dengan batasan
batasan dan pengertian yang tepat. Objek bisa mewakili sesuatu yang nyata seperti
komputer, mobil atau dapat berupa konsep seperti proses kimia, transaksi bank,
permintaan pembelian, dll. Setiap objek dalam sistem memiliki tiga karakteristik yaitu
State (status), Behaviour (sifat) dan Indentity (identitas).
Cara mengidentifikasi objek:
1. pengelompokan berdasarkan kata/frase benda pada skenario.
2. berdasarkan daftar kategori object, antara lain:
• objek fisik, contoh:pesawat telepon
• spesifikasi/rancangan/deskripsi, contoh: deskripsi pesawat
• tempat, contoh:gudang
• transaksi, contoh: penjualan
• butir yang terlibat pada transaksi, contoh: barang jualan
• peran, contoh :pelanggan
• wadah, contoh : pesawat terbang
• piranti, contoh:PABX
• kata benda abstrak, contoh: kecanduan
• kejadian, contoh:pendaratan
• aturan atau kebijakan, contoh:aturan diskon
• catalog atau rujukan, contoh: daftar pelanggan
Klas adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah
objek atau dengan kata lain Klas merupakan template untuk membentuk object. Klas
merupakan inti dari pengembangan dan desain berorientasi objek. Klas menggambarkan
keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk
memanipulasi keadaan tersebut (metoda/ fungsi).
Class diagram menggambarkan struktur dan deskripsi class, package dan objek
beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain.
Class memiliki tiga area pokok :
1. Nama (dan stereotype)
2. Atribut
3. Metoda/operasi
Penamaan class menggunakan kata benda tunggal yang merupakan abstraksi yang
terbaik. Atribut dan metoda dapat memiliki salah satu sifat berikut :
• Private (-) , tidak dapat dipanggil dari luar class yang bersangkutan
• Protected (#) , hanya dapat dipanggil oleh class yang bersangkutan dan anak anak
yang mewarisinya
• Public (+) , dapat dipanggil oleh siapa saja
- names
- address
+ CreditRating():String
Gambar 21. Class Diagram
Class dapat merupakan implementasi dari sebuah interface, yaitu class abstrak yang
hanya memiliki metoda. Interface tidak dapat langsung diinstansiasikan, tetapi harus
diimplementasikan dahulu menjadi sebuah class. Dengan demikian interface
mendukung resolusi metoda pada saat run-time. Sesuai dengan perkembangan class
model, class dapat dikelompokkan menjadi package. Kita juga dapat membuat diagram
yang terdiri atas package.
Hubungan Antar Class
Dalam Obyek Oriented Design, klas-klas yang terbentuk dapat memiliki hubungan
satu dengan yang lainnya, sesuai dengan kondisi dari klas-klas yang bersangkutan.
Secara umum, hubungan antar kelas dapat dibedakan menjadi Asosiasi, agregasi,
komposisi, dependency, inheritance, realization.
Gambar 22. Hubungan Antar Class
Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class yang
memiliki atribut berupa class lain, atau class yang harus mengetahui eksistensi class lain.
Panah navigability menunjukkan arah query antar class.
Contoh :
Klas diagram dalam kasus “Dosen Mengajar Mahasiswa”. 1 Dosen dapat mengajar
banyak Mahasiswa. Dalam hubungan asosiasi, di dalam Klas Dosen ada link atribut nim
mahasiswa yg diperoleh dari Klas Mahasiswa.
Gambar 23. Contoh Class
Agregasi, yaitu hubungan yang menyatakan suatu klas adalah bagian (“terdiri atas
kumpulan”) dari klas yg lain, namun kedua klas ini bisa berdiri sendiri. Merupakan
hubungan yang lebih kuat dari hubungan asosiasi.
Contoh :
• Klas Jurusan menyimpan nilai atribut dari mahasiswa dengan tipe data Klas
bentukan “Mahasiswa”.
• Mahasiswa dapat memiliki objek sendiri
• Jurusan dapat memiliki objek sendiri
• Mahasiswa menjadi bagian dari jurusannya.
• 1 jurusan bisa memiliki banyak mahasiswa.
Gambar 24. Contoh Class 2
Komposisi, merupakan bentuk khusus dari Agregasi di mana kelas yang menjadi part
(bagian) baru dapat diciptakan setelah kelas yang menjadi whole (seluruhnya) dibuat
dan ketika kelas yang menjadi whole dimusnahkan, maka kelas yang menjadi part ikut
musnah.
Contoh :
• Hubungan komposisi antara sebuah laptop dengan komponennya.
• Contoh objek:
• Laptop Asus A43S memiliki CPU intel core i7; VGA Nvidia 2GB;
• Laptop Toshiba S006 memiliki CPU intel core i5; VGA Nvidia 2GB;
Nilai CPU dan VGA tidak bisa didapat jika tidak melalui nilai objek Laptop. Ada
ketergantungan penuh dari class CPU & VGA ke Laptop, dengan Kata lain jika Laptop
tidak ada maka CPU dan VGA juga tidak ada.
Dependency, yaitu hubungan dimana satu klas tergantung/menggunakan klas yang

lain secara langsung.
Contoh :
Klas Car menggunakan attribut atau method yang ada di Klas Wheel secara langsung
tanpa instansiasi objek Wheel.
Pewarisan (inheritance), yaitu hubungan hirarkis antar class. Class dapat diturunkan
dari class lain dan mewarisi semua atribut dan metoda class asalnya dan menambahkan
fungsionalitas baru, sehingga ia disebut anak (subclass) dari class yang diwarisinya
(superclass). Operasi pada superclass dapat di-override oleh subclass (konsep
polymorphism). Kebalikan dari pewarisan adalah generalisasi.
Contoh :
Klas Shape adalah super class dari Klas Square dan Circle, sehingga atribut dan
method Klas Shape diwarisi oleh Klas Square dan Circle namun Klas Square dan Circle
bisa memiliki atribut maupun method yg spesifik.
Realization, Hubungan antara Interface dan Klas, di mana suatu Klas (klien)
mengimplement perilaku dari interface namun secara spesifik menentukan perilaku di
dalam Klas.
Interface adalah prototype klas yang berisi definisi konstanta dan deklarasi
perilaku/method (hanya nama method tanpa definisi kode programnya).
Ciri sebuah interface:

• Semua atribut adalah public dan final (semua atribut bertindak sebagai konstanta).
Dapat juga menambahkan modifier static.
• Semua method adalah abstract dan public
• Tidak boleh ada deklarasi konstruktor.
Contoh :
13.4 Tugas
1. Berdasarkan analisis klas modul pemodelan kebutuhan OO, buatlah klas perancangan
yang siap untuk di implementasikan
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
2. Sesuaikan diagram sekuens sesuai dengan level perancangan
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
Modul 14 : PROYEK DAN DEMOSTRASI PEMODELAN PERANCANGAN
BERORIENTASI OBJEK
14.2 Tujuan
1. Mahasiswa mampu menerapkan konsep pemodelan perancangan berorientasi objek
2. Mahasiswa mampu mempresentasikan hasil pemodelan perancangan.
14.3 Tugas
Pabrik perakitan mobil tersebut berkeinginan untuk membuat program aplikasi
berbasis Web atau Desktop dengan kasus penggunaan sebagai berikut:
a. Simulasi perakitan mobil dilakukan oleh seorang Operator
b. Simulasi yang dapat dilakukan adalah simulasi pembuatan, pemasangan, dan operasi
yang dapat dilakukan oleh seluruh komponen Mobil
c. Proses simulasi sistem yang dilakukan oleh hanya dapat dilakukan setelah seorang
Manajer mengaktifkan program simulasi
d. Visualisasi proses simulasi yang dilakukan ditampilkan dalam dua antarmuka, satu
untuk Operator dan satu untuk Manajer.
e. Operator dapat melakukan seluruh operasi simulasi dan melihat tampilan simulasi
secara visual.
f. Selain dapat mengaktifkan dan menonaktifkan program simulasi, seorang Manajer
dapat melihat seluruh rangkaian proses simulasi.
Jawablah beberapa soal berikut dengan tepat, jelas, dan spesifik!
1. Lakukan analisis fungsionalitas dan penggunaan sistem lengkap dan lakukan pemodelan
dengan menggunakan Model Use Case (Use Case Diagram dan Use Case Specification)
berdasarkan kasus penggunaan program yang telah diuraikan!
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
2. Gambarkan aktivitas skenario penggunaan program/ sistem dalam Activity Diagram.
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
3. Lakukan analisis Boundary, Control, dan Entity dalam untuk setiap aktivitas yang
tergambar dalam skenario penggunan/use case scenario dan wujudkan dalam Sequence
Diagram.
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
4. Gambarkan objek yang telah diidentifikasi dalam soal No.3 dan lengkapi dengan jenis
relasi, kardinalitas, dan modalitas antar class dalam Class Diagram!
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
5. Gambarkan Class Diagram lengkap beserta atribut, method, visibility, relasi, kardinalitas,
dan modularitas relasi antar objek yang diperoleh dari hasil analisis class dan analisis
Boundary, Control, dan Entity sehingga siap untuk diimplementasikan!

SDLC

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

SDLC

Diunggah oleh

Hak Cipta:

Format Tersedia

Hanya dipergunakan di lingkungan Jurusan Teknik Informatika UB

Yang bertanda tangan dibawah ini :

No Keterangan Revisi Tanggal Revisi Terakhir

1 Revisi Bagian Pertama …………………………….

Yang bertanda tangan dibawah ini :

Jabatan : Ka. Lab Pembelajaran

Malang, 22 Januari 2018

Koordinator KJFD …………………………….

1. Tidak berambut gondrong untuk mahasiswa

3. Dilarang menyimpan barang-barang milik pribadi di Laboratorium/Kelas tanpa seijin Fakultas

4. Dilarang menginap di Laboratorium/Kelas tanpa seijin Fakultas

Gambar 1. Waterfall Model .................................................................................................................. 11

0.2 Peraturan Praktikum

1.3 Dasar Teori

1.3.1 Waterfall Model

Gambar 1. Waterfall Model

1.3.2 Prototype Model

Gambar 2. Prototype Model

2. Tuliskan kelebihan dan kelemahan pada masing-masing SDLC.

2.3 Dasar Teori

2. Sebutkan dan gambarkan contoh-contoh pemodelan perangkat lunak

3.3 Dasar Teori

2. Menentukan lingkungan teknis (misalnya, komputasi arsitektur, sistem operasi,

3. Identifikasi ranah permasalahan, yaitu karakteristik lingkungan bisnis yang

4. Menentukan satu atau lebih metode elisitasi kebutuhan misalnya wawancara,

6. Mengidentifikasi kebutuhan yang ambigu dan menyelesaikannya.

7. Membuat skenario penggunaan untuk membantu pelanggan/ pengguna

Deskripsikan pemangku kepentingan dari sistem layanan ATM suatu bank.

1. Nasabah Bank: yaitu orang yang menerima layanan sistem

3. Manajer Bank: orang yang memperoleh informasi manajemen dari sistem

4. Administrator Basis data: orang yang bertanggung jawab untuk menggabungkan

1. Wawancara, pada saat wawancara analis sistem memberikan beberapa

2. Kuisioner, didesain dengan menggunakan standar kuisioner, kuisioner dikirim ke

3. Observasi, kegiatan ini dilakukan dengan mengunjungi lokasi pengamatan dan

Definisi kebutuhan (requirement definition) :

Spesifikasi kebutuhan (requirement specification) :

2. Consistency, apakah ada kebutuhan yang konflik?

3. Comprehensibility, apakah semua fungsi yang diinginkan customer sudah tercakup

1. Identifikasi, bagaimana setiap kebutuhan dapat diidentifikasi dengan mudah (Cont. :

2. Manajemen perubahan, bagaimana mekanisme untuk menangani perubahan

3. Dokumentasi, SRS dan IRS sebagai deliverable, ECP, PCR

Tracking, penelusuran informasi yang berhubungan dengan sebuah kebutuhan

2. Tentukanlah pemangku kepentingan beserta dengan deskripsinya!

3. Susunlah pertanyaan-pertanyaan untuk melakukan elisitasi kebutuhan. Pertanyaan-

4.3 Dasar Teori

Setiap kebutuhan harus menyebutkan tepat seperti yang dibutuhkan. Hindari

3. Attainable (dapat dicapai)

4. Realizable (dapat direalisasikan)

Suatu kebutuhan haruslah dapat direalisasikan dengan mempertimbangkan sumber

5. Traceable/bounded (memiliki dimensi waktu/dapat dilacak)

1. Berdasarkan studi kasus Vario Advertising. Susunlah pernyataan kebutuhan sesuai

2. Perhatikan dan analisis kebutuhan berikut ini:

a. “Sistem dapat melayani permintaan peminjaman ruang rapat secara bersamaan

3. Perhatikan dan analisis kebutuhan berikut ini:

a. “Sistem dapat melayani permintaan peminjaman ruang rapat secara bersamaan

4. Perhatikan dan analisis kebutuhan berikut ini:

5. Perhatikan dan analisis kebutuhan berikut ini:

a. “Sistem memiliki tingkat ketersediaan 100% dan dapat dihandalkan 100%.”

6. Perhatikan dan analisis kebutuhan berikut ini:

a. “Sistem akan memiliki ketersediaan ruang rapat 97%.”

5.3 Dasar Teori

5.3.2 Pemodelan Terstruktur