PEMODELAN DAN UNIFIED MODELING LANGUAGE
Kemampuan akhir tiap tahapan belajar dan Penilaian Pertemuan 10 Sub-CPMK5 Mampu menerapkan pemodelan dan diagram UML serta merancang model UML dengan tools yang sesuai serta dapat melakukan pengujian perangkat lunak yang telah di buat (CMPK1, CPMK6) Indikator: Ketepatan menjelaskan tentang Pemodelan dan UML (diagram UML: Use Case, diagram aktifitas). Kriteria & Teknik: Ketepatan dan penguasaan tentang perancangan system dalam bentuk tes.
Media Pembelajaran 1. Ecampus STTI NIIT (https://ecampus.i-tech.ac.id/) 2. PubHMTL5 (Bahan Ajar) (https://online.pubhtml5.com/ecdbc/oeto/ 3. Power Point 4. Video Streaming 5. Mentimeter 6. Quizizz (Pre Test dan Post Test) dan ecampus 9. Whatsapp (085692405633)
Pokok Bahasan Materi Pertemuan 10 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
Pengetahuan Mahasiswa Pertemuan 10 tentang Pemodelan dan UML https://www.menti.com/kode menti
A. Tingkat Kerumitan Pengembang Perangkat Lunak Sebuah perusahaan software developer dalam pengembangkan suatu rekayasa perangkat lunak bukanlah hal yang mudah. https://i.ytimg.com/vi/ZvISbJNSolg/maxresdefault.jpg
Berikut ini adalah tingkatan kerumitan dalam pengembangan sebuah perangkat lunak yang sering di alami oleh software developer sebagai berikut: Tingkat kerumitan dari Tingkat kesulitan Tingkat fleksibilitas Tingkat permasalahan domain permasalahan dalam mengelola adanya perubahan yang berkarakteristik proses pengembangan pada bagian-bagian perangkat lunak perangkat lunak perangkat lunak dari perangkat lunak
“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”
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. 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 UML adalah bahasa standar untuk menulis blue print PL. UML dapat digunakan untuk memvisualisasikan, menentukan, membuat, dan mendokumentasikan artefak dari sistem PL 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 dapat digunakan dalam domain seperti: Sistem Elektronik Ilmiah Informasi Perusahaan Layanan Pertahanan Layanan Perbangkan aplikasi web terdistribusi Telekomunikasi Angkutan Sistem Real time embedded
• UML adalah proses yang independen, walaupun secara optimal harus digunakan dalam proses yang menggunakan case driven, architecture- centric, iterative, dan incremental. UML digunakan untuk : Menyediakan pedoman bagi TIM PL Menyediakan Menjelaskan kriteria untuk Spesifikasi PL monev aktivitas yang Dibangun proyek PL Menuntun tugas para pengembang secara mandiri atau kelompok
UML adalah bahasa untuk: (ikhtisar /ringkasan UML)
UML adalah bahasa untuk: a. 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.
b. Specifying (Menentukan) • UML dapat membangun model yang tepat, tidak ambigu/jelas, dan lengkap yang sistem tanyakan. Model yang Tidak Lengkap UML Tepat Ambigu (Jelas) • UML membahas spesifikasi semua keputusan analisis, perancangan, dan implementasi penting yang harus dilakukan dalam mengembangkan dan menerapkan sistem PL yang intensif.
UML adalah bahasa untuk (lanjutan) c. 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. C++ Java Visual Studio Model UML
d. 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. Persyaratan Artefak ini meliputi: Rilis PL Arsitektur Prototipe Documen Desain/ artefak PL Rancangan Tes Kode Sumber Rencana Proyek
1994, Dr. James Rumbaugh D. Sejarah UML Pada tahun 2002 lahirlah UML bergabung dengan perusahaan versi 2.0, menjadi 13 buah 1995 Dr. Ivar Jacobson ikut pula rational software dan Grady bergabung memperkenalkan tool use diagram Booch sudah bekerja disana case Object sebelumnya Oriented Software Engineering (OOSE), TRIO tersebut juni 1996 Grady Booch Mengembangkan menghasilkan Unified Modelling Object Oriented Design (OOD) Language (UML) versi 0.9 & Dr James Rumbaugh Mengembangkan Object Banyak perusahaan software Modelling Technique (OMT) merasakan bagaimana pentingnya UML dalam tujuan strategis sehingga membuat konsorsium seperti : Microsoft, Oracle, IBM, HP, dll Oktober 1995 menghasilkan Dari konsorsium tersebut pada Unified Method versi 0.8 bulan Januari 1997 lahirlah UML versi 1.0
UML versi 1.0 dibagi menjadi 2 kelompok:
• UML menyediakan notasi bergambar atau grafis untuk mendokumentasikan artefak seperti kelas, objek dan paket yang membentuk sistem berorientasi objek
E. Diagram-Diagram dalam 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 Pendaftaran Seminar
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 • Mirip dengan Class Diagram • Gambaran tentang objek- objek dalam sistem • Hubungan antar objek
Diagram-Diagram dalam UML (Lanjutan) 3. Component Diagram Menunjukkan organisasi dan ketergantungan antar sekumpulan komponen.
Diagram-Diagram dalam UML (Lanjutan) 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
F. Usecase Diagram 5. 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. • Menunjukkan interaksi antara sistem dan lingkungan • Menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. • Menekankan“apa” yang diperbuat sistem • Menggambarkan kebutuhan sistem dari sudut pandang pengguna (user)
Contoh Use Case Diagram
Simbol-Simbol Use Case No Nama Simbol Keterangan 1. Use Case • Digambarkan dengan elips horizontal 2. Aktor • Nama Use case menggunakan kata kerja • Menggambarkan orang, system/external entitas yang menyediakan atau menerima informasi • Merupakan lingkungan luar dari sistem • Nama Aktor menggunakan Kata benda • Aktor utama digambarkan pada pojok kiri atas dari diagram
Simbol-Simbol Use Case No Nama Simbol Keterangan 3. Asosiasi • Menggambarkan bagaimana aktor berinteraksi dengan use case • Bukan menggambarkan aliran data/informasi 4. Generalisasi • Gambarkan generalisasi antara use case atau antara aktor dengan panah tertutup yang mengarah dari child ke parent
Simbol-Simbol Use Case No Nama Simbol Keterangan 5. Relasi • Hubungan antara dua use case untuk include menunjukkan adanya perilaku use case yang dimasukkan ke dalam perilaku dari base use case • Tanda panah terbuka harus terarah ke sub use case Relasi • Perluasan dari use case lain (optional) extend • Tanda panah terbuka harus terarah ke base use case 6. Boundary • Untuk memperlihatkan batasan sistem Boxes dengan lingkungan luar sistem
Contoh penggunaan relasi include dan extend
Contoh Penggambaran Use Case (1) • Pada gambar di atas, penulisan nama use case tidak dituliskan secara berlebihan, seharusnya hanya bisnis proses saja yang dituliskan yaitu LOGIN • Asosiasi aktor dengan use case sebaiknya tidak menggunakan tanda panah, kecuali untuk penggunaan relasi include/extend, dan generalisasi
Contoh Penggambaran Use Case (2) Pada gambar di atas, penulisan nama use case Pilih Menu, Pilih Profil, Pilih Login, tidak seharusnya ditulis demikian. Use case dituliskan dengan bisnis proses, bukan aksi seperti dalam Activity Diagram
Contoh Berikut contoh pembuatan Use Case untuk pembelian tiket online pesawat
1. Daftar Kebutuhan Fungsional Use Case No Use Case Aktor Deskripsi 1 Registrasi Pembeli Use case ini berfungsi untuk proses 2 Verifikasi data pendaftaran sebagai pembeli 3 Lihat Jadwal Admin Use case ini befungsi untuk melakukan Penerbangan pengecekan data pembeli 4 Login Pembeli Use case ini befungsi untuk melihat jadwal penerbangan oleh pembeli 5 Beli Tiket Pembeli, Admin Use case ini befungsi untuk masuk ke dalam sistem untuk pembeli dan admin Pembeli Use case ini befungsi untuk membeli tiket penerbangan
2. 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
3. Use Case Pembelian Tiket Online
4. Spesifikasi Use Case Nama Use Case Beli Tiket Deskripsi Use case ini menyediakan layanan pembelian tiket penerbangan Aktor Pre-Condition Pembeli Post-Condition Login • Pembeli melengkapi data penumpang • Pembeli memilih cara pembayaran • Pembeli melakukan checkout Relasi Extend dari Login
5. Skenario Use Case Aksi Aktor Reaksi Sistem 1.Pembeli melakukan registrasi 3. Pembeli melihat jadwal penerbangan 2. Sistem menyimpan data registrasi 5. Pembeli membeli tiket penerbangan 4. Sistem akan menampilkan jadwal penerbangan berikut harga tiket yang 7. Pembeli mengisi data penumpang ditawarkan 6. Sistem menampilkan form data penumpang yang harus diisi oleh pembeli 8. Sistem menampilkan halaman untuk memilih cara pembayaran
5. Skenario Use Case (Lanjutan) Aksi Aktor Reaksi Sistem 9. Pembeli memilih cara pembayaran 10.Sistem menampilkan halaman 12.Pembeli melakukan pembayaran checkout 13.Pembeli melakukan konfirmasi 11.Sistem mengirimkan notifikasi pembayaran pembelian tiket melalui email 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.
Simbol-Simbol Activity Diagram No Nama Simbol Keterangan 1. Start 2. End • Menjelaskan awal proses kerja dalam activity diagram 3. Activity 4. Join • Hanya ada satu simbol start • Menandai kondisi akhir dari suatu aktivitas dan merepresentasikan penyelesaian semua arus proses • 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
Simbol-Simbol Activity Diagram No Nama Simbol Keterangan 5. Fork • Membagi aliran aktivitas tunggal 6. Decision menjadi beberapa aktivitas bersamaan 7. Connector 8. Swimlane • Mewakili keputusan yang memiliki setidaknya dua jalur bercabang yang kondisinya sesuai dengan opsi pencabangan • Menunjukkan arah aliran atau aliran kontrol dari aktivitas • Cara untuk mengelompokkan aktivitas berdasarkan aktor • Menggunakan garis vertikal
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 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
Rangkuman • 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 Referensi • Buku : • Rosa, M.Shalahuddin. 2019. “Rekayasa Perangkat Lunak Terstruktur dan Berorientasi Obyek”. Informatika: Bandung. • Shelly, Gary B. and Rosenblatt, Harry J. 2012. Systems Analysis and Design. 9th. USA: Boston. • Simarmata, Janner. 2009. Rekayasa Perangkat Lunak. Andi : Yogyakarta. • Suprapto, Falahah. 2018. “Rekayasa Perangkat Lunak”. Lentera Ilmu Cendikia: Jakarta. • Utami, Feri Hari. 2015. “Rekayasa Perangkat Lunak”. Deepublish: Yogyakarta • Pendukung: • http://staffnew.uny.ac.id/upload/132315977/pengabdian/rekayasaperangkatlunak-plpg2012.pdf • http://informatikaunindra.org/file/RPL/Diktat/Diktat%20RPL.pdf • https://repository.nusamandiri.ac.id/index.php/unduh/item/228647/RPL.pdf • https://www.smktarunabangsa.sch.id/artikel/detail/konsep-pemodelan-perangkat-lunak • https://sis.binus.ac.id/2020/04/20/perbedaan-deployment-diagram-dan-component-diagram/
Search
