Materi Singkat Arsitektur Perangkat Lunak (Software Architecture)

Assalamu‘alaikum wr. wb.

Halo gais, Kembali lagi bersama Inzaghi's Blog! Dalam suatu Perangkat Lunak (Software), harus ada yang terstruktur agar dapat membuatnya dengan baik. Struktural inilah yang bernama Arsitektur Perangkat Lunak atau Software Architecture. Sama seperti Arsitektur Komputer, Arsitektur Perangkat Lunak juga berkaitan dengan Pemrograman Komputer.

Ilustrasi Arsitektur Perangkat Lunak (Software Architecture)

Sumber Materi : Gurupujaz.wordpress.com dan Medium.com (@andrewsavero)

A. Pengertian Arsitektur Perangkat Lunak

Arsitektur Perangkat Lunak adalah seperangkat instruksi yang menjelaskan komponen perangkat lunak dan fungsi yang ada di dalam komponen tersebut. Ini menggambarkan struktur teknis, batasan, karakteristik, dan antarmuka dari komponen-komponen ini. Arsitektur adalah desain fisik dari sistem dan karenanya memerlukan perencanaan yang cermat pada saat pembuatannya (Krafzig et al, 2004).

Arsitektur Perangkat Lunak adalah struktur dari suatu sistem, termasuk elemen perangkat lunak, sifat (property) dari elemen tersebut dan hubungan antara elemen tersebut (Bass et al dalam Krafzig et al, 2004). Atribut muncul, misalnya, fungsionalitas apa yang disediakan oleh elemen, bagaimana penerapannya, bagaimana penanganannya jika terjadi kesalahan, sumber daya apa yang digunakan.

Menurut Erl (2009), ada tiga elemen yang saling berkaitan erat ketika berbicara tentang arsitektur perangkat lunak, yakni :

• Arsitektur teknologi, yaitu desain fisik dari suatu perangkat lunak.
• Infrastruktur teknologi, yaitu lingkungan pendukung yang termasuk di dalamnya perangkat keras dan perangkat lunak.
• Perangkat lunak itu sendiri.

Berikut adalah diagram sederhana yang memperlihatkan keterkaitan ketiga elemen tersebut.

Diagram Arsitektur Perangkat Lunak

B. Lapisan-lapisan pada Arsitektur Perangkat Lunak

Software layer merupakan salah konsep utama yang harus diketahui, dikenali, dimengerti dan diimplementasikan pada saat akan membangun sebuah perangkat lunak (software). Software Layer terbagi menjadi 4 (Empat) Lapisan, yaitu :

• A Quality Focus
• Process
• Methods
• Tools

1. A Quality Focus (Fokus Kualitas)

Ketika kita membangun sebuah aplikasi, hal pertama yang harus dilakukan adalah mengetahui kualitas seperti apa yang akan kita bangun, siapa tujuan kita, siapa pengguna aplikasi yang dibangun, dll. Sehingga programmer Quality Concentrate ini akan mengetahui sejauh mana sebuah aplikasi yang dibangun. Misalnya, Aplikasi Musik akan dibangun. Dengan menyebutkan Fokus Kualitas maka programmer akan mengetahui dimana aplikasi akan dibangun. File musik bisa bermacam-macam mulai dari MP3, MP2, Audio Track, WAV, MDI dan lainnya.

Mengetahui untuk apa file musik aplikasi ini dirancang, pemrogram mengetahui segalanya tentang program yang dibuat. Apakah aplikasi mendukung MP3, MP2, WAV, OGG, Track atau yang lainnya. Mengenai interaksi manusia dengan komputer, dengan Fokus Kualitas, programmer akan mengetahui bentuk dari aplikasi yang akan dibangun.

2. Process

Process atau Proses adalah lapisan kedua dari Software Layer, Lapisan ini terletak setelah Quality Focus, hal ini disebabkan setelah diketahui Fokus Kualitas dari Perangkat Lunak yang akan dibangun, maka pemrogram harus mengetahui bagaimana proses yang harus dijalani oleh pemrograman sehubungan dengan Fokus Kualitas dari Perangkat Lunak yang diharapkan, Proses-proses ini dilakukan terurut dan tepat, agar tidak terjadi kesalahan pada saat sebuah aplikasi di Launching. Proses yang ada akan dijalankan sesuai dengan area proses utama (KPA/area proses utama) yang ada.

