BAB II PEMBAHASAN

10.1 Penstrukturan Sistem Fase Pertama kegiatan perancangan arsitektural biasanya berhubungan dengan penguraian sistem menjadi satu set subsistem yang berinteraksi. Pada tingkat yang paling abstrak, desain arsitektural dapat digambarkan sebagai diagram blok dimana setiap blok pada diagram merepresentasikan subsistem. Diagram blok arsitektural menggambarkan tinjauan terhadap stuktur sistem. Diagram ini biasanya dapat dipahami oleh berbagai perekayasa yang terlibat dalam proses pengembangan sistem. Gambar 10.1 dibawah ini, merupakan model struktural arsitektur untuk sistem robot pengepak. Sistem robotik ini mengepak berbagai benda. Sistem ini menggunakan subsistem visi untuk memilih benda pada ban berjalan, mengidentifikasi jenis benda tersebut, dan memilih pengepak yang sesuai. Sistem ini kemudian mengambil benda dari ban berjalan delivery untuk dipak. Benda yang telah dipak diletakkan pada ban berjalan lain. Sistem Visi

Sistem Identifikasi Objek

Kontroler Lengan

Kontroler Pemegang

Sistem Penyeleksian Pengepakan

Sistem Pengepakan

Kontroler Ban Berjalan

Gambar 10.1 Diagram Blok Sistem Kontrol Robot Pengepak

Bass dkk. (1998) menganggap bahwa diagram kotak dan garis sederhana bukan merupakan representasi arsitektur yang berguna karena tidak menunjukkan sifat hubungan antar komponen sistem maupun properti yang tampak eksternal. Dari sudut pandang perekayasa perangkat lunak hal ini benar sekali. Bagaimanapun juga, tipe model ini efektif untuk komunikasi dengan stakeholder dan untuk perencanaan proyek. Karena tidak dipenuhi dengan detail, stakeholder dapat memahaminya dan memahami tinjauan abstrak dar sistem. Diagram ersebut diatas mengidentifikasikan subsistem kunci yang dikembangkan secara independen sehingga manager dapat mulai memberi tugas pada orang-orang untuk merencanakan pengembangan sistem tersebut. Diagram kotak dan garis seharusnya bukan merupakan satu-satunya representasi arsitektural yang dipakai, namun demikian diagram ini merupakan satu dari sejumlah model arsitektural yang berguna. Model-model struktur yang lebih spesifik dapat dikembangkan, yang menunjukkan bagaimana subsistem memakai data bersama, bagaimana distribusinya dan bagaimana mereka ber-interface satu dengan yang lain. Tiga model standar ini yaitu model repositori, model client-server, dan model mesin abstrak. 10.1.1 Model Repositori (Media Penyimpanan) Subsitem-subsistem yang membentuk suatu sistem harus saling bertukar informasi sehingga dapat bekerja sam dengan efektif. Ada dua cara dasar di mana hal ini dapat dilakukan yaitu :
1. Semua data bersama disimpan pada database pusat sehingga dapat diakses

oleh semua subsistem. Model sistem database yang dipakai bersama kadangkadang disebut model repositori.
2. Setiap subsistem memelihara database sendiri. Data dipertukarkan dengan

subsisten lain dengan mengirimkan message kepada.

Mayoritas sistem yang memakai data dalam jumlah besar diorganisir database yang dipakai bersama atau repositori. Model ini dengan demikian cocok untuk aplikasi dimana data dibangkitkan oleh 1 subsistem dan dipakai oleh subsistem yang lain. Contoh tipe sistem ini mencakup sistem command dan Control, sistem manajemen informasi, sistem CAD, dan Toolset CASE. Gambar 10.2 dibawah ini, merupakan contoh arsitektur toolset CASE yang berdasarkan atas repositori yang dipakai bersama.

Editor Desain

Generator Kode

Penerjemah Desain

Repositori Proyek

Editor Program

Analisis Desain

Generator Laporan

Gambar 10.2 Arsitektur Toolset CASE yang Terintegrasi

Keuntungan dan kerugian dari repositori yang dipakai bersama adalah sebagai berikut : 1. Repositori yang dipakai bersama merupakan cara yang efisien untuk memakai banyak data secara bersama-sama. Dalam cara ini tidak perlu adanya transmisi secara eksplisit dari satu subsistem ke subsistem yang lainnya. 2. Subsistem harus menyetujui model data repositori. Jelas bahwa ini merupakan kompromi antara kebutuhan-kebutuhan khusus dari setiap alat bantu. Kinerja dapat terbalik terpengaruh oleh kompromi ini. Mungkin sulit

