Arsitektur Berbasis Komponen

Arsitektur berbasis komponen berfokus pada penguraian desain menjadi komponen fungsional atau logis individu yang mewakili antarmuka komunikasi terdefinisi dengan baik yang berisi metode, peristiwa, dan properti. Ini memberikan tingkat abstraksi yang lebih tinggi dan membagi masalah menjadi sub-masalah, masing-masing terkait dengan partisi komponen.

Tujuan utama dari arsitektur berbasis komponen adalah untuk memastikan component reusability. Sebuah komponen merangkum fungsionalitas dan perilaku elemen perangkat lunak menjadi unit biner yang dapat digunakan kembali dan dapat diterapkan sendiri. Ada banyak kerangka kerja komponen standar seperti COM / DCOM, JavaBean, EJB, CORBA, .NET, layanan web, dan layanan grid. Teknologi ini banyak digunakan dalam desain aplikasi GUI desktop lokal seperti komponen JavaBean grafis, komponen MS ActiveX, dan komponen COM yang dapat digunakan kembali hanya dengan operasi seret dan lepas.

Desain perangkat lunak berorientasi komponen memiliki banyak keunggulan dibandingkan pendekatan berorientasi objek tradisional seperti -

  • Mengurangi waktu di pasar dan biaya pengembangan dengan menggunakan kembali komponen yang ada.

  • Peningkatan keandalan dengan penggunaan kembali komponen yang ada.

Apa itu Komponen?

Komponen adalah sekumpulan fungsionalitas yang terdefinisi dengan baik yang modular, portabel, dapat diganti, dan dapat digunakan kembali yang merangkum implementasinya dan mengekspornya sebagai antarmuka tingkat yang lebih tinggi.

Komponen adalah objek perangkat lunak, dimaksudkan untuk berinteraksi dengan komponen lain, merangkum fungsionalitas tertentu atau serangkaian fungsi. Ini memiliki antarmuka yang jelas dan sesuai dengan perilaku yang direkomendasikan umum untuk semua komponen dalam arsitektur.

Komponen perangkat lunak dapat didefinisikan sebagai unit komposisi dengan antarmuka yang ditentukan secara kontrak dan hanya ketergantungan konteks eksplisit. Artinya, komponen perangkat lunak dapat diterapkan secara independen dan diatur oleh pihak ketiga.

Tampilan sebuah Komponen

Sebuah komponen dapat memiliki tiga tampilan berbeda - tampilan berorientasi objek, tampilan konvensional, dan tampilan terkait proses.

Object-oriented view

Sebuah komponen dipandang sebagai satu set dari satu atau lebih kelas yang bekerja sama. Setiap kelas domain masalah (analisis) dan kelas infrastruktur (desain) dijelaskan untuk mengidentifikasi semua atribut dan operasi yang berlaku untuk implementasinya. Ini juga melibatkan pendefinisian antarmuka yang memungkinkan kelas untuk berkomunikasi dan bekerja sama.

Conventional view

Ini dipandang sebagai elemen fungsional atau modul program yang mengintegrasikan logika pemrosesan, struktur data internal yang diperlukan untuk mengimplementasikan logika pemrosesan dan antarmuka yang memungkinkan komponen dipanggil dan data diteruskan ke sana.

Process-related view

Dalam tampilan ini, alih-alih membuat setiap komponen dari awal, sistem membangun dari komponen yang ada yang dikelola dalam pustaka. Saat arsitektur perangkat lunak dirumuskan, komponen dipilih dari perpustakaan dan digunakan untuk mengisi arsitektur.

  • Komponen antarmuka pengguna (UI) mencakup kisi, tombol yang disebut kontrol, dan komponen utilitas memperlihatkan subset fungsi tertentu yang digunakan dalam komponen lain.

  • Jenis komponen umum lainnya adalah yang intensif sumber daya, tidak sering diakses, dan harus diaktifkan menggunakan pendekatan just-in-time (JIT).

  • Banyak komponen tidak terlihat yang didistribusikan dalam aplikasi bisnis perusahaan dan aplikasi web internet seperti Enterprise JavaBean (EJB), komponen .NET, dan komponen CORBA.

Karakteristik Komponen

  • Reusability- Komponen biasanya dirancang untuk digunakan kembali dalam situasi yang berbeda dalam aplikasi yang berbeda. Namun, beberapa komponen mungkin dirancang untuk tugas tertentu.

  • Replaceable - Komponen dapat diganti secara bebas dengan komponen serupa lainnya.

  • Not context specific - Komponen dirancang untuk beroperasi di lingkungan dan konteks yang berbeda.

  • Extensible - Sebuah komponen dapat diperpanjang dari komponen yang ada untuk memberikan perilaku baru.

  • Encapsulated - Komponen AA menggambarkan antarmuka, yang memungkinkan pemanggil untuk menggunakan fungsinya, dan tidak mengungkapkan detail proses internal atau variabel atau status internal apa pun.

  • Independent - Komponen dirancang untuk memiliki ketergantungan minimal pada komponen lain.

Prinsip Desain Berbasis Komponen

