MODUL

PEMODELAN PERANGKAT LUNAK

Disusun sebagai

Alat Bantu

Belajar Siswa

Kelas XI

Jurusan Rekayasa Perangkat

Lunak Sekolah Menengah

Kejuruan Multistudi High School

SMK Multistudi High

School 2016
 Kata Pengantar

Puji Syukur kami panjatkan ke hadirat Tuhan yang Maha Esa karena berkat anugerah-Nya modul
ini dapat kami selesaikan dengan baik.

Modul ini adalah modul untuk pelajaran Pemodelan Perangkat Lunak yang dilaksanakan di SMK
Multistudi High School untuk Kelas XI RPL. Modul ini disusun sesuai dengan silabus dan buku
sumber yang ada. Modul ini dapat digunakan sebagai alat bantu belajar bagi siswa dan sebagai
pelengkap buku mata pelajaran.

Namun kami juga sebagai manusia tentu tidak luput dari kesalahan dan kekhilafan. Modul ini
masih jauh dari sempurna karena berbagai kekurangan. Demi kesempurnaan modul ini, segala
saran, kritik, dan ulasan dari berbagai pihak tentu kami harapkan.

Demikianlah kata pengantar ini kami tuliskan. Semoga pembaca dapat mempelajari modul ini
dengan baik dan ilmu yang terdapat di dalam modul ini dapat tersampaikan dengan baik pula.

Selamat membaca!

Batam, 24 Januari 2016

Tim Penulis

2
 Daftar Isi

Kover........................................................................................................................................... 1
Kata Pengantar............................................................................................................................ 2
Daftar Isi...................................................................................................................................... 3
Modul 1 : Konsep Pemodelan Perangkat Lunak..........................................................................4
Modul 2 : Model Proses Pengembangan Perangkat Lunak.........................................................6
Modul 3 : Rekayasa Kebutuhan Perangkat Lunak....................................................................... 9
Modul 4 : Diagram Alur Data (DFD)...........................................................................................12
Modul 5 : Diagram Hubungan Antar Entitas (ERD)....................................................................16
Modul 6 : Antar Muka Pengguna (User Interface)......................................................................19
Modul 7 : Arsitektur Perangkat Lunak........................................................................................21
Modul 8 : Pemodelan Sistem Berorientasi Obyek (UML)........................................................... 24
Modul 9 : Kebutuhan Sistem Berbasis Obyek............................................................................26
Modul 10 : Alur Kerja Sistem Berorientasi Obyek......................................................................28
Modul 11 : Hubungan Antar Class.............................................................................................30
Modul 12 : Interaksi Antar Obyek...............................................................................................32
Modul 13 : Siklus Hidup Obyek..................................................................................................35
Modul 14 : Hubungan Antar Komponen.....................................................................................36
Modul 15 : Dokumen Laporan Pengembangan Sistem Berorientasi Obyek...............................38
Latihan....................................................................................................................................... 39
Referensi................................................................................................................................... 42

A. Materi Modul 1 : Konsep Pemodelan Perangkat Lunak

Materi dari Modul 1 mencakup :
1. Konsep Rekayasa Perangkat Lunak
2. Komponen dan Karakteristik Perangkat Lunak
3. Prinsip Analisis dan Desain
4. Ragam Pemodelan Perangkat Lunak

B. Tujuan Pembelajaran
Setelah mempelajari Modul 1, diharapkan siswa dapat :
1. Memahami konsep rekayasa perangkat lunak.
2. Memahami komponen dan karakteristik perangkat lunak
3. Memahami prinsip analisis dan desain dari perangkat lunak.
4. Mengidentifikasi ragam pemodelan perangkat lunak.
5. Menyajikan karakteristik dari ragam pemodelan perangkat lunak.

C. Uraian
Dalam mempelajari rekayasa perangkat lunak, kita terlebih dahulu harus mengerti terlebih
dahulu apa yang dimaksud dengan perangkat lunak. Yang dimaksud dengan perangkat
lunak adalah instruksi yang ketika dijalankan akan menyediakan fitur, fungsi, dan
hasil sesuai dengan yang diinginkan. Perangkat lunak biasanya terdiri dari dua hal,
yaitu program dan prosedur. Program adalah kumpulan perintah yang bisa dimengerti
dan bisa dikerjakan oleh komputer, sedangkan prosedur adalah kumpulan perintah yang
digunakan oleh user untuk melakukan pemrosesan data dan informasi. Dengan kata lain,
prosedur adalah fungsi yang ketika dipilih oleh user akan membuat komputer
menjalankan program yang ada.

Berikut adalah karakteristik dari perangkat lunak :

a. Perangkat lunak dikembangkan tidak seperti pada industri barang secara material,
yang memiliki wujud. Penilaian kualitas dari sebuah perangkat lunak berbeda dari
sebuah perangkat keras, karena hasil kerja dari sebuah perangkat lunak juga
bergantung dari bagaimana hubungan antar pekerja pada pengembangan perangkat
lunak tersebut.
b. Perangkat lunak tidak memiliki keausan seperti pada benda. Perangkat lunak
walaupun sudah berumur lebih dari 10 tahun tetap bisa menjalankan fungsinya
dengan baik. Perangkat lunak tidak mengalami gangguan akibat pengaruh
lingkungan, seperti panas ataupun dingin. Selama koding dari sebuah program tidak
memiliki kesalahan, program bisa terus digunakan hingga perangkat keras yang
memuatnya mengalami kerusakan.
c. Perangkat lunak kebanyakan dibuat secara kustom/individual. Walaupun sudah
terdapat komponen standar dari perangkat lunak, komponen-komponen tersebut baru
sekarang ini mulai digalakkan untuk dipakai kembali (reusable). Pada awalnya hampir
semua komponen tersebut dibuat dari awal. Jadi, walaupun fungsi dari beberapa
perangkat lunak bisa saja memiliki kemiripan, namun cara menjalankan fungsi
tersebut bisa saja berbeda.

Berikut adalah jenis-jenis perangkat lunak :

a. System Software, yaitu perangkat lunak yang digunakan untuk membantu perangkat
lunak lain agar bisa bekerja secara optimal. Perangkat lunak jenis ini jarang
digunakan secara langsung oleh orang awam, tetapi digunakan secara tidak langsung
pada saat program lain ingin dijalankan. Contoh : Compiler, Editor, Komponen-
komponen pada Sistem Operasi, Driver, dan perangkat lunak Jaringan
b. Application Software, yaitu perangkat lunak yang berfungsi untuk mengerjakan
satu fungsi tertentu. Perangkat lunak jenis ini termasuk pada hampir semua
perangkat lunak yang dijual dan diunduh pada internet. Application Software
dibagi lagi menjadi beberapa jenis, tergantung dari fungsi apakah yang ingin dicapai
oleh perangkat lunak tersebut, seperti pengolah kata, pengolah angkat, pengolah
gambar, dan lain-lain.
c. Engineering / Scientific Software, yaitu perangkat lunak yang bersifat keilmuwan,
berfungsi untuk menganalisis angka yang memiliki nilai tertentu dalam proses
ilmu pengetahuan. Perangkat lunak jenis ini bersifat spesifik pada suatu bidang ilmu
tertentu. Contohnya seperti program SPSS untuk menghitung hasil statistik dari
penelitian.
d. Embedded Software, yaitu perangkat lunak yang terdapat bersama-sama dengan
perangkat keras, ‘menempel’ langsung pada sebuah produk atau sistem lain.
Perangkat lunak jenis ini jarang atau bahkan tidak memiliki bentuk terpisah dari
sistem perangkat keras tertentu. Contohnya seperti sistem operasi pada mesin
konsol video game yang tentu khusus hanya terdapat pada mesin itu saja.
e. Web / Mobile Applications, yaitu perangkat lunak yang terdapat pada perangkat
mobile. Secara umum sama dengan Application Software, namun terletak pada
media berbeda.
f. Artificial Intelligence Software, yaitu perangkat lunak yang menggunakan
algoritma khuus untuk menyelesaikan permasalahan kompleks yang tidak bisa
diselesaikan dengan hanya perhitungan, tetapi juga dengan analisa. Perangkat lunak
jenis ini masih umum dikembangkan untuk tujuan akademik dan militer.

Dalam mengembangkan perangkat lunak, tentu dibutuhkan teknik pengembangan

perangkat lunak yang baik sehingga perangkat lunak yang dikembangkan juga bisa
mencapai hasil yang maksimal. Disiplin ilmu yang digunakan dalam pengembangan
perangkat lunak inilah yang kita sebut dengan istilah Rekayasa Perangkat Lunak
(RPL).

