BAHAN AJAR RPL - PT10 - PEMODELAN PL DAN UML

MODUL KULIAH SEKOLAH TINGGI TEKNOLOGI INFORMASI NIIT Mata Kuliah Rekayasa Perangkat Lunak Semester Ganjil 2021/2022 Dosen Arisantoso, S.T., M.Kom Modul 1 (Satu) Pertemuan Topik 10 (Sepuluh) Sub Topik Materi Pemodelan dan Unified Modeling Language (diagram UML: Capaian Use Case, diagram aktifitas). Pembelajaran Definisi dan Konsep Pemodelan dan UML (diagram UML: Use Case, diagram aktifitas). A. Tingkat Kerumitan Pengembang Perangkat Lunak B. Pemodelan Pengembangan Perangkat Lunak C. Pengenalan UML D. Sejarah UML E. Diagram UML F. Use Case Diagram G. Activity Diagram H. Latihan dan Tugas Mandiri Pertemuan 10 Mampu menjelaskan pemodelan dan diagram UML serta merancang model UML dengan tools yang sesuai serta dapat melakukan pengujian perangkat lunak yang telah di buat.

BAB 10 PEMODELAN dan UML (DIAGRAM UML: USE CASE, DIAGRAM AKTIFITAS) I. Pendahuluan A. Deskripsi singkat, manfaat dan relevan Pada pertemuan kali ini akan membahas mengenai kerumitan dalam pengembangan lunak dan perlunya dilakukan untuk membantu membuat suatu pemodelan perangkat lunak. Pemodelan perangkat lunak yang hingga saat ini digunakan oleh software developer adalah dengan salah satu standar pemodelan yaitu Unified Modeling Language (UML). Manfaat yang didapat setelah mempelajari bab ini mahasiswa dapat menjelaskan secara umum sejarah UML, diagram UML. B. Rumusan capaian pembelajaran matakuliah Mampu menerapkan pemodelan dan diagram UML serta merancang model UML dengan tools yang sesuai serta dapat melakukan pengujian perangkat lunak yang telah di buat. C. Urutan bahasan dan kaitan materi 1. Tingkat Kerumitan Pengembang Perangkat Lunak 2. Pemodelan Pengembangan Perangkat Lunak 3. Pengenalan UML 4. Sejarah UML 5. Diagram UML 6. Use Case Diagram 7. Activity Diagram 8. Latihan dan Tugas Mandiri Pertemuan 10 D. Petunjuk belajar Mari kita membaca petunjuk belajar terlebih dahulu untuk mempermudah materi pertemuan 10 (sepuluh) mengenai kerumitan pemodelan dan Bahasa Standar pemodelan UML: a) Berdoalah sebelum memulai pembelajaran b) Bacalah kemampuan akhir tiap tahapan belajar (sub-cpmk), indikator, kriteria dan teknik, bentuk pembelajaran, metode pembelajaran, penugasan mahasiswa dan materi pembelajaran dengan cermat. c) Baca dan pelajari setiap materi yang ada, bila perlu di garis bawahi hal-hal yang menurut anda penting. d) Mahasiswa dapat belajar secara mandiri ataupun berkelompok, saat pertemuan kuliah yang dilakukan secara daring dengan memanfaatkan fasilitas ecampus Sekolah Tinggi Teknologi Informasi NIIT e) Jika belum memahami segera tanyakan kepada Bapak / Ibu dosen pengampu matakuliah. 121

