Arsitektur Perangkat Lunak

Arsitektur perangkat lunak adalah sekumpulan pernyataan yang menggambarkan

komponen perangkat lunak dan fungsi-fungsi yang ada pada komponen tersebut. Ia
menggambarkan struktur teknis, batasan-batasan, ciri-ciri, serta antarmuka pada komponen-
komponen tersebut. Arsitektur merupakan rancangan fisik sistem dan oleh karena itu
membutuhkan rencana yang matang pada saat pembuatannya (Krafzig et al, 2004).

Arsitektur perangkat lunak merupakan struktur sebuah sistem, yang meliputi elemen
perangkat lunak, sifat (property) yang tampak dari elemen itu, serta relasi di antara elemen-
elemen tersebut (Bass et al dalam Krafzig et al, 2004). Sifat yang tampak misalnya fungsi apa
saja yang disediakan oleh elemen, bagaimana kinerjanya, bagaimana penanganan
kesalahannya, sumber daya apa saja yang digunakan.

Menurut Erl (2009), ada tiga elemen yang saling berkaitan erat ketika berbicara
tentang arsitektur perangkat lunak. Pertama adalah arsitektur teknologi, yaitu desain fisik dari
suatu perangkat lunak. Kedua adalah infrastruktur teknologi, yaitu lingkungan pendukung
yang termasuk di dalamnya perangkat keras dan perangkat lunak. Ketiga adalah perangkat
lunak itu sendiri. Berikut adalah diagram sederhana yang memperlihatkan keterkaitan ketiga
elemen tersebut.

Istilah “arsitektur” berasal dari istilah yang digunakan pada bidang konstruksi bangunan. Sebuah
bangunan memiliki desain fisik yang digambarkan dalam cetak biru arsitektur (architecture
blueprint) atau disebut juga spesifikasi arsitektur. Suatu bangunan berada dalam lingkungan
tertentu. Lingkungan ini bisa memberikan dukungan ataupun tidak terhadap bangunan tersebut.
Sebagai contoh, bangunan perumahan yang dididukung oleh sarana transportasi, pembangkit tenaga
listrik, dan sistem pembuangan limbah. Lingkungan pendukung inilah yang disebut infrastruktur.
Agar bangunan dapat memanfaatkan infrastruktur tersebut, desain fisiknya harus mengintegrasikan
berbagai infrasturktur tadi ke dalam arsitekturnya. Oleh karena itu, spesifikasi arsitektur sebuah
bangunan haruslah memperhatikan infrastruktur di sekitarnya. Begitu juga dengan perangkat lunak,
rancangan arsitekturnya harus memperhatikan infrastruktur di mana perangkat lunak ini akan
ditempatkan.  

2.2 Layering

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 empat lapisan, yaitu :
1. A Quality Focus
2. Process
3. Methods
4. Tools

2.2.1 A QUALITY FOCUS (FOKUS KUALITAS)

Pada saat kita membangun sebuah aplikasi, Fokus pertama kali yang dibuat adalah Kita akan
membangun kualitas yang seperti apa,siapa sasaran kita, aplikasi yang dibangun siapa
pengguna dan lai-lain, Oleh karena itu FOKUS KUALITAS ini programmer akan
mengetahui level sebuah aplikasi yang dibangun. Misalnya akan dibangun APLIKASI
PEMUTAR MUSIC. Dengan berpatokan pada FOKUS KUALITAS maka Programmer
akan mengetahui sampai dimana aplikasi yang akan dibangun. File Music bisa beraneka
ragam mulai dari MP3, MP2, AUDIO TRACK, WAV, MDI dan lain-lain. Dengan
mengetahui, Aplikasi ini dibuat untuk File music apa,
maka programmer akan mengetahui segala hal yang berhubungan dengan
program yang dibuat. Apakah aplikasi yang dibuat akan mendukung untuk MP3, MP2,
WAV, OGG, TRACK atau yang lainnya. Jika dilihat dari segi Interaksi Manusia dan
Komputer, maka dengan FOKUS KUALITAS programmer akan mengetahui bentuk dari
aplikasi yang akan bangun.

2.2.2 PROCESS
Process atau Proses adalah merupakan lapisan kedua dalam 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-proses yang ada akan
dikerjakan sesuai dengan Kunci Proses Area yang ada (KPA/Key Process Area).

2.2.3 METHODS
Methods atau Metode merupakan salah satu hal yang penting dalam Pembuatan Perangkat
Lunak. Dengan metode, pembuat program akan melakukan langkah-langkah dan tindakan-
tindakan yang sesuai dengan metode yang ada. Metode yang digunakan harus disesuaikan
dengan perangkat lunak yang dibangun, dan tujuan dari pembuatan perangkat lunak.

