BAB II
PEMBAHASAN
PENDUKUNG IMPLEMENTASI
1. Elemen Sistem Windowing
Dua
sifat dari system window, kebebasan dari perangkat keras. Workstation khusus
akan berinteraksi dengan beberapa layar display visual, papan ketik dan
biasanya beberapa perangkat penunjuk seperti mouse. Keberagaman dari perangkat
keras ini dapat digunakan pada setiap system interaktif dan semuanya berbeda
dalam hal data yang dikomunikasikan dan perintah yang digunakan. Untuk itu,
pemrogram membutuhkan suatu perintah langsung ke suatu terminal abstrak yang
mengerti dengan bahasa yang generic dan dapat diterjemahkan ke bahasa dari
banyak perangkat khusus lainnya. Selain membuat tugas pemrograman lebih mudah,
terminal abstrak memungkinkan portabilitas dari program aplikasi. Hanya satu program
terjemahan – device driver – butuh dituliskan untuk perangkat keras khusus dan
kemudian setiap program aplikasi dapat mengaksesnya. Bahasa generik untuk
terminal abstrak pada system window disebut dengan imaging model, beberapa
diantaranya : pixels, graphical kernel system (GKS), programmer’s hierarchical
interface to graphics (PHIGS), postscript.
Sistem
window menyediakan kemampuan berbagi sumber dari satu konfigurasi perangkat
keras dengan beberapa salinan terminal abstrak. Masing2 terminal abstrak
berlaku sebagai proses bebas dan system window akan mengkoordinasikan control
dari proses yang ada. System window juga perlu untuk menampilkan aplikasi yang
terpisah dengan mendedikasikan daerah dari layar display ke setiap terminal
abstrak. Tugas koordinasi berhubungan dengan menyelesaikan konflik display
ketia daerah layar yang terlihat dari dua terminal abstrak saling tumpang
tindih.
DevicesBass
dan Coutaz mengidentifikasikan ada 3 arsitektur yang mungkin bagi perangkat
lunak untuk mengimplementasikan role dari system window. Semua ini diasumsikan
bahwa device driver terpisah dari program aplikasi. Pilihan pertama adalah
untuk mengimplementasikan dan replikasi manajemen dari proses yang multiple
dalam setiap aplikasi yang terpisah. Arsitektur ini tidak terlalu baik karena
mendorong setiap aplikasi untuk melihat masalah yang sulit dari penyelesaian
konflik sinkronisasi dengan perangkat hardware yang berbagi. Juga mengurangi
portabilitas dari aplikasi yang terpisah. Pilihan kedua adalah
mengimplementasikan aturan manajemen dalam kernel system operasi, memusatkan
tugas manajemen dengan membebaskan dari aplikasi individual. Aplikasi masih
harus dibangun dengan system operasi khusus. Pilihan ketiga adalah
portabilitas, fungsi manajemen ditulis sebagai aplikasi yang terpisah sehingga
dapat menyediakan interface ke program aplikasi lain yang generic terhadap
semua system operasi. Pilihan terakhir adalah model arsitektur client-server
seperti gambar di atas. Dalam prakteknya, pembagian dari arsitektur ini tidak terlalu
jelas dan setiap aplikasi interaktif atau kumpulan operasi aplikasi dalam
system window berbagi fitur dengan salah satu dari ketiga aritektur konseptual
tersebut. Sehingga, perlu ada satu komponen yaitu aplikasi atau proses yang
terpisah bersama dengan beberapa pendukung system operasi yang siap dan
pendukung aplikasi yang hand-tuned untuk menangani sumber bersama. Aplikasi
yang dibuat untuk system window yang berbasis pada model client-server tidak
terlalu portable. Contoh dari system window berbasis arsitektur client-server
adalah system window X release 11 standar industri X11, dibuat di MIT
pertengahan 1980an.
2.
Pemograman
Aplikasi
Aplikasi
yang interaktif umumnya user-driven, aksi aplikasi yang ada ditentukan oleh
input yang diterima dari user. Ada 2 paradigma pemrograman yang dapat digunakan
untuk mengorganisasikan alur control dalam aplikasi. Paradigma pertama adalah
Read-Evaluation Loop, yang internal terhadap program aplikasi itu sendiri.
Contoh pada pemrograman Macintosh. Server mengirim input user sebagai event
terstruktur ke aplikasi client. Fokus server yang penting adalah pada event
dari client yang harus diarahkan. Aplikasi client diprogram untuk membaca
setiap event yang melaluinya dan menentukan semua perilaku aplikasi khusus yang
menghasilkan respon. Aplikasi memiliki
control yang lengkap terhadap proses event yang diterima. Pemrogram harus
mengeksekusi control melalui setiap kemungkinan event yang client akan terima.
Pada macintosh, MacApp.
Paradigma
pemrograman lainnya adalah berbasis notifikasi, dimana loop control utama untuk
proses event tidak ada dalam aplikasi. Pusat notifier menerima event dari
system window dan menyaringnya ke program aplikasi dengan suatu program seperti
terlihat pada gambar di bawah. Program aplikasi menginformasikan ke notifier
event apa yang penting dan masing2 event mendeklarasikan satu prosedurnya
sebagai callback sebelum mengubah kontrolnya ke notifier. Ketika notifier
menerima event dari system window, terlihat jika event diidentifikasi oleh
program aplikasi maka notifier akan melewatkan event dan control ke prosedur
callback yang diregistrasi untuk event. Setelah pemrosesan, prosedur callback
mengembalikan control ke notifier, memberitahukan untuk melanjutkan event yang
diterima atau meminta diakhiri. Alur control terpusat di notifier yang
membebaskan program aplikasi dari proses yang terlalu banyak dari setiap proses
event yang lewat dari system window. Misalkan program aplikasi akan
menghasilkan kotak dialog pre-empsi dan menginginkan adanya konfirmasi dari
user sebelum diproses.
Dialog
pre-empsi menghapus secara efektif semua aksi user kecuali yang dibutuhkan user
untuk memperbaikinya.
3.
Sistim
Manajemen User Interface
Set
dari pemrograman dan teknik desain yang dapat menambah level lain dari servis
untuk desain system interaktif selain level toolkit adalah system manajemen
interface user (UIMS) ini. Focus utama dari UIMS :
1)
Arsitektur konseptual untuk struktur
dari system interaktif yang dikonsentrasikan pada pemisahan semantic aplikasi
dan presentasi
2)
Teknik untuk mengimplementasikan
aplikasi dan presentasi secara terpisah
3)
Teknik pendukung untuk menangani,
mengimplementasikan, dan mengevaluasi lingkungan interaksi yang sedang
berjalan.
UIMS sebagai arsitektur konseptual
Isu
utama adalah bagaimana memisahkan antara semantic aplikasi dan interface yang
tersedia bagi user. Banyak argument yang baik untuk mendukung pemisahan ini,
yaitu :
a) Portability
: agar aplikasi yang sama dapat digunakan di system yang berbeda maka membuat
aplikasinya sebaiknya terpisah dari interface device-dependent-nya.
b) Reusability
: pemisahan meningkatkan komponen untuk dapat digunakan kembali agar dapat
mengurangi biaya.
c) Multiple interfaces
: untuk meningkatkan fleksibilitas aplikasi yang interaktif, beberapa interface
yang berbeda dibuat untuk mengakses fungsionalitas yang sama.
d) Customization
: interface user dapat dikustom oleh desainer dan user untuk meningkatkan
keefektifan tanpa mengubah aplikasi.
Sekali
aplikasi dan presentasi dipisahkan, komunikasi antara keduanya perlu
dipertimbangkan, ini yang disebut sebagai control dialog. Secara konseptual, ada
3 komponen utama dari system interaktif – aplikasi, presentasi dan control
dialog.
Komponen
logika dari UIMS :
a.
Presentasi : komponen bertanggungjawab
atas tampilan interface, termasuk output dan input yang tersedia bagi user.
b.
Control dialog : komponen mengatur
komunikasi antara presentasi dan aplikasi.
c.
Interface aplikasi : pandangan dari
semantic aplikasi yang disediakan sebagai interface.
Model
Seeheim berikut memasukkan aplikasi dan user dalam konteks dari system
interaktif meskipun tidak secara eksplisit karena hanya memodelkan komponen
logika UIMS bukan system interaktif secara keseluruhan. Dengan tidak membuat
aplikasi secara eksplisit ada di model, control dialog eksternal perlu
diasumsikan. Dari sudut pandang pemrogram, model Seeheim ini sesuai dengan
adanya pembedaan antara lapis leksikal klasik, sintaksis dan semantic dari
system computer. Masalah utama dari model Seeheim ini adalah meskipun terlayani
baik pada akhirnya, tetapi tidak terlihat bagaimana arah sebenarnya dari
kemungkinan UIMS distrukturkan. Gambar tersebut menunjukkan alasan efisiensi
yang mungkin dengan dilewatkan/ dihindarkannya komponen control dialog secara
eksplisit sehingga aplikasi memberikan respon semantic aplikasi yang lebih
besar. Kotak kosong tersebut ada karena logika tidak dipisahkan dari
implementasi. Selain itu model Seeheim tidak menginformasikan bagaimana
membangun system interaktif yang besar dan kompleks dari komponen yang lebih
kecil.
BAB III
PENUTUP
1. Kesimpulan
Pendukung implementasi terdiri dari 4 yaitu:
1)
Elemen Sistem
Windowing
Dua sifat dari system window,
kebebasan dari perangkat keras. Workstation khusus akan berinteraksi dengan
beberapa layar display visual, papan ketik dan biasanya beberapa perangkat
penunjuk seperti mouse.
2) Pemograman
Aplikasi
Aplikasi yang interaktif umumnya
user-driven, aksi aplikasi yang ada ditentukan oleh input yang diterima dari
user.
3) User
Interface Management Systems (UIMS)
Set dari pemrograman dan teknik desain yang dapat menambah level lain
dari servis untuk desain system interaktif selain level toolkit adalah system
manajemen interface user (UIMS
2. Saran
Kami
menyadari dalam pembuatan makalah ini masih banyak kekurangan. Kami tetap
berharap makalah ini tetap memberikan manfaat bagi pembaca. Namun, saran dan
kritik yang sifatnya membangun dengan senang hati kami terima demi kesempurnaan
makalah kami di masa yang akan datang.
DAFTAR PUSTAKA
Santoso,
Insap. 2010.Interaksi Manusia dan
Komputer. Yogyakarta : ANDI OFFSET.
Tidak ada komentar:
Posting Komentar