II. Penyajian A. Tingkat Kerumitan Pengembang Perangkat Lunak Sebuah perusahaan software developer dalam pengembangkan suatu rekayasa perangkat lunak bukanlah hal yang mudah. Hal ini dikatakan secara logika sama halnya dengan mengelola sebuah sistem dari hasil buah pemikiran dan pemahaman setiap orang (kepala). Dengan banyaknya kepala tentu saja akan semakin sulit dalam menyatukan visi. Berikut ini adalah tingkatan kerumitan dalam pengembangan sebuah perangkat lunak yang sering di alami oleh software developer sebagai berikut: 1. Tingkat kerumitan dari domain permasalahan perangkat lunak tentang bagaimana mendefinisikan fungsi-fungsi pada sebuah perangkat dan penanganan masalah terhadap fungsi-fungsi perangkat bukanlah hal yang mudah. 2. Tingkat kesulitan dalam mengelola proses pengembangan perangkat lunak dalam hal ini yang biasa dilakukan oleh Tim pengembang perangkat lunak. Solusi dari hal tersebut adalah perlu adanya koordinasi diantara anggota tim sehingga apabila terjadi kesalahpahaman dari interpretasi dapat di urai permasalahannya, namun jika tidak adanya koordinasi bisa jadi perangkat lunak yang dibangun tidak akan selesai. 3. Tingkat fleksibilitas adanya perubahan perangkat lunak dari kasus di dunia nyata bahwa tim developer yang mengerjakan perangkat lunak bukanlah orang / pengguna yang memiliki kepentingan terhadap perangkat lunak tersebut. Dari sudut pandang ini tentu saja akan terciptanya hubungan antara klien dengan developer. Client tentu saja dapat melakukan banyak permintaan aplikasi serta fungsi-fungsi yang dibutuhkannya, kita sebagai developer tentu saja memiliki kewajiban membuat aplikasi sesuai apa yang diminta oleh client tersebut. Semakin terbatasnya pengetahuan client terhadap teknologi informasi dan juga semakin banyaknya permintaan dan pertimbangan dari client mengenai kebutuhan dari aplikasi, maka di mungkinkan adanya suatu perubahan dari spesifikasi aplikasi di tengah proses pengembangan perangkat lunak. Dengan adanya masalah tersebut tentunya akan menyebabkab pengembangan aplikasi perangkat lunak akan bertambah lama waktu dalam pembangunan perangkat lunak tersebut. 4. Tingkat permasalahan yang berkarakteristik pada bagian-bagian dari perangkat lunak. Dalam pengembangan perangkat lunak tentu saja dilakukan oleh beberapa orang atau tim. Biasanya jika dilakukan dengan tim maka tugas nya akan dibagi- bagi berdasarkan bagian nya masing-masing. Apabila terdapat suatu permasalahan dari bagian-bagian perangkat lunak yang tidak terdefinisi dengan benar atau tingkat pemahaman tim berbeda maka dimungkinkan pada saat bagian-bagian tersebut akan terjadi faktor kesalahan atau error program. Maka dari itu perlu adanya sebuah koordinasi dan komunikasi yang baik di dalam tim pengembangan perangkat lunak tersebut. Dari berbagai faktor dan masalah serta resiko yang dihadapi dan tentunya akan timbul didalam pengembangan perangkat lunak maka perlu adanya perencanaan yang baik serta membuat rancangan pemodelan perangkat lunak agar setiap masalah dapat diuraikan dan perancangan aplikasi perangkat lunak tidak akan mengalami kendala ke depan. 122

B. Pemodelan Pengembangan Perangkat Lunak Menurut fatmawati (2019) Pemodelan Perangkat Lunak adalah Disiplin ilmu untuk mempelajari bentuk-bentuk pemodelan perangkat lunak yang digunakan sebagai bagian dari tahapan pengembangan perangkat lunak secara terstruktur dan berorientasi objek. Pemodelan dalam suatu rekayasa perangkat lunak merupakan suatu hal yang dilakukan di tahapan awal. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya masih memungkinkan tanpa melakukan suatu pemodelan. Namun hal itu tidak dapat lagi dilakukan dalam suatu industri perangkat lunak. Pemodelan delam perangkat lunak merupakan suatu yang harus dikerjakan di bagian awal dari rekayasa, dan pemodelan ini akan mempengaruhi perkerjaan-pekerjaan dalam rekayasa perangkat lunak tersebut. Di dalam suatu industri dikenal berbagai macam proses, demikian juga halnya dengan industri perangkat lunak. Perbedaan proses yang digunakan akan menguraikan aktivitas-aktivitas proses dalam cara-cara yang berlainan. Perusahaan yang berbeda menggunakan proses yang berbeda untuk menghasilkan produk yang sama. Tipe produk yang berbeda mungkin dihasilkan oleh sebuah perusahaan dengan menggunakan proses yang berbeda. Namun beberapa proses lebih cocok dari lainnya untuk beberapa tipe aplikasi. Jika proses yang salah digunakan akan mengurangi kualitas kegunaan produk yang dikembangkan. Menurut Grady Booch, James Rumbaugh dan Ivar Jacobson Prinsip dari Pemodelan adalah: 1. Memilih model apa yang di gunakan, bagaimana masalahnya dan bagaimana juga dengan solusinya. 2. Setiap Model dapat dinyatakan dalam tingkatan yang berbeda 3. Model yang terbaik adalah yang berhubungan dengan realitas. 4. Tidak pernah ada model tunggal yang cukup baik, setiap system yang baik memilik serangkaian model kecil yang independen. Belajar pemodelan perangkat lunak sebagai berikut: 1. Tahapan pengembangan perangkat lunak 2. Model pengembangan perangkat lunak 3. Pemodelan untuk pengembangan perangkat lunak secara terstruktur / structured system development (Data Flow Diagram, Structured chart, Entity Relationship diagram) 4. Pemodelan untuk pengembangan perangkat lunak berorientasi objek / object oriented system development (Unified Modelling Languange: Use Case Diagram, Class Diagram, Activity Diagram) C. Pengenalan Unified Modeling Language Unified Modeling Language adalah bahasa standar untuk menulis blue print Perangkat Lunak. UML umumnya dapat digunakan untuk memvisualisasikan, menentukan, membuat, dan mendokumentasikan artefak dari sistem Perangkat Lunak secara intensif. UML sesuai untuk sistem pemodelan mulai dari sistem informasi perusahaan, aplikasi berbasis web yang terdistribusi, bahkan sampai sistem real time embedded yang sulit. UML digunakan untuk: 1. Menyediakan pedoman kepada Tim Perangkat Lunak 2. Menjelaskan Spesifikasi Perangkat Lunak yang dibangun 3. Menuntun tugas para pengembang Perangkat Lunak secara mandiri ataupun berkelompok 123