2.2.4 TOOLS
Tools merupakan alat bantu yang dapat digunakan oleh programmer dalam menyelesaikan
proyek yang ada. Mulai dari tools animasi tools multimedia, tools normalisasi dan lain-lain.
Misalnya : X3D, power designer, paintshop pro, etc.

 2.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.

2.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

2.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 :
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.
2.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 terde
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.

Gambar 5.4

2.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.

2.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.

2.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 7.1

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).
2.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.

Gambar 8.1

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."

2.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.

2.4 Pengenalan Struktur Chart Diagram

Structure Chart ( bagan struktur ) :
organisasi dari sistem secara berjenjang dalam bentuk modul dan submodul.
Salah satu alat bantu pemecahan masalah teknik top-down
- Structure Chart menggambarkan hubungan
elemen data dan elemen kontrol serta
hubungan antar modulnya.
- Structure Chart penjelasan yang lengkap dari
sistem.

2.4.1 Elemen Struktur Chart Diagram

Elemen Structure Chart Diagram terdiri dari :
1. elemen data
2. elemen kontrol
3. modul
hubungan antar modulnya (panah).

2.4.2 Simbol-simbol Dasar

Simbol-simbol standar yang paling banyak digunakan :
Software Engineering : Design Engineering
– Architectural Design
Architectural design digunakan untuk menggambarkan hubungan antar elemen struktural
utama dari perangkat lunak, gaya arsitektur dan pola desain yang membantu mencapai tujuan
dibuatnya suatu sistem. Menurut Mathiassen (2000, p197), Architectural design memiliki
tujuan untuk menstrukturkan suatu sistem yang menggunakan komputerisasi. Desain ini
sangat mempengaruhi dalam seberapa baik suatu sistem, seperti dalam kecepatan, keamanan,
dan kemudahan dalam dimodifikasi.

Arsitektur berfungsi sebagai ‘Blue Print’ untuk suatu sistem. Ini memberikan abstraksi untuk
mengelola kompleksitas sistem dan membangun mekanisme komunikasi dan koordinasi antar
komponen. Ini mendefinisikan solusi terstruktur untuk memenuhi semua persyaratan teknis
dan operasional, sambil mengoptimalkan atribut kualitas umum seperti kinerja  dan
keamanan.

Lebih lagi, ini melibatkan serangkaian keputusan penting tentang organisasi yang terkait
dengan pengembangan perangkat lunak dan masing-masing keputusan ini dapat memiliki
dampak yang besar pada kualitas, pemeliharaan, kinerja, dan keberhasilan keseluruhan
produk akhir. Keputusan-keputusan ini terdiri dari :

 Keputusan arsitektur selaras dengan tujuan bisnis.

 Gaya arsitektur memandu organisasi.
 Komposisi elemen struktural dan perilaku ini menjadi subsistem
 Pemilihan elemen struktural dan antarmuka mereka yang digunakan
 Perilaku sebagaimana ditentukan dalam kolaborasi antara elemen-elemen

Kenapa software architecture penting?

1. Arsitektur menjadi kerangka sebuah sistem
Setiap sistem memiliki sebuah arsitektur, secara sadar atau pun tidak sadar
pengembang memilihnya. Setiap arsitektur memiliki keunggulannya masing-masing.
Oleh karena itu kita harus memilih kerangka yang sesuai.

2. Arsitektur mempengaruhi quality attributes

Quality attributes adalah properti yang terlihat secara eksternal, berupa security,
usability, latency atau modifiability. Kerangka yang berbeda dapat mempermudah
ataupun mempersulit dalam menangani suatu permasalahan. Dengan demikian
memiliki arsitektur yang tepat dapat mempermudah kita dalam mencapai kualitas
yang diinginkan

3. Sebagian arsitektur adalah ortogonal terhadap fungsionalitas.

Hal ini mungkin untuk membuat sistem yang sama dengan arsitektur yang berbeda.
Jika arsitektur yang digunakan tidak cocok dengan fungsionalitas, developer akan
kesulitan dalam mengembangkannya
 4. Arsitektur membatasi sistem
Arsitektur adalah seni dalam menentukan batasan yang cukup sehingga sistem
memiliki quality attributes yang diinginkan. Contohnya, sebuah desain yang
menjamin scalability memerlukan beberapa komponen harus stateless agar scalability
dapat didapat.