Yang dimaksud dengan Rekayasa Perangkat Lunak adalah suatu disiplin ilmu yang
membahas semua aspek produksi perangkat lunak, mulai dari tahap awal yaitu
analisa kebutuhan pengguna, menentukan spesifikasi dari kebutuhan pengguna,
desain, pengkodean, pengujian sampai pemeliharaan sistem setelah digunakan.
Rekayasa Perangkat Lunak mencakup hal seperti manajemen proyek, personil,
anggaran, jadwal, kualitas, hingga pelatihan pengguna.

Dalam Rekayasa Perangkat Lunak, terdapat 5 langkah secara umum, antara lain :
a. Communication, tahap komunikasi dengan pihak perusahaan berkaitan dengan
perangkat lunak yang dibutuhkan, meliputi Project Initiation dan Requirements
Gathering. Project Initiation adalah proses memulai proyek secara resmi.
Requirements Gathering adalah proses mencari kebutuhan akan perangkat lunak dari
perusahaan.
b. Planning, tahap perencanaan perangkat lunak, seperti estimating, scheduling,
dan tracking. Estimating adalah proses memperkirakan cara memenuhi
kebutuhan perusahaan dalam perangkat lunak. Scheduling adalah proses
memperkirakan kapan perangkat lunak akan selesai. Tracking adalah proses
penyusunan jadwal dalam bentuk yang dapat diawasi baik oleh pihak pengembang
maupun pihak perusahaan.
c. Modeling, tahap analisis dari fitur dan algoritma untuk memenuhi kebutuhan
 perusahaan, serta tahap menggambarkan proses analisis dalam bentuk desain
d. Construction, tahap pengerjaan proyek dalam bentuk coding, serta melakukan
percobaan (testing) dari hasil pengerjaan tersebut.
 e. Deployment, tahap pemberian proyek yang sudah selesai kepada pihak perusahaan,
meliputi pemasangan (delivery), layanan bantuan dan pelatihan terhadap perangkat
lunak (support), dan proses meminta umpan balik dari pihak perusahaan
(feedback).

Modul 2 : Model Proses Pengembangan Perangkat Lunak

A. Materi
Materi dari Modul 2 mencakup :
1. Tahapan Proses Pengembangan Perangkat Lunak
2. Ragam Model Proses Pengembangan Perangkat Lunak

B. Tujuan Pembelajaran
Setelah mempelajari Modul 2, diharapkan siswa dapat :

1. Memahami berbagai model proses pengembangan perangkat lunak.

2. Menyajikan karakteristik metode pengembangan perangkat lunak.
3. Menganalisis karakteristik metode pengembangan perangkat lunak.

C. Uraian
Proses pengembangan perangkat lunak (Software Process / Development Paradigm)
adalah sekumpulan tahap yang dibutuhkan untuk mengubah kebutuhan pemakai menjadi
suatu perangkat lunak yang sesuai dengan kebutuhan pemakai. Proses pengembangan
meliputi segala hal yang harus dilakukan dari proses pendefinisian kebutuhan
(Requirement Engineering) hingga menjadi produk perangkat lunak yang siap untuk
digunakan dan sesuai dengan hasil Requirement Engineering.

Segala kegiatan dalam proses pengembangan perangkat lunak dituangkan dalam pemodelan
proses pengembangan perangkat lunak (Software Process Modelling). Pemodelan
proses perangkat lunak (Software Process Modeling) bertujuan untuk merepresentasikan
aktivitas yang terjadi selama pembuatan perangkat lunak dan tahapan yang dilalui.

Pada saat ini terdapat bermacam-macam jenis model pengembangan perangkat lunak
yang masing-masing memiliki karakteristik yang berbeda-beda. Hal ini disebabkan karena
setiap pihak memiliki visi sendiri-sendiri apa saja yang harus dilakukan untuk
mencapai sebuah perangkat lunak yang sempurna.

Jenis model pengembangan perangkat lunak yang telah dikembangkan pun belum
memberikan hasil yang maksimal dan belum teruji.

Jenis Model Proses Pengembangan Perangkat Lunak

1. Waterfall Model atau kadang disebut Linear Sequential Model adalah model
pengembangan perangkat lunak yang paling klasik, bersifat sistematis dengan proses
yang berurut. Dalam model ini, proses pengembangan perangkat lunak dilakukan
secara berurutan. Proses tahap berikutnya tidak bisa dikerjakan apabila tahap
sebelumnya belum selesai. Bagan model Waterfall adalah sebagai berikut :
2. Model V, yang pada dasarnya adalah pengembangan dari Waterfall Model, namun
lebih dirinci kembali, terutama dalam tahap design dan testing.
3. Prototyping, yaitu model pengembangan ini menggunakan bantuan Prototype,
yaitu sebuah perangkat lunak yang bersifat Alpha/Beta yang merupakan uji coba
terhadap Requirement yang sudah ada, sehingga Customer bisa lebih cepat
memberikan Feedback terhadap Prototype tersebut. Hal ini mempercepat proses
Feedback sehingga kesalahan dan kekeliruan dapat cepat diketahui. Model
Prototype pun dibagi lagi menjadi beberapa jenis, yaitu :
a. Concept Prototyping, menganalisa beberapa definisi perangkat lunak
b. Feasibility Prototyping, menganalisa kelayakan dari beberapa solusi perangkat lunak
c. Horizontal Prototyping, menganalisa fungsionalitas dari perangkat lunak
d. Vertical Prototyping, menganalisa kebutuhan sistem dari perangkat lunak
secara mendalam
e. Functional Storyboarding, menganalisa bagaimana data dan informasi digunakan
dalam perangkat lunak

Berikut adalah bagan dari model Prototyping

4. RAD (Rapid Application Development) adalah sebuah proses perkembangan

perangkat lunak yang bersifat sekuensial linier yang menekankan siklus
perkembangan yang sangat pendek dengan menggunakan pendekatan konstruksi
berbasis komponen. Maksud dari sifat sekuensial linier adalah proses perkembangan
yang bersifat siklus (berputar terus) dengan tahapan yang diulang-ulang. Berikut
adalah bagan dari RAD :
5. Spiral Model (Spiral Boehm) adalah model yang dikembangkan tahun 1988 oleh
Barry Boehm.
Spiral model adalah pendekatan proses pembuatan perangkat lunak yang
menggabungkan metode perulangan seperti pada model prototyping dengan
aspek sistematis (keteraturan) yang dikembangkan model waterfall. Tahap-tahap
dalam model Spiral sebenarnya sama saja dengan yang ada pada model
Waterfall, namun yang berbeda adalah di dalam Spiral Model terdapat analisis
resiko untuk mempertimbangkan resiko yang mungkin muncul dalam setiap kali
perulangan proses. Bagan dari model Spiral adalah sebagai berikut

6. Model 4GT, yaitu model yang menggunakan bantuan 4GT. Istilah Fourth
Generation Techniques (4GT) mencakup seperangkat peralatan perangkat lunak
yang berfungsi sebagai perangkat bantu yang memudahkan seorang
pengembang software mengaplikasi beberapa software pada tingkat yang tinggi,
yang akan menghasilkan source code dan object code secara otomatis sesuai
dengan spesifikasi (persyaratan khusus) yang dibuat oleh sang pengembang
perangkat lunak. Pada dasarnya, metode ini menggunakan peralatan perangkat lunak
eksternal untuk membantu menyelesaikan proses pembuatan perangkat lunak.
Berikut adalah bagan dari model 4GT
 Modul 3 : Rekayasa Kebutuhan Perangkat Lunak
A. Materi
Materi dari Modul 3 mencakup :
1. Tipe Kebutuhan dan Penggunannya
2. Ukuran Kebutuhan
3. Tahapan Proses Rekayasa Kebutuhan
4. Teknik Analisa Kebutuhan
5. Perancangan Kebutuhan Perangkat Lunak

B. Tujuan Pembelajaran
Setelah mempelajari Modul 3, diharapkan siswa dapat :

1. Memahami jenis-jenis kebutuhan dalam rekayasa kebutuhan perangkat lunak.

2. Menyajikan hasil rancangan kebutuhan fungsionalitas dari sistem perangkat lunak
yang diminta sesuai dengan dunia nyata.

C. Uraian
Seperti yang telah disebutkan pada modul sebelumnya, perangkat lunak dibuat untuk
memenuhi tujuan atau kebutuhan tertentu. Yang dimaksud dengan kebutuhan atau
requirement adalah deskripsi dari layanan perangkat lunak serta batasan dari
layanan tersebut yang muncul saat penggunaan perangkat lunak. Sangatlah penting
untuk dapat menghasilkan deskripsi dari kebutuhan dengan jelas sehingga perangkat
lunak yang dihasilkan tepat sasaran.

Proses pendefinisian dari Requirement inilah yang disebut dengan Rekayasa Kebutuhan
Perangkat Lunak (Requirement Engineering). Dalam proses inilah pihak
pengembang mencari tahu, menganalisa, dan meneliti kira-kira apa kebutuhan yang
harus dapat dipenuhi oleh sebuah perangkat lunak.

