Mardiyyah Hasnawi ▪ Desain tingkat komponen terjadi setelah iterasi arsitektur yang pertama desain telah ▪ ▪ ▪ ▪ ▪ ▪ selesai. Pada tahap ini, data dan program secara keseluruhan struktur perangkat lunak telah ditetapkan. Tujuannya adalah untuk menerjemahkan model desain menjadi perangkat lunak operasional. Tetapi tingkat abstraksi file model desain yang ada relatif tinggi, dan tingkat abstraksi operasional. Satu set lengkap perangkat lunak komponen didefinisikan selama desain arsitektur. Tapi internal struktur dan pemrosesan data detail setiap komponen tidak terwakili pada tingkat abstraksi yang dekat dengan kode. Desain tingkat komponen mendefinisikan struktur data, algoritma, karakteristik antarmuka, dan mekanisme komunikasi dialokasikan untuk masing-masing komponen perangkat lunak. ▪ Representasi desain data, arsitektur, dan antarmuka membentuk fondasi untuk desain tingkat komponen. ▪ Definisi kelas atau pemrosesan narasi untuk masing-masing komponen diterjemahkan ke dalam desain rinci yang menggunakan diagram atau berbasis teks formulir yang menentukan struktur data internal, local detail antarmuka, dan logika pemrosesan. ▪ Rancangan notasi meliputi diagram UML dan pelengkap formulir. ▪ Desain prosedural ditentukan menggunakan sekumpulan konstruksi pemrograman terstruktur. ▪ Desain untuk masing-masing komponen, direpresentasikan dalam grafik, tabel, atau notasi berbasis teks, adalah pekerjaan utama produk yang diproduksi selama level komponen desain. ▪ Komponen adalah blok bangunan modular untuk perangkat lunak komputer. ▪ Lebih formal, file Spesifikasi UML OMG [OMG03a] mendefinisikan komponen sebagai “. . . bagian modular, dapat diterapkan, dan dapat diganti dari sistem yang merangkum implementasi dan memperlihatkan sekumpulan antarmuka. " ▪ komponen mengisi arsitektur perangkat lunak dan, sebagai konsekuensinya, berperan dalam mencapai tujuan dan persyaratan sistem yang akan dibangun. Karena komponen berada dalam arsitektur perangkat lunak, mereka harus berkomunikasi dan berkolaborasi dengan komponen lain dan dengan entitas (misalnya, sistem, perangkat, orang lain) yang ada di luar batas perangkat lunak. ▪ Arti sebenarnya dari istilah komponen akan berbeda tergantung dari sudut pandangnya insinyur perangkat lunak yang menggunakannya. ▪ Tiga hal penting pandangan tentang apa itu komponen dan bagaimana itu digunakan sebagai hasil pemodelan desain. ▪ Dalam konteks rekayasa perangkat lunak berorientasi objek, sebuah komponen berisi satu set kelas berkolaborasi. ▪ Setiap kelas dalam sebuah komponen telah dijabarkan sepenuhnya untuk memasukkan semua atribut dan operasi yang relevan dengan implementasinya. ▪ Sebagai bagian dari elaborasi desain, semua antarmuka yang memungkinkan kelas untuk berkomunikasi dan berkolaborasi dengan kelas desain lain juga harus ditentukan. ▪ Untuk menyelesaikan hal ini,yaitu model persyaratan dan kelas analisis yang rumit (untuk komponen yang terkait dengan domain masalah) dan kelas infrastruktur (untuk komponen yang menyediakan layanan dukungan untuk domain masalah). ▪ Dalam konteks rekayasa perangkat lunak tradisional, komponen adalah elemen fungsional dari program yang menggabungkan logika pemrosesan, struktur data internal yang diperlukan untuk mengimplementasikan logika pemrosesan, dan antarmuka yang memungkinkan komponen untuk dipanggil dan data untuk diteruskan ke sana. ▪ Komponen tradisional, juga disebut modul, berada dalam arsitektur perangkat lunak dan melayani salah satu dari tiga peran penting: (1) Komponen kontrol yang mengoordinasikan pemanggilan semua komponen domain masalah lainnya, (2) Komponen domain masalah yang mengimplementasikan fungsi lengkap atau parsial yang dibutuhkan oleh pelanggan, atau (3) Komponen infrastruktur bertanggung jawab atas fungsi yang mendukung pemrosesan yang diperlukan dalam domain masalah. ▪ Seperti komponen berorientasi objek, komponen perangkat lunak tradisional diturunkan dari model analisis. ▪ Dalam hal ini, bagaimanapun, elemen berorientasi aliran data dari model analisis berfungsi sebagai dasar untuk derivasi. ▪ Setiap transformasi diwakili pada tingkat terendah dari diagram aliran data dipetakan menjadi sebuah hierarki modul. ▪ Komponen kontrol (modul) berada di dekat bagian atas hierarki (arsitektur program), dan komponen domain masalah cenderung berada bagian bawah hierarki. ▪ Untuk mencapai modularitas yang efektif, konsep desain seperti independensi fungsional diterapkan saat komponen diuraikan. ▪ View berorientasi objek dan tradisional dari desain tingkat komponen mengasumsikan bahwa komponen sedang dirancang scratch. ▪ Artinya, harus membuat komponen baru berdasarkan spesifikasinya berasal dari model persyaratan. ▪ Katalog desain yang terbukti atau komponen tingkat kode tersedia sebagai hasil pekerjaan desain. ▪ Saat arsitektur perangkat lunak dikembangkan, dapat memilih komponen atau pola desain dari katalog dan menggunakannya untuk mengisi arsitektur. ▪ Karena komponen ini telah dibuat dengan mempertimbangkan kegunaan kembali, lengkap deskripsi antarmuka mereka, fungsi yang mereka lakukan, dan komunikasi dan kolaborasi yang mereka butuhkan tersedia ▪ Suatu rekayasa perangkat lunak berorientasi objek pendekatan dipilih, desain tingkat komponen berfokus pada elaborasi masalah kelas khusus domain dan definisi serta penyempurnaan kelas infrastruktur terkandung dalam model kebutuhan. ▪ Deskripsi rinci dari atribut, operasi, dan antarmuka yang digunakan oleh kelas- kelas ini adalah detail desain yang diperlukan sebagai pendahulu aktivitas konstruksi. ▪ Prinsip Terbuka-Tertutup/ Open-Closed (OCP). ▪ Prinsip Substitusi Liskov / Liskov Substitution (LSP). ▪ Prinsip Pembalikan Ketergantungan / Dependency Inversion (DIP). ▪ Prinsip Segregasi Antarmuka / Interface Segregation (ISP). ▪ Prinsip Kesetaraan Penggunaan Kembali Rilis/ Release Reuse Equivalency (REP). ▪ Prinsip Penutupan Umum / Common Closure(CCP). ▪ Prinsip Penggunaan Kembali Umum / Common Reuse (CRP). ▪ Sebuah modul [komponen] harus terbuka untuk ekstensi tetapi ditutup untuk modifikasi ini mewakili salah satu karakteristik terpenting dari sebuah barang desain tingkat komponen. ▪ Sederhananya, harus menentukan komponen dengan cara yang memungkinkannya untuk diperpanjang (dalam domain fungsional yang dialamatkannya) tanpa kebutuhan untuk membuat modifikasi internal (kode atau tingkat logika) pada komponen diri. ▪ Untuk melakukannya, buat abstraksi yang berfungsi sebagai buffer antara file fungsionalitas yang kemungkinan akan diperluas dan kelas desain itu sendiri. ▪ Misalnya, asumsikan bahwa fungsi keamanan SafeHome menggunakan Detektor kelas yang harus memeriksa status setiap jenis sensor keamanan. Seiring waktu berlalu, jumlah dan jenis sensor keamanan akan bertambah. ▪ Subclass harus bisa diganti kelas dasar ▪ Prinsip desain ini, awalnya dikemukakan oleh Barbara Liskov menyarankan bahwa komponen yang menggunakan kelas dasar harus terus berfungsi benar jika kelas yang diturunkan dari kelas dasar diteruskan ke komponen sebagai gantinya. ▪ LSP menuntut bahwa setiap kelas yang diturunkan dari kelas dasar harus menghormati kontrak tersirat di antara keduanya kelas dasar dan komponen yang menggunakannya. ▪ Dalam konteks pembahasan ini, "kontrak" adalah prasyarat yang harus benar sebelum komponen menggunakan kelas dasar dan kondisi akhir yang harus benar setelah komponen menggunakan kelas dasar. ▪ Kapan membuat kelas turunan, pastikan kelas tersebut sesuai dengan kondisi sebelum dan sesudah. ▪ Tergantung pada abstraksi. ▪ Jangan tergantung pada beton/ concretions ▪ Abstraksi adalah tempat di mana desain dapat diperpanjang tanpa kerumitan yang besar. ▪ Terlebih Sebuah komponen bergantung pada komponen konkret lainnya (bukan pada abstraksi seperti antarmuka), semakin sulit untuk diperluas. ▪ Banyak antarmuka khusus klien lebih baik daripada satu antarmuka tujuan ▪ Beberapa komponen klien menggunakan operasi yang disediakan oleh kelas server. ▪ ISP menyarankan agar membuat antarmuka khusus untuk melayani setiap kategori utama klien. ▪ Hanya operasi yang relevan dengan kategori klien tertentu harus ditentukan di antarmuka untuk klien itu. ▪ Jika banyak klien membutuhkan hal yang sama operasi, itu harus ditentukan di setiap antarmuka khusus. ▪ Sebagai contoh, kelas FloorPlan yang digunakan untuk keamanan SafeHome dan fungsi pengawasan ▪ Granul penggunaan kembali adalah butiran rilis ▪ Ketika kelas atau komponen dirancang untuk digunakan kembali, di sana adalah kontrak implisit yang dibuat antara pengembang entitas yang dapat digunakan kembali dan orang-orang yang akan menggunakannya. ▪ Pengembang berkomitmen untuk menetapkan kontrol rilis sistem yang mendukung dan memelihara versi lama dari entitas sementara pengguna lambat meningkatkan ke versi terbaru. ▪ Daripada membahas setiap kelas satu per satu, sering disarankan untuk mengelompokkan kelas yang dapat digunakan kembali ke dalam paket yang dapat dikelola dan dikontrol sebagai versi yang lebih baru berkembang. ▪ Kelas yang berubah bersama adalah milik bersama ▪ Kelas harus dikemas secara kohesif. Yaitu, saat kelas berlangsung dikemas sebagai bagian dari suatu desain, mereka harus membahas fungsi atau perilaku yang sama domain. ▪ Ketika beberapa karakteristik dari domian itu harus berubah, kemungkinan besar hanya itu saja kelas dalam paket akan membutuhkan modifikasi. ▪ Ini mengarah pada lebih efektif mengubah kontrol dan manajemen rilis. ▪ Kelas yang tidak digunakan dikelompokkan bersama. kembali bersama seharusnya tidak akan ▪ Ketika satu atau lebih kelas dalam satu paket perubahan, nomor rilis paket berubah. ▪ Semua kelas atau paket lainnya yang mengandalkan paket yang telah diubah sekarang harus diperbarui ke yang terbaru rilis paket dan diuji untuk memastikan bahwa rilis baru beroperasi tanpa event. ▪ Jika kelas tidak dikelompokkan secara kohesif, ada kemungkinan kelas tersebut tidak memiliki hubungan ke kelas lain dalam sebuah paket yg diubah. ▪ Ini akan memicu hal yang tidak perlu integrasi dan pengujian. ▪ Hanya kelas yang digunakan kembali bersama harus dimasukkan dalam satu paket. ▪ Konvensi penamaan harus ditetapkan untuk komponen yang ditentukan sebagai bagian dari model arsitektur dan kemudian disempurnakan dan diuraikan sebagai bagian dari model tingkat komponen. ▪ Nama komponen arsitektur harus digambar dari domain masalah dan harus memiliki arti bagi semua pemangku kepentingan yang melihat model arsitektur. ▪ Misalnya, ▪ nama kelas FloorPlan berarti bagi semua orang membacanya tanpa memandang latar belakang teknis. ▪ Di sisi lain, infrastruktur komponen atau kelas tingkat komponen yang diuraikan harus diberi nama untuk mencerminkan makna khusus implementasi. ▪ Jika daftar tertaut akan dikelola sebagai bagian dari implementasi FloorPlan, operasi manageList () sudah sesuai, bahkan jika bukan teknis orang mungkin salah menafsirkannya ▪ Dapat memilih untuk menggunakan stereotip untuk membantu mengidentifikasi sifat komponen di tingkat desain rinci. ▪ Misalnya ▪ <<infrastructure>> mungkin digunakan untuk mengidentifikasi file komponen infrastruktur, ▪ <<database>> dapat digunakan untuk mengidentifikasi database itu layanan satu atau lebih kelas desain atau keseluruhan sistem; ▪ <<table>> bisa digunakan untuk mengidentifikasi tabel dalam database. ▪ Antarmuka memberikan informasi penting tentang komunikasi dan kolaborasi (serta membantu mencapai OCP). ▪ Namun representasi “tak terkekang” antarmuka cenderung memperumit diagram komponen. ▪ Ambler merekomendasikan bahwa (1) representasi lollipop dari sebuah antarmuka harus digunakan sebagai pengganti UML yang lebih formal dan pendekatan panah putus-putus, ketika diagram menjadi kompleks; (2) untuk konsistensi, antarmuka harus mengalir dari sisi kiri komponen kotak; (3) hanya antarmuka yang relevan dengan komponen yang dipertimbangkan harus ditampilkan, meskipun antarmuka lain tersedia. Rekomendasi ini adalah dimaksudkan untuk menyederhanakan sifat visual diagram komponen UML. ▪ Untuk meningkatkan keterbacaan, itu ide yang bagus untuk memodelkan ketergantungan dari kiri ke kanan dan warisan dari bawah (diturunkan kelas) ke atas (kelas dasar). ▪ Selain itu, saling ketergantungan komponen harus direpresentasikan melalui antarmuka, bukan dengan representasi komponen-ke-komponen ketergantungan. ▪ Mengikuti filosofi OCP, ini akan membantu membuat sistem lebih mudah dirawat.