Bab II Landasan Teori

Bab II Landasan Teori

II.1

Rekayasa Domain

Domain adalah bidang pengetahuan yang (1) dibatasi untuk memaksimumkan kepuasan pihak-pihak yang berkepentingan, (2) memasukkan sekumpulan konsep dan terminologi yang dipahami oleh praktisi-praktisi di bidang itu, dan (3) memasukkan pengetahuan bagaimana membangun sistem-sistem perangkat lunak (atau bagian-bagian dari sistem-sistem perangkat lunak) di bidang itu. Domain dari sistem dapat dibagi menjadi dua jenis yaitu domain dari sistem dan domain dari bagian sistem (subsistem).

Jenis pertama dari domain disebut

sebagai domain vertikal (misalnya domain sistem medical record, domain sistem finansial, dan lain-lain.)

dan jenis kedua disebut sebagai domain horisontal

(misalnya sistem basis data, pustaka kode numerik, dan lain-lain.) Rekayasa domain adalah aktivitas mengumpulkan, mengorganisasikan, dan menyimpan pengalaman dalam membangun sistem-sistem atau bagian-bagian dari sistem-sistem pada domain tertentu dalam bentuk aset-aset yang dapat digunaulang (reuse) yaitu produk-produk yang dapat digunaulang, juga menyediakan sarana-sarana yang memadai untuk menggunaulang aset-aset ini (yaitu kualifikasi, penyebaran, adaptasi, perakitan, dan sebagainya) ketika membangun sistem-sistem baru. Rekayasa domain terdiri dari tiga tahap [1]: 1. Analisis

domain

(domain

analysis),

mendefinisikan

sekumpulan

kebutuhan yang dapat digunaulang untuk sistem-sistem di domain. Analisis domain mengidentifikasi lingkup, fitur-fitur, dan titik-titik variasi sistem. 2. Perancangan domain (domain design), menetapkan satu arsitektur yang umum (common) untuk sistem-sistem pada satu domain. 3. Implementasi domain (domain implementation), mengimplementasi asetaset yang dapat digunaulang misalnya framework, komponen-komponen, 4

bahasa spesifik domain, generator-generator, dan infrastruktur yang dapat digunaulang (reusable) . Rekayasa domain dapat diterapkan untuk berbagai permasalahan, seperti pengembangan framework, pustaka-pustaka komponen, bahasa spesifik domain, dan generator-generator.

Gambar II.1 Rekayasa Domain [1] Rekayasa aplikasi (application engineering) adalah proses membangun sistemsistem kongkret berbasis pada hasil rekayasa domain. Selama analisis untuk sistem-sistem baru, pengembang memanfaatkan model domain dan memilih kebutuhan-kebutuhan (fitur-fitur) dari model domain yang memenuhi.

II.1.1 Analisis Domain Analisis domain merepresentasikan pendekatan sistematik untuk mengidentifikasi lingkup, fitur-fitur, dan titik-titik variasi pada domain. Analisis domain tidak 5

hanya mengidentifikasi fitur-fitur relevan yang tampak tapi juga fitur-fitur relevan yang masih merupakan potensi sedini mungkin. Pengetahuan mengenai fitur-fitur yang direncanakan dan yang masih potensi merupakan syarat untuk memperoleh rancangan yang tangguh untuk diadaptasi dan diperbesar (scale up). Tujuan utama dari analisis domain adalah [1] : 

Memilih domain dan menetapkan fokus, dan



Mengumpulkan informasi domain yang relevan dan mengintegrasikan ke dalam domain model yang koheren.

Sumber informasi domain dapat berasal dari sistem yang ada di domain itu sendiri, pakar-pakar pada domain tersebut, buku-buku pegangan tentang sistem, prototipe, eksperimen, dan sebagainya. Analisis domain adalah pemodelan. Pemodelan fitur bertujuan menangkap kesamaan (commonalities) dan keberagaman (variabilities) dalam abstraksi level tinggi, tidak terikat mekanisme dan teknologi implementasi. Model fitur (feature model) merepresentasikan aspek konfigurasi perangkat lunak gunaulang pada level lebih abstrak.

II.1.2 Perancangan Domain Perancangan domain bertujuan untuk mengembangkan arsitektur generik untuk seluruh sistem di satu domain (satu keluarga sistem), dan rancangan-rancangan yang akan diimplementasikan seperti (1) arsitektur generik satu keluarga sistem, (2) rancangan komponen-komponen

implementasi elementer dan

(3) DSL

(Domain Specific Language) Perancangan domain menghasilkan arsitektur untuk memperoleh struktur yang luwes yang memenuhi semua kebutuhan dan tetap memberikan tingkat kebebasan yang besar untuk implementasi. Arsitektur untuk satu keluarga sistem harus lebih luwes karena harus mencakup himpunan-himpunan kebutuhan sistem-sistem berbeda di satu keluarga sistem. Arsitektur satu keluarga sistem harus memasukkan representasi eksplisit keberagaman yang dicakup sehingga 6

