ARSITEKTUR PERANGKAT LUNAK

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.

Halaman| 1
Gambar 1.1
Hubungan arsitektur, infrastruktur, dan perangkat lunak

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

Gambar 2.1
Lapisan Perangkat Lunak Secara Umum
Resources : Software Engineering - A Practitioner's Approach
Roger S. Pressman, 2003, McGraw-Hill.

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

Halaman| 3
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.

Halaman| 4
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.

Halaman| 5
Gambar 3.3

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 :

Halaman| 6
§ 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.

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

Halaman| 8
Gambar 4.3

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.

Halaman| 9
Gambar 5.1

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.

H a l a m a n | 10
Gambar 5.2

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

H a l a m a n | 11
Gambar 5.3

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.

H a l a m a n | 12
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

H a l a m a n | 13
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
H a l a m a n | 14
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

H a l a m a n | 15
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
H a l a m a n | 16
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.

H a l a m a n | 17
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.

H a l a m a n | 18
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

H a l a m a n | 19
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

H a l a m a n | 20
hubungan antar modulnya (panah).

2.4.2 Simbol-simbol Dasar

Simbol-simbol standar yang paling banyak digunakan :

SUMBER:

H a l a m a n | 21