Menurut sasaran, Requirement bisa dibagi menjadi dua, antara lain :

1. User Requirement, yaitu pernyataan kebutuhan dalam bahasa natural dan
ditujukan kepada pihak pengguna secara umum. Biasanya dibaca oleh pihak
Client/Customer, Pengguna, dan Manager.
2. System Requirement, yaitu pernyataan terstruktur mengenai deskripsi dari
layanan perangkat lunak. Ditujukan kepada pihak pengembang. Biasanya dibaca
oleh Developer, Architect, dan Desainer.

Berdasarkan fungsionalnya, Requirement bisa dibagi menjadi tiga, antara lain :

1. Functional Requirement, yaitu kebutuhan dari perangkat lunak yang

berhubungan langsung dengan fungsi dan layanan dari sebuah perangkat lunak.
Requirement ini harus didefinisikan dengan baik oleh pihak Client supaya tidak terjadi
kesalahpahaman yang dapat mengakibatkan perangkat lunak yang dihasilkan tidak
tepat sasaran. Functional Requirement harus dapat didefinisikan dengan lengkap
dan tidak saling kontradiktif. Contoh Functional Requirement : Sistem Pendataan
Siswa tentu harus bisa diinputkan data siswa, dan kemudian menampilkan data
siswa yang telah dimasukkan.
2. Non-Functional Requirement, yaitu kebutuhan dari perangkat lunak yang berhubungan
dengan kinerja dari perangkat lunak secara keseluruhan. Umumnya requirement
ini disesuaikan dengan kondisi pemakaian perangkat lunak. Requirement ini bersifat
lebih kritis daripada Functional Requirement. Bahkan terkadang Non-Functional
Requirement yang muncul dapat mengubah, mengganti, atau menghilangkan
Functional Requirement. Apabila Non-Functional Requirement tidak terpenuhi, maka
perangkat lunak mungkin memiliki fungsi yang sesuai, tetapi tidak dapat digunakan.
Non-Functional Requirement sendiri bisa dibagi lagi menjadi beberapa kategori,
yang dapat dilihat pada bagan di bawah.

Secara singkat, Non-Functional Requirement bisa dibagi menjadi tiga, yaitu :

a. Product Requirement, yaitu Non-Functional Requirement yang berasal dari fungsi
perangkat lunak. Biasanya Product Requirement lebih ke arah penjelasan
dan hambatan yang mungkin saja terjadi saat pemakaian perangkat lunak.
Biasanya berhubungan dengan tempat penyimpanan, efisiensi, pemakaian,
alat yang digunakan, serta keamanan perangkat lunak. Contohnya : Sistem
pendataan siswa memerlukan tempat penyimpanan 500 kb per orang karena
terdapat foto siswa di dalam data siswa tersebut.
 b. Organizational Requirement, yaitu Non-Functional Requirement yang berasal dari
organisasi atau perusahaan tempat perangkat lunak tersebut akan dipergunakan.
Biasanya Organizational Requirement berhubungan dengan kebijakan khusus
yang hanya berlaku pada perusahaan itu saja dan bersifat unik untuk setiap
perusahaan. Biaanya berhubungan dengan pemakaian tempat, waktu
operasional, dan pengembangan dari perusahaan itu sendiri. Contohnya : sistem
pendataan siswa hanya akan aktif saat jam sekolah saja, yaitu dari hari Senin
sampai Jum’at dari jam
07.00 WIB sampai 16.00 WIB.
c. External Requirement, yaitu Non-Functional Requirement yang berasal dari
lingkungan luar organisasi maupun perangkat lunak itu sendiri. Biasanya External
Requirement muncul dari kondisi lingkungan sekitar yang harus disesuaikan
ke dalam perangkat lunak tersebut. Yang dimaksud dengan lingkungan sekitar
bisa dari peraturan atau Undang-Undang yang berlaku, norma dan etika, dan
dari segi keamanan daerah tersebut. Contohnya : Sistem pendataan siswa
mengharuskan siswa mencantumkan agama sesuai dengan Sila Pertama
Pancasila.
3. Domain Requirement, yaitu pembatasan dari Functional ataupun Non-Functional
Requirement yang terjadi pada saat perangkat lunak digunakan. Domain
Requirement biasanya baru dapat diketahui pada saat perangkat lunak
digunakan, sehingga membutuhkan bantuan seorang spesialis pada bidangnya
untuk dapat mendeteksi Domain Requirement lebih cepat. Apabila Domain
Requirement tidak terpenuhi, maka ada kemungkinan perangkat lunak tidak dapat
dimanfaatkan secara optimal. Contoh Domain Requirement : Sistem Pendataan
Siswa ternyata hanya bisa digunakan oleh satu siswa untuk satu waktu, tidak dapat
digunakan secara bersamaan
Pada umumnya ada 4 tahap dalam proses Requirement Engineering, yaitu :

1. Requirement Elicitation, proses menemukan Requirement dari sebuah perangkat

lunak. Biasanya proses ini dikerjakan bersama-sama dengan Requirement Analysis.
Proses ini melibatkan pihak Client untuk mengetahui sebanyak mungkin dan
sejelas mungkin Requirement yang ada dari perangkat lunak yang akan
dikembangkan.
2. Requirement Analysis, proses menganalisis Requirement yang berhasil ditemukan.
Dalam proses ini terdapat tahap-tahap sebagai berikut :
a. Requirement Classification and Organization, mengelompokkan Requirement
yang saling berhubungan sehingga mudah untuk dibaca oleh pihak
lainnya. Biasanya dikelompokkan berdasarkan kesamaan fungsi atau fitur
yang diinginkan.
b. Requirement Prioritisation and Negotiation, memberi prioritas
Requirement mana yang mungkin untuk dikerjakan, kemudian
dinegosiasikan kepada pihak Client mengenai Requirement prioritas serta
Requirement yang saling bertolak belakang. Dalam proses inilah sangat
dibutuhkan kerja sama Client untuk mengklarifikasi dan mendefinisikan
Requirement secara baik dan benar.
c. Requirement Specification, penulisan atau dokumentasi Requirement sesuai
dengan hasil tahapan sebelumnya.
3. Requirement Validation, menguji secara pasti apakah Requirement sudah sesuai
dengan keinginan User. Tahap ini biasanya dilakukan untuk mendefinisikan
kembali Requirement dalam bentuk yang dimengerti oleh pihak pengembang. Hal
yang diperiksa seperti :
a. Validity, apakah fungsinya sudah sesuai
b. Consistency, apakah fungsi memiliki kontradiksi dengan fungsi lain
 c. Completeness, apakah fungsi sudah lengkap
d. Realism, mampukah fungsi dikerjakan sesuai dengan dana, waktu, dan
teknologi yang ada
e. Verifiability, bisakah requirement diperiksa kesesuaiannya

Cara untuk memvalidasi Requirement bisa melalui :

a. Review, dilakukan melalui dokumentasi (dibaca ulang) secara manual

b. Prototyping, dibuat model percobaan sehingga bisa dilihat dulu sampel
dari Requirement tersebut
c. Test Case, dibuat contoh kasus yang sesuai dengan Requirement
kemudian menguji apakah Requirement valid atau tidak
4. Requirement Management, proses mengelola Requirement, mulai dari Requirement
yang muncul pertama kali dengan requirement yang muncul di saat berikutnya.
Hal ini digunakan untuk menjaga konsistensi dari keseluruhan fitur dan proses sistem
sehingga tidak memunculkan masalah ataupun error di kemudian hari.

Modul 4 : Diagram Alur Data (DFD)

A. Materi
Materi dari Modul 4 mencakup :
1. Fungsi dan Komponen DFD
2. Tingkatan Level DFD
3. Spesifikasi Proses
4. Tahapan Pembuatan DFD

B. Tujuan Pembelajaran
Setelah mempelajari Modul 4, diharapkan siswa dapat :

1. Memahami konsep diagram alur data.

2. Memahami dan menggunakan bangun dalam diagram alur data
3. Menyajikan diagram alur data dari sebuah perangkat lunak

C. Uraian
DFD adalah singkatan dari Data Flow Diagram, yaitu sebuah diagram yang
menggambarkan bagaimana data inputan masuk ke dalam suatu proses, dan
kemudian proses itu menghasilkan data output. Secara singkat, DFD adalah penjabaran
proses dari perangkat lunak berdasarkan alur data, mulai dari data apa yang dimasukkan
ke dalam perangkat lunak, proses apa yang kemudian dijalankan perangkat lunak, dan
apa hasil yang akan dihasilkan oleh perangkat lunak tersebut. DFD menggunakan panah
sebagai arah data, yang masuk ke dalam sistem, kemudian output atau informasi yang
dihasilkan diarahkan keluar dari sistem.