4. Menyediakan kriteria untuk monitoring dan evaluasi dari aktivitas proyek Perangkat Lunak. UML adalah bahasa untuk: (ikhtisar UML) Gambar 10.1. Ikhtisar UML 1. Visualizing (Memvisualisasikan) Beberapa hal dimodelkan secara tekstual atau dengan model grafis. UML adalah bahasa grafis yang menggunakan sekelompok simbol grafis. Setiap simbol dalam notasi UML didefinisikan dengan baik secara semantik, sehingga pengembang dapat menulis model UML dan dapat menafsirkan model itu dengan jelas. Gambar 10.2. Visualizing 2. Specifying (Menentukan) UML dapat membangun model yang tepat, tidak ambigu/jelas, dan lengkap yang sistem tanyakan. 124

Gambar 10.3. Specifying UML membahas spesifikasi semua keputusan analisis, perancangan, dan implementasi penting yang harus dilakukan dalam mengembangkan dan menerapkan sistem PL yang intensif. 3. Constructing (Membangun) UML bukan bahasa pemrograman visual, namun modelnya bisa langsung terhubung ke berbagai bahasa pemrograman, dan memungkinkan untuk memetakan ke bahasa pemrograman seperti Java, C ++, atau Visual Basic, atau bahkan ke tabel dalam basis data relasional atau penyimpanan database berorientasi objek yang tetap. Gambar 10.4. Constructing 4. Documenting (Mendokumentasikan artefak dari sistem intensif perangkat lunak.) UML membahas dokumentasi arsitektur sistem dan semua detailnya. UML menyediakan bahasa untuk mengekspresikan persyaratan dan tes. UML juga menyediakan bahasa untuk memodelkan kegiatan perencanaan proyek. Artefak ini meliputi: Gambar 10.5. Documenting 125

D. Sejarah UML Pada tahun 1994, Dr. James Rumbaugh bergabung dengan perusahaan rational software dan Grady Booch sudah bekerja disana sebelumnya. Grady Booch Mengembangkan Object Oriented Design (OOD) & Dr James Rumbaugh Mengembangkan Object Modelling Technique (OMT). Oktober 1995 menghasilkan Unified Method versi 0.8. selanjutnya pada Tahun 1995 Dr. Ivar Jacobson ikut pula bergabung memperkenalkan tool use case Object Oriented Software Engineering (OOSE), Trio tersebut pada bulan juni 1996 menghasilkan Unified Modelling Language (UML) versi 0.9. Banyak perusahaan software merasakan bagaimana pentingnya UML dalam tujuan strategis sehingga membuat konsorsium seperti: Microsoft, Oracle, IBM, HP, dan lain-lain. Dari konsorsium tersebut pada bulan Januari 1997 lahirlah UML versi 1.0. Pada tahun 2002 lahirlah UML versi 2.0, menjadi 13 buah diagram. Gambar 10.6. Sejarah UML Gambar 10.7. Pencipta UML Mulai dari sebelah kiri Grady Booch, Tengah James Rumbaugh, dan sebelah kanan Ivar Jacobson. UML versi 1.0 dibagi menjadi 2 kelompok: Gambar 10.8. Pengelompokan UML Versi 1.0 126

