Arsitektur Perangkat Lunak

ARSITEKTUR PERANGKAT LUNAK

1. Pengertian Arsitektur Perangkat Lunak

Apa yang dimaksud dengan "Arsitektur Perangkat Lunak"? Definisinya menurut para ahli, antara lain:  

1. IEEE: "Arsitektur adalah organisasi mendasar pada sebuah system yang mewujudkan komponen-komponen, hubungan antara satu dengan yang lainnya, dan dengan lingkungan, dan prinsip yang mengarahkan rancangan dan evolusi."

2. Grady Booch, Philip Krutchen, Kurt Bittner, dan Rich Reitman: "Arsitektur perangkat lunak mencakup serangkaian keputusan-keputusan penting tentang organisasi sistem perangkat lunak, yaitu: pemilihan elemen struktural dan interface yang menyusun sistem; perilaku seperti spesifikasi dalam kolaborasi antar unsur-unsur; komposisi struktural dan perilaku elemen-elemen dalam membentuk subsistem yang lebih besar; dan gaya arsitektur yang memandu organisasi." 
 - Booch, P. Krutchen, K. Bittner and R. Reitman. The Rational Unified Process - An Introduction. 1999. Definition derived from Mary Shaw's definition presented in 1995 at the First International Workshop on Architectures for Software System.

3. Len Bass: "Arsitektur perangkat lunak dari sebuah program atau sistem komputasi adalah struktur atau struktur dari sistem yang terdiri dari unsur-unsur perangkat lunak, sifat-sifat yang terlihat secara eksternal dari elemen-elemen, dan hubungan diantara mereka." 
 - Bass, Len; Clements, Paul; & Kazman, Rick. Software Architecture in Practice, Second Edition. Boston, MA: Addison - Wesley, 2003.

Pengertian lainnya adalah arsitektur merupakan struktur komponen sebuah program atau sistem, hubungan timbal balik antar komponen tersebut, dan merupakan prinsip serta pedoman dalam membuat desain dan evolusinya dari waktu ke waktu.

Arsitektur juga merupakan komponen dan penghubung, yang memiliki arti sebagai sebuah mekanisme untuk mengirimkan kontrol dan data dalam sebuah sistem.

Dalam Arsitektur Perangkat Lunak, terdapat sebuah konsep layer yang merupakan suatu konsep utama untuk membangun sebuah perangkat lunak.

2. Layer

Sesuai dengan namanya, layer merupakan lapisan dalam arsitektur perangkat lunak. Layer terdiri dari dari 4 lapisan, yaitu: Quality Focus, Process, Methods, dan Tools.

2.1. Quality Focus

Dalam arsitektur perangkat lunak, hal yang diamati oleh programmer adalah kualitas perangkat lunak yang akan dibangunnya. Seorang programmer harus memerhatikan tujuan dibangunnya perangkat lunak, kepada siapa sasarannya, dan kualitas yang distandarkan bagaimana. 

2.2. Process

Setelah diketahui fokus kualitasnya, programmer harus mengetahui proses suatu program agar program tersebut dapat berjalan dan sesuai dengan fokus kualitas dari perangkat lunak yang diharapkan.

2.3. Methods

Metode adalah suatu langkah dalam pembuatan perangkat lunak. Metode harus disesuaikan tergantung dari perangkat lunak yang akan dibangun sehingga programmer dapat mudah mencapai tujuan dari perangkat lunak yang diharapkan.

2.4. Tools

Tools merupakan suatu alat bantu yang digunakan oleh programmer dalam membangun perangkat lunak. Contoh tools: Blender (animasi).

3. Ragam Arsitektur Perangkat Lunak 

Ragam Arsitektur perangkat lunak terdiri dari :  Data Centered Architectures, Data Flow Architectures, Call and Return Architectures, Layered architectures,  Event-based, Implicit Invocation, Repositories, Table Driven Interpreters, Heterogeneous Architectures.

3.1. Data Centered Architectures