DFD disusun secara hierarkis atau bertingkat berdasarkan Level (lv.). DFD Lv. 0 (sering
juga disebut diagram konteks) adalah DFD utama yang menggambarkan keseluruhan
sistem. Baru
kemudian DFD Lv. 1 menggambarkan secara lebih jelas proses dari DFD Lv. 0.
DFD Lv. 2 kemudian menggambarkan secara lebih rinci lagi proses dari DFD Lv.1,
dan demikian seterusnya.

Banyak cara penggambaran DFD. Berikut adalah contoh simbol DFD menurut
Gane and Sarson.

1. Process, menggambarkan proses dalam sistem.

2. Data Store, menggambarkan tabel yang terdapat pada basis data.
3. Source and/or Destination, menggambarkan asal dan tujuan dari data inputan
ataupun data output
4. Data Flow, menggambarkan arah aliran data

Dalam menggambarkan DFD, arah aliran data yang diperbolehkan adalah :

1. Source/Destination boleh memiliki arah aliran data menuju Process dan sebaliknya
2. Process boleh memiliki arah aliran data ke Data Store dan sebaliknya
3. Process boleh memiliki arah aliran data ke Process

lainnya. Arah aliran data yang tidak diperbolehkan antara

lain :

1. Source/Destination tidak boleh memiliki arah aliran data menuju

Source/Destinantion yang lainnya, karena ini menandakan proses aliran data di
luar sistem
2. Source/Destination tidak boleh memiliki arah aliran data menuju Data Store dan
sebaliknya, karena ini menandakan bahwa pihak di luar sistem dapat
berhubungan langsung dengan basis data pada perangkat lunak. Dilihat dari sudut
pandang keamanan sistem, hal ini sangat tidak diperbolehkan.

Dalam menggambarkan proses, pada DFD Lv.1 diberikan penomoran pada bagian
atasnya. Hal ini untuk memudahkan User untuk membaca DFD, juga untuk memudahkan
Desainer untuk membuat DFD Lv.2 dan seterusnya. Nomor yang digunakan tinggal
direferensikan lagi sehingga tidak terjadi kebingungan saat membaca lebih dari satu
DFD.

Umumnya DFD Lv.1 adalah DFD yang paling kompleks, karena pada diagram
ini kita menjelaskan semua proses yang dapat dilakukan pada perangkat
lunak.

contoh DFD

DFD lv. 0 (Diagram Konteks)

DFD lv.1
DFD lv.2 Proses 4
 Modul 5 : Diagram Hubungan Antar Entitas (ERD)
A. Materi
Materi dari Modul 5 mencakup :
1. Conceptual Data Model
2. Physical Data Model
3. Transformasi Physical Data Model ke SQL

B. Tujuan Pembelajaran
Setelah mempelajari Modul 5, diharapkan siswa dapat :

1. Memahami konsep ERD.

2. Memahami dan menggunakan bangun dalam ERD.
3. Menyajikan ERD dari sebuah perangkat lunak.
4. Menyajikan ERD dalam bahasa SQL.

C. Uraian
Dalam perangkat lunak, terutama yang digunakan dalam sebuah perusahaan, umumnya
memiliki basis data sebagai tempat penyimpanan data yang digunakan oleh perangkat
lunak tersebut. Pengelolaan basis data tentulah menjadi hal yang dipertimbangkan
supaya basis data yang digunakan dapat sesuai dengan kebutuhan perangkat lunak dan
tentunya kepada pihak Client.

Basis data digambarkan terlebih dahulu dalam bentuk Conceptual Data Model dan
Physical Data Model. Conceptual dan Physical Data Model adalah model data yang biasa
digunakan untuk menggambarkan basis data dari sebuah sistem. Conceptual dan
Physical Data Model dibuat untuk mengetahui lebih lanjut apa saja yang harus dicatat
dan disimpan di dalam sebuah basis data. Perbedaannya, Conceptual Data Model
dibuat sebagai model data yang bersifat hardware independent dan software
independent. Sedangkan Physical Data Model dibuat sebagai model data yang bersifat
hardware dependent dan software dependent.

Conceptual Data Model biasanya digambarkan dengan menggunakan Entity Relationship

Diagram (ERD). ERD adalah diagram yang menggambarkan entitas yang berhubungan
langsung dengan sistem serta hubungan yang terjadi antar entitas.

Jadi berbeda dengan DFD yang lebih terfokus pada alur data dan proses dalam sistem,
ERD lebih terfokus pada desain sebuah basis data dalam sistem. Bagian-bagian dari
ERD antara lain.

1. Entitas, yaitu pihak, benda, obyek, atau jabatan tertentu yang memiliki arti dalam
sistem. Contohnya seperti entitas murid dan guru pada basis data sekolah
2. Attribute, yaitu suatu fakta atau hal yang berkaitan dengan entitas yang selayaknya
atau seharusnya disimpan di dalam sebuah basis data karena memiliki nilai
kepentingan tertentu. Contohnya entitas murid memiliki attribute seperti NISN, nama
lengkap, nama orang tua, alamat, dan nomor telepon, tapi kita tidak perlu mengetahui
nama panggilan, warna mata, dan panjang kaki dari entitas murid. Jenis-jenis
attribute antara lain:
a. Single-Valued Attribute, attribute yang hanya memiliki satu nilai. Contoh :
nama
b. Multiple-Valued Attribute, attribute yang bisa memiliki satu atau lebih nilai.
Contoh : hobi, alamat
 c. Composite Attribute, attribute yang bisa dipecah menjadi beberapa
atribute sederhana. Contoh : nama, bisa dipecah menjadi nama depan
dan nama belakang
d. Derived Attribute, attribute yang nilainya berasal dari nilai attribut lainnya.
Contoh : usia, bisa diambil dari tanggal lahir dan tanggal sekarang.
3. Cardinality (Kardinalitas), yaitu jenis hubungan yang terjadi antar dua buah
entitas. Cardinality inilah yang menentukan apakah desain sebuah basis data dapat
digunakan dalam sistem atau tidak. Cardinality pada dasarnya bisa dibagi menjadi 3
macam, yaitu:
a. one-to-one, hubungan satu-satu atau bersifat korespondensi satu-satu. Jadi
satu entitas asal hanya bisa memiliki relasi dengan satu entitas kawan.
Contoh :
Penduduk dengan KTP
b. one-to-many, terkadang bisa dibalik menjadi many-to-one, adalah hubungan
satu-banyak. Jadi satu entitas asal bisa memiliki relasi dengan beberapa
entitas kawan, tapi satu entitas kawan tersebut hanya bisa memiliki relasi
dengan satu entitas asal. Jenis hubungan seperti ini yang biasanya
ditemukan. Contoh : murid dengan kelas.
c. many-to-many, adalah hubungan banyak-banyak. Jadi satu entitas asal bisa
memiliki relasi dengan beberapa entitas kawan, dan begitu pula
sebaliknya. Contoh : guru dengan murid

Ada dua macam cara untuk menggambarkan ERD, yaitu menggunakan notasi Chen atau
notasi Crow's Foot (kaki gagak). Notasi Chen pertama kali diperkenalkan untuk
menggambarkan ERD, namun sulit untuk menggambarkan attribute. Notasi Crow's Foot
diperkenalkan kemudian untuk mempermudah penulisan attribute, namun penggambaran
cardinality menjadi lebih sulit.

Berikut adalah contoh penggambaran ERD dengan notasi Chen dan Crow's Foot.

Hubungan one-to-many

Hubungan many-to-many

Hubungan one-to-one

ERD kemudian bisa dijadikan dasar untuk menuliskan SQL dari basis data perangkat
lunak. Entitas yang digambarkan di dalam ERD akan disusun menjadi tabel, dengan
atribut dari Entitas akan menjadi field dari tabel tersebut. Cardinality akan menjadi
penentu untuk hubungan Primary Key dan Foreign Key dari tabel yang memiliki
Cardinality. Penggambaran
ERD dalam bentuk SQL juga bisa kita anggap sebagai perubahan dari bentuk Conceptual
Model menjadi Physical Model.

Berikut adalah contoh pengubahan ERD menjadi SQL

 Modul 6 : Antar Muka Pengguna (User Interface)
A. Materi
Materi dari Modul 6 mencakup :
1. Tujuan dan Manfaat Antar Muka Pengguna
2. Prinsip Desain Antar Muka
3. Penyajian Informasi dan Interaksi Pengguna
4. Perancangan User Interface

B. Tujuan Pembelajaran
Setelah mempelajari Modul 6, diharapkan siswa dapat :

1. Memahami konsep desain User Interface.

2. Memahami dan menerapkan prinsip desain User Interface
3. Menyajikan hasil rancangan desain User Interface

C. Uraian
User Interface adalah desain yang digunakan untuk menciptakan media komunikasi yang
efektif antara pengguna dan program. User Interface menjembatani program dan
User secara langsung. User Interface adalah salah satu aspek dari sistem yang
harus dibuat dengan teliti, karena :