UML menyediakan notasi bergambar atau grafis untuk mendokumentasikan artefak seperti kelas, objek dan paket yang membentuk sistem berorientasi objek. E. Diagram-Diagram UML 1. Class Diagram Menunjukkan seperangkat kelas, antarmuka, dan kolaborasi dan hubungan di antara mereka. Class Diagram membahas desain statis dari suatu sistem. Class diagram mewakili sesuatu/benda (misalnya: employee, paycheck, dan lain- lain) Gambar 10.9. Contoh Class Diagram 2. Object Diagram Menunjukkan satu set objek dan hubungan antara objek. Diagram objek memodelkan instance dari hal-hal yang terdapat dalam Class Diagram. Diagram objek digunakan untuk memodelkan desain statis suatu sistem, untuk memvisualisasikan, menentukan, dan mendokumentasikan model struktural, dan membangun aspek statis sistem melalui teknik maju (forward) dan mundur (reverse). Object Diagram juga mirip dengan Class Diagram, gambaran tentang objek-objek dalam sistem serta hubungan antar objek. Gambar 10.10. Contoh Object Diagram 127

3. Component Diagram Menunjukkan organisasi dan ketergantungan antar sekumpulan komponen. Atau hubungan fisik di antara komponen perangkat lunak Gambar 10.11. Contoh Component Diagram Gambar 10.12. Contoh Component Diagram 4. Deployment Diagram Menunjukkan konfigurasi komponen dalam proses eksekusi aplikasi. Diagram ini terdiri dari node yang merupakan perangkat keras dan membungkus satu atau lebih komponen. Menunjukkan arsitektur fisik dan komponen perangkat lunak sistem. Misal: network nodes Gambar 10.13. Contoh Deployment Diagram 128

F. Use Case Diagram Menunjukkan sebuah interaksi antara satu atau lebih aktor dengan sistem informasi yang akan dibuat. Diagram ini sangat penting dalam mengatur dan memodelkan perilaku suatu sistem. Beberapa gambaran tentang use case diagram sebagai berikut: 1. Menunjukkan interaksi antara sistem dan lingkungan 2. Menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. 3. Menekankan “apa” yang diperbuat sistem 4. Menggambarkan kebutuhan sistem dari sudut pandang pengguna (user) Gambar 10.14. Contoh Use Case Diagram Beberapa simbol-simbol Use Case dapat dijelaskan pada tabel dibawah ini: Tabel 10.1. Simbol-Simbol Use Case No Nama Simbol Keterangan 1 Use Case 1. Digambarkan dengan elips horizontal 2. Nama Use case menggunakan kata kerja 2 Actor 1. Menggambarkan orang, system/external entitas yang menyediakan atau menerima informasi 2. Merupakan lingkungan luar dari sistem 3. Nama Aktor menggunakan Kata benda 4. Aktor utama digambarkan pada pojok kiri atas dari diagram 129

3 Asosiasi 1. Menggambarkan bagaimana aktor 4 Generalisasi berinteraksi dengan use case 5 Relasi include 2. Bukan menggambarkan Relasi aliran extend data/informasi 6 Boundary Gambaran Boxes generalisasi antara use case atau antara aktor dengan panah tertutup yang mengarah dari child ke parent 1.Hubungan antara dua use case untuk menunjukkan adanya perilaku use case yang dimasukkan ke dalam perilaku dari base use case 2.Tanda panah terbuka harus terarah ke sub use case 1. Perluasan dari use case lain (optional) 2. Tanda panah terbuka harus terarah ke base use case Untuk memperlihatkan batasan sistem dengan lingkungan luar sistem 130