Arsitektur ini memiliki tujuan untuk mencapai kualitas integrability data. Istilah ini mengacu ke sistem di mana akses dan update dari menyimpan data diakses secara luas adalah tujuan utama mereka. Pada dasarnya, itu tidak lebih dari menyimpan data terpusat yang berkomunikasi dengan sejumlah klien Penting untuk gaya ini adalah tiga protokol: komunikasi, definisi data dan protokol data manipulasi. Sarana komunikasi membedakan dua subtipe: repositori dan papan tulis

- Repository: klien mengirimkan permintaan ke sistem untuk melakukan tindakan yang diperlukan (misalnya memasukkan data)

-  Papan tulis: sistem mengirimkan pemberitahuan dan data untuk pelanggan ketika data perubahan bunga, dan dengan demikian aktif.

   

Salah satu contoh yang paling terkenal dari Data Centered Architectures, adalah arsitektur database. Ada skema database yang umum (meta struktur-yaitu dari repositori) - dibuat dengan data protokol definisi Misalnya dalam RDBMS satu set tabel yang berkaitan dengan bidang, tipe data, kunci, dll.

Klien menggunakan protokol data manipulasi untuk bekerja dengan data. Misalnya SQL untuk memasukkan, memilih, deleteing data, dll. Tergantung di mana klien terletak protokol komunikasi mungkin :

§ Sebuah komunikasi batin-proces

§ Komunikasi antar komponen di mesin yang sama

§ Komunikasi melalui jaringan, misalnya LAN, Internet, dll

Analisis Data Centered Architectures :

1. Memastikan integritas data

2. Handal, aman, dijamin testability

3. Klien independen pada sistem: kinerja dan kegunaan di sisi klien baik

4. Masalah dengan skalabilitas

5. Solusi: repositori bersama, replikasi tapi ini meningkatkan kompleksitas

  3.2. Data Flow Architectures

Arsitektur ini memiliki tujuan untuk mencapai kualitas pemakaian ulang dan modifiability. Gaya Data Flow Architectures ditandai dengan melihat sistem sebagai rangkaian transformasi pada potongan-potongan berturut-turut input data. Data masuk ke sistem dan kemudian mengalir melalui satu komponen pada suatu waktu sampai akhirnya, data ditugaskan untuk beberapa tujuan akhir (output atau menyimpan data).

Data Flow Architectures dapat diklasifikasikan ke dalam Batch Sekuensial Architectures dan Pipes and Filters. Dalam gaya batch berurutan setiap langkah berjalan untuk penyelesaian sebelum langkah berikutnya mulai. Misalnya pipa baris perintah UNIX. Dalam pipa dan filter akan menjalankan langkah-langkah gaya merangkap bagian pengolahan data secara bertahap.

Pipes and Filters, prosesnya, dalam pipa dan komponen filter gaya masing-masing memiliki satu set input dan satu set output. Komponen membaca aliran data pada input dan menghasilkan aliran data outputnya, memberikan contoh lengkap hasilnya dalam urutan standar. Hal ini biasanya dicapai dengan menerapkan local transformasi untuk memasukkan aliran dan komputasi bertahap sehingga output input dimulai sebelum dikonsumsi. Oleh karena itu komponen yang disebut "filter". Konektor gaya ini berfungsi sebagai medium untuk sungai, transmisi output satu filter untuk masukan lain. Oleh karena itu konektor ini disebut "pipa".

Di antara invariants penting dari gaya, filter harus independen entitas: khususnya, mereka tidak harus berbagi negara dengan filter lainnya. Lain invarian penting adalah bahwa filter tidak mengetahui identitas mereka hulu dan hilir filter. Spesifikasi mereka mungkin membatasi apa yang muncul pada masukan pipa atau membuat jaminan tentang apa yang muncul pada pipa output, tetapi mereka tidak dapat mengidentifikasi komponen-komponen di ujung pipa tersebut. Selanjutnya, kebenaran output dan menyaring jaringan pipa tidak boleh bergantung pada urutan filter yang melakukan pemrosesan tambahan mereka-meskipun penjadwalan wajar dapat diasumsikan.

Spesialisasi umum dari gaya ini meliputi saluran pipa, yang membatasi topologi untuk urutan linear filter, pipa berikat yang membatasi jumlah data yang dapat berada pada pipa, dan diketik pipa, yang mengharuskan data yang melewati antara dua filter memiliki tipe yang didefinisikan dengan baik.

  3.3. Call and Return Architectures