1. User seringkali menilai dari bagus atau tidaknya sistem dari User Interface, bukan
dari fungsionalitas. Hal ini dikarenakan User Interface adalah sesuatu yang
langsung digunakan sebagai media interaksi oleh User. Jadi User dapat merasakan
nyaman atau tidaknya penggunaan perangkat lunak melalui User Interface. Bisa saja
terdapat sistem yang memiliki fungsionalitas yang bagus tetapi User tidak mau
memakainya karena tidak mengerti caranya atau terlalu rumit pemakaiannya.
2. User bisa saja membuat kesalahan karena User Interface yang tidak bagus.
Bahkan konsep simbol dan logo bisa memiliki pengaruh yang cukup besar. Bisa
dibayangkan apa yang terjadi apabila simbol x yang selalu dianalogikan dengan tidak,
tiba-tiba diartikan sebagai ya. Penempatan shortcut yang terlalu dekat juga sangat
berpengaruh.
3. User yang menganggap User Interface tidak bagus bisa saja tidak pernah
menggunakan sistem tersebut, bahkan hingga ke versi berikutnya. Hal ini lebih
berkaitan dengan prinsip pemasaran dan marketing. User dari sebuah program yang
User Interfacenya bagus lebih mungkin bertahan menggunakan program tersebut,
bahkan hingga ke versi berikutnya.

Dalam mendesain User Interface, ada tiga aturan utama yang harus diperhatikan, yaitu :

1. Kontrol ada di tangan user, maksudnya adalah kita membuat sebuah UI yang
membuat user nyaman menggunakannya dan membuat seakan-akan semua
perintah user pasti dituruti. Berikut adalah contoh prinsip yang bisa diikuti:
a. buatlah interaksi yang fleksibel dan berbeda-beda
b. buatlah pekerjaan user bisa dipotong dan bisa diganti
 c. buatlah sehingga user bisa berinteraksi dengan segala hal yang tampak di
layar.
2. Kurangi beban memori user, maksudnya jangan membuat user harus mengingat
segala perbuatannya. Berikut adalah contoh prinsip yang bisa diikuti :
a. buatlah sehingga komputer bisa kembali ke pengaturan semula (default)
b. buatlah shortcut yang mudah diingat
c. buatlah gambar atau visual lainnya menyerupai sesuatu di kehidupan nyata
3. Konsistenlah dalam desainnya, maksudnya mekanisme IO, kerja, dan informasi visual
haruslah konsisten. Berikut adalah contoh prinsip yang bisa diikuti:
a. buatlah perintah yang konsisten untuk setiap aplikasi yang sekelompok
b. apabila terdapat konotasi yang sudah populer, janganlah diubah

Jenis-jenis interaksi user maksudnya cara bagaimana user dapat berinteraksi

dengan program. Ada beberapa cara yang umum digunakan, karena semakin
berkembang teknologi, maka jenis interaksi user semakin beraneka ragam.

1. Direct Manipulation, user langsung berinteraksi dengan sistem, mudah untuk

dipelajari dan berkesan sangat canggih dan intuitif, tetapi susah untuk
diimplementasikan
2. Menu Selection, user memilih menu yang sudah disediakan, digunakan untuk
menghindari kesalahan user dan mengurangi perintah ketikan, tetapi menjemukan
bagi pengguna berpengalaman dan menjadi sangat kompleks apabila terdapat
banyak pilihan pada menu
3. Form, user mengisi formulir yang disediakan, mudah untuk dipelajari namun
biasanya memenuhi layar dan harus diberikan kontrol untuk mengecek kesalahan
yang dilakukan user
4. Command Language, user memberikan perintah dengan bahasa program, dapat
diimplementasikan dengan mudah dan biasanya mencakup banyak pilihan, namun
susah untuk dipelajari dan kesalahan susah untuk dicari penyebabnya
5. Natural Language, user memberikan perintah dengan bahasa natural, dapat
diimplementasikan dengan mudah dan tidak menyulitkan user, tetapi sistem
belum tentu dapat menerjemahkan bahasa natural secara tepat.

Berikut adalah cara-cara sistem menampilkan kerja program atau respon dari interaksi
user

1. berdasarkan kecepatan, informasi bisa ditampilkan secara langsung, atau diproses

menjadi bentuk lain.
2. berdasarkan sifatnya, informasi bisa berupa statis ataupun dinamis
3. berdasarkan tampilannya, bisa dipilih antara analog atau

digital Tahap-tahap desain User Interface antara lain:

1. Interface Analysis and Modeling, menganalisa user, langkah kerja, dan model
User Interface yang sesuai
2. Interface Design, menentukan obyek dan tampilan User Interface yang sesuai
dengan model
3. Interface Construction, membuat tampilan User Interface dan prototipe cara kerja
4. Interface Validation, melihat apakah sudah sesuai dengan model dan keinginan user
 Modul 7 : Arsitektur Perangkat Lunak
A. Materi
Materi dari Modul 7 mencakup :
1. Pengenalan Arsitektur Perangkat Lunak
2. Layering
3. Ragam Arsitektur Perangkat Lunak
4. Pengenalan Struktur Chart Diagram
5. Transformasi DFD ke Struktur Chart Diagram
6. Interaksi Komponen

B. Tujuan Pembelajaran
Setelah mempelajari Modul 7, diharapkan siswa dapat :

1. Memahami konsep arsitektur perangkat lunak.

2. Memahami lapisan dalam arsitektur perangkat lunak.
3. Memahami ragam arsitektur perangkat lunak.
4. Memahami stuktur chart diagram dan interaksi antar komponen di dalamnya
5. Menyajikan hasil perubahan DFD ke Struktur Chart diagram.

C. Uraian
Arsitektur Perangkat Lunak adalah struktur dari sebuah sistem yang menggambarkan
komponen perangkat lunak yang terdapat pada sistem tersebut, di mana kita bisa melihat
sifat dari setiap komponen sistem serta hubungan antara komponen tersebut. Arsitektur
memberikan pengaruh besar dalam pengembangan perangkat lunak karena arsitektur
merupakan wujud dari keputusan bentuk desain yang akan digunakan untuk sistem
hingga sistem tersebut selesai.

Fungsi Arsitektur Perangkat Lunak:

1. Melihat secara keseluruhan desain dari sebuah sistem
2. Efektivitas desain dapat dianalisa untuk melihat apakah sistem dapat
memenuhi kebutuhan
3. Apabila terjadi sesuatu, alternatif desain dapat sekaligus dicari karena perubahan
desain masih dapat dilakukan secara relatif mudah
4. Mengurangi resiko dalam proses konstruksi sistem

Ragam Gaya Pemodelan Arsitektur :

1. Data Centered Architecture / Model Repository, tempat penyimpanan data menjadi
pusat komponen lainnya. Komponen yang memiliki akses data berdiri sendiri
sehingga antar komponen tidak saling mengganggu.
Berikut adalah penggambaran Repository Model
2. Data Flow Architecture, menggambarkan input data yang melewati proses sehingga
menghasilkan output. Kira-kira mirip seperti jalur di DFD. Berikut adalah
penggambaran model Data Flow Architecture

3. Call and Return Architecture, menggambarkan struktur program secara

hierarkis / bertingkat. Sistem terdiri atas program yang dibagi lagi menjadi
sub program. Berikut adalah penggambaran model Call and Return
Architecture

4. Layered Architecture, dibagi menjadi beberapa lapisan yang memiliki fungsi

masing- masing.
Pemetaan Arsitektur perangkat lunak yang akan kita gunakan adalah structured design,
karena metode ini menggunakan transisi / pengubahan dari DFD menjadi arsitektur
sistem. Proses transisi ini melalui beberapa tahap, yaitu :
1. Pelajari kembali diagram konteks, hingga ke iterasi paling kecil (lv2 atau lv3)
2. Deteksi apakah DFD memuat aliran data transaksional, artinya ketika diberikan
data tertentu, apa yang dilakukan sistem berbeda sesuai dengan tipe atau isi data
tersebut.
3. Tentukan bagian mana yang mengalami perubahan transaksional, dengan memisahkan
jalur data masuk dan jalur data keluar
4. Ubah bagian transaksional menjadi bentuk Call and Return, dengan jalur data masuk
dan jalur data keluar sebagai salah satu cabang
 Modul 8 : Pemodelan Sistem Berorientasi Obyek (UML)
A. Materi
Materi dari Modul 8 mencakup :
1. Prinsip Analisis dan Desain Sistem Berorientasi Obyek
2. Pemodelan menggunakan UML

B. Tujuan Pembelajaran
Setelah mempelajari Modul 8, diharapkan siswa dapat :

1. Memahami konsep analisis dan desain pada sistem berorientasi obyek

2. Memahami dan menggunakan bangun dalam UML
3. Menyajikan pemodelan menggunakan UML.