3. Methods

Methods atau Metode merupakan salah satu hal yang penting dalam Pembuatan Perangkat Lunak. Dengan metode, programmer akan melakukan langkah-langkah dan operasi sesuai dengan metode yang ada. Metode yang digunakan harus sesuai dengan perangkat lunak yang dibangun dan tujuan pembuatan perangkat lunak tersebut.

4. Tools

Tools adalah alat yang dapat digunakan oleh programmer untuk menyelesaikan proyek yang ada. Dari alat animasi, alat multimedia, alat normalisasi dan banyak lagi. Misalnya : X3D, Power designer, Paintshop pro, etc.

C. Jenis-jenis 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.

1. Data Centered Architectures

Arsitektur ini bertujuan untuk mencapai kualitas integritas data. Istilah ini mengacu pada sistem yang tujuan utamanya adalah mengakses dan memperbarui penyimpanan data yang dapat diakses secara luas. Ini pada dasarnya tidak lebih dari penyimpanan data terpusat yang digunakan beberapa klien Penting untuk gaya ini adalah 3 Protokol, yaitu komunikasi, definisi data dan protokol data manipulasi. Sarana komunikasi membedakan dua Subtipe repositori dan papan tulis.

1. Repository : Klien mengirimkan permintaan ke sistem untuk melakukan tindakan yang diperlukan (misalnya memasukkan data)
2. 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. Skema basis data umum (Yaitu Metastruktur Repositori), dibuat melalui definisi Registry data. Misalnya, dalam RDBMS, sekumpulan tabel yang terkait dengan bidang, tipe data, kunci, dll.

Klien menggunakan Protokol Pemrosesan data untuk memproses data. Misalnya SQL untuk memasukkan data, pemilihan, penghapusan dan lainnya. Tergantung pada lokasi klien, protokol komunikasi mungkin terlihat seperti ini :

• 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

2. Data Flow Architectures

Arsitektur ini memiliki tujuan untuk mencapai kualitas pemakaian ulang dan modifiability. Gaya Data Flow Architectures dicirikan dengan mempertimbangkan sistem sebagai rangkaian transformasi data input yang berurutan. Data memasuki sistem dan kemudian mengalir melalui satu komponen pada satu waktu sampai data tersebut akhirnya ditetapkan ke tujuan akhir (output atau penyimpanan data).

Data Flow Architectures dapat diklasifikasikan ke dalam arsitektur serial dan pipa dan filter. Dengan gaya coretan berurutan, setiap fase berakhir sebelum fase berikutnya dimulai. Misalnya pipa baris perintah UNIX. Pipa dan filter melakukan tahapan dalam gaya bagian paralel dari pemrosesan data secara bertahap.

Batch Sequential Style & Pipe and Filter Style

Pipes and Filters :

Dalam pipa dan komponen filter gaya masing-masing memiliki satu set input dan output. Komponen membaca aliran data masukan dan menghasilkan aliran data keluaran yang memberikan contoh lengkap hasil dalam urutan default. Hal ini biasanya dicapai dengan menerapkan transformasi lokal ke input stream dan meningkatkan hitungan sehingga output input dimulai sebelum aus. Karenanya komponen yang disebut "filter". Konektor ini bertindak sebagai media daya, meneruskan output dari satu filter ke input filter lainnya. Itulah mengapa koneksi ini disebut "pipa".

Variasi gaya yang penting adalah bahwa filter harus berdiri sendiri dan tidak boleh berbagi ruang dengan filter lain. Invarian penting lainnya adalah filter tidak mengetahui identitas filter hulu dan hilirnya. Spesifikasi mereka mungkin membatasi apa yang terlihat di pipa saluran masuk atau menjamin apa yang terlihat di pipa saluran keluar, tetapi mereka tidak dapat mengidentifikasi komponen di ujung pipa. Juga, kebenaran output dan tabung filter tidak boleh bergantung pada urutan di mana filter melakukan pemrosesan lebih lanjut, meskipun waktu yang wajar dapat diasumsikan.