arsitektur-arsitektur kongkret dapat dikonfigurasi berbasis himpunan-himpunan kebutuhan yang spesifik. Salah satu cara untuk menangkap variabilitas adalah dengan menyediakan bahasa konfigurasi spesifik domain untuk menspesifikasikan arsitektur (struktur) yang dapat dikonfigurasikan. DSL adalah bahasa berorientasi persoalan. DSL menawarkan cara yang jelas dalam mengekspresikan konsep-konsep spesifik domain yang kompleks dan membuat perangkat lunak yang lebih mudah berubah, dan secara signifikan meningkatkan produktivitas pengembang [2]. Penggunaan bahasa spesifik domain meningkatkan level abstraksi dengan menspesifikasikan solusi secara langsung menggunakan konsep-konsep domain persoalan. Produk-produk akhir kemudian dibangkitkan dari spesifikasi level tinggi ini. Masing-masing bahasa spesifik domain fokus pada domain tertentu

yang memungkinkan otomatisasi dan

mempermudah pendefinisian.

II.1.3 Implementasi Domain Selama implementasi domain, pengembang menerapkan teknologi-teknologi yang cocok untuk mengimplementasi komponen-komponen elementer dan bahasa konfigurasi spesifik domain. Bahasa konfigurasi spesifik domain dapat diimplementasikan dengan satu deret =. Pengembang aplikasi hanya perlu membuat deret = untuk menspesifikasi komponen-komponen dan/atau sistem yang dikehendaki.

II.2

Pemodelan Fitur

Pada analisis domain, keberagaman dapat diekspresikan dengan pemodelan fitur (feature

modeling)

[1].

Pemodelan

fitur

adalah

teknik

utama

untuk

mengidentifikasi dan menangkap keberagaman. Pemodelan fitur adalah aktivitas pemodelan properti-properti yang umum (common) dan beragam (variable), serta kebergantungan-kebergantungannya dan mengorganisasikan properti-properti itu dalam satu model yang koheren yang disebut model fitur. Model fitur adalah representasi yang kompak (compact) dari semua sistem yang dimungkinkan pada satu keluarga sistem[1]. Model fitur digunakan untuk memodelkan sekumpulan sistem dalam fitur-fitur dan hubungan-hubungan di

7

antara fitur-fitur itu. Merancang sistem perangkat lunak dalam istilah-istilah fiturfitur lebih alami dibanding dalam istilah-istilah objek-objek atau kelas-kelas. Sistem perangkat lunak disusun dan sekumpulan fitur-fitur. Pada model fitur, properti-properti kualitatif konsep direpresentasikan dengan fitur-fitur. Fitur adalah unit logik perilaku yang dispesifikasikan[1]. Fitur adalah properti dari konsep domain yang relevan untuk suatu pihak yang berkepentingan dan digunakan untuk membedakan instan-instan konsep. Fitur adalah bentukan untuk mengelompokkan kebutuhan-kebutuhan yang terkait. Fitur-fitur adalah cara untuk mengabstraksikan kebutuhan-kebutuhan. Pemahaman dan pemodelan keberagaman diperlukan agar pengembangan perangkat lunak semakin produktif dan terutama meningkatkan gunaulang yang akan menghasilkan efisiensi pengkodean yang berarti peningkatan produktivitas. Arsitektur yang luwes dan sekumpulan komponen gunaulang dirancang untuk memaksimumkan

keberagaman

untuk

memaksimumkan

kemampuan

membangkitkan anggota-anggota keluarga sistem. Keluarga sistem membentuk satu domain, biasanya dapat direpresentasikan menggunakan model fitur. Pemodelan fitur sangat penting pada rekayasa untuk gunaulang. Perangkat lunak untuk gunaulang berisi keberagaman yang lebih banyak dibanding sistem-sistem kongkret. Pemodelan fitur mengatasi dua persoalan, yaitu: (1) fitur-fitur relevan dan titik-titik variasi tidak dimasukkan ke perangkat lunak, (2) banyak fitur dan titik variasi dimasukkan tapi tidak pernah digunakan dan ini menyebabkan kompleksitas, ongkos pengembangan dan ongkos pemeliharaan yang tidak perlu. Gambar II.2 menunjukkan peran pemodelan fitur untuk menyaring fitur-fitur yang dikemukakan. Pemodelan fitur menyaring fitur-fitur yang tidak relevan yang hanya akan memperbesar ukuran elemen. Hasil pemodelan fitur adalah model fitur yang terdiri dari diagram fitur (feature diagram) dan deskripsi terhadap diagram-diagram fitur itu.

