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.