Spesialisasi umum dari gaya ini termasuk saluran pipa, yang membatasi topologi ke serangkaian filter linier, pipa yang terhubung, yang membatasi jumlah data dalam pipa, dan diketik pipa, yang mengharuskan data yang melewati antara dua filter memiliki tipe yang didefinisikan dengan baik.

3. Call and Return Architectures

Call and Return Arhitectures bertujuan untuk mencapai properti konvertibilitas dan resolvabilitas. Call and Return Architectures telah menjadi gaya arsitektur dominan dalam sistem perangkat lunak besar selama 30 tahun terakhir. Namun, beberapa sub-gaya telah muncul dalam gaya tersebut, masing-masing dengan karakteristik yang menarik.

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.

Panggilan proses Sistem Remote adalah program utama dan sistem subprogram yang dibagi menjadi beberapa komponen pada komputer yang terhubung oleh jaringan. Tujuannya adalah untuk meningkatkan kinerja dengan berbagi kalkulasi dan menggunakan banyak prosesor. Dalam sistem pemanggilan prosedur jarak jauh, alokasi aktual komponen ke prosesor ditangguhkan saat runtime, artinya alokasi dapat dengan mudah diubah saat kinerja dioptimalkan. Terlepas dari fakta bahwa pemanggilan subrutin memakan waktu lebih lama untuk dieksekusi ketika pemanggilan fungsi berada di mesin jarak jauh, pemanggilan prosedur jarak jauh sebenarnya tidak dapat dibedakan dari program utama reguler dan subrutin sistem.

Sistem tipe data berbasis objek atau abstrak adalah arsitektur panggilan dan giliran modern. Paradigma objek, seperti paradigma tipe data abstrak dari mana ia muncul, menekankan agregasi data dan metode untuk menangani dan menggunakan data (antarmuka publik).

Objek abstraksi Bentuk komponen yang menyediakan layanan kotak hitam dan komponen lain yang meminta layanan tersebut. Tujuannya adalah kualitas konvertibilitas.

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 :

1. Pengguna jasa tidak perlu tahu, dan tidak harus tahu, apa-apa tentang bagaimana layanan yang diimplementasikan.
2. 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.

Pattern ini digunakan untuk menstruktur program yang dapat didekompos menjadi beberapa subtask. Setiap layer memberikan service kepada layer diatasnya. 4 layer yang umumnya ditemukan ada sebagai berikut :

• Presentation layer (UI layer)
• Application layer (Service layer)
• Business logic layer (Domain layer)
• Data access layer (Persistence layer)

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.

4. Layered Architectures

Sistem lantai diatur secara hierarkis, dengan setiap lantai menyediakan layanan untuk tingkat di atasnya dan bertindak sebagai klien untuk lantai di bawahnya. Dalam sistem berlapis, lapisan dalam disembunyikan dari semua kecuali lapisan luar yang berdekatan, kecuali untuk fitur tertentu yang dipilih dengan cermat untuk ekspor. Dengan demikian, dalam sistem ini komponen mesin virtual diimplementasikan dalam beberapa tingkatan hierarki. (Dalam sistem berlapis lainnya, lapisan hanya sebagian buram.) Konektor ditentukan oleh protokol yang menentukan bagaimana lapisan berinteraksi. Kendala topologi termasuk membatasi interaksi ke lapisan yang berdekatan.

Contoh paling menonjol dari gaya arsitektur protokol komunikasi berlapis. Di area ini, setiap lapisan aplikasi menyediakan platform untuk komunikasi pada tingkat abstraksi tertentu. Semakin rendah level yang ditunjukkan, semakin rendah level interaksi, yang terendah biasanya ditentukan oleh perangkat keras penghubung. Aplikasi lain dari jenis ini adalah sistem database 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.

5. Event-based, Implicit Invocation