8

Fitur-fitur relevan yang tampak

Pemodelan Fitur

Fitur-fitur relevan yang potensial Fitur-fitur tidak relevan

Fitur-fitur relevan yang tampak

Fitur-fitur relevan yang potensial

Model Fitur Diagram-diagram fitur

Deskripsi diagramdiagram fitur

Gambar II.2 Pemodelan Fitur [3]

II.2.1 Model Fitur Model fitur merepresentasikan fitur-fitur umum dan beragam dari sebuah konsep serta kebergantungan antara fitur-fitur variabel tersebut. Model fitur dibuat pada tahap pemodelan fitur. [1] Fitur muncul pada sembarang level seperti level kebutuhan sistem level tinggi, level arsitektur, level subsistem, level komponen, bahakan pada level implementasi (yaitu level objek atau prosedur). Pemodelan terhadap semantik fitur biasanya memerlukan formalisasi pemodelan yang lain seperti diagram objek, diagram interaksi, atau diagram state-transition. Model fitur berisi diagram fitur dan beberapa informasi tambahan antara lain sebagai berikut (1) deskripsi semantiks ringkas masing-masing fitur, (2) alasan untuk masing-masing fitur, (3) pihak-pihak yang berkepentingan terhadap fitur, 9

(4) contoh-contoh sistem dengan fitur yang dikaji, (5) konstrain-konstrain terhadap fitur, (6) aturan-aturan kebergantungan default, (7) dimana, kapan dan pada apa fitur tersedia dan diikatkan, dan (8) prioritas-prioritas fitur. Diagram fitur menyediakan notasi grafis seperti pohon. Diagram fitur menunjukkan hirarki fiturfitur. Akar pohon diagram fitur merepresentasikan satu simpul konsep. Semua simpul lain merepresentasikan tipe-tipe fitur berbeda. Fitur-fitur merepresentasi karakteristik-karakteristik yang dapat dibedakan dari satu konsep. [3]

II.2.2 Diagram Fitur Sebuah diagram fitur terdiri dari kumpulan simpul (node), kumpulan sisi (edge), dan kumpulan dekorasi sisi (edge decoration). Simpul-simpul dan dan tepi-tepi yang ada membentuk sebuah pohon (tree). Dekorasi sisi adalah garis yang digambarkan sebagai busur yang menghubungkan sebagian atau semua sisi yang berasal dari simpul yang sama. Akar (root) dari sebuah diagram fitur merepresentasikan sebuah konsep, yang disebut simpul konsep (concept node). Simpul-simpul lainnya dalam diagram fitur merepresentasikan fitur-fitur dan disebut simpul fitur (feature node). [1]. Berikut ini adalah tabel notasi diagram fitur : Tabel II.1 Tabel notasi diagram fitur [1] Notasi

Nama Simpul konsep (concept node)

Simpul fitur (feature node)

10

Tabel II.1 Tabel notasi diagram fitur [1] (lanjutan) Notasi

Nama Dekorasi sisi untuk fitur opsional (optional feature) Dekorasi sisi (edge decoration) untuk fitur mandatori (mandatory feature) Dekorasi sisi

untuk fitur alternatif

(alternative feature) Dekorasi sisi untuk fitur or (or feature)

Pada Gambar II.3 dapat kita lihat sebuah diagram fitur dengan tiga buah simpul fitur f1, f2, dan f3 dan sebuah simpul konsep C, dimana induk dari f1 adalah C, induk dari f2 adalah f1, dan induk dari f3 adalah f2. Dengan keterhubungan diatas kita dapat mengatakan bahwa (1) f1 adalah fitur lansung (direct feture) dari C, (2) f2 dan f3 adalah fitur tidak lansung (inderect feature) dari C, (3) f2 adalah subfitur lansung (direct subfeature) dari f1, dan (4) f3 adalah subfitur tidak lansung (inderect subfeature) dari f1.

Gambar II.3 Diagram Fitur

11

Pemodelan fitur mendukung mandatory features, optional features, alternative features (mutual exclusive dari satu fitur), dan or feature. Mandatory feature (Gambar II.4) adalah deskripsi satu konsep jika dan hanya jika simpul induk termasuk dalam deskripsi konsep.

Gambar II.4 Diagram Fitur dengan fitur mandatory Optional feature (Gambar II.5) dapat dimasukkan di deskripsi satu konsep jika dan hanya jika simpul induknya termasuk dalam deskripsi. Optional feature dapat dimasukkan atau tidak dimasukkan, dan jika simpul induk tidak dimasukkan, optional feature tidak dapat dimasukkan.

Gambar II.5 Diagram Fitur dengan fitur optional 12