Gambar 10.15. Contoh penggunaan relasi include dan extend Berikut contoh pembuatan Use Case untuk pembelian tiket online 1. Daftar Kebutuhan Fungsional Use Case Tabel 10.2. Daftar Kebutuhan Fungsional Use Case No Use Case Aktor Deskripsi 1 Registrasi Pembeli Use case ini berfungsi untuk proses pendaftaran sebagai pembeli 2 Verifikasi Admin Use case ini befungsi untuk melakukan data pengecekan data pembeli 3 Lihat Jadwal Pembeli Use case ini befungsi untuk melihat Penerbangan jadwal penerbangan oleh pembeli 4 Login Pembeli, Admin Use case ini befungsi untuk masuk ke dalam sistem untuk pembeli dan admin 5 Beli Tiket Pembeli Use case ini befungsi untuk membeli tiket penerbangan 2. Daftar Kebutuhan Fungsional Aktor Tabel 10.3. Daftar Kebutuhan Fungsional Aktor No Aktor Deskripsi 1 Pembeli Pembeli adalah aktor yang dapat melakukan Registrasi, melihat jadwal penerbangan, melakukan login, membeli tiket, dan checkout 2 Admin Admin adalah aktor yang dapat melakukan verifikasi data pembeli dan melakukan login 131

3. Use Case Pembelian Tiket Online Gambar 10.16. Use Case Pembelian Tiket Online 4. Spesifikasi Use Case Tabel 10.4. Spesifikasi Use Case Nama Use Case Beli Tiket Deskripsi Use case ini menyediakan layanan Aktor pembelian tiket penerbangan Pembeli Pre-Condition Login Post-Condition • Pembeli melengkapi data penumpang Relasi • Pembeli memilih cara pembayaran • Pembeli melakukan checkout Extend dari Login 5. Skenario Use Case Tabel 10.5. Skenario Use Case Aksi Aktor Reaksi Sistem 1.Pembeli melakukan registrasi 2. Sistem menyimpan data registrasi 3. Pembeli melihat jadwal penerbangan 132

4. Sistem akan menampilkan jadwal penerbangan berikut harga tiket yang ditawarkan 5. Pembeli membeli tiket penerbangan 6. Sistem menampilkan form data penumpang yang harus diisi oleh pembeli 7. Pembeli mengisi data penumpang 8. Sistem menampilkan halaman untuk memilih cara pembayaran 9. Pembeli memilih cara pembayaran 10. Sistem menampilkan halaman checkout 11. Sistem mengirimkan notifikasi pembelian tiket melalui email 12. Pembeli melakukan pembayaran 13. Pembeli melakukan konfirmasi pembayaran 14. Sistem mengirimkan e- tiket melalui email G. Activity Diagram Activity Diagram adalah teknik untuk menggambarkan logika prosedural, proses bisnis, dan jaringan kerja antara pengguna dan sistem. Menggunakan notasi yang mirip flowchart, meskipun terdapat sedikit perbedaan notasi karena diagram ini mendukung behavior paralel. Activity diagram dibuat berdasarkan sebuah atau beberapa use case pada use case diagram. Memungkinkan melakukan proses untuk memilih urutan dalam melakukannya atau hanya menyebutkan aturan- aturan rangkaian dasar yang harus diikuti, karena proses- proses sering muncul secara paralel. 133

Simbol-Simbol Activity Diagram Tabel 10.6. Simbol-simbol Activity Diagram No Nama Simbol Keterangan 1. Start 1. Menjelaskan awal 2. End proses kerja dalam activity 3. Activity diagram 4. Join 5. Fork 2. Hanya ada satu 6. Decision simbol start 7. Connector 1. Menandai kondisi 8. Swimlane akhir dari suatu aktivitas dan merepresentasikan penyelesaian semua arus proses 2. Bisa lebih dari satu simbol end • Menunjukkan kegiatan yang membentuk proses dalam diagram • Menggabungkan dua atau lebih aktivitas bersamaan dan menghasilkan hanya satu aktivitas yang terjadi dalam satu waktu • Membagi aliran aktivitas tunggal menjadi beberapa aktivitas bersamaan • Mewakili keputusan yang memiliki setidaknya dua jalur bercabang yang kondisinya sesuai dengan opsi pencabangan • Menunjukkan arah aliran atau aliran kontrol dari aktivitas 1. Cara untuk mengelompokkan aktivitas berdasarkan aktor 2. Menggunakan garis vertikal 134

Contoh Activity Diagram Gambar 10.17. Contoh Activity Diagram H. Latihan dan Tugas Mandiri Pertemuan 10 Perpustakaan di sekolah SMK Cyber Media saat ini merupakan salah satu unsur penunjang sarana dalam kegiatan belajar siswa. Perpustakaan ini melayani pendaftaran anggota perpustakaan baru melalui form registrasi pendaftaran apabila terdapat siswa yang hendak menjadi anggota perpustakaan, selanjutnya apabila anggota sudah terdaftar pada perpustakaan tersebut siswa dapat melakukan transaksi peminjaman buku dengan menunjukkan kartu anggota perpustakaan, sehingga saat melakukan transaksi tersebut petugas perpustakaan mencatat di buku besar saat anggota 135