Secara tradisional, dalam sistem di mana komponen antarmuka pengguna menyediakan kumpulan prosedur dan fungsi, komponen berinteraksi secara eksplisit satu sama lain dengan memanggil rutinitas mereka. Namun, baru-baru ini ada minat yang cukup besar dalam teknik integrasi alternatif, yang secara beragam disebut sebagai pemanggilan implisit, integrasi reaktif, dan penyiaran selektif. Gaya ini memiliki akar sejarah dalam sistem berdasarkan pelaku daemon, dan jaringan packet-switched.

Ide di balik pemanggilan implisit adalah bahwa sebuah komponen dapat mengumumkan (atau siaran) satu atau lebih event daripada memanggil prosedur secara langsung. Komponen sistem lainnya dapat mendaftarkan minat pada acara tersebut dengan melampirkan tindakan ke acara tersebut. Saat kejadian ini dilaporkan, sistem itu sendiri memanggil semua fungsi yang terdaftar untuk kejadian tersebut. Artinya, pemberitahuan implisit dari suatu peristiwa menyebabkan pemanggilan prosedur di modul lain.  

Misalnya, dalam sistem lapangan, alat seperti editor dan variabel jam tangan mendaftarkan peristiwa debugger. Saat debugger berhenti di breakpoint, ia melaporkan peristiwa yang memungkinkan sistem memanggil metode terdaftar alat secara otomatis. Metode ini dapat berupa editor yang menggulir ke baris sumber yang sesuai atau mengembalikan nilai variabel yang dipantau. Dalam sistem ini, debugger hanya melaporkan kejadian tetapi tidak mengetahui alat lain apa (jika ada) yang terkait dengan kejadian tersebut atau apa yang mereka lakukan saat kejadian dilaporkan.

Secara Arsitektural, komponen gaya panggilan implisit adalah modul yang menyediakan antarmuka untuk sekumpulan prosedur (misalnya, tipe data abstrak) dan rangkaian kejadian. Prosedurnya bisa disebut seperti biasa. Namun, selain itu, komponen dapat mendaftarkan beberapa tindakan untuk kejadian sistem. Ini akan memanggil prosedur ini saat acara dilaporkan saat runtime. Jadi konektor untuk pemanggilan sistem implisit mencakup pemanggilan prosedur tradisional serta koneksi antara pernyataan kejadian dan pemanggilan prosedur.

Invarian utama dari gaya ini adalah operator event tidak mengetahui komponen mana yang dipengaruhi oleh peristiwa-peristiwa. Oleh karena itu, komponen tidak dapat membuat asumsi tentang urutan proses atau bahkan pemrosesan apa yang akan terjadi sebagai hasil dari kejadian mereka. Oleh karena itu, selain sebagian besar pemanggilan implisit, sistem juga menyertakan pemanggilan eksplisit (yaitu pemanggilan prosedur normal) sebagai bentuk interaksi tambahan.

Contoh sistem dengan mekanisme panggilan implisit sangat banyak. Mereka digunakan dalam lingkungan pemrograman untuk mengintegrasikan alat-alat, dalam sistem manajemen basis data untuk menegakkan batasan konsistensi, di pengguna interface untuk memisahkan presentasi data dari aplikasi manajemen data, dan dalam editor sintaks berbasis halaman untuk mendukung tambahan semantic memeriksa.

Salah satu keuntungan penting dari pemanggilan implisit adalah ia memberikan dukungan penggunaan kembali yang kuat. Setiap komponen dapat dibawa ke dalam sistem hanya dengan mendaftar pada kejadian di sistem itu. Keuntungan lain adalah panggilan implisit menyederhanakan pengembangan sistem. Komponen dapat diganti oleh komponen lain tanpa mempengaruhi koneksi komponen sistem lainnya.

Sebaliknya, dalam sistem berbasis panggilan eksplisit, jika identitas penyedia fungsi sistem berubah, semua modul lain yang mengimpor modul itu juga harus berubah.