Call and Return Arhitectures memiliki tujuan untuk mencapai kualitas modifiability dan solvabilitas. Call and Return Architectures telah menjadi gaya arsitektur dominan dalam sistem perangkat lunak besar selama 30 tahun terakhir. Namun, dalam gaya sejumlah substyles, yang masing-masing memiliki fitur yang menarik, telah muncul.

Arsitektur Main-Program-dan subrutin adalah paradigm pemrograman klasik. Tujuannya adalah untuk menguraikan program menjadi potongan kecil untuk membantu mencapai modifiability.

Suatu program merupakan dekomposisi hierarkis. Ada benang tunggal biasanya control dan masing-masing komponen dalam hirarki mendapatkan control ini (opsional bersama dengan beberapa data) dari orang tua dan melewati itu bersama anak-anaknya.

 

Sistem prosedur panggilan Remote adalah sistem utama-program-dan-sub rutin yang diuraikan menjadi bagian-bagian yang hidup di komputer yang terhubung melalui jaringan. Tujuannya adalah untuk meningkatkan kinerja dengan mendistribusikan perhitungan dan mengambil keuntungan dari beberapa prosesor. Dalam sistem pemanggilan prosedur remote, penugasan sebenarnya bagian untuk prosesor ditangguhkan sampai runtime, yang berarti bahwa tugas mudah diubah untuk mengakomodasi tuning kinerja. Pada kenyataannya, kecuali bahwa panggilan subroutine memerlukan waktu lebih lama untuk menyelesaikan jika pemanggilan fungsi pada mesin remote, panggilan prosedur remote tidak dapat dibedakan dari program utama standar dan sistem subrutin.

Berorientasi objek atau abstrak sistem data tipe adalah versi modern dari arsitektur panggilan-dan-kembali. Paradigma berorientasi objek, seperti paradigma tipe data abstrak dari yang berevolusi, menekankan bundling data dan metode untuk memanipulasi dan akses data (Public Interface).

Abstraksi objek Komponen bentuk yang menyediakan layanan kotak hitam dan komponen lainnya yang meminta layanan tersebut. Tujuannya adalah untuk mencapai kualitas modifiability.

Rangkaian ini adalah enkapsulasi suatu yang menyembunyikan rahasia internal dari lingkungannya. Akses ke objek hanya diperbolehkan melalui operasi yang disediakan, biasanya dikenal sebagai metode, yang dibatasi bentuk prosedur panggilan. enkapsulasi ini mempromosikan penggunaan kembali dan modifiability, terutama karena mempromosikan pemisahan keprihatinan:

Ø  Pengguna jasa tidak perlu tahu, dan tidak harus tahu, apa-apa tentang bagaimana layanan yang diimplementasikan.

                Ø  Sistem berlapis adalah orang-orang di mana komponen ditugaskan ke lapisan untuk 
                     mengontrol interaksi intercomponent. Dalam versi murni arsitektur ini, setiap tingkat     
                    hanya berkomunikasi dengan tetangga terdekat

Tujuannya adalah untuk mencapai kualitas modifiability dan, biasanya, mudah dibawa. Lapisan terendah menyediakan beberapa fungsi inti, seperti perangkat keras, atau kernel sistem operasi. Setiap lapisan berturut-turut dibangun di atas pendahulunya, menyembunyikan lapisan bawah dan menyediakan beberapa layanan yang lapisan atas memanfaatkan.

3.4. Layered architectures

Sebuah sistem berlapis diatur secara hirarki, setiap lapisan menyediakan layanan kepada lapisan di atasnya dan melayani sebagai klien ke lapisan bawah. Dalam beberapa berlapis Sistem lapisan dalam yang tersembunyi dari semua kecuali lapisan luar yang berdekatan, kecuali untuk fungsi-fungsi tertentu dipilih dengan cermat untuk ekspor. Jadi dalam sistem ini yang menerapkan komponen-komponen mesin virtual pada beberapa lapisan dalam hirarki. (Dalam sistem berlapis lapisan lainnya mungkin hanya sebagian buram.) Konektor didefinisikan oleh protokol yang menentukan bagaimana lapisan akan berinteraksi. Kendala Topological termasuk membatasi interaksi ke lapisan yang berdekatan.

 