Prinsip dari software design juga disebut sebagai teknik penyediaan, adalah ide utama
berdasarkan pada berbagai pendekatan dan konsep yang berbeda dari software  design.
Macam enabling techniques sebagai berikut:

 Abstraction
 Coupling and cohesion
 Decomposition and modularization
 Encapsulation / information hiding
 Separation of interface and implementation

Pola arsitektur dalam aplikasi

Pola arsitektur membantu menentukan karakteristik dasar dan perilaku suatu aplikasi yang
membuat sebuah aplikasi berbeda dengan aplikasi lainnya.

1. Layered Architecture (Arsitektur berlapis)

Seluruh komponen yang ada dalam arsitektur berlapis dibuat ke dalam bentuk
horizontal, dimana setiap lapisan melakukan peran tertentu dalam sebuah aplikasi.
Salah satu kelebihan dibanding arsitektur lain adalah arsitektur berlapis memisahkan
kepentingan antar komponen (yang berada di layer yang berbeda). Pemisahan
komponen di layer berbeda memudahkan membangun peran yang efektif, mudah
untuk dikembangkan, diperbaharui, dan dapat menghubungkan komponen dengan
baik.
2. Event-Driven Architecture (arsitektur berbasis acara)

Arsitektur berbasis acara relatif kompleks dan sulit untuk diterapkan karena sifatnya
yang didistribusikan secara tidak sinkron. Untuk menerapkan arsitektur ini, harus
mempertimbangkan ketersediaan proses jarak jauh, kurangnya respon, dan koneksi
ulang ketika terjadi kegagalan. Salah satu kesulitan penerapan arsitektur ini adalah
penciptaan awal arsitektur, pemeliharaan, dan pengelolaan komponen.

3. Microkernel Architecture
Arsitektur microkernel (kadang disebut sebagai arsitektur plug-in) adalah pola untuk
menerapkan aplikasi berbasis produk yang mana dikemas dan tersedia untuk diunduh
dalam versi produk pihak ketiga. Arsitektur microkernel terdiri dari dua jenis
komponen arsitektur, yaitu sistem inti dan plug-in module. Sistem inti dari pola
arsitektur microkernel hanya berisi fungsionalitas minimal yang diperlukan untuk
membuat sistem operasional.
 Modul plug-in adalah komponen independen yang berisi pemrosesan khusus, fitur
tambahan dan kode khusus yang diperuntukkan untuk meningkatkan sistem inti. Anda
dapat merancang plug-in yang independen, namun juga dapat berupa plug-in yang
membutuhkan plug-in lainnya. Dalam bentuk apa pun, komunikasi tiap plug-in harus
dibuat seminimal mungkin untuk menghindari masalah ketergantungan.

4. Microservices Architecture Pattern

Konsep dari pola ini adalah unit yang dikelola secara terpisah, yang mana setiap
komponen arsitektur digunakan sebagai unit yang terpisah dan memungkinkan untuk
penyebaran yang lebih mudah, meningkatkan skalabilitas, dan tingkat aplikasi yang
tinggi.

5. Space-Based Architecture (arsitektur berbasis ruang)

Pola arsitektur berbasis ruang (terkadang disebut sebagai cloud architecture pattern
atau pola arsitektur awan) dirancang khusus untuk mengatasi dan memecahkan
masalah skalabilitas yang ekstrem dan konkurensi. Pola ini juga berguna untuk
 aplikasi yang volume penggunanya tidak dapat diprediksi. Pola ini dinamakan
berdasar pada konsep tuple space dimana menggunakan shared memory yang
terdistribusi.

Mapping Requirements Into A Software Architecture

1. Transform Flow
Mengingat sistem model fundamental (level 0 data flow diagram), informasi harus
keluar dan masuk software dalam bentuk “external world”. Informasi masuk ke dalam
sistem melalui jalur yang mengubah data eksternal menjadi bentuk internal. Jalur ini
disebut incoming flow. Di kernel software, transaksi terjadi. Data yang masuk adalah
data melewati pusat transformasi dan mulai bergerak di sepanjang jalan yang
sekarang mengarah “keluar” software. Ini disebut outgoing flow. Secara keseluruhan
aliran data terjadi secara berurutan dan mengikuti satu, atau hanya beberapa jalur
“straight line”. Ketika segmen diagram aliran data menunjukkan karakteristik ini,
transform flow pun terjadi.

2. Transaction Flow
Aliran informasi data sering kali dikarakterisasikan oleh item data single, yang
disebut transaction, yang memicu aliran data lain di sepanjang satu jalan dari banyak
jalan.

Saat DFD menunjukkan bentuk seperti

gambar, disitulah transaction flow.