Bab II Landasan Teori

4

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 aset-aset yang dapat digunaulang misalnya framework, komponen-komponen,

5

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 sistem-sistem 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

6

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

7

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 <attribute>=<value>. Pengembang aplikasi hanya perlu membuat deret <attribute>=<value> 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

8

antara fitur itu. Merancang sistem perangkat lunak dalam istilah-istilah fitur-fitur 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.

9

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,

Fitur-fitur relevan yang tampak

Fitur-fitur relevan yang potensial

Fitur-fitur tidak relevan

Pemodelan

Fitur

Diagram-diagram fitur Deskripsi diagram-diagram fitur

Model Fitur

Fitur-fitur

10

(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 fitur-fitur. 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)

11

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.

12

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.

13

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 f2 f3 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

14

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 parameter-parameter yang tidak dispesifikasikan berdasar parameter-parameter-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 rancangan dan

15

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 metode-metode eksplisit untuk digunakan oleh pengembang. Metode-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 pengembangan aplikasi,

16

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()

17

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.

18

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

No. FCP Deskripsi

4 Decorator principle sama dengan di atas; perbedaannya: objek T mengacu nol atau satu objek H.

5 Chain-of-responsibility principle

t() dan h() membentuk satu method

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

19

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 Class-Responsibility-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.

20

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.

21

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

oleh end-user Model objek

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

22 3. Perancangan (ulang) framework.

Setelah pakar domain dan perekayasa perangkat lunak mengidentifikasi kartu-kartu 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

23

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

order-of-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

24

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

25

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 operasi-operasi pada satu batch diolah secara parallel pada satu cummulative resource. Waktu selesai satu operasi sama dengan waktu selesai batch itu. Konstrain

no-wait, 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

26

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.