Satu konsep dapat mempunyai satu himpunan atau levih dari alternative features (Gambar II.6). Fitur juga dapat mempunyai satu himpunan alternative subfeatures. Jika induk dari himpunan alternative features dimasukkan di deskripsi satu konsep, maka tepat satu fitur dari himpunan alternative features masuk di deskripsi, fitur-fitur lain di himpunan tidak masuk di deskripsi.

C

f1

f3

f2

f4

f5

Gambar II.6 Diagram Fitur dengan fitur alternatif Konsep dapat mempunyai satu himpunan atau lebih dari or-features (Gambar II.7). Fitur dapat mempunyai satu himpunan or-subfeatures atau lebih. Jika induk himpunan or-features dimasukkan di deskripsi satu konsep, maka sembarang subset himpunan or-features tidak kosong harus dimasukkan di deskripsi.

Gambar II.7 Diagram Fitur dengan fitur or

II.2.3 Kesamaan dan Keberagaman Diagram fitur dapat merepresentasikan kesamaan dan keberagaman.[1] Common feature dari satu konsep adalah fitur yang ada di semua instan satu konsep. Kesamaan diekspresikan dengan mandatory features. Keberagaman diekspresikan menggunakan optional features, alternative features, optional alternative 13

features, dan or-features. Kesemuanya itu disebut variable features. Simpul dimana variable features dicantolkan disebut titik variasi (variation point). Pemodelan fitur cocok untuk analisis variabilitas kebutuhan-kebutuhan pada sistem. Setelah titik-titik variabilitas diidentifikasi maka kemudian pengembang perlu memilih mekanisme-mekanisme untuk mengimplementasikannya. Model fitur mengekspresikan variabilitas pada level abstrak. Model fitur juga berisi

kebergantungan-kebergantungan

di

antara variable

features

yang

dieskpresikan dalam konstrain dan aturan kebergantungan default. Konstrain menspesifikasikan kombinasi fitur yang absah dan tidak absah. Aturan kebergantungan default menyarankan nilai-nilai default untuk parameterparameter yang tidak dispesifikasikan berdasar parameter-parameter lain.[3]

II.3

Framework Berorientasi Objek (Object Oriented Framework)

Framework berorientasi objek adalah sebuah teknologi yang menjanjikan untuk membentuk rancangan dan implementasi perangkat lunak yang handal sehingga dapat mengurangi ongkos pembangunan dan meningkatkan kualitas perangkat lunak. Sebuah framework dapat diartikan sebagai aplikasi “setengah jadi” yang dapat digunaulang dan dapat dikhususkan untuk menghasilkan bermacam-macam aplikasi dalam sebuah domain tertentu. Berbeda dengan teknik gunaulang pada paradigma berorientasi objek yang berbasis pada pustaka kelas, framework lebih ditujukan untuk unit-unit bisnis tertentu

(misalnya pemrosesan data atau

komunikasi selular) dan untuk domain-domain aplikasi (misalnya antarmuka pengguna). [4] Manfaat-manfaat utama dari framework berorientasi objek sangat beragam yaitu modularitas, penggunaulangan, dan perluasan. [4] 1. Modularitas (Modularity) Framework dapat meningkatkan modularitas dengan mengenkapsulasi detail-detail implementasi yang mudah berubah dibelakang sebuah antarmuka yang stabil. Modularitas dari sebuah framework dapat membantu untuk meningkatkan kualitas perangkat lunak dengan melokalisasi

dampak

dari

perubahan-perubahan 14

rancangan

dan

implementasi. Adanya lokalisasi ini mengurangi usaha yang diperlukan untuk memahami dan merawat perangkat lunak. 2. Penggunaulangan (Reusability) Antarmuka yang stabil yang disediakan oleh framework meningkatkan peggunaulangan dengan mendefinisikan komponen-komponen generik yang dapat digunaulang untuk membentuk aplikasi baru. Penggunaulangan pada framework dapat memaksimalkan domain pengetahuan dan usaha pengembang-pengembang berpengalaman sebelumnya untuk menghindari pembangunan kembali solusi-solusi yang umum pada pembangunan perangkat lunak-perangkat lunak. Penggunaulangan pada framework dapat meningkatkan produktifitas pemrogram serta meningkatkan kualitas, kinerja dan kehandalan dari perangkat lunak. 3. Perluasan (Extensibility) Sebuah framework meningkatkan perluasan dengan menyediakan metodemetode eksplisit untuk digunakan oleh pengembang. Metode-metode ini secara sistematis melepas ikatan antara antarmuka-antarmuka yang stabil dan perilaku dari domain aplikasi dengan bagian-bagian aplikasi yang memerlukan instantiasi. Perluasan ini sangat penting dalam mengurangi waktu untuk kostumisasi layanan-layanan dan fitur-fitur aplikasi. Framework memberi peningkatan penting pengembangan komponen gunaulang berskala besar dibanding komponen gunaulang pada pendekatan tradisional. Pada penggunaan pustaka (library), pengembang (developer) aplikasi menulis program utama, menentukan aliran kendali dan kode pengembang memanggil kode pustaka. Pada penggunaan framework, pengembang aplikasi menulis kode implementasi spesifiknya, dan framework menentukan aliran kendali dan kode framework yang memanggil kode implementasi tersebut. Framework dimaksud untuk mereduksi usaha pengembangan produk perangkat lunak serta menghasilkan perangkat lunak berkualitas. Aplikasi dibangun menggunakan framework sebagai basis dan memperluasnya dengan fungsionalitas spesifik