Dikenal secara luas contoh sebagian besar semacam ini gaya arsitektur protokol komunikasi berlapis. Di daerah ini masing-masing lapisan aplikasi menyediakan substrat untuk komunikasi di beberapa level abstraksi. Rendah menentukan tingkat yang lebih rendah tingkat interaksi, terendah biasanya didefinisikan oleh hardware koneksi. Lain appli-kation daerah untuk gaya ini meliputi database sistem dan sistem operasi.

Sistem Layered memiliki beberapa sifat yang diinginkan. Pertama, mereka mendukung desain yang didasarkan pada peningkatan tingkat abstraksi. Hal ini memungkinkan pelaksana untuk partisi masalah yang kompleks menjadi urutan langkah-langkah tambahan. Kedua, mereka mendukung peningkatan. Seperti pipa, karena setiap lapisan berinteraksi dengan di sebagian lapisan bawah dan atas, perubahan fungsi satu lapisan berdampak pada paling banyak dua lapisan lainnya. Ketiga, mereka mendukung kembali. Seperti jenis data abstrak, implementasi yang berbeda dari lapisan yang sama bisa digunakan secara bergantian, asalkan mereka mendukung interface yang sama untuk lapisan yang berdekatan mereka. Hal ini menyebabkan untuk kemungkinan mendefinisikan interface standar lapisan yang berbeda pelaksana dapat membangun. (Sebuah contoh yang baik adalah ISO OSI model dan beberapa X Window System protokol.)

Tetapi sistem berlapis juga memiliki kekurangan. Tidak semua sistem yang mudah terstruktur secara berlapis. Dan bahkan jika sistem secara logis dapat berupa lapisan, pertimbangan kinerja mungkin memerlukan kopling dekat antara logis tingkat tinggi fungsi dan mereka yang lebih rendah tingkat implementasi. Selain itu bisa sangat sulit untuk menemukan tingkat yang tepat abstraksi. Hal ini terutama benar untuk model berlapis standar. Salah satu catatan bahwa komunikasi masyarakat telah memiliki beberapa protokol yang ada pemetaan kesulitan ke ISO kerangka: banyak jembatan protokol tersebut beberapa lapisan.

Di satu sisi ini mirip dengan manfaat implementasi ditemukan bersembunyi dalam tipe data abstrak. Namun, berikut ada beberapa tingkat abstraksi dan implementasi. Mereka juga mirip dengan pipa, dalam komponen paling banyak berkomunikasi dengan satu komponen lainnya di kedua sisi. Tapi bukannya pipa sederhana membaca / menulis protokol pipa, sistem berlapis-lapis dapat memberikan banyak kaya bentuk interaksi. Hal ini membuat sulit untuk mendefinisikan sistem lapisan independen (sebagaimana dengan filter)-sejak lapisan harus mendukung spesifik protokol di atas dan bawah batas-batasnya. Tetapi juga memungkinkan lebih dekat interaksi antara lapisan, dan izin transmisi dua arah informasi.

3.5. Event-based, Implicit Invocation

Secara tradisional, dalam sebuah sistem di mana komponen antarmuka memberikan koleksi prosedur dan fungsi, komponen yang berinteraksi satu sama lain dengan eksplisit memanggil mereka rutinitas. Namun, baru-baru ini telah ada cukup bunga dalam teknik integrasi alternatif, berbagai dimaksud sebagai doa implisit, integrasi reaktif, dan siaran selektif. Ini gaya memiliki akar sejarah dalam sistem berdasarkan pelaku daemon, dan jaringan packet-switched.

Ide di balik pemanggilan implisit adalah bahwa alih-alih memanggil sebuah prosedur secara langsung, komponen dapat mengumumkan (atau siaran) satu atau lebih acara. Komponen lain dalam sistem dapat mendaftarkan suatu kepentingan dalam suatu acara oleh mengasosiasikan prosedur dengan acara tersebut. Ketika acara ini mengumumkan sistem itu sendiri memanggil semua prosedur yang telah terdaftar untuk acara. Jadi pengumuman acara''`` implisit menyebabkan doa prosedur dalam modul lain.