atau bahkan mustahil bagi kita untuk mengintegrasikan subsistem baru jika model datanya ridak sesuai dengan skema yang disetujui. 3. 4. Subsistem yang menghasilkan data tidak perlu mempermasalahkan bagaimana data dipakai oleh subsistem lain. Evolusi bisa jadi sulit karena informasi dengan volume besar dibangkitkan menurut model data yang disetujui. Penerjemahan model yang disetujui ini menjadi model yang baru dan tentu akan mahal, sulit atau bahkan tidak mungkin. 5. Tersentralisasinya kegiatan seperti backup, keamanan, kontrol akses, dan pemulihan dari eror. Kegiatan-kegiatan ini merupakan tanggung jawab manajer repositori. Alat bantu dapat memfokuskan diri pada fungsi utamanya dan tidak perlu mempertimbangkan isu-isu ini. 6. Subsistem yang berbeda dapat memiliki persyaratan yang berbeda untuk kebijakan keamanan, pemulihan, dan backup. Model repositori ini emaksakan kebijakan yang sama untuk semua susbsistem. 7. Model pemakaian bersama dapat terlihat melalui skema repositori. Integrasi alat bantu yang baru merupakan proses yang mudah jika alat tersebut kompatibel dengan model data yang disetujui. 8. Mungkin tidak akan mudah untuk emndistribusikan repositori ke sejumlah mesin. Walaupun mungkin dilakukan distribusi repositori yang tersentralisai secara logika, mungkin akan ada masalah dengan redundansi data dan ketidakkonsistenannya. Pada model diatas, repositori bersifat pasif dan kontrol merupakan tanggungjawab subsistem yang memakai repositori tersebut. Pendekatan alternatif telah diturunkan untuk sistem-sistem AI yang menggunakan model blackboard yang memicu subsistem ketika data tertentu telah tersedia. Pendekatan ini cocok jika bentuk data repositori yang ada kurang terstruktur dengan baik. Keputusan mengenai alat bantu yang mana yang aka diaktifkan hanya dapat dibuat ketika data telah dianalisa.

10.1.2 Model Client-Server Model arsitektural client server merupakan model sistem terdistribusi yang menunjukkan bagaimana data dan pemrosesan didistribusikan pada serangkaian prosesor. Komponen utama model ini adalah:
1. Satu set server stand-alone yang memberikan layanan ke subsistem lain.

Contoh server adalah print server yang menyediakan layanan pencetakan., file server yang menyediakan layanan manajemen file, dan compile server compile server yang menyediakan layanan kompilasi bahasa pemrograman.
2. Satu set klien yang meminta layanan yang diberikan oleh server. Klien-klien ini

biasanya adalah subsistem itu sendiri. Terdapat beberapa instance program klien yang dieksekusi secara bersamaan.
3. Satu jaringan yang memungkinkan pelanggan mengakses layanan-layanan.

Pada prinsipnya, hal ini tidak penting karena baik pelanggan maupun server dapat berjalan pada satu mesin. Akan tetapi, pada prakteknya, model ini tidak akan dipakai pada situasi seperti itu. Klien mungki harus tahu nama server-server yang tersedia dan layanan yang diberikan server Namun, server tidak perlu tahu identitas dari pelanggan, juga tidak perlu tahu berapa jumlah pelanggan. Pelanggan mengakses layanan yang disediakan server melalui panggilan prosedur jarak jauh (remote procedure call). Gambar 10.3 dibawah ini menunjukkan tentang contoh sistem yang dibangun sekitar model client-server . Ini merupakan sistem hiperteks multi-user untuk menyediakan perpustakaan foto dan video. Pada sistem ini ada beberapa server yang menangani dan menampilkan jenis media yang berbeda. Kerangka video harus ditransmisi dengan cepat dan sinkron tetapi dengan resolusi yang relatif rendah. Kerangka dapat dikompres dalam penyimpanannya. Namun demikian, gambar diam harus dikirim dengan resolusi tinggi. Katalog harus dapat menangani berbagai query

dan menyediakan link ke sistem informasi hiperteks. Program pelanggan merupakan inerface user terintegrasi bagi layanan-layanan ini.

Klien 1

Klien 1

Klien 1

Klien 1

Jaringan dengan Bandwidth Lebar

Server Katalog Katalog

Server Video File Klip Video

Server Gambar Foto Terdigitalisas i

Server Hiperteks Web Hiperteks

Gambar 10.3 Arsitektur Sistem Perpustakaan Film dan Gambar

Keuntungan yang paling penting dari model client-server adalah bahwa model ini merupakan arsitekstur yang terdistribusi. Pemakaian yang efektif dapat dilakukan pada sistem jaringan dengan banyak prosesor terdistribusi. Tidak sukar bagi pengguna untuk menambahkan server yang baru dan mengintegrasinya dengan sistem atau untuk mengupgrade server secara transparan tanpa mempengaruhi bagian lain dari sistem. 10.1.3 Model Mesin Abstrak Model mesin abstrak dari arsitektur (kadang-kadang disebut model berlapis) memodelkan interfacing subsistem. Model ini mengorganisir sistem menjadi serangkaian lapisan yang masing-masing menyediakan serangkaian layanan. Setiap lapisan mendefinisikan mesin abstrak yang bahasa mesinnya (layanan yang diberikan oleh lapisan tersebut) dipakai untuk mengimplementasikan tingkat berikutnya dari mesin abstrak tersebut. Sebagai contoh, cara umum untuk implementasi bahasa adalah