aplikasi.

Framework

mempermudah

15

pengembangan

aplikasi,

memungkinkan penulisan kode sesedikit mungkin, memungkinkan pemrogram pemula menulis program bagus. Secara umum framework dapat dibagi menjadi dua bagian yaitu [4]: 1. Kernel (frozen spot) Frozen-spot adalah bagian dari framework yang cenderung tetap dan sulit untuk diubah. Frozen-spot telah dimplementasikan sebelumnya di dalam framework dan akan selalu ada dalam setiap instan dari framework. 2. Hot-spot Hot-spot adalah titik fleksibilitas dari framework. Hot-spot akan diimplementasikan oleh pengguna sesuai kebutuhannya. Hot-spot ini nantinya akan dipanggil oleh frozen spot sesuai dengan event yang terjadi dalam framework.

II.3.1 Prinsip-prinsip konstruksi Framework (Framework Construction Principles) Prinsip konstruksi framework (FCP – framework construction principles) berurusan dengan bagaimana membuat sebuah framework dapat diperluas. [5] Gagasan dasar FCP adalah memisahkan antara 1. template method, ditandai sebagai t() 2. hook method, ditandai sebagai h()

Gambar II.8 Arsitektur Framework [4]

16

Jika metode melakukan pemanggilan (invoke) metode lain, metode pemanggil adalah template method dan metode yang dipanggil adalah hook method. Konsep orientasi objek memungkinkan melakukan overriding terhadap hook method yang akan mengubah perilaku template method. Template method t() mempunyai hook h() dimana dua item kongkret dapat dipasangkan (plugged) pada (h1() dan h2()). Hasil ini di template method dengan dua perilaku berbeda: t() dengan h1() dan t() dengan h2().

Gambar II.9 Konsep Template-Hook [5] Kelas yang mempunyai template method ditandai sebagai T. Kelas yang mempunyai hook method ditandai sebagai H. Kelas yang berisi template method dan hook method ditandai sebagai TH. Kelas yang mempunyai concrete hook method ditandai sebagai HA. Berdasarkan penempatan template method dan hook method di satu kelas atau dua kelas, kita memperoleh lima FCP:

Tabel II.2 Framework Construction Principles [5] No.

FCP

Deskripsi

1

Unification principle

t() dan h() di satu kelas TH

2

Separation principle

T dan H secara abstrak di-couple

3

Composite principle

T dan H secara abstrak di-couple dan T subkelas dari H, objek T mengacu ke nol atau sejumlah objek H; t() dan h() mempunyai nama yang sama. 17

Tabel II.2 Framework Construction Principles [5] (lanjutan) No. 4

FCP Decorator principle

Deskripsi sama dengan di atas; perbedaannya: objek T mengacu nol atau satu objek H.

5

Chain-of-

t() dan h() membentuk satu method

responsibility principle Diagram kelas dari FCP dari Tabel II.2 digambarkan pada Gambar II.10

Gambar II.10 Konsep Template-Hook [5]

18

II.3.2 Pengembangan Framework Dengan Hot-Spot Driven. Framework yang baik umumnya adalah hasil dari beberapa iterasi perancangan. Sehingga tidak ada framework yang ideal saat pertama dibuat. Karena itu dibutuhkan metode pengembangan framework yang baik agar dapat dihasilkan framework yang bagus dengan waktu yang relatif singkat. Proses Pengembangan Hot-Spot Driven adalah salah satu metode yang dapat digunakan untuk mengembangkan framework. Gambar II.11 menunjukkan proses pengembangan framework dengan hot-spot driven. Proses Pengembangan Hot-Spot Driven terdiri dari beberapa langkah-langkah pengembangan sebagai berikut : 1. Pendefinisian Model Objek yang Spesifik. Metodologi Analisis dan Desain Berorintasi Objek (OOAD – Object Oriented Analysis and Design) mendukung identifikasi awal terhadap objek-objek dan kelas-kelas yang membentuk sebuah sistem. Misalnya Unified Modelling Language (UML). Demikian juga dengan penggunaan kartu ClassResponsibility-Collaboration (CRC) membantu dalam identifikasi awal dari objek-objek dan asosiasinya. Pemodelan objek membutuhkan pengetahuan spesifik-domain. Aktifitas ini dilakukan perekayasa perangkat lunak dibantu dengan ahli pada domain tersebut. Proses ini sendiri adalah proses yang kompleks dan membutuhkan banyak iterasi. Objek-objek yang dibentuk harus diperhalus (refine) sampai memenuhi kebutuhan-kebutuhan yang spesifik terhadap domain tersebut. 2. Identifikasi hot-spot. Dalam proses ini akan dilakukan identifikasi terhadap hot-spot yang mungkin muncul dalam framework. Dalam mengidentifikasi hot-spot perekayasa perangkat lunak harus memperhatikan FCP (Framework Construction Principle) dan mengkombinasikannya dengan semantik dari domain yang diteliti. Perekayasa perangkat lunak harus berkolaborasi dengan pakar domain (domain expert) untuk mengidentifikasi hot-spot.