Sebagai contoh, dalam sistem Bidang, alat-alat seperti editor dan variabel monitor mendaftar untuk's breakpoint peristiwa debugger. Ketika debugger berhenti di breakpoint, itu mengumumkan suatu peristiwa yang memungkinkan sistem untuk secara otomatis memanggil metode alat tersebut terdaftar. Metode ini mungkin sebuah gulir editor untuk garis sumber yang tepat atau menampilkan kembali nilai dipantau variabel. Dalam skema ini, debugger hanya mengumumkan suatu peristiwa, tetapi tidak tahu lain alat apa (jika ada) prihatin dengan peristiwa itu, atau apa yang mereka akan lakukan ketika peristiwa yang diumumkan.

Berbicara arsitektur, komponen dalam sebuah gaya doa implicit adalah modul yang menyediakan antarmuka kedua kumpulan prosedur (seperti tipe data abstrak) dan rangkaian peristiwa. Prosedur dapat disebut di biasa cara. Tapi di samping itu, komponen dapat mendaftarkan beberapa prosedur dengan kejadian dari sistem. Hal ini akan menyebabkan prosedur ini dapat dipanggil ketika peristiwa tersebut diumumkan pada waktu berjalan. Jadi konektor dalam implicit Sistem doa termasuk pemanggilan prosedur tradisional maupun bindings antara pengumuman acara dan panggilan prosedur.

Pada invarian utama dari gaya ini adalah bahwa penyiar peristiwa tidak tahu komponen yang akan terpengaruh oleh peristiwa-peristiwa. Dengan demikian komponen tidak bisa membuat asumsi tentang urutan proses, atau bahkan tentang apa pengolahan, akan terjadi sebagai akibat peristiwa mereka. Untuk alasan ini yang paling implisit pemanggilan, Sistem ini juga mencakup permintaan eksplisit (yakni, pemanggilan prosedur normal) sebagai pelengkap bentuk interaksi.

Contoh sistem dengan mekanisme pemanggilan implisit abound. Mereka digunakan dalam lingkungan pemrograman untuk mengintegrasikan alat-alat, dalam database sistem manajemen untuk memastikan kendala konsistensi, di pengguna interface untuk memisahkan penyajian data dari aplikasi yang mengelola data, dan oleh-diarahkan editor sintaks untuk mendukung tambahan semantic memeriksa.

Salah satu manfaat penting dari doa implisit adalah bahwa ia menyediakan kuat dukungan untuk digunakan kembali. Setiap komponen dapat diperkenalkan ke dalam sistem hanya dengan mendaftar untuk peristiwa sistem itu. Manfaat kedua adalah bahwa implicit doa memudahkan sistem evolusi. Komponen mungkin akan digantikan dengan yang lain komponen tanpa mempengaruhi antarmuka komponen lain dalam sistem.

Sebaliknya, dalam sistem yang didasarkan pada pemanggilan eksplisit, apabila identitas dari yang memberikan beberapa fungsi sistem berubah, semua modul lain yang impor bahwa modul juga harus diubah.

Kelemahan utama dari doa implisit adalah bahwa komponen melepaskan kontrol atas perhitungan yang dilakukan oleh sistem. Ketika komponen mengumumkan acara, itu tidak tahu apa yang akan komponen lainnya menanggapinya. Lebih buruk lagi, bahkan jika tidak tahu apa komponen-komponen lainnya tertarik pada kegiatan yang mengumumkan, tidak bisa mengandalkan urutan di mana mereka dipanggil. Juga bisa tahu ketika mereka selesai. Masalah lain keprihatinan pertukaran data. Kadang-kadang data dapat lulus dengan acara tersebut. Tapi dalam situasi lain sistem acara harus bergantung pada repositori bersama untuk interaksi. Dalam kasus ini kinerja global dan pengelolaan sumber daya dapat menjadi isu serius. Akhirnya, penalaran tentang kebenaran dapat bermasalah, karena pengertian prosedur yang mengumumkan acara akan tergantung pada konteks binding di mana ia dipanggil. Hal ini berbeda dengan tradisional penalaran tentang panggilan prosedur, yang hanya perlu mempertimbangkan Prosedur pra-dan pasca-kondisi ketika penalaran tentang doa itu.

