KD 7

ARSITEKTUR PERANGKAT LUNAK

1. PENGENALAN ARSITEKTUR PL
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.

Gambar hubungan arsitektur, infrastruktur dan pl

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

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

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.

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.
 RAGAM ARSITEKTUR
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 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.
 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, dan lain-lain.

Klien menggunakan protokol data manipulasi untuk bekerja dengan data.

Misalnya SQL untuk memasukkan, memilih, deleteing data, dan lain-lain. 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. 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.

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

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:

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.

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.
 Gambar 5.4
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.

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.

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

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

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.

2. PENGENALAN STRUKTUR CHART DIAGRAM

Struktur chart berfungsi untuk mendefinisikan dan mengilustrasikan organisasi dari
sistem informasi secara berjenjang dalam bentuk modul dan submodul. Struktur chart juga
menunjukkan hubungan elemen data dan elemen kontrol antara hubungan modulnya. Struktur
chart dapat memberikan penjelasan lengkap dari sistem dipandang dari elemen data, elemen
kontrol, modul dan hubungan antar modul. Sebuah bagan struktur menggambarkan :
 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.

Sebuah bagan struktur juga digunakan untuk diagram elemen terkait yang terdiri dari
aliran run atau thread. Hal ini sering dikembangkan sebagai diagram hirarkis , tetapi representasi
lain diijinkan. Representasi harus menjelaskan rincian dari sistem konfigurasi ke subsistem dan
tingkat terendah dikelola. Sebuah bagan struktur yang akurat dan lengkap adalah kunci untuk
penentuan item konfigurasi, dan representasi visual dari sistem konfigurasi dan antarmuka
internal. Selama proses konfigurasi kontrol, bagan struktur digunakan untuk mengidentifikasi
dan artefak yang terkait bahwa perubahan yang diusulkan dapat mempengaruhi.

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 : php
2.2. Komponen Stucture Chart
Produk dari Perancangan Terstruktur adalah Structure Chart yang memperlihatkan
komponen-komponen prosedural program, pengaturan hierarkinya dan data yang
menghubungkan komponen-komponen tersebut.
2.3. Model Bagan Terstruktur
Bagan terstruktur adalah mendefinisikan dan Mengilustrasikan Organisasi dari system
informasi secara berjenjang dalam bentuk modul dan submodul.
2.4. Elemen Struktur Chart Diagram terdiri dari :
1. Elemen data
2. Elemen control
3. Modul

3. TRANSFORMASI DFD KE STRUKTUR CHART DIAGRAM

 Untuk masalah sederhana pembuatan structure chart untuk menggambarkan
rancangan modul program dapat dilakukan tanpa harus memodelkan hasil
analisis terlebih dahulu.
 Tetapi untuk masalah yang cukup besar dan kompleks pembuatan rancangan
modul program harus dilakukan setelah hasil analisis selesai dimodelkan.

Tahap Pembuatan Structure Chart dari DFD :

1. Ubah diagram Konteks menjadi modul utama (top module) dari structure chart.
2. Ubah DFD level O menjadi modul-modul yang dipanggil oleh modul utama.
 3. Ubah DFD level rinci menjadi modul-modul lainnya sesuai dengan fungsinya
dengan pendekatan Transform Analysis dan atau Transaction Analysis.
4. Evaluasi dan perbaiki structure chart yang diperoleh dengan memperhatikan
coupling, cohesion dan lain-lain.

Transform Analysis
 Model aliran informasi yang digunakan untuk merancang program dengan mengenali
komponen-komponen fungsional utama serta masukan dan keluarannya.
 Dalam DFD sebuah transformasi direpresentasikan oleh sebuah jaringan yang berbentuk
linier.

 Untuk mengubah DFD berbentuk Transformasi dengan cara :

1. Bagi DFD menjadi tiga kelompok bagian yaitu bagian Input,pusat transformasi
dan keluaran.
2. Gambarkan bagian pusat transformasi, input dan output dari DFD masing-masing
sebagai sebuah komponen fungsional (Modul).
Tempatkan pusat transformasi atau komponen fungsional yang baru sebagai
modul pemanggil di level atas dari structure chart dan tempatkan yang lainnya di
level berikutnya sebagai modul yang akan dipanggil.
3. Tambahkan sub fungsi-fungsi yang dibutuhkan untuk setiap level untuk
melengkapi penggambaran structure chartnya.