19

Gambar II.11 Proses Pengembangan Hot-Spot Driven [4] Umumnya para pakar domain tidak memahami tentang konsep seperti kelas, objek, pewarisan dsb, apalagi konsep mengenai framework dan pola rancangan (design pattern), karena itu komunikasi antara perekayasa perangkat lunak dan pakar domain harus menggunakan cara yang dapat dimengerti oleh keduanya.

20

Kartu hot-spot (hot-spot card) adalah salah satu cara yang dapat digunakan. Nama hot-spot derajat fleksibilitas adaptasi tanpa restart adaptasi oleh end-user

Deskripsi : Deskripsi umum mengenai semantik hot-spot.

Variabilitas : Behaviour hot-spot dan contoh situasi-situasi berbeda yang mungkin muncul.

Gambar II.12 Kartu Hot-Spot [4] Kartu hot-spot ini menyediakan informasi mengenai nama hot-spot, yang merupakan sebuah istilah ringkas yang menggambarkan fungsionalitas yang harus dijaga sefleksibel mungkin. Kartu hot-spot juga menyediakan informasi mengenai derajat fleksibilitas dari hot-spot apakah hot-spot tersebut dapat beradaptasi tanpa restart aplikasi dan apakah hot-spot tersebut dapat diadaptasi oleh end-user. Berikut adalah tabel deskripsinya.

Tabel II.3 Derajat fleksibilitas Hot-Spot [4] Adaptasi

Adaptasi

Model objek

oleh end-user

Dengan restart

Tidak

Tambahan hook method

Tanpa restart

Tidak

Tambahan hook method di kelas yang berbeda

Dengan restart

Ya

Tambahan hook method dan konfigurasi eksternal

Tanpa restart

Ya

Tambahan hook method di kelas yang berbeda dan konfigurasi eksternal

21

3. Perancangan (ulang) framework. Setelah pakar domain dan perekayasa perangkat lunak mengidentifikasi kartukartu hot-spot, perekayasa perangkat lunak harus memodifikasi model objek untuk mendapatkan fleksibilitas hot-spot yang diinginkan. FCP digunakan untuk membantu perekayasa perangkat lunak dalam tahap ini. Dalam tahap ini dihasilkan model objek yang telah dimodifikasi sehingga memenuhi FCP. 4. Penggunaan framework Framework

seharusnya

digunakan

beberapa

kali

untuk

mengetahui

kelemahannya atau mengidentifikasi hot-spot yang tidak cocok ataupun mungkin hot-spot yang hilang. Identifikasi hot-spot secara eksplisit dengan menggunakan kartu hot-spot dan FCP berkontribusi terhadap pengurangan secara signifikan terhadap siklus iterasi pembangungan framework.

II.4

Deskripsi Sistem Penjadwalan

Penjadwalan (scheduling) merupakan proses pembuatan jadwal-jadwal [6]. Jadwal adalah rencana atau dokumen yang memberitahu kapan sesuatu akan terjadi, menunjukkan satu rencana pewaktuan aktivitas-aktivitas tertentu yang merupakan jawaban pertanyaan : “Kapan sesuatu akan berlangsung?”. Pada proses penjadwalan, kita perlu menspesifikasi tipe dan jumlah masing-masing sumber daya sehingga dapat menentukan kapan operasi-operasi dapat dilakukan secara layak. Saat menspesifikasi sumber daya, kita mendefinisi batasan penjadwalan. Kita mendeskripsi masing-masing operasi dalam kebutuhan sumber daya, durasi, waktu dapat dimulai, durasi pengolahan, waktu seharusnya telah selesai, dan sebagainya. Teori penjadwalan telah dikembangkan sejak tahun 1950-an. Penjadwalan banyak ditemui pada manufakturing dan rekayasa secara umum [8].