mendefinisikan bahasa mesin yang ideal dan mengkompilasi bahasa tersebut menjadi kode untuk mesin ini. Langkah penerjemahan berikutnya kemudian mengkonversikan kode mesin abstrak ini menjadi kode mesin yang sesungguhnya.

Manajemen Versi Manajemen Objek Sistem Sistem Database Operasi

Gambar 10.4 Model Mesin Abstrak dari Sistem Manajemen Versi

Contoh yang dikenal baik untuk pendekatan ini adalah model referensi OSI untuk protokol jaringan (Zimmermann, 1980) yang dibahas pada subbab 10.4. Untuk mendukung fasilitas manajemen konfigurasi ini, sistem manajemen versi memakai sistem manajemen objek yang menyedikan layanan penyimpanan informasi dan manajemen untuk objek. Sistem ini menggunakan sistem basis data untuk menyediakan penyimpanan data dan layanan yang dasar seperti manajemen transaksi, rollback dan pemulihan, dan kontrol akses. Manajemen basis data menggunakan fasilitas sistem operasi dan penyimpanan file yang mendasarinya pada implementasi.

10.2

Model Kontrol Model untuk penstrukturan sistem membahas bagaimana sistem diuraikan

menjadi subsistem-subsistem. Untuk bekerja sebagai suatu sistem, subsistem harus dikendalikan sehingga layanannya diberikan pada tempat dan waktu yang tepat. Model struktural tidak mencakup informasi kontrol. Sebaliknya, arsitek harus mengorganisir subsistem menurut model kontrol yang melengkapi model struktur yang dipakai. Model kontrol pada tingkat arsitektural berkenaan dengan aliran kontrol antara subsistem. Dua pendekatan umum terhadap kontrol dapat diidentifikasi :
1.

Kontrol tersentralisasi. Satu susbsistem memiliki tanggung jawab menyeluruh untuk kontrol, dan memulai serta menghentikan subsistem-subsistem lain. Subsistem tersebut juga dapat memindahkan kontrol ke subsistem lain tetapi menantikan tanggung jawab kontrol ini dikembalikan kepadanya.

2.

Kontrol berbasis-event. Bukan informasi kontrol yang disatukan dengan subsistem, melainkan setiap subsistem dapat menanggapi event yang dibangkitkan secara eksternal. Event-event ini dapat berasal dari subsistem lain atau dari lingkungan sistem.

Model kontrol melengkapi model struktural. Semua model struktural di atas dapat direalisasikan dengan memakai kontrol tersentralisasi atau berbasis event.

10.2.1 Kontrol Tersentralisasi Pada model kontrol tersentralisasi, satu subsistem ditujukan sebagai kontroler sistem dan memiliki tanggung jawab untuk mengatur eksekusi subsistem lainnya. Model kontrol tersentralisasi digolongkan dalam dua kelas, bergantung pada apakah susbsistem yang dikontrol berjalan secara sekuensial atau paralel.
1. Model call-return. Ini merupakan model subrutin top-down yang biasa,

dimana kontrol dimulai dari puncak hierarki subrutin dan melalui

pemanggilan subrutin, diteruskan ke tingkat-tingkat yang lebih bawah pada pohin tersebut. Model subrutin hanya dapat diterapkan pada sistem sekuensial.
2. Model manajer. Model ini dapat diterapkan pada sistem konkuren. Satu

komponen sistem ditujukan sebagai manajer sistem dan mengendalikan awal, akhir, dan koordinasi proses-proses sistem lainnya. Suatu proses merupakan satu subsistem atau modul yang dapat berjalan secara paralel dengan proses-proses lain. Suatu bentuk model ini juga dapat diterapkan pada sistem sekuensial diaman rutin manajemen memanggil susbsistem tertentu, bergantung pada nilai variabel status tertentu. Tipe ini biasanya diimplementasi sebagai statemen case.

Model call-return diilusikan pada Peraga 10.5. Program utama dapat memanggil Rutin 1, 2, dan 3. Selanjutnya rutin 1 dapat memanggil Rutin1.1 atau 1.2, Rutin 3 dapat memanggil Rutin 3.1 atau 3.2, dll. Ini merupakan model dinamika program. Model ini bukan merupakan model struktural; Rutin 1.1 misalnya tidak perlu menjadi bagian dari Rutin 1. Model yang biasa dikenal tergabung dalam bahasa pemrogramana seperti Ada, Pascal,dan C. Kontrol diteruskan dari rutin tingkat yang lebih tinggipada hierarki ke rutin tingkat yang lebih rendah. Kontrol kemudian kembali ke tempat dimana rutin tersebut dipanggil. Subrutin yang sedang berjalan memiliki tanggung jawab untuk kontrol dan dapat memanggil subrutin lain atau mengembalikan kontrol ke orang tuanya. Kembali ke tampat yang lain pada program merupakan gaya pemrograman yang buruk. Model call-return ini dapat dipakai pada tingkat modul untuk mengontrol fungsi atau objek. Subrutin pada bahasa pemrograman yang dipanggil oleh subrutin lain secara natural adalah fungsional. Namun demikian, pada banyak sistem berorientasi