Sebuah desain tingkat komponen dapat direpresentasikan dengan menggunakan beberapa representasi perantara (misalnya grafis, tabel, atau berbasis teks) yang dapat diterjemahkan ke dalam kode sumber. Desain struktur data, antarmuka, dan algoritme harus sesuai dengan pedoman yang mapan untuk membantu kami menghindari kesalahan.

  • Sistem perangkat lunak diuraikan menjadi unit komponen yang dapat digunakan kembali, kohesif, dan dikemas.

  • Setiap komponen memiliki antarmuka sendiri yang menentukan port yang diperlukan dan port yang disediakan; setiap komponen menyembunyikan implementasinya yang terperinci.

  • Sebuah komponen harus diperpanjang tanpa perlu membuat kode internal atau modifikasi desain pada bagian komponen yang ada.

  • Bergantung pada abstraksi komponen tidak tergantung pada komponen konkret lainnya, yang menambah kesulitan dalam pengeluaran.

  • Konektor menghubungkan komponen, menentukan dan mengatur interaksi antar komponen. Jenis interaksi ditentukan oleh antarmuka komponen.

  • Interaksi komponen dapat berupa pemanggilan metode, pemanggilan asinkron, penyiaran, interaksi berbasis pesan, komunikasi aliran data, dan interaksi khusus protokol lainnya.

  • Untuk kelas server, antarmuka khusus harus dibuat untuk melayani kategori utama klien. Hanya operasi yang relevan dengan kategori klien tertentu yang harus ditentukan di antarmuka.

  • Sebuah komponen dapat diperluas ke komponen lain dan masih menawarkan titik ekstensi sendiri. Ini adalah konsep arsitektur berbasis plug-in. Ini memungkinkan sebuah plugin menawarkan API plugin lain.

Panduan Desain Tingkat Komponen

Membuat konvensi penamaan untuk komponen yang ditentukan sebagai bagian dari model arsitektur dan kemudian menyempurnakan atau menguraikan sebagai bagian dari model tingkat komponen.

  • Mendapatkan nama komponen arsitektur dari domain masalah dan memastikan bahwa mereka memiliki arti bagi semua pemangku kepentingan yang melihat model arsitektur.

  • Mengekstrak entitas proses bisnis yang dapat ada secara independen tanpa ketergantungan terkait pada entitas lain.

  • Mengenali dan menemukan entitas independen ini sebagai komponen baru.

  • Menggunakan nama komponen infrastruktur yang mencerminkan arti spesifik implementasinya.

  • Memodelkan dependensi apa pun dari kiri ke kanan dan warisan dari atas (kelas dasar) ke bawah (kelas turunan).

  • Buat model dependensi komponen apa pun sebagai antarmuka daripada merepresentasikannya sebagai dependensi komponen-ke-komponen langsung.

Melakukan Desain Tingkat Komponen

Mengenali semua kelas desain yang sesuai dengan domain masalah seperti yang didefinisikan dalam model analisis dan model arsitektur.

  • Mengenali semua kelas desain yang sesuai dengan domain infrastruktur.

  • Menjelaskan semua kelas desain yang tidak diperoleh sebagai komponen yang dapat digunakan kembali, dan menentukan detail pesan.

  • Mengidentifikasi antarmuka yang sesuai untuk setiap komponen dan menguraikan atribut serta menentukan tipe data dan struktur data yang diperlukan untuk mengimplementasikannya.

  • Menjelaskan aliran pemrosesan dalam setiap operasi secara rinci dengan menggunakan kode pseudo atau diagram aktivitas UML.

  • Menjelaskan sumber data yang persisten (database dan file) dan mengidentifikasi kelas yang diperlukan untuk mengelolanya.

  • Kembangkan dan uraikan representasi perilaku untuk kelas atau komponen. Ini dapat dilakukan dengan menguraikan diagram status UML yang dibuat untuk model analisis dan dengan memeriksa semua kasus penggunaan yang relevan dengan kelas desain.

  • Menguraikan diagram penerapan untuk memberikan detail implementasi tambahan.

  • Mendemonstrasikan lokasi paket kunci atau kelas komponen dalam sistem dengan menggunakan instance kelas dan menentukan perangkat keras dan lingkungan sistem operasi tertentu.

  • Keputusan akhir dapat dibuat dengan menggunakan prinsip dan pedoman desain yang telah ditetapkan. Desainer berpengalaman mempertimbangkan semua (atau sebagian besar) solusi desain alternatif sebelum menetapkan model desain akhir.

Keuntungan

  • Ease of deployment - Saat versi baru yang kompatibel tersedia, lebih mudah untuk mengganti versi yang sudah ada tanpa berdampak pada komponen lain atau sistem secara keseluruhan.

  • Reduced cost - Penggunaan komponen pihak ketiga memungkinkan Anda untuk menyebarkan biaya pengembangan dan pemeliharaan.

  • Ease of development - Komponen mengimplementasikan antarmuka terkenal untuk menyediakan fungsionalitas yang ditentukan, memungkinkan pengembangan tanpa memengaruhi bagian lain dari sistem.

  • Reusable - Penggunaan komponen yang dapat digunakan kembali berarti bahwa mereka dapat digunakan untuk menyebarkan biaya pengembangan dan pemeliharaan ke beberapa aplikasi atau sistem.

  • Modification of technical complexity - Komponen memodifikasi kompleksitas melalui penggunaan wadah komponen dan layanannya.

  • Reliability - Keandalan sistem secara keseluruhan meningkat karena keandalan masing-masing komponen meningkatkan keandalan seluruh sistem melalui penggunaan kembali.

  • System maintenance and evolution - Mudah untuk mengubah dan memperbarui implementasi tanpa mempengaruhi sistem lainnya.

  • Independent- Independensi dan konektivitas komponen yang fleksibel. Pengembangan independen komponen oleh kelompok yang berbeda secara paralel. Produktivitas untuk pengembangan perangkat lunak dan pengembangan perangkat lunak di masa depan.