II.4.1 Teori Penjadwalan Teori penjadwalan berkaitan dengan model-model matematika yang berhubungan dengan proses penjadwalan. Pengembangan model yang bagus menuntun penemuan teknik-teknik penyelesaian. Pendekatan kuantitatif dimulai dengan 22

deskripsi sumber daya–sumber daya dan operasi-operasi serta menerjemahkan goal keputusan menjadi fungsi objektif eksplisit. Solusi terhadap persoalan penjadwalan adalah sembarang penyelesaian yang layak, memenuhi batas kapasitas sumber daya (mesin) dan urutan dimana job-job dilaksanakan. Solusi menjawab dua pertanyaan : 1.Sumber daya mana yang akan dialokasi untuk operasi? 2.Kapan operasi dilakukan? [8] Hubungan antara persoalan penjadwalan dan teknik penyelesaian dapat dikaji dengan teori kompleksitas. Kompleksitas mengacu pada usaha komputasi oleh algoritma penyelesaian. Usaha komputasi sering dideskripsi dengan notasi orderof-magnitude. Misalkan kita menggunakan algoritma untuk menyelesaikan persoalan berukuran n. Secara teknis, n menunjukkan ukuran (jumlah) informasi untuk menspesifikasi persoalan. Jumlah komputasi yang diperlukan algoritma biasanya berbatas atas oleh satu fungsi dari n. Jika order-of-magnitude fungsi adalah polinom begitu n membesar maka kita sebut algoritma adalah polinom (P). Jika fungsi adalah O(2n) maka algoritma adalah non-polinom (NP), dalam kasus ini adalah eksponensial. Kita lebih baik menggunakan algoritma polinom. Terdapat kelas persoalan NP-complete yang termasuk di dalamnya persoalan kombinatorial yang sulit. Jika satu darinya dapat diselesaikan dengan algoritma polinom maka persoalan-persoalan lain pun dapat diselesaikan dengan algoritma polinomial. Konjekturnya adalah algoritma seperti itu tidak ada. Persoalan optimisasi sering merupakan persoalan NP-hard. Banyak persoalan penjadwalan merupakan NP-hard. Dengan memodelkan dalam bahasa spesifikasi maka dapat dilakukan verifikasi untuk menyatakan kompleksitas persoalan penjadwalan yang dihadapi.

Shop berisi m ≥ 1 pemroses (atau mesin). Masing-masing pemroses melakukan satu operasi berbeda. Terdapat n ≥ 1 job. Masing-masing job i mempunyai m operasi. Waktu pengolahan untuk operasi j job i adalah pj,i. Operasi j job i diolah pemroses j, 1 ≤j≤m. Satu jadwal untuk pemroses j adalah sekuen tupel (Ji, si, ci), 1 ≤ i ≤r, i adalah indeks job J, si adalah waktu mulai job Ji, dan ci adalah waktu selesai. Job Ji diproses pada pemroses j mulai dari si sampai ci. Tupel-tupel

23

diurutkan sehingga si < ci ≤ si+1, 1 ≤ i < r. Dapat terdapat lebih dari satu tupel per job dan diasumsikan Ji ≠ Ji+1, 1 ≤ i < r. Masing-masing job i menggunakan pj,i waktu pengolahan pemroses j. Satu jadwal untuk satu m-shop adalah himpunan jadwal m pemroses. Satu jadwal untuk masing-masing pemroses di shop. Pada jadwal-jadwal m pemroses, tidak ada job yang diolah secara simultan pada dua pemroses atau lebih. Waktu penyelesaian (completion time) jadwal adalah waktu penyelesaian paling akhir jadwal-jadwal pemroses individu dan merepresentasi waktu dimana semua operasi telah selesai. Jadwal optimal finish time (OFT) adalah finish time yang mempunyai waktu finish paling kecil dibanding jadwal-jadwal lain. Jika himpunan job untuk penjadwalan tidak berubah sepanjang waktu berarti sistem penjadwalan adalah statik. Jika job-job baru muncul sepanjang waktu eksekusi sistem berarti sistem penjadwalan adalah dinamis. Meski model dinamis lebih penting pada aplikasi praktis, model statik sering menangkap esensi sistem dinamis. Analisis terhadap model statik sering menyingkap prinsip-prinsip dasar yang berguna untuk model dinamis.

II.4.2 Notasi Persoalan Penjadwalan Notasi untuk menyatakan persoalan penjadwalan adalah tiga field, ||. Field  adalah tipe persoalan.  dirinci 12, 1 adalah lingkungan mesin, 2 adalah jumlah mesin yang tersedia.  adalah konstrain-konstrain eksplisit.  adalah kriteria yang dioptimasi. Tipe penjadwalan terbagi dua, penjadwalan dengan penugasan dan tanpa penugasan. Lingkungan persoalan penjadwalan tanpa penugasan terbagi sebagai berikut: 1. Flowshop (F) : terdapat sejumlah mesin di shop. Karakteristik tipe ini adalah job-job menggunakan mesin dengan urutan sama, job-job mempunyai routing yang sama.