objek, operasi pada objek (metode) diimplementasikan sebagai prosedur atau fungsi, sebagai contoh, ketika objek Java meminta layanan dari objek lain, objek Java melakukannya dengan memanggil metode yang berhubungan. Sifat ketat dan terbatas dari model ini merupakan kekuatan dan kelemahan. Merupakan kekuatan karena relatif sederhana untuk menganalisa aliran kontrol dan mengetahui bagaimana sistem akan menaggapi input tertentu, merupakan kelemahan karena sebagaimana telah dibahas sebelumnya, eksepsi terhadap operasi normal tidak mudah ditangani.

Program utama

Rutin 1

Rutin 2

Rutin 3

Rutin 1.1

Rutin 1.2

Rutin 3.1

Rutin 3.2

Gambar 10.5 Model Kontrol Call-return

Proses Sensor

Proses aktuator

Kontroler sistem

Proses komputasi

Interface user

Penanganan kesalahan

Gambar 10.6 Model Kontrol Tersentralisasi untuk Sistem Waktu Nyata

Peraga 10.6 merupakan ilustrasi model manajemen tersentralisasi dari kontrol untuk sistem konkuren. Model ini sering digunakan pada sistem real-time soft yang tidak memiliki batas waktu yang ketat. Kontroler pusat menangani eksekusi serangkaian proses yang berhubungan dengan sensor dan aktuator. Sistem monitoring pembangunan dibahas pada bahasan selanjutnya dengan mengikuti model kontrol ini. Proses kontroler sistem memutuskan kapan proses harus dimulai atau dihentikan., tergantung pada variabel status sistem. Proses ini memeriksa apakah proses lain telah menghasilkan informasi yang akan diolah atau meneruskan informasi ke proses-proses lain untuk perubahan event atau status. Dengan alasan ini, model ini kadang-kadang disebut juga model event-loop.

10.2.2 Sistem Event-driven (dikendalikan-event) Pada model kontrol tersentralisasi, keputusan kontrol biasanya ditentukan olen nilai beberapa variabel status sistem. Untuk lebih jelasnya, model kontrol event-driven dikendalikan oleh event yang dibangkitkan secara eksternal. Istilah event pada konteks tidak hanya berarti sinyal biner. Event bisa merupakan sinyal yang dapat mengambil nilai berapapun. Perbedaan antara event dan input yang sederhana adalah bahwa timing event berada di luar kontrol proses yang menangani event tersebut. Suatu subsistem mungkin perlu mengakses informasi status untuk menangani event-event ini tetapi informasi status ini tidak biasanya menentukan aliran kontrol. Ada berbagai variasi tipe sistem event-driven yang dapat dikembangkan. Variasi ini mencakup : spreadsheet dimana perubahan nilai suatu sel menyebabkan sel lain dimodifikasi, sistem produksi yang berdasarkan aturan seperti digunakan pada AI di mana suatu kondisi yang menjadi bernilai benar menyebabkan suatu aksi diaktifkan, dan objek-objek aktif dimana perubahan nilai atribut objek mengaktifkan beberapa aksi. Garlan et al. membahas tipe-tipe sistem yang berbeda ini. Pada subbab ini, akan dibahas dua model kontrol event-driven:
1. Model broadcast. Pada model-model ini, suatu event, pada prinsipnya

melakukan penyiaran event ke semua subsitstem. Setiap subsistem yang dapat menangani event ini akan menanggapinya.

Subsistem 1

Subsistem 2

Subsistem 3

Subsistem 4

Penanganan (Handler) event dan message

Gambar 10.6 Model Kontrol yang Berdasarkan pada Broadcasting Selektif

2. Model interrupt-driven. Model ini digunakan secara eksklusif pada sistem

real-time dimana interupt eksternal dideteksi oleh sebuah interrupt handler (penangan interupt). Interupt-interupt ini kemudian diteruskan ke komponen lain untuk diolah.

Model broadcast efektif dalam mengintegrasikan subsistem yang terdistribusi melintasi komputer-komputer pada suatu jaringan. Model interrupt-driven dipakai pada sistem real-time dengan persyaratan timing yang ketat. Pada model broadcast, subsistem menyatakan ketertarikan pada suatu event. Keyika event ini terjadi, kontrol ditransfer ke subsistem yang dapat menangani event tersebut. Perbedaan antara model ini dan model tersentralisasi yang ditunjukkan pada Peraga 10.6 adalah tidak disatukannya kebijakan kontrol pada event dan message handler. Subsistem memutuskan event mana yang mereka butuhkan dan event dan message handler menjamin bahwa event-event ini dikirimkan ke subsistem. Semua event dapat disebarkan ke semua subsistem tetapi hal ini menimbulkan overhead pemrosesan yang benar. Event handler mendeteksi event ini, berkonsultasi dengan register event dan meneruskan event ke subsistem yang telah menyatakan minat. Event handler biasanya juga mendukung komunikasi point-in-point. Softbench dan Field environtmenttelah dipakai untuk mengendalikan interaksi alat bantu pada lingkungan rekayasa perangkat lunak. Perantara permintaan objek juga mendukung model kontrol ini untuk komunikasi objek terdistribusi.

