REKAYA PERANGKAT LUNAK TUGAS MERANGKUM
IAN SOMMERVILLE. “SOFTWARE ENGINEERING”. 9th EDITION. ADDISON- WESLEY. 2011.
DOSEN PENGAMPU:
FIRMANSYAH ADIPUTRA, ST.M.Cs
DISUSUN OLEH : AMELIA ZALFA SAHIRA
220441100082
PRODI SISTEM INFORMASI JURUSAN TEKNIK INFORMATIK
FAKULTAS TEKNIK
UNIVERSITAS TRUNOJOYO MADURA
CHAPTER 5
Modelisasi sistem adalah proses pengembangan model abstrak dari suatu sistem, di mana setiap model menyajikan pandangan atau perspektif yang berbeda terhadap sistem tersebut. Modelisasi sistem umumnya mengacu pada representasi sistem menggunakan notasi grafis, yang sekarang hampir selalu didasarkan pada notasi dalam Unified Modeling Language (UML). Namun, juga memungkinkan untuk mengembangkan model formal (matematis) dari suatu sistem, biasanya sebagai spesifikasi sistem yang rinci.
Model-model digunakan selama proses rekayasa kebutuhan untuk membantu menurunkan kebutuhan sistem, selama proses desain untuk menjelaskan sistem kepada insinyur yang
mengimplementasikan sistem, dan setelah implementasi untuk mendokumentasikan struktur dan operasi sistem. Ada dua jenis model yang dapat dikembangkan: model sistem yang sudah ada dan model sistem yang akan dikembangkan.
Model sistem yang sudah ada digunakan selama rekayasa kebutuhan untuk mengklarifikasi apa yang dilakukan sistem yang sudah ada dan dapat digunakan sebagai dasar untuk membahas kelebihan dan kelemahan sistem tersebut. Ini kemudian mengarah ke kebutuhan untuk sistem baru.
Model sistem yang akan dikembangkan digunakan selama rekayasa kebutuhan untuk
menjelaskan kebutuhan yang diusulkan kepada pemangku kepentingan sistem lainnya. Insinyur menggunakan model ini untuk mendiskusikan proposal desain dan mendokumentasikan sistem untuk implementasi. Dalam proses rekayasa berbasis model, mungkin dapat menghasilkan implementasi sistem yang lengkap atau sebagian dari model sistem
Aspek paling penting dari model sistem adalah bahwa ia mengabaikan detail. Sebuah model adalah abstraksi dari sistem yang sedang dipelajari bukan representasi alternatif dari sistem itu.
Representasi sistem seharusnya mempertahankan semua informasi tentang entitas yang
direpresentasikan. Abstraksi dengan sengaja menyederhanakan dan memilih karakteristik yang paling menonjol.
Berbagai model dapat dikembangkan untuk merepresentasikan sistem dari perspektif yang berbeda, seperti perspektif eksternal, interaksi, struktural, dan perilaku. Perspektif ini memiliki kesamaan dengan pendekatan arsitektur sistem 4 + 1 dari Krutchen, yang menyarankan untuk mendokumentasikan arsitektur dan organisasi sistem dari perspektif yang berbeda.
Dalam pengembangan model sistem, notasi grafis dapat digunakan dengan fleksibilitas
tergantung pada cara penggunaan model. Tiga cara umum penggunaan model grafis melibatkan fasilitasi diskusi, dokumentasi sistem yang sudah ada, dan deskripsi sistem rinci untuk
menghasilkan implementasi sistem.
Terutama, dalam pemodelan sistem menggunakan UML, lima jenis diagram yang sering digunakan adalah diagram aktivitas, diagram use case, diagram urutan, diagram kelas, dan diagram keadaan. Masing-masing digunakan untuk menggambarkan aspek tertentu dari sistem Dalam penggunaan model sebagai bagian dari proses pengembangan berbasis model, model- model sistem harus lengkap dan benar karena digunakan sebagai dasar untuk menghasilkan kode sumber sistem. Notasi harus digunakan dengan hati-hati untuk menghindari kebingungan simbol yang mirip namun memiliki makna yang berbeda.
Ringkasan Materi:
5.1 Model Konteks (Context Models)
Pada tahap awal dalam spesifikasi suatu sistem, perlu menentukan batas sistem. Ini melibatkan kerjasama dengan pemangku kepentingan sistem untuk menentukan fungsionalitas yang harus disertakan dalam sistem dan apa yang disediakan oleh lingkungan sistem. Keputusan ini harus diambil pada awal proses untuk membatasi biaya sistem dan waktu yang diperlukan untuk memahami kebutuhan dan desain sistem.
Batas antara sistem dan lingkungannya mungkin jelas dalam beberapa kasus, tetapi dalam kasus lain, fleksibilitas lebih besar, dan batas tersebut dapat ditentukan selama proses rekayasa
kebutuhan. Keputusan ini terkait dengan apa yang harus difokuskan oleh sistem, apakah hanya mengumpulkan informasi tentang konsultasi atau juga mengumpulkan informasi pribadi pasien.
Penentuan batas sistem bukanlah penilaian bebas nilai. Pertimbangan sosial dan organisasional dapat mempengaruhi posisi batas sistem oleh faktor non-teknis. Contohnya, batas sistem mungkin diposisikan agar proses analisis dapat dilakukan di satu lokasi, atau mungkin dipilih agar manajer yang sulit untuk berkomunikasi tidak perlu dikonsultasikan.
Setelah beberapa keputusan tentang batas sistem dibuat, bagian dari aktivitas analisis adalah mendefinisikan konteks dan ketergantungan sistem pada lingkungannya. Biasanya, langkah pertama dalam aktivitas ini adalah menghasilkan model arsitektur sederhana.
Model Konteks Sederhana (Simple Context Model)
Model konteks sederhana menunjukkan hubungan antara sistem dan sistem lainnya di lingkungannya. Model ini membantu mengidentifikasi sistem-sistem lain yang berinteraksi dengan sistem yang sedang dijelaskan. Misalnya, model konteks sederhana dapat menunjukkan bahwa sistem informasi pasien untuk perawatan kesehatan mental terhubung dengan sistem pencatatan janji temu dan sistem rekam pasien umum.
Model konteks biasanya menunjukkan bahwa lingkungan melibatkan beberapa sistem otomatis, tetapi tidak menunjukkan jenis hubungan antara sistem-sistem di lingkungan dan sistem yang sedang dijelaskan. Oleh karena itu, model konteks sederhana digunakan bersama dengan model
lain, seperti model proses bisnis, untuk memberikan gambaran yang lebih lengkap tentang hubungan dan interaksi antara sistem dan lingkungannya.
Model Proses Aktivitas (Activity Process Model)
Model proses aktivitas menggunakan diagram aktivitas UML untuk menunjukkan serangkaian kegiatan yang membentuk suatu proses dalam sistem. Diagram ini mencakup aktivitas, objek, dan alur kendali dari satu aktivitas ke aktivitas lainnya.
Contoh model proses aktivitas dapat menunjukkan bagaimana sistem informasi pasien untuk perawatan kesehatan mental digunakan dalam proses penanganan pasien yang berpotensi berbahaya bagi diri sendiri atau orang lain. Diagram ini mencakup aktivitas-aktivitas seperti memberitahukan perawatan sosial dan keluarga pasien, serta pembaruan register penahanan.
Pentingnya Model Konteks dan Model Proses Aktivitas
Model-model ini membantu dalam memahami dan mengidentifikasi bagaimana sistem berinteraksi dengan lingkungannya, bagaimana sistem digunakan dalam proses tertentu, dan bagaimana aktivitas sistem koordinatif dilakukan. Model konteks dan model proses aktivitas diperlukan untuk memahami kebutuhan sistem dan merancang implementasi sistem yang sesuai.
5.2 Ringkasan Model Interaksi (Interaction Models)
Semua sistem melibatkan interaksi dalam beberapa bentuk. Ini bisa berupa interaksi pengguna, yang melibatkan input dan output pengguna, interaksi antara sistem yang sedang dikembangkan dengan sistem lain, atau interaksi antara komponen-komponen sistem. Memodelkan interaksi pengguna penting karena membantu mengidentifikasi kebutuhan pengguna. Memodelkan interaksi antara sistem membantu menyoroti masalah komunikasi yang mungkin muncul.
Memodelkan interaksi komponen membantu kita memahami apakah struktur sistem yang diusulkan kemungkinan akan memberikan kinerja dan keterandalan sistem yang dibutuhkan.
Dalam bagian ini, saya membahas dua pendekatan terkait untuk pemodelan interaksi:
1. Pemodelan Use Case: Pemodelan ini digunakan terutama untuk memodelkan interaksi antara sistem dan aktor eksternal (pengguna atau sistem lain).
2. Diagram Urutan (Sequence Diagrams): Digunakan untuk memodelkan interaksi antara komponen-komponen sistem, meskipun agen eksternal juga dapat disertakan.
Pemodelan Use Case (Use Case Modeling)
Pemodelan use case adalah pendekatan untuk menggambarkan interaksi antara sistem dan aktor eksternal. Use case adalah skenario atau situasi yang menggambarkan bagaimana sistem
berinteraksi dengan pengguna atau sistem eksternal. Pemodelan ini membantu dalam
mengidentifikasi kebutuhan pengguna dan menyajikan pandangan yang jelas tentang fungsionalitas sistem dari perspektif pengguna.
Diagram Urutan (Sequence Diagrams)
Diagram urutan digunakan untuk memodelkan interaksi antara komponen-komponen sistem, tetapi juga dapat mencakup agen eksternal. Diagram ini menunjukkan urutan pesan atau aktivitas antara objek dalam sistem dari waktu ke waktu. Ini membantu memahami bagaimana komponen- komponen berinteraksi satu sama lain dan dapat digunakan untuk mengidentifikasi masalah komunikasi atau ketergantungan yang mungkin muncul.
Penggunaan Bersama Model Use Case dan Diagram Urutan
Model use case dan diagram urutan menyajikan interaksi pada tingkat detail yang berbeda dan oleh karena itu dapat digunakan bersama. Detail interaksi yang terlibat dalam use case tingkat tinggi dapat didokumentasikan dalam diagram urutan. UML juga mencakup diagram komunikasi yang dapat digunakan untuk memodelkan interaksi, meskipun tidak dibahas di sini karena merupakan representasi alternatif dari diagram urutan. Beberapa alat bahkan dapat menghasilkan diagram komunikasi dari diagram urutan.
Kesimpulan:
Memahami dan memodelkan interaksi adalah langkah penting dalam pengembangan sistem.
Pemodelan use case dan diagram urutan membantu mengidentifikasi kebutuhan pengguna, memahami komunikasi antara sistem dan komponennya, dan memastikan kinerja serta keterandalan sistem yang diusulkan. Keduanya dapat digunakan secara bersamaan untuk memberikan pandangan yang komprehensif tentang bagaimana sistem berinteraksi dengan pengguna, sistem lain, dan komponennya sendiri.
5.2.1 Ringkasan Pemodelan Use Case (Use Case Modeling)
Pemodelan use case awalnya dikembangkan oleh Jacobson dkk. (1993) pada tahun 1990-an dan diintegrasikan ke dalam rilis pertama UML (Rumbaugh dkk., 1999). Seperti yang telah dibahas dalam Bab 4, pemodelan use case sangat umum digunakan untuk mendukung perolehan
kebutuhan. Sebuah use case dapat dianggap sebagai skenario sederhana yang menggambarkan harapan pengguna terhadap suatu sistem.
Setiap use case mewakili tugas diskrit yang melibatkan interaksi eksternal dengan sistem. Dalam bentuk paling sederhana, use case ditampilkan sebagai elips dengan aktor yang terlibat dalam use case tersebut direpresentasikan sebagai gambar stick figure. Gambar 5.3 menunjukkan use case dari MHC-PMS yang mewakili tugas mengunggah data dari MHC-PMS ke sistem rekam pasien umum yang lebih umum.
Perhatikan bahwa ada dua aktor dalam use case ini: operator yang mentransfer data dan sistem rekam pasien. Notasi gambar stick figure awalnya dikembangkan untuk mencakup interaksi manusia tetapi sekarang juga digunakan untuk mewakili sistem eksternal dan perangkat keras.
Secara formal, diagram use case seharusnya menggunakan garis tanpa panah karena panah dalam UML menunjukkan arah aliran pesan. Namun, panah dalam Gambar 5.3 digunakan secara informal untuk menunjukkan bahwa resepsionis medis memulai transaksi dan data ditransfer ke sistem rekam pasien.
Diagram use case memberikan gambaran yang cukup sederhana tentang interaksi, sehingga perlu memberikan lebih banyak detail untuk memahami yang terlibat. Detail ini dapat berupa deskripsi tekstual sederhana, deskripsi terstruktur dalam tabel, atau diagram urutan seperti yang dibahas di bawah ini. Anda memilih format yang paling sesuai tergantung pada use case dan tingkat detail yang Anda anggap diperlukan dalam model. Format tabular standar umumnya dianggap paling berguna.
Seperti yang telah dibahas dalam Bab 4, diagram use case komposit menunjukkan beberapa use case yang berbeda. Terkadang, mungkin memungkinkan untuk menyertakan semua interaksi mungkin dengan sistem dalam satu diagram use case komposit. Namun, hal ini mungkin tidak mungkin karena jumlah use case. Dalam kasus tersebut, Anda mungkin mengembangkan beberapa diagram, masing-masing menunjukkan use case terkait. Sebagai contoh, Gambar 5.5 menunjukkan semua use case di MHC-PMS di mana aktor 'Resepsionis Medis' terlibat.
5.2.2 Ringkasan Diagram Urutan (Sequence Diagrams)
Diagram urutan dalam UML digunakan terutama untuk memodelkan interaksi antara aktor dan objek dalam sistem serta interaksi antara objek itu sendiri. UML memiliki sintaks yang kaya untuk diagram urutan, yang memungkinkan banyak jenis interaksi dapat dimodelkan. Di sini saya fokus pada dasar-dasar jenis diagram ini karena keterbatasan ruang.
Seperti namanya, diagram urutan menunjukkan urutan interaksi yang terjadi selama use case atau instance use case tertentu. Gambar 5.6 adalah contoh diagram urutan yang mengilustrasikan dasar-dasar notasi. Diagram ini memodelkan interaksi yang terlibat dalam use case 'View patient information', di mana seorang resepsionis medis dapat melihat beberapa informasi pasien.
Objek dan aktor yang terlibat terdaftar di bagian atas diagram, dengan garis putus-putus digambar secara vertikal dari mereka. Interaksi antara objek ditunjukkan oleh panah yang
dianotasi. Persegi panjang pada garis putus-putus menunjukkan lifeline objek yang bersangkutan (yaitu, waktu instansi objek terlibat dalam perhitungan). Anda membaca urutan interaksi dari atas ke bawah. Anotasi pada panah menunjukkan panggilan ke objek, parameter mereka, dan nilai kembalian. Dalam contoh ini, saya juga menunjukkan notasi yang digunakan untuk
menunjukkan alternatif. Kotak bernama 'alt' digunakan dengan kondisi yang ditunjukkan dalam kurung siku.
Anda dapat membaca Gambar 5.6 sebagai berikut:
1. Resepsionis medis memicu metode 'ViewInfo' pada instansi P dari kelas objek 'PatientInfo', menyediakan pengidentifikasi pasien, PID. P adalah objek antarmuka pengguna, yang
ditampilkan sebagai formulir yang menunjukkan informasi pasien.
2. Instansi P memanggil database untuk mengembalikan informasi yang diperlukan, menyediakan pengidentifikasi resepsionis untuk memungkinkan pemeriksaan keamanan.
3. Database memeriksa dengan sistem otorisasi bahwa pengguna diotorisasi untuk tindakan ini.
4. Jika diotorisasi, informasi pasien dikembalikan dan formulir di layar pengguna diisi. Jika otorisasi gagal, maka pesan kesalahan dikembalikan.
Gambar 5.7 adalah contoh kedua dari diagram urutan dari sistem yang sama yang
mengilustrasikan dua fitur tambahan. Ini adalah komunikasi langsung antara aktor dalam sistem dan penciptaan objek sebagai bagian dari urutan operasi. Dalam contoh ini, objek tipe 'Summary' dibuat untuk menyimpan data ringkasan yang akan diunggah ke PRS (sistem rekam pasien).
Anda dapat membaca diagram ini sebagai berikut:
1. Resepsionis masuk ke PRS.
2. Ada dua opsi yang tersedia. Ini memungkinkan transfer langsung informasi pasien yang diperbarui ke PRS dan transfer data kesehatan ringkasan dari MHC-PMS ke PRS.
3. Dalam setiap kasus, izin resepsionis diperiksa menggunakan sistem otorisasi.
4. Informasi pribadi dapat ditransfer langsung dari objek antarmuka pengguna ke PRS. Atau, catatan ringkasan dapat dibuat dari database dan rekaman tersebut kemudian ditransfer.
5. Setelah transfer selesai, PRS mengeluarkan pesan status dan pengguna keluar.
Kecuali jika Anda menggunakan diagram urutan untuk penghasilan kode atau dokumentasi rinci, Anda tidak harus menyertakan setiap interaksi dalam diagram ini. Jika Anda mengembangkan model sistem pada awal proses pengembangan untuk mendukung rekayasa kebutuhan dan desain tingkat tinggi, akan ada banyak interaksi yang bergantung pada keputusan implementasi.
Misalnya, dalam Gambar 5.7, keputusan tentang cara mendapatkan pengidentifikasi pengguna untuk memeriksa otorisasi adalah keputusan yang dapat ditunda. Dalam implementasi, ini mungkin melibatkan berinteraksi dengan objek Pengguna tetapi ini tidak penting pada tahap ini dan oleh karena itu tidak perlu disertakan dalam diagram urutan.
5.3 Ringkasan Model Struktural (Structural Models)
Model struktural perangkat lunak menampilkan organisasi suatu sistem dalam hal komponen- komponen yang membentuk sistem tersebut dan hubungan mereka. Model struktural dapat berupa model statis, yang menunjukkan struktur desain sistem, atau model dinamis, yang menunjukkan organisasi sistem saat sedang berjalan. Ini bukan hal yang sama—organisasi dinamis dari sistem sebagai serangkaian benang yang saling berinteraksi mungkin sangat berbeda dari model statis komponen sistem.
Anda membuat model struktural dari suatu sistem ketika Anda membahas dan merancang arsitektur sistem tersebut. Desain arsitektur adalah topik yang sangat penting dalam rekayasa perangkat lunak dan diagram komponen, paket, dan deployment UML dapat semua digunakan saat menyajikan model arsitektural. Saya membahas berbagai aspek arsitektur perangkat lunak dan pemodelan arsitektural di Bab 6, 18, dan 19. Pada bagian ini, saya fokus pada penggunaan diagram kelas untuk memodelkan struktur statis kelas objek dalam sistem perangkat lunak.
5.3.1 Ringkasan Diagram Kelas (Class Diagrams)
Diagram kelas digunakan saat mengembangkan model sistem berbasis objek untuk menunjukkan kelas-kelas dalam suatu sistem dan hubungan antara kelas-kelas tersebut. Dalam arti longgar, kelas objek dapat dianggap sebagai definisi umum dari satu jenis objek sistem. Asosiasi adalah tautan antara kelas-kelas yang menunjukkan bahwa ada hubungan antara kelas-kelas ini. Oleh karena itu, setiap kelas mungkin harus memiliki pengetahuan tentang kelas yang terkait dengannya.
Ketika Anda mengembangkan model selama tahap awal proses rekayasa perangkat lunak, objek mewakili sesuatu dalam dunia nyata, seperti pasien, resep, dokter, dll. Seiring dengan
pengembangan implementasi, biasanya Anda perlu mendefinisikan objek implementasi tambahan yang digunakan untuk menyediakan fungsionalitas sistem yang diperlukan. Di sini, saya fokus pada pemodelan objek dunia nyata sebagai bagian dari kebutuhan atau proses desain perangkat lunak awal.
Diagram kelas dalam UML dapat diungkapkan pada tingkat detail yang berbeda. Ketika Anda mengembangkan model, tahap pertama biasanya adalah melihat dunia, mengidentifikasi objek- objek penting, dan merepresentasikan ini sebagai kelas-kelas. Cara termudah menuliskan ini adalah dengan menulis nama kelas dalam sebuah kotak. Anda juga dapat mencatat keberadaan suatu asosiasi dengan hanya menggambar garis antara kelas. Sebagai contoh, Gambar 5.8 adalah diagram kelas sederhana yang menunjukkan dua kelas: Pasien dan Rekam Pasien dengan asosiasi antara keduanya.
Di Gambar 5.8, saya mengilustrasikan fitur lain dari diagram kelas—kemampuan untuk
menunjukkan berapa banyak objek yang terlibat dalam asosiasi. Dalam contoh ini, setiap ujung asosiasi dianotasi dengan angka 1, yang berarti ada hubungan 1:1 antara objek-objek kelas ini.
Artinya, setiap pasien memiliki tepat satu rekam, dan setiap rekam mempertahankan informasi tentang tepat satu pasien. Seperti yang dapat Anda lihat dari contoh-contoh berikutnya,
multiplicities lainnya mungkin terjadi. Anda dapat menentukan bahwa jumlah objek yang tepat terlibat atau, dengan menggunakan *, seperti yang ditunjukkan dalam Gambar 5.9, bahwa ada jumlah objek yang tidak terbatas yang terlibat dalam asosiasi.
Gambar 5.9 mengembangkan jenis diagram kelas ini untuk menunjukkan bahwa objek kelas Pasien juga terlibat dalam hubungan dengan sejumlah kelas lain. Dalam contoh ini, saya menunjukkan bahwa Anda dapat memberi nama asosiasi untuk memberikan pembaca indikasi
jenis hubungan yang ada. UML juga memungkinkan peran objek yang berpartisipasi dalam asosiasi untuk dijelaskan.
Pada tingkat detail ini, diagram kelas terlihat seperti model data semantik. Model data semantik digunakan dalam desain basis data. Mereka menunjukkan entitas data, atribut terkait mereka, dan hubungan antara entitas ini. Pendekatan pemodelan ini pertama kali diusulkan pada pertengahan tahun 1970-an oleh Chen (1976); beberapa varian telah dikembangkan sejak saat itu (Codd, 1979; Hammer dan McLeod, 1981; Hull dan King, 1987), semuanya dengan bentuk dasar yang sama.
UML tidak mencakup notasi khusus untuk pemodelan basis data semantik ini karena
mengasumsikan proses pengembangan berbasis objek dan memodelkan data menggunakan objek dan hubungan mereka. Namun, Anda dapat menggunakan UML untuk merepresentasikan model data semantik. Anda dapat memandang entitas dalam model data semantik sebagai kelas objek yang disederhanakan.
Ringkasan Diagram Kelas (Lanjutan)
Ketika menunjukkan asosiasi antara kelas-kelas, nyaman untuk mewakili kelas-kelas ini dengan cara yang paling sederhana. Untuk mendefinisikan mereka dengan lebih detail, Anda
menambahkan informasi tentang atribut mereka (karakteristik objek) dan operasi (hal-hal yang dapat Anda minta dari objek). Sebagai contoh, objek Pasien akan memiliki atribut Alamat dan Anda mungkin menyertakan operasi bernama UbahAlamat, yang dipanggil ketika seorang pasien mengindikasikan bahwa mereka pindah dari satu alamat ke alamat lain. Dalam UML, Anda menunjukkan atribut dan operasi dengan memperluas kotak sederhana yang mewakili suatu kelas. Ini diilustrasikan dalam Gambar 5.10, di mana:
1. Nama kelas objek berada di bagian atas.
2. Atribut kelas berada di bagian tengah. Ini harus mencakup nama atribut dan, opsional, tipe atribut.
3. Operasi (disebut metode dalam bahasa pemrograman OO seperti Java) yang terkait dengan kelas objek berada di bagian bawah kotak.
Gambar 5.10 menunjukkan atribut dan operasi yang mungkin pada kelas Konsultasi. Dalam contoh ini, saya mengasumsikan bahwa dokter mencatat catatan suara yang kemudian
ditranskripsi untuk mencatat detail konsultasi. Untuk meresepkan obat, dokter yang terlibat harus menggunakan metode Resep untuk menghasilkan resep elektronik.
5.3.2 Generalisasi
Generalisasi adalah teknik umum yang kita gunakan untuk mengelola kompleksitas. Daripada mempelajari karakteristik detail dari setiap entitas yang kita alami, kita menempatkan entitas-
entitas ini dalam kelas yang lebih umum (hewan, mobil, rumah, dll.) dan mempelajari karakteristik dari kelas-kelas ini. Hal ini memungkinkan kita menyimpulkan bahwa anggota- anggota berbeda dari kelas-kelas ini memiliki beberapa karakteristik umum (misalnya, tupai dan tikus adalah hewan pengerat). Kita dapat membuat pernyataan umum yang berlaku untuk semua anggota kelas (misalnya, semua hewan pengerat memiliki gigi untuk menggigit).
Dalam pemodelan sistem, seringkali berguna untuk memeriksa kelas-kelas dalam suatu sistem untuk melihat apakah ada ruang untuk generalisasi. Ini berarti bahwa informasi umum akan dipertahankan hanya di satu tempat. Ini adalah praktik desain yang baik karena berarti bahwa jika perubahan diusulkan, maka Anda tidak perlu melihat semua kelas dalam sistem untuk melihat apakah mereka terpengaruh oleh perubahan tersebut. Dalam bahasa berorientasi objek, seperti Java, generalisasi diimplementasikan menggunakan mekanisme warisan kelas yang dibangun ke dalam bahasa tersebut.
UML memiliki tipe asosiasi khusus untuk menunjukkan generalisasi, seperti yang diilustrasikan dalam Gambar 5.11. Generalisasi ditunjukkan sebagai ujung panah yang menunjuk ke kelas yang lebih umum. Ini menunjukkan bahwa dokter umum dan dokter rumah sakit dapat
digeneralisasikan sebagai dokter dan bahwa ada tiga jenis Dokter Rumah Sakit: mereka yang baru lulus dari sekolah kedokteran dan harus diawasi (Dokter Magang); mereka yang dapat bekerja tanpa pengawasan sebagai bagian dari tim konsultan (Dokter Terdaftar); dan konsultan, yang merupakan dokter senior dengan tanggung jawab pengambilan keputusan penuh.
Dalam generalisasi, atribut dan operasi yang terkait dengan kelas-kelas tingkat lebih tinggi juga terkait dengan kelas-kelas tingkat lebih rendah. Pada dasarnya, kelas-kelas tingkat lebih rendah adalah subclass yang mewarisi atribut dan operasi dari superclass mereka. Kelas-kelas tingkat lebih rendah ini kemudian menambahkan atribut dan operasi yang lebih spesifik. Misalnya, semua dokter memiliki nama dan nomor telepon; semua dokter rumah sakit memiliki nomor staf dan departemen tetapi dokter umum tidak memiliki atribut ini karena mereka bekerja secara independen. Namun, mereka memiliki nama dan alamat praktik. Ini diilustrasikan dalam Gambar 5.12, yang menunjukkan sebagian dari hirarki generalisasi yang telah saya perpanjang dengan atribut kelas.
5.3.3 Agregasi
Objek di dunia nyata sering terdiri dari bagian-bagian yang berbeda. Sebagai contoh, paket studi untuk suatu kursus dapat terdiri dari buku, slide PowerPoint, kuis, dan rekomendasi bacaan lanjutan. Kadang-kadang dalam model sistem, Anda perlu mengilustrasikan ini. UML
menyediakan jenis asosiasi khusus antara kelas yang disebut agregasi yang berarti bahwa satu objek (keseluruhan) terdiri dari objek lain (bagian-bagian). Untuk menunjukkan ini, kita
menggunakan bentuk berlian di sebelah kelas yang mewakili keseluruhan. Ini ditunjukkan dalam Gambar 5.13, yang menunjukkan bahwa rekam medis pasien adalah komposisi dari Pasien dan sejumlah Konsultasi yang tidak tentu.
5.4 Model Perilaku
Model perilaku adalah model dari perilaku dinamis sistem saat sedang dieksekusi. Mereka menunjukkan apa yang terjadi atau apa yang seharusnya terjadi ketika sistem merespons stimulus dari lingkungannya. Anda dapat menganggap stimulus ini terdiri dari dua jenis:
1. Data: Data tertentu datang yang harus diproses oleh sistem.
2. Event: Sebuah peristiwa tertentu terjadi yang memicu pemrosesan sistem. Event mungkin memiliki data terkait, tetapi hal ini tidak selalu terjadi.
Banyak sistem bisnis adalah sistem pemrosesan data yang didorong terutama oleh data. Mereka dikendalikan oleh data yang masuk ke sistem dengan pemrosesan event eksternal yang relatif sedikit. Pemrosesan mereka melibatkan serangkaian tindakan pada data tersebut dan penghasilan output. Sebagai contoh, sistem penagihan telepon akan menerima informasi tentang panggilan yang dibuat oleh pelanggan, menghitung biaya panggilan tersebut, dan menghasilkan tagihan yang akan dikirimkan kepada pelanggan tersebut. Sebaliknya, sistem real-time sering kali didorong oleh event dengan pemrosesan data minimal. Sebagai contoh, sistem switching telepon tetap merespons event seperti 'receiver off hook' dengan menghasilkan nada panggil, atau
menekan tombol pada handset dengan menangkap nomor telepon, dll.
5.4.1 Pemodelan Berbasis Data
Model berbasis data menunjukkan urutan tindakan yang terlibat dalam pemrosesan data masukan dan menghasilkan keluaran yang terkait. Model ini sangat berguna selama analisis persyaratan karena dapat digunakan untuk menunjukkan pemrosesan end-to-end dalam suatu sistem. Artinya, model ini menunjukkan seluruh urutan tindakan yang terjadi mulai dari pemrosesan input hingga keluaran yang sesuai, yaitu respons sistem.
Model berbasis data termasuk dalam jenis model perangkat lunak grafis pertama. Pada tahun 1970-an, metode terstruktur seperti Analisis Terstruktur oleh DeMarco (DeMarco, 1978)
memperkenalkan diagram alur data (DFD) sebagai cara untuk menggambarkan langkah-langkah pemrosesan dalam suatu sistem. Model alur data bermanfaat karena melacak dan
mendokumentasikan bagaimana data yang terkait dengan suatu proses bergerak melalui sistem membantu analis dan desainer memahami apa yang sedang terjadi. Diagram alur data sederhana dan intuitif sehingga biasanya memungkinkan untuk menjelaskan kepada calon pengguna sistem yang dapat berpartisipasi dalam validasi model tersebut.
UML tidak mendukung diagram alur data sebagaimana yang awalnya diusulkan dan digunakan untuk pemodelan pemrosesan data. Alasannya adalah bahwa DFD berfokus pada fungsi sistem dan tidak mengakui objek sistem. Namun, karena sistem berbasis data sangat umum dalam bisnis, UML 2.0 memperkenalkan diagram aktivitas, yang mirip dengan diagram alur data.
Sebagai contoh, Gambar 5.14 menunjukkan rantai pemrosesan yang terlibat dalam perangkat
lunak pompa insulin. Pada diagram ini, Anda dapat melihat langkah-langkah pemrosesan (diwakili sebagai aktivitas) dan data yang mengalir antara langkah-langkah tersebut (diwakili sebagai objek).
Cara alternatif untuk menunjukkan urutan pemrosesan dalam suatu sistem adalah dengan menggunakan diagram urutan UML. Anda telah melihat bagaimana ini dapat digunakan untuk memodelkan interaksi tetapi, jika Anda menggambarnya sehingga pesan hanya dikirim dari kiri ke kanan, maka mereka menunjukkan pemrosesan data berurutan dalam sistem. Gambar 5.15 mengilustrasikan ini, menggunakan model urutan dari pemrosesan pesanan dan pengirimannya kepada pemasok. Model urutan menyoroti objek dalam suatu sistem, sementara diagram alur data menyoroti fungsi. Diagram alur data setara untuk pemrosesan pesanan ditunjukkan di halaman web buku ini.
5.4.2 Pemodelan Berbasis Kejadian
Pemodelan berbasis kejadian menunjukkan bagaimana suatu sistem merespons kejadian
eksternal dan internal. Ini didasarkan pada asumsi bahwa sistem memiliki jumlah keadaan yang terbatas dan bahwa kejadian (stimulus) dapat menyebabkan transisi dari satu keadaan ke keadaan lainnya. Sebagai contoh, sebuah sistem yang mengendalikan katup dapat berpindah dari keadaan 'Katup terbuka' ke keadaan 'Katup tertutup' ketika menerima perintah operator (stimulus).
Pandangan ini terutama cocok untuk sistem real-time. Pemodelan berbasis kejadian
diperkenalkan dalam metode desain real-time seperti yang diusulkan oleh Ward dan Mellor (1985) serta Harel (1987, 1988).
UML mendukung pemodelan berbasis kejadian menggunakan diagram keadaan, yang didasarkan pada Statecharts (Harel, 1987, 1988). Diagram keadaan menunjukkan keadaan sistem dan kejadian yang menyebabkan transisi dari satu keadaan ke keadaan lainnya. Mereka tidak menunjukkan aliran data dalam sistem tetapi dapat mencakup informasi tambahan tentang perhitungan yang dilakukan di setiap keadaan.
Saya menggunakan contoh perangkat lunak pengendali untuk oven microwave yang sangat sederhana untuk mengilustrasikan pemodelan berbasis kejadian. Oven microwave sebenarnya
jauh lebih kompleks daripada sistem ini, tetapi sistem yang disederhanakan ini lebih mudah dipahami. Microwave sederhana ini memiliki sakelar untuk memilih daya penuh atau setengah, keypad numerik untuk memasukkan waktu memasak, tombol mulai/berhenti, dan layar
alfanumerik.
Saya mengasumsikan urutan tindakan dalam menggunakan microwave adalah sebagai berikut:
1. Pilih tingkat daya (setengah daya atau daya penuh).
2. Masukkan waktu memasak menggunakan keypad numerik.
3. Tekan Mulai dan makanan dimasak selama waktu yang diberikan.
Untuk alasan keamanan, oven tidak boleh beroperasi ketika pintu terbuka dan, setelah memasak selesai, alarm berbunyi. Oven memiliki layar alfanumerik yang sangat sederhana yang digunakan untuk menampilkan berbagai peringatan dan pesan peringatan.
Dalam diagram keadaan UML, persegi panjang dibulatkan mewakili keadaan sistem. Mereka dapat mencakup deskripsi singkat (mengikuti 'do') dari tindakan yang diambil dalam keadaan tersebut. Panah berlabel mewakili stimulus yang memaksa transisi dari satu keadaan ke keadaan lainnya. Anda dapat menunjukkan keadaan awal dan akhir menggunakan lingkaran yang diisi, seperti dalam diagram aktivitas.
Dari Gambar 5.16, Anda dapat melihat bahwa sistem dimulai dalam keadaan menunggu dan awalnya merespons baik tombol daya penuh atau daya setengah. Pengguna dapat mengubah pikiran setelah memilih salah satu tombol ini dan menekan tombol lainnya. Waktu diatur dan, jika pintu tertutup, tombol Mulai diaktifkan. Menekan tombol ini memulai operasi oven dan memasak berlangsung selama waktu yang ditentukan. Ini adalah akhir siklus memasak dan sistem kembali ke keadaan menunggu.
Notasi UML memungkinkan Anda menunjukkan aktivitas yang terjadi dalam suatu keadaan.
Dalam spesifikasi sistem yang rinci, Anda harus memberikan lebih banyak detail tentang stimuli dan keadaan sistem. Saya mengilustrasikan ini pada Gambar 5.17, yang menunjukkan deskripsi tabular dari setiap keadaan dan bagaimana stimuli yang memaksa transisi keadaan dihasilkan.
Masalah dengan pemodelan berbasis keadaan adalah bahwa jumlah keadaan yang mungkin meningkat dengan cepat. Untuk model sistem yang besar, oleh karena itu, Anda perlu menyembunyikan detail dalam model tersebut. Salah satu cara untuk melakukannya adalah dengan menggunakan gagasan tentang superstate yang mencakup sejumlah keadaan terpisah.
Superstate ini terlihat seperti satu keadaan pada model tingkat tinggi tetapi kemudian diperluas untuk menunjukkan lebih banyak detail pada diagram terpisah. Untuk mengilustrasikan konsep ini, pertimbangkan keadaan Operasi pada Gambar 5.15. Ini adalah superstate yang dapat diperluas, seperti yang diilustrasikan pada Gambar 5.18.
Keadaan Operasi mencakup beberapa sub-keadaan. Ini men
unjukkan bahwa operasi dimulai dengan pemeriksaan status dan bahwa jika ada masalah yang ditemukan, alarm akan diindikasikan dan operasi dinonaktifkan. Memasak melibatkan
menjalankan generator microwave selama waktu yang ditentukan; setelah selesai, alarm berbunyi. Jika pintu dibuka selama operasi, sistem beralih ke keadaan dinonaktifkan, seperti yang ditunjukkan pada Gambar 5.15.
5.5 Rekayasa Berbasis Model
Rekayasa berbasis model (Model-driven engineering/MDE) adalah pendekatan pengembangan perangkat lunak di mana model, bukan program, merupakan keluaran utama dari proses
pengembangan (Kent, 2002; Schmidt, 2006). Program-program yang dieksekusi pada platform perangkat keras/perangkat lunak kemudian dihasilkan secara otomatis dari model-model tersebut. Pendukung MDE berargumen bahwa ini meningkatkan tingkat abstraksi dalam rekayasa perangkat lunak sehingga insinyur tidak lagi harus memikirkan detail bahasa pemrograman atau spesifik dari platform eksekusi.
Rekayasa berbasis model memiliki akarnya dalam model-driven architecture (MDA) yang diusulkan oleh Object Management Group (OMG) pada tahun 2001 sebagai paradigma pengembangan perangkat lunak baru. Meskipun MDE dan MDA sering dianggap sebagai hal yang sama, MDE dianggap memiliki cakupan yang lebih luas daripada MDA. Seperti yang saya bahas nanti dalam bagian ini, MDA berfokus pada tahap desain dan implementasi
pengembangan perangkat lunak sementara MDE menangani semua aspek dari proses rekayasa
perangkat lunak. Oleh karena itu, topik seperti rekayasa kebutuhan berbasis model, proses perangkat lunak untuk pengembangan berbasis model, dan pengujian berbasis model merupakan bagian dari MDE, tetapi tidak, saat ini, bagian dari MDA.
Meskipun MDA telah digunakan sejak tahun 2001, rekayasa berbasis model masih pada tahap awal pengembangan dan belum jelas apakah itu akan memiliki dampak signifikan pada praktik rekayasa perangkat lunak. Argumen utama mendukung dan menentang MDE adalah:
Argumen Mendukung MDE:
- Model-based engineering memungkinkan insinyur untuk memikirkan sistem pada tingkat abstraksi tinggi, tanpa memperhatikan detail implementasinya. Hal ini mengurangi kemungkinan kesalahan, mempercepat proses desain dan implementasi, dan memungkinkan pembuatan model aplikasi yang dapat digunakan ulang dan independen platform.
- Dengan menggunakan alat yang kuat, implementasi sistem dapat dihasilkan untuk berbagai platform dari model yang sama. Oleh karena itu, untuk menyesuaikan sistem dengan teknologi platform baru, hanya perlu menulis penerjemah untuk platform tersebut. Ketika ini tersedia, semua model independen platform dapat dengan cepat diadopsi kembali di platform baru.
Argumen Menentang MDE:
- Seperti yang telah saya diskusikan sebelumnya dalam bab ini, model adalah cara yang baik untuk memfasilitasi diskusi tentang desain perangkat lunak. Namun, tidak selalu terjadi bahwa abstraksi yang didukung oleh model adalah abstraksi yang tepat untuk implementasi. Jadi, Anda mungkin membuat model desain informal tetapi kemudian melanjutkan untuk
mengimplementasikan sistem menggunakan paket yang dapat dikonfigurasi.
- Selain itu, argumen untuk independensi platform hanya valid untuk sistem besar dengan umur panjang di mana platform menjadi usang selama masa pakai sistem. Namun, untuk kelas sistem ini, kita tahu bahwa implementasi bukanlah masalah utama—rekayasa kebutuhan, keamanan dan keandalan, integrasi dengan sistem warisan, dan pengujian lebih signifikan.
Telah dilaporkan ada kisah sukses MDE yang signifikan oleh OMG di halaman web mereka (www.omg.org/mda/products_success.htm) dan pendekatan ini digunakan dalam perusahaan besar seperti IBM dan Siemens. Teknik ini telah digunakan dengan sukses dalam pengembangan sistem perangkat lunak besar dan berumur panjang seperti sistem manajemen lalu lintas udara.
Namun demikian, pada saat penulisan ini, pendekatan berbasis model belum banyak digunakan dalam rekayasa perangkat lunak. Seperti metode formal rekayasa perangkat lunak, yang saya bahas di Bab 12, saya percaya bahwa MDE adalah perkembangan penting. Namun, seperti juga dengan metode formal, belum jelas apakah biaya dan risiko dari pendekatan berbasis model melebihi manfaat yang mungkin diperoleh.
5.5.1 Arsitektur Berbasis Model
Arsitektur berbasis model (Model-driven architecture/MDA) adalah pendekatan berfokus pada model untuk desain dan implementasi perangkat lunak yang menggunakan subset model UML untuk menggambarkan suatu sistem. Pada pendekatan ini, dibuat model-model pada tingkat abstraksi yang berbeda. Dari model independen platform tinggi, secara prinsip, dapat menghasilkan program yang berfungsi tanpa campur tangan manual.
Metode MDA merekomendasikan tiga jenis model sistem abstrak yang harus diproduksi:
1. **Model Independen Komputasi (CIM):** Model ini memodelkan abstraksi domain penting yang digunakan dalam sistem. CIM terkadang disebut model domain. Beberapa CIM yang berbeda dapat dikembangkan, mencerminkan pandangan yang berbeda terhadap sistem.
2. **Model Independen Platform (PIM):** Model ini memodelkan operasi sistem tanpa referensi ke implementasinya. PIM biasanya dijelaskan menggunakan model UML yang menunjukkan struktur sistem statis dan bagaimana sistem merespons peristiwa eksternal dan internal.
3. **Model Spesifik Platform (PSM):** PSM adalah transformasi dari model independen platform dengan PSM terpisah untuk setiap platform aplikasi. Dalam prinsipnya, mungkin ada lapisan PSM, dengan setiap lapisan menambahkan beberapa detail spesifik platform.
Transformasi antara model-model ini dapat didefinisikan dan diterapkan secara otomatis oleh alat perangkat lunak. Proses ini diilustrasikan pada Gambar 5.19, yang juga menunjukkan tingkat transformasi otomatis terakhir. Transformasi diterapkan pada PSM untuk menghasilkan kode eksekusi yang berjalan pada platform perangkat lunak yang ditentukan.
Pada saat penulisan, terjemahan otomatis dari CIM ke PIM masih berada pada tahap prototipe penelitian. Kemungkinan bahwa alat terjemahan sepenuhnya otomatis akan tersedia dalam waktu dekat adalah rendah. Intervensi manusia, ditandai oleh gambar manusia di Gambar 5.19, akan diperlukan untuk masa mendatang yang dapat dilihat. CIM saling terkait dan bagian dari proses terjemahan mungkin melibatkan penghubungan konsep di berbagai CIM. Sebagai contoh, konsep
peran dalam CIM keamanan dapat dipetakan ke konsep anggota staf dalam CIM rumah sakit.
Mellor dan Balcer (2002) memberi nama 'jembatan' pada informasi yang mendukung pemetaan dari satu CIM ke CIM lainnya.
Terjemahan dari PIM ke PSM lebih matang, dan beberapa alat komersial tersedia yang menyediakan penerjemah dari PIM ke platform umum seperti Java dan J2EE. Ini bergantung pada perpustakaan aturan dan pola spesifik platform yang ekstensif untuk mengonversi PIM menjadi PSM. Mungkin ada beberapa PSM untuk setiap PIM dalam sistem. Jika sistem perangkat lunak ditujukan untuk dijalankan pada platform yang berbeda (misalnya, J2EE dan .NET), maka hanya perlu memelihara PIM. PSM untuk setiap platform dihasilkan secara otomatis. Hal ini diilustrasikan pada Gambar 5.20.
Meskipun alat dukungan MDA termasuk penerjemah spesifik platform, seringkali penerjemah ini hanya menawarkan dukungan parsial untuk terjemahan dari PIM ke PSM. Dalam sebagian besar kasus, lingkungan eksekusi untuk suatu sistem lebih dari platform eksekusi standar
(misalnya, J2EE, .NET, dll.). Ini juga mencakup sistem aplikasi lain, perpustakaan aplikasi yang khusus untuk perusahaan, dan perpustakaan antarmuka pengguna. Karena ini bervariasi secara signifikan dari satu perusahaan ke perusahaan lainnya, dukungan alat standar tidak tersedia. Oleh karena itu, ketika MDA diperkenalkan, mungkin harus dibuat penerjemah khusus tujuan yang memperhitungkan karakteristik lingkungan lokal. Dalam beberapa kasus (misalnya, untuk generasi antarmuka pengguna), terjemahan otomatis PIM ke PSM mungkin tidak
mungkinTerdapat hubungan yang tidak nyaman antara metode agile dan arsitektur berbasis model.
5.5.2 UML yang Dapat Dijalankan (Executable UML)
Idea dasar di balik rekayasa berbasis model adalah bahwa transformasi sepenuhnya otomatis dari model ke kode seharusnya memungkinkan. Untuk mencapai hal ini, Anda harus dapat membuat model grafis yang semantikanya terdefinisi dengan baik. Anda juga memerlukan cara untuk menambahkan informasi ke model grafis tentang cara operasi yang didefinisikan dalam model diimplementasikan. Ini dimungkinkan dengan menggunakan subset UML 2, yang disebut UML yang Dapat Dijalankan atau xUML (Mellor dan Balcer, 2002). Saya tidak memiliki ruang di sini untuk menjelaskan detail xUML, jadi saya hanya menyajikan tinjauan singkat tentang fitur utamanya.
UML dirancang sebagai bahasa untuk mendukung dan mendokumentasikan desain perangkat lunak, bukan sebagai bahasa pemrograman. Perancang UML tidak memperhatikan detail
semantik bahasa tetapi dengan ekspresivitasnya. Mereka memperkenalkan konsep yang berguna seperti diagram use case yang membantu dalam desain tetapi terlalu informal untuk mendukung eksekusi. Untuk membuat subset UML yang dapat dijalankan, jumlah jenis model telah
dikurangi secara dramatis menjadi tiga jenis model kunci:
1. **Model Domain:** Mengidentifikasi kepentingan utama dalam sistem. Ini didefinisikan menggunakan diagram kelas UML yang mencakup objek, atribut, dan asosiasi.
2. **Model Kelas:** Mendefinisikan kelas, bersama dengan atribut dan operasinya.
3. **Model Status:** Di mana diagram status dikaitkan dengan setiap kelas dan digunakan untuk menjelaskan siklus hidup kelas.
Perilaku dinamis sistem dapat dijelaskan secara deklaratif menggunakan bahasa batasan objek (Object Constraint Language/OCL) atau dapat diungkapkan menggunakan bahasa tindakan UML. Bahasa tindakan mirip dengan bahasa pemrograman tingkat tinggi di mana Anda dapat merujuk pada objek dan atribut mereka serta menentukan tindakan yang akan dilakukan.