C. Uraian
UML (Unified Modeling Language) adalah serangkaian notasi yang digunakan untuk
membantu desain sistem, terutama yang berorientasi obyek. Standar UML dikontrol
oleh Object Management Group (OMG) atau juga dikenal dengan istilah CORBA.
UML pada dasarnya adalah gabungan dari banyak bahasa model lainnya dan
pertama kali diperkenalkan tahun 1997.

UML dapat digunakan dalam 3 hal, yaitu :

1. sebagai sketsa sistem, untuk menjelaskan bagian dari sistem, baik sistem yang
sudah ada atau sistem yang akan dibuat. UML yang digunakan tidak bersifat kaku,
lebih bervariasi karena penyampaian ide dan maksud lebih penting.
2. sebagai blueprint sistem, untuk panduan dalam membuat sistem, atau menjelaskan
sistem yang sudah ada. UML yang dibuat bersifat sempurna dan menggunakan
kaidah- kaidah yang tepat, tidak boleh salah
3. sebagai bahasa pemrograman, UML yang dibuat diubah langsung menjadi bahasa
kode pemrograman.

Jenis diagram UML yang digunakan, antara lain:

a. Activity Diagram, menunjukkan tingkah laku sistem
b. Class Diagram, menunjukkan Class, fungsi Class, dan hubungan antar Class
c. Communication Diagram, menunjukkan interaksi antar objek sistem, lebih ke arah link
d. Component Diagram, menunjukkan struktur dan koneksi antar komponen
e. Composite Structure Diagram, menunjukkan dekomposisi Class, pembagian Class
secara struktur sehingga terlihat lebih rinci daripada Class Diagram
f. Deployment Diagram, menunjukkan penggunaan Node, maksudnya pembagian
tempat di mana komponen sistem nantinya akan bekerja.
g. Interaction Overview Diagram, campuran Sequence dan Activity Diagram
h. Object Diagram, menunjukkan konfigurasi dari objek sistem. Sebenarnya bukan
merupakan jenis diagram UML yang resmi. Object Diagram pada dasarnya
adalah tampilan dari Class Diagram yang disertai dengan isi sehingga
memudahkan user untuk mengerti Multiplicity dari Class.
i. Package Diagram, menunjukkan struktur hierarki dari perangkat lunak saat melalui
tahap Compile. Package Diagram juga bukan diagram UML yang resmi.
j. Sequence Diagram, menunjukkan interaksi antar objek, lebih ke arah jalur dari
interaksi tersebut.
k. State Machine Diagram, menunjukkan bagaimana peristiwa mengubah objek
l. Timing Diagram, menunjukkan interaksi antar objek, lebih ke arah waktu.
m. Use Case Diagram, menunjukkan interaksi user dengan sistem

Secara umum, jenis diagram UML bisa dibagi menjadi 3 macam

1. Diagram yang berkaitan dengan struktur sistem, seperti Class, Component,

Deployment, Object, dan Package

2. Diagram yang berkaitan dengan cara kerja sistem, seperti Activity, Use Case, dan
State Machine

3. Diagram yang berkaitan dengan interaksi bagian sistem, seperti Sequence

dan Communication
 Modul 9 : Kebutuhan Sistem Berbasis Obyek
A. Materi
Materi dari Modul 9 mencakup :
1. Use Case Diagram
2. Spesifikasi Use Case
3. Pembuatan Use Case

B. Tujuan Pembelajaran
Setelah mempelajari Modul 9, diharapkan siswa dapat :

1. Memahami konsep Use Case Diagram.

2. Memahami dan menggunakan bangun dalam Use Case Diagram
3. Menyajikan Use Case Diagram dari sebuah perangkat lunak.

C. Uraian
USE CASE biasanya digunakan untuk menggambarkan Functional Requirement. USE CASE
menggambarkan proses alur interaksi antara user dengan sistem. USE CASE biasa juga
digunakan untuk menggambarkan skenario. Skenario yang menggambarkan proses seperti
biasa adalah skenario utama, karena bisa saja terjadi kesalahan dalam langkah di atas
sehingga memerlukan skenario tambahan.

contoh penggambaran USE

CASE USE CASE Membeli Barang
(on-line) Skenario Utama:
1. Customer melihat-lihat katalog dan memilih barang
2. Sistem memasukkan barang yang dipilih ke dalam keranjang belanja
3. Customer kemudian berniat membayar
4. Customer mengisi informasi pengiriman barang
5. Sistem menentukan harga yang harus dibayar
6. Customer memilih metode pembayaran
7. Customer mengisi informasi metode pembayaran
8. Sistem memastikan informasi metode pembayaran
9. Sistem mensahkan transaksi
10. Sistem mengirimkan e-mail sebagai bukti transaksi
Skenario Tambahan:
5a. Apabila Customer adalah member
1. Sistem memberikan diskon sebesar 10%
8a. Apabila Sistem gagal memastikan informasi metode pembayaran
1. Sistem mempersilakan Customer untuk melakukan input ulang atau membatalkan
transaksi

USE CASE bisa ditambahkan dengan hal-hal berikut

1. Pre-Condition, kondisi yang diperiksa sistem sebelum langkah selanjutnya
2. Guarantee, kondisi yang dijaga saat use case selesai
3. Trigger, kondisi saat use case dimulai

Semua USE CASE yang ada pada sistem barulah dituliskan dalam USE CASE diagram. Kita
tidak menjelaskan setiap detil dari Use Case, tetapi melihat semua Use Case yang
muncul dari kerja perangkat lunak tersebut.

Dalam Penggambaran Use Case, konsep yang harus dimengerti antara lain:

1. Actor, yaitu obyek atau pihak di luar perangkat lunak yang akan melakukan
interaksi secara langsung dengan Use Case. Actor digambarkan mirip seperti
orang
2. Use Case, yaitu skenario yang sudah dijelaskan di atas. Use Case digambarkan
berupa gelembung dengan tulisan nama Use Case.
3. Tanda interaksi antara Actor dan Use Case, digambarkan dengan garis
4. Include, yaitu Use Case terpisah yang menjadi pembuka untuk Use Case lainnya.
Artinya, Use Case yang memiliki hubungan ‘include’ harus dikerjakan terlebih dahulu
baru bisa mengerjakan Use Case lainnya. Hubungan include digambarkan dengan
tanda panah dari Use Case yang menjadi penentu ke Use Case lainnya. Hubungan
Include juga sering disebut Hubungan Uses. Contoh Hubungan Include adalah antara
Use Case Login dengan
Use Case Register. User tentu harus melakukan Register dulu, baru bisa melakukan
Login. Tanda panah akan digambarkan dari Register ke Login.
5. Extend, yaitu Use Case terpisah yang merupakan bagian dari sebuah Use Case,
namun bisa digambarkan dalam Use Case terpisah. Bisa juga merupakan variasi
dari Use Case utama. Contoh hubungan Extend adalah antara Use Case Membeli
Barang dengan Use Case Membeli Barang Garansi. Use Case Membeli Barang
adalah Use Case utama, sedangkan Use Case Membeli Barang Garansi adalah Use
Case sampingan karena belum tentu semua barang memiliki garansi. Tanda panah
akan digambarkan dari Use Case sampingan ke Use Case Utama.

Contoh penggambaran Use Case Diagram

 Modul 10 : Alur Kerja Sistem Berorientasi Obyek
A. Materi
Materi dari Modul 10 mencakup :
1. Pengenalan Activity Diagram
2. Langkah Pembuatan Activity Diagram

B. Tujuan Pembelajaran
Setelah mempelajari Modul 10, diharapkan siswa dapat :

1. Memahami konsep Activity Diagram.

2. Memahami dan menggunakan notasi dalam Activity Diagram
3. Menyajikan Activity Diagram dari sebuah perangkat lunak.

C. Uraian
Activity Diagram adalah diagram yang menjelaskan tentang alur kegiatan (activity) yang
dikerjakan oleh sistem untuk melakukan suatu layanan. Tampilan dari Activity Diagram
pada dasarnya hampir sama dengan Flowchart pada program. Kelebihan dari Activity
diagram adalah dapat memunculkan jenis activity yang dilakukan tanpa urutan jelas atau
dilakukan secara bersama-sama. Berikut adalah contoh activity diagram.
Activity Diagram juga biasa dibuat dengan menggunakan swimlane untuk membedakan
pihak yang melakukan kegiatan. Swinlane Activity Diagram berguna juga untuk
menunjukkan aktivitas yang berjalan sesuai dengan waktu. Contoh penggunaan Swinlane
pada Activity Diagram:
 Modul 11 : Hubungan Antar Class
A. Materi
Materi dari Modul 11 mencakup :
1. Pengenalan Class Diagram
2. Langkah Pembuatan Class Diagram
 3. Transformasi Class Diagram ke dalam Conceptual Data Model

B. Tujuan Pembelajaran
Setelah mempelajari Modul 11, diharapkan siswa dapat :