melakukan peminjaman buku tersebut. Setelah 7 hari batas waktu peminjaman buku telah berakhir maka siswa mengembalikan buku tersebut dengan dilakukan pencatatan di buku besar tentang buku yang di kembalikannya apakah sesuai atau tidak, apakah waktu peminjaman melebihi batas waktu yang di tentukan atau tidak, apabila siswa terlambat mengembalikan buku, maka petugas perpustakaan memberikan sanksi berupa denda keterlambatan atas buku yang dipinjam oleh siswa tersebut. Selanjutnya setelah semua transaksi selesai, petugas perpustakaan membuat laporan kepada kepala perpustakaan berupa daftar anggota perpustakaan baru, laporan peminjaman buku, laporan pengembalian buku serta laporan denda peminjaman buku bagi anggota yang terlambat mengembalikan buku perpustakaan. Tugas anda buatlah : 1. Daftar Kebutuhan Fungsional Use Case 2. Daftar Kebutuhan Fungsional Aktor 3. Rancangan Use Case Diagram 4. Spesifikasi Use Case 5. Skenario Use Case III. Penutup Pemodelan Perangkat Lunak adalah Disiplin ilmu untuk mempelajari bentuk-bentuk pemodelan perangkat lunak yang digunakan sebagai bagian dari tahapan pengembangan perangkat lunak secara terstruktur dan berorientasi objek. Unified Modeling Language adalah bahasa standar untuk menulis blue print Perangkat Lunak. UML umumnya dapat digunakan untuk memvisualisasikan, menentukan, membuat, dan mendokumentasikan artefak dari sistem Perangkat Lunak secara intensif. Pada tahun 1994, Dr. James Rumbaugh bergabung dengan perusahaan rational software dan Grady Booch sudah bekerja disana sebelumnya. Grady Booch Mengembangkan Object Oriented Design (OOD) & Dr James Rumbaugh Mengembangkan Object Modelling Technique (OMT). Oktober 1995 menghasilkan Unified Method versi 0.8. selanjutnya pada Tahun 1995 Dr. Ivar Jacobson ikut pula bergabung memperkenalkan tool use case Object Oriented Software Engineering (OOSE), Trio tersebut pada bulan juni 1996 menghasilkan Unified Modelling Language (UML) versi 0.9. Banyak perusahaan software merasakan bagaimana pentingnya UML dalam tujuan strategis sehingga membuat konsorsium seperti: Microsoft, Oracle, IBM, HP, dan lain-lain. Dari konsorsium tersebut pada bulan Januari 1997 lahirlah UML versi 1.0. Pada tahun 2002 lahirlah UML versi 2.0, menjadi 13 buah diagram. Use case diagram menunjukkan sebuah interaksi antara satu atau lebih aktor dengan sistem informasi yang akan dibuat. Diagram ini sangat penting dalam mengatur dan memodelkan perilaku suatu sistem. Daftar Pustaka Buku : 1. Rosa, M.Shalahuddin. 2019. “Rekayasa Perangkat Lunak Terstruktur dan Berorientasi Obyek”. Informatika: Bandung. 2. Shelly, Gary B. and Rosenblatt, Harry J. 2012. Systems Analysis and Design. 9th. USA: Boston. 3. Simarmata, Janner. 2009. Rekayasa Perangkat Lunak. Andi : Yogyakarta. 4. Suprapto, Falahah. 2018. “Rekayasa Perangkat Lunak”. Lentera Ilmu Cendikia: Jakarta. 5. Utami, Feri Hari. 2015. “Rekayasa Perangkat Lunak”. Deepublish: Yogyakarta 136

Pendukung: 1. http://staffnew.uny.ac.id/upload/132315977/pengabdian/rekayasaperangkatlu nak-plpg2012.pdf 2. http://informatikaunindra.org/file/RPL/Diktat/Diktat%20RPL.pdf 3. https://repository.nusamandiri.ac.id/index.php/unduh/item/228647/RPL.pdf 4. https://www.smktarunabangsa.sch.id/artikel/detail/konsep-pemodelan- perangkat-lunak 5. https://sis.binus.ac.id/2020/04/20/perbedaan-deployment-diagram-dan- component-diagram/ 137