Keuntungan pendekatan broadcast ini ialah bahwa evolusinya relatif mudah. Suatu subsistem baru untuk menangani kelas event tertentu dapat diintegrasikan dengan menyatakan eventnya dengan event handler. Subsistem dapat diimplementasikan pada mesin terdistribusi. Distribusi ini transparan terhadap subsistem lainnya. Kerugian model ini ialah bahwa subsistem tidak mengetahui jika atau kapan event akan ditangani. Ketika suatu subsistem membangkitkan event, subsistem tidak mengetahui subsistem mana yang telah mencatatkan minat terhadap event tersebut. Hal ini dapat mengakibatkan konflik ketika hasil penanganan event telah tersedia. Interupt-interupt

Vektor interupt

Handler 1

Handler 2

Handler 3

Handler 4

Proses 1

Proses 2

Proses 3

Proses 4

Gambar 10.8 Modul Kontrol Interupt-driven

Sistem real-time yang menuntut event-event yang dibangkitkan secara eksternal ditangani dengan sangat cepat harus merupakan sistem yang event-driven. Sebagai contoh, jika sistem real-time dipakai untuk mengendalikan sistem keselamatan pada

sebuah mobil, sistem tersebut harus mendeteksi kemungkinan tabrakan dan mungkin menggembungkan kantung idara tepat sebelum kepala pengemudi mengenai setir. Ada sejumlah tipe interrupt yang diketahui yang didefinisikan handler untuk setiap tipenya. Setiap tipe interrupt dihubungkan dengan lokasi memori dimana alamat handler disimpan. Handler interrupt ini kemudian dapat memulai atau menghentikan proses lain sebagai tanggapan terhadap event yang disinyalkan oleh interrupt tersebut. Keuntungan pendekatan untuk kontrol ini adalah dimungkinkannya tanggapan yang sangat cepat terhadap event yang akan diimplementasi. Kerugiannya ialah bahwa pemrograman menjadi kompleks dan validasi menjadi sulit. Bisa jadi tidak mungkin dilakukan replikasi pola timing interrupt pada proses pengujian sistem. Sistem yang dikembangkan dengan model ini bisa sulit diubah jika jumlah interrupt dibatasi oleh perangkat keras. Begitu batas ini dicapai, tidak ada tipe event lain yangdapat ditangani. Pembatasan ini kadang-kadang dapat dielakkan dengan memetakan beberapa tipe event pada suatu interrupt, kemudian membiarkan handler menentukan sendiri event apa yang telah terjadi. 10.3 Dekomposisi Modular Setelah arsitektur struktural selesai dirancang, tahap berikutnya dari proses perancangan arsitektural adalah penguraian (dekomposisi) subsistem menjadi modulmodul. Komponen pada modul biasanya lebih kecil daripada subsistem dan hal ini memungkinkan digunakannya model dekomposisi alternatif.

Ada dua model yang dapat digunakan ketika menguraikan subsistem menjadi modul, yaitu sebagai berikut : 1. Model berorientasi objek Pada model ini sistem siuraikan menjadi serangkaian objek yang berkomunikasi. Modul adalah objek dengan status privat, dan operasi yang didefinisikan pada status tersebut. 2. Model aliran data Pada model aliran data, sistem diuraikan menjadi modul-modul fungsional yang menerima data input dan mentransformasikannya dengan suatu cara menjadi data output. Ini juga disebut dengan pendekatan pipeline. Pada model ini, modul merupakan transformasi fungsional.

Pada kedua kasus di atas, modul dapat diimplementasikan sebagai komponen sekuensial atau sebagai proses. Desain sistem konkuren sedapat mungkin harus dihindari, karena dengan begitu didapatkan keuntungan yaitu program sekuensial lebih mudah dirancang, diimplementasi, diverifikasi, dan diuji dibandingkan dengan sistem paralel. Yang paling baik adalah jika kita menguraikan sistem menjadi modul-modul, kemudian memutuskan pada saat implementasi apakah kebutuhan eksekusi ini sekuensial atau paralel.

10.3.1 Model Objek Suatu model berorientasi objek dari arsitektur sistem menstruktur sistem menjadi serangkaian objek yang terhubung longgar dengan interface yang terdefinisi dengan baik. Objek memanggil layanan yang diberikan oleh objek lain.

Gambar 10.9 merupakan contoh model arsitektural berorientasi objek untuk sistem pemrosesan faktur. Sistem ini dapat mengeluarkan faktur untuk pelanggan, menerima pembayaran, mengeluarkan resi untuk pembayaran ini dan bisa berfungsi sebagai pengingat faktur-faktur yang tidak dibayar.
Pembuatan Kuitansi faktur# tanggal jumlah pelanggan#