1. Memahami konsep Class Diagram.

2. Memahami dan menggunakan bangun dalam Class Diagram
3. Menyajikan Class Diagram dari sebuah perangkat lunak
4. Menyajikan Conceptual Data Model dari Class Diagram

C. Uraian
Class Diagram adalah salah satu diagram UML yang umum digunakan sebagai pengantar
untuk mempelajari diagram UML. Class Diagram menjelaskan jenis object pada sistem dan
berbagai hubungan tetap yang terdapat pada object-object tersebut. Class Diagram juga
menunjukkan keterangan (Properties) dan operasi dari sebuah Class serta hambatan
yang terdapat pada bagaimana object saling terhubung. Dalam Class Diagram,
keterangan dan operasi umum disebut sebagai Fitur. Berikut adalah contoh Class
Diagram yang sederhana

Yang dimaksud dengan Properties adalah fitur struktur dari Class. Cara penulisan Properties
dalam Class Diagram bisa dibedakan menjadi atribut (Attribute) dan asosiasi (Association).
Attribute berkenaan dengan keterangan yang menempel pada Class yang menunjukkan
identitas Class. Dalam Class Diagram, Attribute dituliskan di dalam kotak Class. Pola
lengkap dari penulisan Attribute adalah sebagai berikut :
(Visibilitas) (Nama) : (Jenis) (Multiplicity) = (Nilai Default) {(Keterangan lain)}
a. Visibilitas menunjukkan apakah Attribute bersifat publik (boleh dilihat) atau tidak
b. Nama menunjukkan nama dari attribute tersebut
c. Jenis menunjukkan tipe data yang digunakan oleh Attribute
d. Multiplicity menunjukkan jenis hubungan pada Attribute
e. Nilai Default menunjukkan isi dari Attribute apabila dikosongkan
f. Keterangan Lain menunjukkan keterangan tambahan dari Attribute yang penting
Penulisan Attribute tidak harus mengikuti pola secara
lengkap Contoh :
+ name : String [1] = “Untitled” {readOnly}
Artinya terdapat Attribute bersifat publik bernama name dengan tipe data String dengan
multiplicity
1, nilai Defaultnya Untitled dan bersifat readOnly atau tidak bisa diganti
Contoh penulisan Attribute dalam Class Diagram :

Association berkenaan dengan hubungan antara Class tersebut dengan Class lainnya.
Dalam Class Diagram, Association ditunjukkan dalam bentuk garis antara dua buah Class,
dari Class asal ke Class tujuan, dengan Multiplicity dituliskan di pinggir garis. Multiplicity
bisa saja dituliskan di bagian Class asal dan Class tujuan.
Contoh penulisan Association dalam Class Diagram :

Modul 12 : Interaksi Antar Obyek

A. Materi
Materi dari Modul 12 mencakup :
1. Object Diagram
2. Sequence Diagram
 3. Kolaborasi Diagram

B. Tujuan Pembelajaran
Setelah mempelajari Modul 12, diharapkan siswa dapat :

1. Memahami konsep Object Diagram, Sequence Diagram, dan Kolaborasi Diagram.

2. Memahami dan menggunakan notasi dalam Object Diagram, Sequence Diagram,
dan Kolaborasi Diagram
3. Menyajikan Object Diagram, Sequence Diagram, dan Kolaborasi Diagram dari sebuah
perangkat lunak.

C. Uraian
object diagram menggambarkan objek sebuah sistem dalam satu waktu. Sering disebut
juga Instance Diagram. object diagram digunakan untuk menunjukkan object yang
saling berhubungan. Yang dimaksud dengan object adalah contoh isi dari sebuah Class.
Jadi apabila kita menghentikan proses sejenak untuk melihat semua instance dari
sistem, maka inilah yang kita sebut object diagram.

Contoh Class Diagram dengan Object Diagramnya:

sequence diagram termasuk dalam jenis interaction diagram yang menunjukkan

bagaimana objek saling bekerja sama. Sequence diagram digunakan untuk melihat
bagaimana tingkah laku objek dalam satu buah skenario (UC). Notasi dalam
sequence diagram:

1. Object, berupa kotak besar di bagian atas dengan Lifeline sendiri-sendiri. Cara
penulisan objek dalam sequence diagram bisa berupa nama objek diikuti nama class,
atau hanya salah satu.

2. Lifeline, berupa garis putus-putus ke bawah yang menggambarkan masa hidup objek
pada sequence tersebut.

3. Message, berupa perintah pemanggilan method atau operasi dari class, menggunakan
tanda panah ke arah lifeline object yang dimaksud. Message bisa juga dibuat dengan
tanda panah putus-putus untuk menandakan panah balik ke kelas asal. Message
pertama ditandai dengan panah diawali dengan tanda bulat.

4. Creation dan Deletion, creation adalah penciptaan object baru (panah new) dan
Deletion adalah penghapusan object (lifeline dipotong dengan X besar)

5. Activation, ditandai dengan kotak yang menunjukkan bahwa object tersebut

sedang digunakan
6. Frame, ditandai dengan sebuah kotak besar yang meliputi beberapa proses, bisa
diartikan sebagai proses selection (if) ataupun iteration (loop).

Contoh Sequence Diagram:

Collaborations sebenarnya bukan merupakan satu buah diagram tersendiri.

Collaborations digunakan untuk menunjukkan tingkah laku dan interaksi dari beberapa
class yang berbeda. Collaboration diagram sangat mirip dengan sequence diagram.
Collaboration diagram menggambarkan interaksi antar objek tanpa menggunakan
batasan waktu.

Contoh Collaboration Diagram

 Modul 13 : Siklus Hidup Obyek
A. Materi
Materi dari Modul 13 mencakup :
1. State Chart Diagram
2. Langkah Pembuatan State Chart Diagram
B. Tujuan Pembelajaran
Setelah mempelajari Modul 13, diharapkan siswa dapat :

1. Memahami konsep State Chart Diagram.

2. Memahami dan menggunakan notasi dalam State Chart Diagram
3. Menyajikan State Chart Diagram dari sebuah perangkat lunak.

C. Uraian
State Chart Diagram juga sering disebut sebagai State Machine Diagram. State
Machine Diagram adalah diagram yang digunakan untuk menjelaskan tingkah laku
yang mungkin terjadi dari sebuah class.

Simbol pada State Machine Diagram :

1. State, kondisi atau situasi dari sebuah object

2. Start State, merupakan kondisi awal dari object digambarkan dengan lingkaran hitam

3. Finish State, merupakan kondisi akhir dari object digambarkan dengan lingkaran
hitam di dalam lingkaran putih.

4. Transisi, perpindahan antar state digambarkan dengan garis disertai kondisi

transisi Contoh State Machine Diagram adalah sebagai berikut

Modul 14 : Hubungan Antar Komponen

A. Materi
Materi dari Modul 14 mencakup :
1. Component Diagram
2. Deployment Diagram

B. Tujuan Pembelajaran
Setelah mempelajari Modul 14, diharapkan siswa dapat :
 1. Memahami konsep Component Diagram dan Deployment Diagram.
2. Memahami dan menggunakan notasi dalam Component Diagram dan
Deployment Diagram
3. Menyajikan Component Diagram dan Deployment Diagram dari sebuah perangkat lunak.

C. Uraian
Component Diagram adalah diagram yang menjelaskan komponen dari sebuah sistem.
Berbeda dengan Class, yang dimaksud dengan komponen adalah bagian dari sistem yang
bersifat fisik. Komponen juga bisa berupa file tertentu. Jenis komponen yang biasa
ditemukan adalah :

1. <<executable>> : program .exe

2. <<library>> : file referensi .dll

3. <<file>> : file teks, source code .txt

4. <<table>> : file basis data, tabel

5. <<document>> : dokumen office, web, dan lain-lain.

Fungsi Component Diagram adalah untuk menunjukkan struktur coding dan memodelkan
struktur dari sistem.

Contoh Component Diagram:

Deployment diagram menunjukkan tampilan sistem secara fisik, bagian sistem apa
yang berjalan pada hardware apa. Jadi, yang ditampilkan pada Deployment diagram
adalah perangkat keras yang digunakan, perangkat lunak yang ada di dalam
perangkat keras tersebut, dan perangkat perantara yang menghubungkan antar
perangkat keras.

Fungsi Deployment diagram:

1. Menunjukkan perangkat keras yang akan digunakan dan bagaimana hubungan

antar perangkat keras tersebut.

2. Menunjukkan arsitektur dari sistem

3. Menunjukkan tempat komponen dari sistem.

Gambar Component pada Deployment Diagram sama seperti pada Component

Diagram Contoh Deployment Diagram:

Modul 15 : Dokumen Laporan Pengembangan Sistem Berorientasi
Obyek
A. Materi
Materi dari Modul 15 mencakup :
1. Kerangka Dokumen
2. Contoh Dokumen