3.6. Repositories

Dalam gaya repositori yang berbeda ada dua macam komponen cukup: pusat struktur data yang mewakili negara saat ini, dan sebuah koleksi independen komponen yang beroperasi pada menyimpan data pusat. Interaksi antara repositori dan komponen eksternal dapat bervariasi secara signifikan antara sistem.

Pilihan disiplin kontrol mengarah ke halaman utama. Jika jenis transaksi dalam aliran input transaksi memicu proses pemilihan mengeksekusi, repositori bisa menjadi database tradisional. Jika keadaan saat ini pusat struktur data merupakan pemicu utama memilih proses untuk mengeksekusi, yang repositori bisa berupa papan tulis.

Gambar diatas mengilustrasikan pandangan sederhana dari sebuah arsitektur papan tulis. Papan Model biasanya disajikan dengan tiga bagian utama:

Ø  Sumber pengetahuan (The knowledge  sour ces) : terpisah, paket independen dari aplikasi tergantung pengetahuan. Interaksi antara sumber-sumber pengetahuan yang diperlukan tempat hanya melalui papan tulis.

Ø  Papan tulis struktur data (The blackboard data structure) : pemecahan masalah negara data, terorganisir menjadi tergantung aplikasi hirarki. Pengetahuan sumber melakukan perubahan papan tulis yang mengarah bertahap untuk solusi untuk masalah tersebut.

Ø  Pengendalian (Control) : didorong sepenuhnya oleh negara dari papan tulis. sumber Pengetahuan merespon oportunis ketika perubahan di papan tulis membuat mereka berlaku.

Dalam diagram tidak ada representasi eksplisit control komponen. Doa dari sumber pengetahuan dipicu oleh keadaan papan tulis. Lokus aktual kontrol, dan karenanya pelaksanaannya, dapat dalam sumber-sumber pengetahuan, papan tulis, modul terpisah, atau beberapa kombinasi ini.

Blackboard sistem secara tradisional telah digunakan untuk aplikasi yang memerlukan kompleks interpretasi dari pemrosesan sinyal, seperti berbicara dan pola pengakuan. Beberapa di antaranya yang disurvei oleh Nii. Mereka juga muncul dalam jenis lain dari sistem yang melibatkan berbagi akses ke data dengan longgar agen ditambah.

Ada, tentu saja, contoh lain dari sistem repositori. Batch- sistem sekuensial dengan database global merupakan kasus khusus. Pemrograman lingkungan sering diselenggarakan sebagai kumpulan alat bersama-sama dengan berbagi repositori program dan fragmen program. Bahkan aplikasi yang telah secara tradisional dipandang sebagai arsitektur jaringan pipa, mungkin lebih akurat diartikan sebagai sistem repositori. Sebagai contoh, seperti yang akan kita lihat nanti, sementara arsitektur compiler secara tradisional telah disajikan sebagai pipa, yang "Fase" dari kompiler modern yang paling beroperasi pada dasar informasi bersama (Simbol tabel, pohon sintaks abstrak, dll).

3.7. Table Driven Interpreters

Dalam sebuah organisasi juru mesin virtual diproduksi dalam perangkat lunak. Sebuah penerjemah mencakup pseudo-program yang diinterpretasikan dan penafsiran mesin itu sendiri. Pseudo-program termasuk program itu sendiri dan penafsir analog negara pelaksanaannya (catatan aktivasi). Pada mesin interpretasi meliputi definisi penafsir dan keadaan saat pelaksanaannya. Jadi penerjemah umumnya memiliki empat komponen: mesin interpretasi untuk melakukan pekerjaan itu, sebuah memori yang berisi pseudo-code untuk ditafsirkan, sebuah representasi dari negara control interpretasi mesin, dan sebuah representasi dari keadaan saat ini program yang ditinjau.

Juru biasanya digunakan untuk membangun mesin virtual yang menutup kesenjangan antara mesin komputasi diharapkan oleh semantik program dan mesin komputasi yang tersedia di hardware. Kami kadang-kadang berbicara tentang bahasa pemrograman menyediakan, katakanlah, "Pascal mesin virtual."