Pelanggan pelanggan# nama alamat periode kredit

Pemfakturan faktur# tanggal jumlah pelanggan keluarkan () kirimkan Pengingat () terima Bayaran () kirim Kuitansi ()

Pembayaran invoice# tanggal jumlah pelanggan#

Gambar 10.9 Model objek sistem pemrosesan faktur (invoice)

Pada model di atas, digunakan notasi UML, dimana kelas objek memiliki nama dan serangkaian atribut yang berhubungan. Operasi, jika ada, didefinisikan pada bagian bawah persegi panjang dengan sudut bulat yang merepresentasikan objek. Tanda panah putus-putus menunjukkan bahwa suatu objek memakai atribut atau layanan yang disediakan oleh objek lain. Dekomposisi berorientasi objek membahas kelas objek, atribut, dan operasinya. Ketika diimplementasi, objek dibuat dari kelas-kelas ini dan suatu model kontrol digunakan untuk mengkoordinasikan operasi objek, yang dalam contoh di atas adalah

kelas

invoice

yang

memiliki

berbagai

operasi

yang

berhubungan

yang

mengimplementasi fungsionalitas sistem. Kelas ini menggunakan kelas lain yang merepresentasikan pelanggan, pembayaran, dan resi. Keuntungan pendekatan berorientasi objek antara lain adalah karena objekobjek terkopel (coupled) secara longgar, maka implementasi objek dapat dimodifikasi tanpa mempengaruhi objek lainnya, struktur sistem dapat langsung dimengerti karena objek seringkali merupakan representasi dari entitas di dunia nyata, objek dapat dipakai ulang, dan bahasa pemrograman berorientasi objek telah dikembangkan dengan memberikan implementasi langsung dari komponen-komponen arsitektural. Sedangkan kekurangan dari pendekatan ini diantaranya adalah objek harus mengacu nama dan interface ke objek lain dengan eksplisit, efek perubahan interface pada semua user objek yang berubah harus dievaluasi, dan entitas yang lebih kompleks kadang sulit untuk direpresentasikan sebagai objek. 10.3.2 Model Aliran Data Pada model aliran data (data-flow), transformasi fungsional memproses input dan menghasilkan output. Data mengalir dari satu ke yang lainnya dan ditransformasikan ketika menelususri rangkaian tersebut. Setiap langkah pemrosesan diimplementasi sebagai transformasi. Data input mengalir melalui transformasitransformasi ini sampai dikonversi menjadi output. Transformasi dapat dijalankan secara sekuensial atau paralel. Data dapat diproses oleh setiap transformasi, item demi item atau dalam satu batch. Jika transformasi direpresentasikan sebagai proses yang terpisah, model ini kadang kala disebut model pipa (pipe) dan filter, mengikuti istilah yang dipakai pada sistem Unix, dimana disediakan pipa yang berfungsi sebagai penyalur data dan serangkaian command yang merupakan transformasi fungsional. Istilah filter dipakai karena transformasi menyaring data yang dapat diprosesnya dari aliran data input. Ketika transformasi bersifat sekuensial dengan data diproses dalam batch, model arsitektural, model arsitektural ini merupakan model sekuensial batch. Ini

merupakan arsitektur umum untuk beberapa kelas sistem pemrosesan data seperti sistem pembuatan tagihan, yang membangkitkan laporan output dalam jumlah banyak dari komputasi sederhana atas record input dalam jumlah banyak.

Keluarkan Kuitansi Baca faktur yang dikeluarkan Identifikasi Pembayaran Cari batas pembayara n Faktur Pembayara n

Kuitansi (Resi)

Keluarkan pengingat faktur

Pengingat

Gambar 10.10 Model Aliran Data Sistem Pemrosesan Faktur

Contohnya ditunjukkan pada Gambar 10.10. Sebuah organisasi telah mengeluarkan faktur kepada pelanggan. Sekali seminggu pembayaran yang telah dilakukan depasangkan dengan fakturnya. Untuk faktur yang telah dibayar, diberikan suatu resi. Untuk faktur yang belum dibayar dalam waktu yang diberikan, dikeluarkan peringatan. Keuntungan arsitektur ini adalah sebagai berikut : 1. Arsitektur ini mendukung pemakaian ulang transformasi 2. Arsitektur ini intuitif dalam artian bahwa banyak orang menganggap pekerjaan mereka sebagai proses input dan output 3. Mengubah sistem dengan menambahkan transformasi baru biasanya tidak berbelit-belit 4. Arsitektur ini mudah diimplementasikan sebagai sistem konkruen maupun sekuensial Kekurangan utama dari model ini berakar dari kebutuhan akan format umum untuk transfer data yang dapat dikenali semua transformasi. Setiap transformasi harus sesuai dengan transformasi yang berkomunikasi dengannya mengenai format data yang diproses, atau ditetapkan format standar untuk semua data yang dikomunikasikan. Pada