B. Tujuan Pembelajaran
Setelah mempelajari Modul 15, diharapkan siswa dapat :

1. Memahami kerangka dari dokumen laporan pengembangan sistem

2. Mengidentifikasi contoh dokumen laporan pengembangan sistem
 3. Menyajikan dokumen laporan pengembangan sistem.

C. Uraian
Selama proses Rekayasa Perangkat Lunak, termasuklah di dalamnya proses pemodelan
perangkat lunak. Dalam proses inilah kita mendesain beberapa dokumen yang
menggambarkan proses, cara kerja, dan karakteristik dari perangkat lunak yang akan
dikerjakan.

Dokumen yang kita buat mencakup bagian-bagian berikut:

n. Definisi dari perangkat lunak, berisikan penjelasan mengenai bagaimana

perangkat lunak yang dikembangkan akan memenuhi kebutuhan User dan
Client.
o. Definisi kebutuhan dari perangkat lunak secara rinci, berisikan semua
batasan- batasan yang muncul dari pemakaian perangkat lunak sesuai
dengan hasil Requirement Engineering.
p. Perincian biaya yang akan dikeluarkan selama pembuatan perangkat
lunak (budget)
q. Penjadwalan dari pengerjaan perangkat lunak
r. Penjelasan semua anggota tim yang akan mengerjakan perangkat lunak
s. Analisa cara kerja perangkat lunak menggunakan DFD
t. Analisa penggunaan data perangkat lunak menggunakan ERD
u. Analisa struktur dari perangkat lunak, menggunakan Class Document
dan Component Document
v. Analisa struktur bentuk jadi dari perangkat lunak, menggunakan
Object Document dan Deployment Document
w. Analisa cara kerja perangkat lunak, menggunakan Use Case Diagram,
Activity Diagram, dan State Machine Diagram
x. Analisa hubungan dan interaksi antar struktur perangkat lunak
menggunakan Sequence Diagram dan Communication Diagram

Dari dokumen yang dihasilkan diharapkan hasil perangkat lunak yang sudah selesai
dapat dimanfaatkan sesuai dengan kebutuhan User dan Client.

Latihan

Modul 1

1. Jelaskan apa yang dimaksud dengan perangkat lunak!

2. Jelaskan perbedaan antara perangkat lunak dengan perangkat keras dari komputer!
3. Berikan contoh untuk masing-masing jenis perangkat lunak!
4. Jelaskan apa yang dimaksud dengan rekayasa perangkat lunak!
5. Jelaskan proses apa saja yang umum dilakukan dalam rekayasa perangkat lunak!
6. Carilah informasi mengenai cabang-cabang dari rekayasa perangkat lunak sebanyak minimal
3 dan jelaskan perbedaan masing-masing cabang tersebut!

Modul 2
 1. Jelaskan mengapa terdapat begitu banyak model proses pengembangan perangkat
lunak!
2. Berdasarkan penjelasan pada modul ini, jelaskan keuntungan dan kerugian saat
menerapkan model pengembangan perangkat lunak berikut!
a. Waterfall model
b. Model 4GT
c. Prototyping
d. RAD
3. Berdasarkan penjelasan pada modul ini, jelaskan kapan kita lebih tepat menerapkan
model pengembangan perangkat lunak berikut!
a. Prototyping
b. RAD
c. Model 4GT
4. Carilah informasi mengenai model proses pengembangan perangkat lunak yang
disebut Agile Programming dan jelaskan!

Modul 3

1. Jelaskan jenis-jenis Requirement menurut fungsionalnya, kemudian berikan

contoh berkaitan pada satu perangkat lunak yang umum kamu gunakan!
2. Jelaskan tahap-tahap Requirement Engineering!
3. Carilah informasi mengenai cara-cara melakukan validasi Requirement dan jelaskan!

Modul 4

1. Jelaskan apa yang dimaksud dengan DFD!

2. Gambarkan dan jelaskan apa saja simbol DFD jenis Gane-Sarson!
3. Gambarkan secara ringkas mulai dari DFD Lv.0, DFD Lv.1, hingga DFD Lv.2 dari salah
satu perangkat lunak berikut!
a. Perangkat lunak peminjaman buku di perpustakaan
b. Perangkat lunak absensi menggunakan sidik jari
c. Perangkat lunak sistem poin SMK MHS
4. Carilah informasi mengenai simbol DFD selain model Gane-Sarson, kemudian gambarkan
dan berikan penjelasan!

Modul 5

1. Jelaskan perbedaan Conceptual Data Model dan Physical Data Model

2. Gambarkan dan jelaskan simbol ERD yang digunakan pada model Chen dan model
Crow’s Foot!
3. Gambarkan ERD secara ringkas dari basis data :
a. Mini market
b. Perpustakaan
4. Ubahlah ERD yang telah kamu buat menjadi bahasa

SQL! Modul 6

1. Jelaskan mengapa desain antar muka yang baik itu perlu!

2. Tuliskan contoh nyata cara mengaplikasikan tiga aturan utama desain antar muka!
 3. Jelaskan keuntungan dan kelebihan dari masing-masing jenis interaksi antar muka!
4. Carilah informasi mengenai cara interaksi user yang lain dan

jabarkan! Modul 7

1. Jelaskan apa yang dimaksud dengan arsitektur perangkat lunak!

2. Jelaskan ragam-ragam gaya arsitektur perangkat lunak!

Modul 8

1. Jelaskan apa yang dimaksud dengan UML!

2. Jabarkan pembagian UML berdasarkan fungsinya!
3. Carilah informasi mengenai diagram UML lain yang tidak dijabarkan di modul ini,
kemudian gambarkan contohnya dan berikan penjelasan singkat!

Modul 9

1. Jelaskan apa yang dimaksud dengan Use Case!

2. Jelaskan bagaimana cara membedakan hubungan Use Case <include> dan <extends>!
3. Gambarkanlah Use Case diagram untuk :
a. Sistem peminjaman perpustakaan
b. Sistem penjualan mini market
c. Sistem poin SMK MHS

Modul 10
1. Jelaskan apa yang dimaksud dengan Activity Diagram!
2. Jelaskan keuntungan menggambarkan Activity Diagram menggunakan swimlane!
3. Gambarkan salah satu Use Case yang telah kamu buat di Modul 9 dalam bentuk
Activity Diagram

Modul 11

1. Jelaskan apa yang dimaksud dengan Class Diagram!

2. Jelaskan apa yang dimaksud dengan Multiplicity dan berikan contoh penulisan
Multiplicity dengan baik.
3. Gambarkan Class Diagram sesuai dengan sistem yang telah kamu pilih di Modul 9!

Modul 12

1. Jelaskan apa yang dimaksud dengan Object Diagram!

2. Jelaskan apa yang dimaksud dengan Sequence Diagram!
3. Jelaskan apa yang dimaksud dengan Colaboration Diagram!
4. Jelaskan simbol-simbol apa saja yang digunakan di Object Diagram!
5. Jelaskan perbedaan Sequence Diagram dengen Activity Diagram!
6. Gambarkan Object Diagram berdasarkan Class Diagram yang telah dibuat di Modul 11!
7. Gambarkan Sequence Diagram berdasarkan Activity Diagram yang telah dibuat di Modul
10!
8. Gambarkan Collaboration Diagram berdasarkan Object Diagram dan Sequence Diagram yang
telah dibuat pada modul ini!
Modul 13
 1. Jelaskan apa yang dimaksud dengan State Machine Diagram!
2. Gambarkan State Machine Diagram sederhana berkaitan dengan jenis perangkat lunak
pada modul 9!

Modul 14

1. Jelaskan apa yang dimaksud dengan Component Diagram!

2. Jelaskan apa yang dimaksud dengan Deployement Diagram!
3. Apa saja yang digambarkan pada Component Diagram!
4. Jelaskan fungsi dari Deployment Diagram!
5. Gambarkan Component Diagram dan Deployment Diagram sesuai dengan jenis perangkat
lunak pada modul 9!

Modul 15

1. Jelaskan mengapa dokumentasi sistem adalah hal yang penting!

Referensi

Coronel, C., Morris, S., Rob, Peter. Database Systems : Design, Implementation, and
Management. 2010. Cengage Learning.

Fowler, M. UML Distilled A Brief Guide to the Standard Object Modeling Language, Third Edition.
2004. Pearson.

Pressman, R., Maxim, B. Software Engineering A Practitioner’s Approach, Eighth Edition.

2015. McGraw Hill Education.
Ramakrishnan, R., Gehrke, J. Database Management Systems, Third Edition. 2003. McGraw Hill
Education.

Shelly, G., Rosenblatt, H.J., Systems Analysis and Design, Ninth Edition. 2011. Cengage Learning.

Sommerville, I. Software Engineering, Ninth Edition. 2011. Pearson.