24

2. Jobshop (J) : beberapa mesin tersedia di shop. Masing-masing job mempunyai route nya sendiri, yaitu menggunakan sumber daya–sumber daya dalam urutannya sendiri. 3. Openshop (O) : beberapa mesin tersedia di shop. Job-job tidak mempunyai routing yang tetap. Job-job dapat menggunakan mesin-mesin dengan sembarang urutan. 4. Mixed shop (X) : beberapa mesin tersedia di shop. Beberapa job mempunyai routing sendiri dan lainnya tidak. Konstrain di antaranya adalah konstrain waktu mulai, waktu mulai suatu operasi pada satu job harus setelah waktu tertentu. Konstrain deadline, konstrain adalah tidak boleh melampaui waktu tertentu. Konstrain preemption, pmtn, preeemption dimungkinkan. Operasi dapat diinterupsi dimana operasi akan dilakukan pada masa datang. Konstrain precedence, prec, mengindikasi operasi dihubungkan konstrain

precedence.

Konstrain

batch,

mengindikasi

operasi-operasi

dikelompokkan di batch-batch. P-batch adalah parallel batch dimana operasioperasi pada satu batch diolah secara parallel pada satu cummulative resource. Waktu selesai satu operasi sama dengan waktu selesai batch itu. Konstrain nowait, yaitu operasi-operasi di satu job berturutan tanpa waktu tunggu. Konstrain due date, di=d, yaitu semua due date adalah identik. Konstrain keidentikan pengolahan, pi=p adalah waktu pengolahan semua identik. Setup time dan removal time, snsd dan rnsd adalah waktu setup dan removal sumber daya–sumber daya sebelum dan setelah pengolahan. Penyiapan independen sekuen operasi. Konstrain unavailibility, unavail, adalah sumber daya–sumber daya tidak tersedia pada satu waktu tertentu. Konstrain sequencing, apakah job-job perlu secara diurutkan operasi-operasi tertentu. Konstrain uniquesness, apakah operasi dapat dilakukan lebih dari satu mesin di shop? Konstrain cummulativity, apakah masing-masing mesin dapat melakukan lebih dari satu operasi pada satu saat. Konstrain instantaneously transferred, apakah job dapat secara instan ditransfer dari satu mesin ke mesin lain.

25

Fungsi obyektif tidak harus berupa ekspresi matematika sederhana, dapat berupa algoritma rumit, misalnya melibatkan sejumlah simulasi. Optimisasi global berisi sejumlah teknik yang dapat digunakan untuk menemukan elemen terbaik xi di domain X berkaitan dengan kriteria fF. Kriteria yang biasanya dikaji di dalam penjadwalan adalah [8] 1. Waktu penyelesaian (completion time), C. Alternatifnya adalah (a) minimisasi maksimum waktu penyelesaian, disebut makespan, (b) minimisasi rataan atau total waktu penyelesaian seluruh job, (c) minimisasi rataan atau total waktu penyelesaian seluruh job mempertimbangkan pembobotan. 2. Durasi penyelesaian (flow time), F. Alternatifnya adalah (a) minimisasi maksimum durasi penyelesaian, (b) minimisasi rataan atau total durasi penyelesaian seluruh job, (c) minimisasi rataan atau total durasi penyelesaian seluruh job mempertimbangkan pembobotan. 3. Durasi tardiness, T. Alternatifnya adalah (a) minimisasi maksimum durasi tardiness, (b) minimisasi rataan atau total durasi tardiness seluruh job, (c) minimisasi rataan atau total durasi tardiness seluruh job mempertimbangkan pembobotan. 4. Durasi lateness, L. Alternatifnya adalah (a) minimisasi maksimum durasi lateness, (b) minimisasi rataan atau total durasi lateness seluruh job, (c) minimisasi rataan atau total durasi lateness seluruh job mempertimbangkan pembobotan. 5. Durasi earliness, E. Alternatifnya adalah (a) minimisasi maksimum durasi earliness, (b) minimisasi rataan atau total durasi earliness seluruh job, (c) minimisasi rataan atau total durasi earliness seluruh job mempertimbangkan pembobotan. 6. Durasi promptness, P, minimisasi terhadap maksimum durasi promptness 7. Jumlah job yang terlambat, U. Alternatifnya adalah (a) minimisasi jumlah job yang terlambat, (b) minimisasi rataan atau total durasi lateness seluruh job mempertimbangkan pembobotan. 8. Minimisasi terhadap fungsi ongkos generik

26