Kerugian utama dari pemanggilan implisit adalah bahwa komponen menyerahkan kendali atas kalkulasi yang dilakukan oleh sistem. Ketika sebuah komponen melaporkan suatu peristiwa, ia tidak tahu komponen lain mana yang akan meresponsnya. Lebih buruk lagi, bahkan jika ia tidak mengetahui komponen lain apa yang tertarik dengan operasi yang dideklarasikan, ia tidak dapat mempercayai urutan pemanggilannya. Cari tahu juga kapan mereka dibuat. Masalah lain menyangkut pertukaran informasi. Terkadang data dapat ditransfer dengan transaksi. Namun dalam situasi lain, sistem acara harus bergantung pada penyimpanan data bersama untuk berinteraksi. Dalam kasus ini, kinerja global dan pengelolaan sumber daya dapat menjadi masalah utama. Akhirnya, penalaran tentang kebenaran bisa menjadi masalah, karena konsep proses yang mendeklarasikan suatu peristiwa tergantung pada konteks binding di mana ia dipanggil. Ini berbeda dengan pembenaran pemanggilan metode tradisional, yang hanya perlu mempertimbangkan kondisi pra dan pasca metode saat membenarkan pemanggilan tersebut.

6. Repositories

Dari berbagai jenis repositori, hanya ada dua jenis komponen, yaitu struktur data pusat yang mewakili keadaan saat ini dan sekumpulan komponen independen yang beroperasi pada penyimpanan data pusat. Interaksi antara repositori dan komponen eksternal dapat sangat bervariasi dari sistem ke sistem.

Pilih disiplin kontrol yang mengarah ke halaman utama. Jika jenis transaksi dalam aliran input transaksi memicu proses pemilihan yang sedang berjalan, repositori dapat menjadi database tradisional. Jika status struktur data pusat saat ini adalah pemicu utama untuk memilih proses mana yang akan dijalankan, repositori dapat menjadi sarana pemblokiran.

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

1. Sumber pengetahuan (The knowledge sources) : terpisah, paket independen dari aplikasi tergantung pengetahuan. Interaksi antara sumber-sumber pengetahuan yang diperlukan tempat hanya melalui papan tulis.
2. 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.
3. Pengendalian (Control) : didorong sepenuhnya oleh negara dari papan tulis. sumber Pengetahuan merespons 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 digunakan untuk aplikasi yang membutuhkan interpretasi pemrosesan sinyal yang kompleks, seperti pengenalan ucapan dan pola. Beberapa dari mereka diinterogasi oleh Nii. Mereka juga muncul dalam jenis sistem lain yang melibatkan berbagi hak akses data dengan aktor yang digabungkan secara longgar.

Ada, tentu saja, contoh lain dari sistem repositori. Sistem Batch 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 secara tradisional dilihat sebagai arsitektur pipa dapat lebih akurat didefinisikan sebagai repositori. 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).

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.

Penerjemah biasanya digunakan untuk membangun mesin virtual yang menjembatani kesenjangan antara kalkulator yang diharapkan oleh semantik program dan kalkulator di perangkat keras. Kami terkadang berbicara tentang bahasa pemrograman yang menyediakan hal-hal seperti "Mesin Virtual Pascal".

8. Heterogeneous Architectures

Sejauh ini kita terutama berbicara tentang gaya konstruksi "murni". Meskipun penting untuk memahami sifat individual dari setiap gaya, sebagian besar sistem cenderung mengandung kombinasi gaya.

Gaya arsitektur dapat dikombinasikan dengan berbagai cara. Salah satu caranya adalah melalui hirarki. Bagian dari sistem yang diatur dalam satu gaya arsitektur mungkin memiliki struktur internal yang dirancang dengan gaya yang sama sekali berbeda. Misalnya, dalam pipa Unix, masing-masing komponen dapat direpresentasikan secara internal di hampir semua gaya - termasuk, tentu saja, pipa dan filter lain, sistem. 

Mungkin yang lebih mengejutkan, konektor seringkali dapat dipatahkan secara hierarki juga. Misalnya, konektor dapat berupa pipa internal yang diimplementasikan sebagai Antrean FIFO yang dapat diakses dengan operasi tambah dan hapus.