3.8.  Heterogeneous Architectures

Sejauh ini kita telah berbicara terutama dari "murni" gaya arsitektur. Meskipun penting untuk memahami sifat individu dari masing-masing gaya, kebanyakan sistem biasanya melibatkan beberapa kombinasi dari beberapa gaya.

Ada berbagai cara di mana gaya arsitektur dapat dikombinasikan. Salah satu cara adalah melalui hirarki. Sebuah komponen dari suatu sistem yang diselenggarakan di satu gaya arsitektur mungkin memiliki struktur internal yang dikembangkan sebuah yang sama sekali berbeda gaya. Sebagai contoh, dalam sebuah pipa Unix individu komponen dapat diwakili secara internal menggunakan hampir gaya apapun- termasuk, tentu saja, lain pipa dan filter, sistem.

Apa yang mungkin lebih mengejutkan adalah bahwa konektor juga, seringkali dapat secara hirarki membusuk. Sebagai contoh, sebuah konektor mungkin pipa internal diimplementasikan sebagai antrian FIFO diakses oleh menyisipkan dan menghapus operasi.

Cara kedua untuk gaya untuk digabungkan adalah untuk memungkinkan komponen tunggal gunakan campuran konektor arsitektur. Sebagai contoh, komponen mungkin mengakses repositori melalui bagian interface-nya, tetapi berinteraksi melalui pipa dengan komponen lain dalam sistem, dan menerima informasi kontrol melalui bagian lain dari antarmuka. (Bahkan, pipa Unix dan sistem filter melakukan hal ini, sistem berkas memainkan peran dan inisialisasi switch repositori bermain peran kontrol.)

Contoh lain adalah "basis data aktif". Ini adalah repositori yang mengaktifkan komponen eksternal melalui pemanggilan implisit. Dalam hal ini organisasi komponen eksternal mendaftarkan minat dalam porsi dari database. Database secara otomatis memanggil alat yang tepat berdasarkan ini asosiasi. (Papan tulis yang sering dibangun dengan cara ini, sumber-sumber pengetahuan terkait dengan jenis data tertentu, dan diaktifkan setiap kali seperti itu data dimodifikasi.)

Cara ketiga untuk gaya untuk digabungkan adalah untuk benar-benar rumit satu tingkat dari deskripsi arsitektur dalam arsitektur gaya yang berbeda sepenuhnya. Kami akan melihat contoh ini dalam studi kasus.

KESIMPULAN

• Perancangan arsitektur merupakan perancangan tingkat tinggi yang menjelaskan bagaimana perangkat lunak disusun dalam komponen yang mendefinisikan hubungan antar komponen, arsitektur dan pola desain yang membantu mencapaipersyaratanyangditetapkanuntuksistem
• Aktifitas dalam perancangan arsitektur, meliputi: (1) Dekomposisi kotor sistem menjadi komponen utama. (2) Alokasi tanggung jawab fungsional untuk komponen. (3) Antarmuka Komponen. (4) Komponen penskalaan dan properti kinerja, properti konsumsi sumber daya, properti keandalan, dan sebagainya. (5) Komunikasi dan interaksi antar komponen.
• [Kelompok] dan perancangan [Style] arsitektur, antara lain:
• [Kelompok] Data flow: [Style] Pipe & filter, process control.
• [Kelompok] Data-centered: [Style] Repository, blackboard.
• [Kelompok] Hierarchial: [Style] Layered, master.
• [Kelompok] Interaction Oriented: [Style] Model-View-Controller (MVC).
• [Kelompok] Distributed: [Style] Client-server, multi-tiers, broker, cluster.
• [Kelompok] Implicit Asynchronous Communication: [Style] Buffered Message-Based, Non-Buffered Event-Based implicit invocation.

 

Sumber

https://wardani.staff.telkomuniversity.ac.id/definisi-arsitektur-perangkat-lunak/
http://rinanti1.blogspot.com/2015/09/arsitektur-perangkat-lunak.html
Anggraini, Dian. 2020. https://classroom.google.com/c/NTM1MjY3MzU0NTRa/m/Njc3NDE3ODMyMTRa/details.