Unix, format standar merupakan rangkaian karakter. Setiap transformasi harus menguraikan inputnya dan menggabungkan outputnya menjadi bentuk yang telah disetujui. Hal ini menambah overhead sistem dan bisa berarti bahwa kita tidak mungkin mengintegrasikan transformasi yang memakai format data yang tidak kompatibel. Sistem interaktif sulit ditulis dengan menggunakan model aliran data karena adanya kebutuhan akan aliran data yang akan diproses. Kalau input dan output tekstual yang sederhana dapat dimodelkan dengan cara ini, interface user grafis memiliki format I/O dan kontrol yang lebih rumit yang didasarkan pada event seperti pengeklikan mouse atau pemilihan menu. 10.4 Arsitektur Spesifik Domain Model-model arsitektural di atas adalah model umum. Model-model tersebut dapat diterapkan pada banyak kelas aplikasi. Selain model umum, model-model arsitektural yang spesifik bagi suatu domain aplikasi juga dapat digunakan. Walaupun contoh sistem ini berbeda dalam detailnya, struktur arsitektural umu dapat dipakai ulang ketika mengembangkan sistem baru. Model arsitektural ini disebut arsitektur spesifik domain. Ada dua model arsitektur spesifik model:
1. Model generik. yang merupakan abstraksi dari sejumlah sistem riil. Model ini

meng-enkapulasi karakteristik utama dari sistem-sistem ini. Sebagai contoh, pada sistem real-time, mungkin ada model arsitektural generik dari berbagai sistem seperti sistem pengumpulan data, sistem monitoring, dsb.
2. Model refensi. yang merupakan abstrak dan mendeskripsikan kelas sistem yang

lebih besar. Model-model ini merupakan cara menginformasikan kepada perancang mengenai struktur umum kelas sistem tersebut. Sebagai contoh, Rockwell dan Gera (1993) telah mengusulkan model referensi untuk pabrik perangkat lunak.

Model referensi biasanya dipakai untuk mengkomunikasikan konsep domain dan membandingkan arsitektur yang mungkin, sedangkan model generik dapat digunakan ulang secara langsung pada suatu desain. Hal ini merefleksikan asal model-model ini. Model generik biasanya diturunkan secara bottom-up dari sistem yang sudah ada, sedangkan model referensi diturunkan secara top-down. Model-model ini merupakan representasi sistem abstrak. Model referensi tidak harus merefleksikan arsitektur yang sebenarnya dari sistem yang ada pada domain.

10.4.1 Model Generik Yang mungkin merupakan contoh yang paling terkenal dari model arsitektural generik adalah model compiler. Beribu-ribu compiler telah ditulis. Saat ini telah diakui secara umum bahwa compiler harus mencakup modul-modul berikut ini :
1. Penganalisa leksikal. Yang mengambil token bahasa input dan mengubahnya

menjadi bentuk internal tertentu.

2. Tabel simbol. Dibuat oleh penganalisa leksikal, yang menyimpan informasi

mengenai nama dan tipe yang dipakai pada program.

3. Penganalisa sintaks. Yang memeriksa bahasa yang dikompilasi. Penganalisa ini

menggunakan grammar yang terdefinisi dari bahasa tersebut dan membuat pohon sintaks.
4. Pohon sintaks. Merupakan struktur internal yang merepresentasikan program

yang dikompilasi.

Tabel Simbol

Analisis leksikal

Analisis sintaksis

Analisis semantik

Pembangkitan kode

Gambar 10.11 Model Aliran Data Compiler

5. Penganalisa semantik yang memakai informasi dari pohon sintaks dan tabel

simbol untuk memeriksa kebenaran semantik program input.

6. Generator kode yang menjalani pohon sintaks dan membangkitkan kode

mesin.

Komponen-komponen lain juga mungkin dicakup, yang mentranformasikan pohon sintaks untuk memperbaiki efisiensi dan membuang redundansi dari kode mesin yang dibangkitkan. Komponen-komponen yang membentuk compiler dapat diorganisasikan menurut model arsitektural yang berbeda. Sebagaimana ditunjukkan oleh Garlan dan Shaw (1993), compiler dapat diimplementasikan dengan memakai kode komposit. Arsitektur aliran data dapat digunakan, dengan tabel simbol berfungsi sebagai repositori untuk data yang dipakai bersama. Fase analisis lesikal, sintaktik, dan semantik diatur secara sekuensial seperti ditunjukkan pada peraga 10.11. Model ini masih digunakan secara luas. Model ini efektif dalam lingkungan batch dimana program dikompilasi dan dieksekusi tanpa interaksi user. Namun demikian, model ini kurang efektif jika compiler diintegrasi dengan alat bantu pemrosesan bahasa lain seperti sistem edit terstruktur, debugger interaktif, program