Contoh lain adalah "database aktif". Ini adalah repositori yang mengaktifkan komponen eksternal dengan panggilan implisit. Dalam hal ini, organisasi konstituen eksternal mendaftarkan kepentingannya di bagian database ini. Berdasarkan koneksi ini, database secara otomatis memanggil alat yang sesuai. (Papan tulis sering kali dibuat dengan cara ini, dengan sumber daya data yang terkait dengan tipe data tertentu dan diaktifkan saat data tersebut berubah.)

Cara ketiga menggabungkan gaya sebenarnya adalah mengembangkan satu tingkat deskripsi arsitektur dalam gaya arsitektur yang sama sekali berbeda.

D. Struktur Chart Diagram pada Arsitektur Perangkat Lunak

Struktur chart berfungsi untuk mendefinisikan dan mengilustrasikan organisasi sistem informasi dalam bentuk modul dan sub modul secara bertahap. Struktur diagram juga menunjukkan hubungan antara data dan kontrol dalam hubungan modul. Struktur skematis dapat memberikan penjelasan lengkap tentang suatu sistem dalam hal elemen data, kontrol, modul, dan hubungan antar modul. Diagram struktur menjelaskan :

• Ukuran dan kompleksitas sistem, dan
• Sejumlah fungsi mudah dikenali dan modul dalam fungsi masing-masing dan
• Apakah setiap fungsi diidentifikasi adalah entitas dikelola atau harus dipecah menjadi komponen yang lebih kecil.

Diagram struktural juga digunakan untuk mewakili elemen yang saling berhubungan yang terdiri dari Aliran Run atau Utas (Thread). Ini sering dikembangkan sebagai diagram hierarkis, tetapi representasi lain diperbolehkan. Presentasi harus menjelaskan detail konfigurasi sistem hingga ke subsistem dan level terbawah yang dapat dikelola. Diagram struktur yang akurat dan lengkap adalah kunci untuk menentukan item konfigurasi dan menyediakan representasi visual dari sistem konfigurasi dan antarmuka internal. Selama proses konfigurasi pengontrol, diagram struktur digunakan untuk mengidentifikasi dan memetakan artefak yang mungkin terpengaruh oleh perubahan yang diusulkan. 

Menurut Wolber (2009), “bagan struktur dapat dikembangkan dimulai dengan menciptakan struktur, yang menempatkan akar pohon terbalik yang membentuk bagan struktur. Langkah selanjutnya adalah konsep utama sub-tugas yang harus dilakukan oleh program untuk memecahkan masalah. Selanjutnya, programmer berfokus pada setiap tugas sub-individual, dan mengkonseptualisasikan bagaimana masing-masing dapat dipecah menjadi tugas yang lebih kecil. Akhirnya, program ini dipecah ke titik di mana daun pohon merupakan metode sederhana yang dapat dikodekan dengan hanya beberapa laporan program.

Struktur chart umumnya dipakai dalam perencanaan top-down programming (Alat bantu ini sering juga disebut hirarki atau tingkatan, atau chart atau Visual Table of Contents — VTOC). Pada saat ini tidak ada standar yang digunakan dalam struktur chart, dan teknik yang akan dikemukakan dibawah ini, yang bekerja cukup baik,serta kenapa digunakan sebagai alat diambil dari berbagai variasi sumber. Contoh structure chart adalah PHP.

1. Komponen Structure Chart

Produk dari Perancangan Terstruktur adalah Structure Chart yang memperlihatkan komponen-komponen prosedural program, pengaturan hierarkinya dan data yang menghubungkan komponen-komponen tersebut.

2. Model Bagan Terstruktur

Bagan terstruktur adalah mendefinisikan dan mengilustrasikan organisasi dari sistem informasi secara berjenjang dalam bentuk modul dan submodul.

3. Elemen Struktur Chart Diagram

Elemen Struktur Chart Diagram terdiri dari :

• Elemen data
• Elemen control
• Modul

Itulah Penjelasan singkat Materi tentang apa itu Arsitektur Perangkat Lunak (Software Architecture). Semoga bermanfaat bagi Mahasiswa Teknik Informatika (TI).

Terima Kasih 😄😘👌👍 :)

Wassalamu‘alaikum wr. wb.