ELEMEN PENDUKUNG IMPLEMENTASI IMK

BAB I

PENDAHULUAN

A.  Latar Belakang

Pada pembahasan sebelumnya, kita sudah mengetahui bagaimana interaksi manusia dan komputer. Tetapi dalam implementasinya kita tidak mengetahui alat pendukungnya. Karena pengetahuan kita terbatas untuk penggunaan saja atau hanya sebagai user saja. Untuk mengetahui bagaimana pendukung implementasi interaksi komputer dengan manusia, disini pemakalah akan membahas apa-apa saja yang terkait dengan alat atau elemen pendukung implementasi interaksi dan manusia.

B. Rumusan Masalah

Dari latar belakang di atas maka pemakalah membuat rumusan masalah sebagai berikut:

1.      Apa saja elemen sistem windows?

2.      Bagaimana pemograman aplikasinya?

3.      Bagaimana sistem manajemen user interfacenya?

C. Tujuan Penulisan

            Makalah ini di buat oleh pemakalah bertujuan untuk memberikan informasi tentang Komputer dalam berinteraksi dengan manusia,  yang mungkin sebagian dari mahasiswa atau mahasiswi belum mengetahui media pembelajaran ini tersebut.

D. Manfaat Penulisan

Hasil dari tulisan pemakalah, diharapkan dapat bermanfaat dan dapat pula menambah wawasan bagi para teman-teman, pemakalah dan para pembaca.

BAB II

PEMBAHASAN

Pembahasan ini tentang pendukung pemrograman yang disediakan untuk implementasi dari sebuah sistem yang interaktif.  Juga memberikan penjelasan bagi pengguna dalam membuat suatu sistem bantuan-help dan bagaimana membuat dokumentasi dari sistem.

A.    Elemen sistem windowing

Sistem Windowing merupakanpusat lingkungan untuk programmer dan penggguna dari sistem interaktif yang memungkinkan satu workstation  tunggal mendukung sistem-pengguna dengan aksi-aksi secara bersamaan. Sistem Windowing mengkordinasikan berbagai macam perangkat input-output.

·         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. Masing-masing 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 ketika daerah layar yang terlihat dari dua terminal abstrak saling tumpang tindih.

Arsitektur dari sistem windows :

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

Elemen-elemen Sistem Windowing itu sendiri adalah :

1.      Kemandirian perlengkapan (device independence)

a.       Pemrograman driver alat terminal abstrak.

b.      Input dan output untuk model image/graphic:

§  Pixel

§  PostScript (MacOS X, NextStep)

§  Graphical Kernel System (GKS)

§  Programmers’ Hierarchical Interface to Graphics (PHIGS)

2.      Berbagi-pakai sumber daya

a.       Mencapai tugas dari pengguna secara bersamaan.

b.      Sistem jendela mendukung proses mandiri.

c.       Isolasi dari aplikasi individual.

B.     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. Alur logika dari aplikasi client dalam pseudocode dan diagram adalah :

Repeat

read-event(myevent)

case myevent.type

type_1 :

                                    do type_1 processing

type_2 :

                                    do type_2 processing

                                    .

                                    .

type_n :

                                    do type_n processing

end case

end repeat

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.

Pada paradigma loop read-evaluation, ini langsung dikerjakan. Jika kesalahan dideteksi, aplikasi memulai loop read-evaluation yang ada dalam cabang statement case. Pada loop tersebut, semua event yang tidak relevan dapat diterima dan dihapus. Pseudocode nya adalah :

repeat

read-event(myevent)

case myevent.type

type_1 :

                                    do type_1 processing

type_2 :

                                     if (error-condition) then

                                    repeat

read-event(myevent2)

case myevent2.type

type_1 :

                                                .

type_n :

                                                end case

                                    until (end-condition2)

                                    end if

                                    …..

type_n :

                                    do type_n processing

end case

until (end-condition)

Pada paradigma berbasis notifikasi, dialog pre-empsi tidak sederhana, karena alur control diluar dari pemrogram aplikasi. Prosedur callback harus dimodifikasi semua untuk megenal situasi dimana dialog pre-empsi diperlukan dan pada situasi tersebut dihapus semua event yang dilewatkan kepadanya oleh notifier.

C.    Sistem Manajemen User Interface (UIMS)

UIMS adalah level akhir dari alat pendukung pemrograman. Memungkinkan desainer dan programmer mengkontrol hubungan antara obyek presentasi dari toolkit dengan fungsi semantiknya dalam aplikasi sebenarnya. UIMS menambahkan level di atas toolkit karena toolkit terlalu sulit untuk bagi yang bukan programmer. Dimungkinkan menggunakan UI Development System (UIDS), UI Builder, atau UI Development Environment (UIDE) sebagai arsitektur konseptual teknik implementasi dan dukungan. seperti Netbeans, Eclipse, Visual Studio, Delphi, dll.

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 :

·         Arsitektur konseptual untuk struktur dari system interaktif yang dikonsentrasikan pada pemisahan semantic aplikasi dan presentasi

·         Teknik untuk mengimplementasikan aplikasi dan presentasi secara terpisah 

·         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 :

Portability : agar aplikasi yang sama dapat digunakan di system yang berbeda maka membuat aplikasinya sebaiknya terpisah dari interface device-dependent-nya.

Reusability : pemisahan meningkatkan komponen untuk dapat digunakan kembali agar dapat mengurangi biaya.

Multiple interfaces : untuk meningkatkan fleksibilitas aplikasi yang interaktif, beberapa interface yang berbeda dibuat untuk mengakses fungsionalitas yang sama.

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 :

·         Presentasi : komponen bertanggungjawab atas tampilan interface, termasuk output dan input yang tersedia bagi user.

·         Control dialog : komponen mengatur komunikasi antara presentasi dan aplikasi.

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

Paradigma Model-View-Controller (MVC) menangani masalah Seeheim di atas. Pada pemrograman Smalltalk, link antara semantic aplikasi dan presentasi dapat dibangun dari tiga serangkai MVC ini. Smalltalk adalah system pemrograman berorientasi objek yang berhasil membangun system interaktif baru berdasarkan system yang sudah ada.

Model MVC menunjukkan semantic aplikasi, view menangani output grafik atau teks dari aplikasi dan pengontrol menangani input. Perilaku dasar dari model ini adalah view dan pengontrol ditempelkan/ dimasukkan dalam kelas objek umum dari Smalltalk yang diwariskan dari instant dan dimodifikasi.

Model Coutaz berikut merupakan system interaktif berasitektur multi-agent, disebut model Presentation-Application-Control (PAC). Model ini berbasis tiga serangkai pula, semantic aplikasi dilambangkan dengan komponen abstraksi, input dan output digabungkan dalam satu komponen presentasi dan ada komponen control eksplisit yang menangani dialog dan menghubungkan aplikasi dan presentasi.

Ada 3 perbedaan penting antara PAC dan MVC. Pertama adalah PAC menggabungkan input dan output, MVC memisahkannya. PAC menyediakan komponen eksplisit  yang tugasnya melihat kekonsistenan antara abstraksi dan presentasi, dimana MVC tidak menugaskan ke salah satu komponen. PAC tidak berhubungan dengan lingkungan pemrograman apapun, secara kondusif merupakan pendekatan berorientasi objek. Perbedaan yang terakhir ini yang membuat PAC mudah mengisolasi komponen control adalah PAC lebih merupakan arsitektur konseptual dibandingkan MVC karena kurang implementation-dependent.