pretty printer, dll. Komponen-komponen sistem generic dengan demikian dapat diorganisasikan pada model berbasiskan repository sebagaimana ditunjukkan pada peraga 10.12. Pada model compiler ini, tabel simbol dan pohon sintaks berfungsi sebagai repositori informasi sentral. Alat bantu atau bagian alat bantu berkomunikasi melalui repositori tersebut. Informasi lain seperti definisi grammar (tatabahasa) dan definisi format output untuk program telah dikeluarkan dari alat bantu dan dimasukkan ke dalam repositori.

Analis leksikal

Analis sintaks

Analis semantik

Prettyprinter

Pohon sintaks abstrak

Definisi grammar

Pengoptima si

Editor

Tabel simbol

Definisi output

Generator kode

Gambar 10.12 Model Repositori Sistem Pemrosesan Bahasa

Namun demikian, model generik spesifik domain yang tersedia secara umum masih relatif sedikit. Organisasi yang mengembangkan model ini melihatnya sebagai

property intelektual yang berharga, yang mereka perlukan untuk pengembangan sistem selanjutnya. Model-model ini sering merepresentasikan arsitektur jalur produksi dimana dimana produk yang berhubungan diimplementasikan dengan menggunakan arsitektur dasar yang sama. Sebagai contoh, driver printer untuk printer dengan kemampuan yang berbeda (kecepatan, pilihan kertas, dll.) semuanya dapat menggunakan arsitektur dasar yang sama.

10.4.2 Arsitektur Referensi Model arsitektural generic merefleksikan arsitektur sistem yang ada. Sebaliknya, model referensi biasanya diturunkan dari studi domain aplikasi. Model ini merepresentasikan arsitektur yang ideal yang mencakup semua fitur yang dapat dimiliki sistem. Arsitektur referensi dapat digunakan sebagai dasar implementasikan sistem. Ini merupakan tujuan di balik model referensi OSI (Zimmermann, 1980) untuk interkoneksi sistem terbuka. Model tersebut ditujukan sebagai standar. Jika suatu sistem mengikuti suatu model, seharusnya sistem dapat berkomunikasi dengan sistem lain yang mengikuti model tersebut. Dengan demikian, sistem kontrol stok pada supermarket yang mengikuti model OSI dapat bertukar data langsung dengan sistem pemesanan pemasok. Namun demikian, model referensi biasanya tidak boleh dianggap sebagai rute untuk implementasi. Melainkan, fungsi utamanya adalah untuk berperan sebagai cara membandingkan sistem berbeda pada domain. Model referensi menyediakan vocabulary (kosakata) unutuk perbandingan. Model ini berfungsi sebagai standar, terhadap apa sistem dapat dievaluasi. Model OSI merupakan model tujuh lapis untuk interkoneksi sitem terbuka. Model ini diilustrasikan pada peraga 10.13. Fungsi yang tepat dari berbagai lapisan tidaklah penting disini. Pada intinya, lapisan bawah berkaitan dengan interkoneksi fisik, lapisan tengah berkaitann dengan transfer data, dan lapisan atas berkaitan dengan transfer informasi aplikasi yang bermakna secara semantic seperti dokumen standar, dsb. Perancang model OSI mempunyai tujuan yang sangat praktis dalam mendefinisikan standar, sehingga sistem yang mengikutinya dapat berkomunikasi satu sama lain. Setian lapisan seharusnya hanya bergantung pada lapisan di bawahnya.

Dengan berkembangnya teknologi, suatu lapisan dapat diimplementasi ulang secara transparan tanpa mempengaruhi sistem yang memakai lapisan yang lain. Namun demikian, pada prakteknya, masalah pendekatan berlapis terhadao permodelan arsitektural telah melakukan kompromi denga tujuan ini. Karena adanya perbedaan yang besar antarjaringan, interkoneksi yang sederhana mungkin saja tidak dapat dibuat. Walaupun karakteristik fungsional setiap lapisan berfungsi sangat baik, karakteristik non-fungsionalnya tidaklah didefinisikan. Pengembang sistem harus mengimplementasikan fasilitas tingkat tinggi mereka sendiri dan melompati lapisanlapisan pada model. Kalau tidak, mereka harus merancangfitur non-standar untuk memperbaiki kinerja sistem. Sebagai konsekuensinya, penggantian yang transparan dari lapisan pada model hamper tidak pernah mungkin dilakukan. Akan tetapi, hal ini tidak menegatifkan kegunaan model karena model ini memberikan dasar bagi penstrukturan abstrak dan implementasi sistematis dari komunikasi antara sistem. Model referensi lain yang telah diusulkan mencakup model untuk lingkungan CASE (ECMA, 1991) dan model untuk pabrik pernagkat lunak (Rockwell dan Gera, 1993). Beberapa pola desain (Gamma et.al, 1995) juga dapat dianggap sebagai arsitektur referensi.
7 6 5 4 3 2 1

Aplikasi Presentasi Sesi Transport Network Link data Fisik Network Link data Fisik Medium komunikasi

Aplikasi Presentasi Sesi Transport Network Link data Fisik

Gambar 10.13 Arsitektur Model Referensi OSI