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-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 relevan yang tampak

Fitur-fitur relevan yang potensial

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)

Simpul fitur (feature 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.

Gambar II.3 Diagram Fitur

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.

Gambar II.5 Diagram Fitur dengan fitur optional

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

Gambar II.8 Arsitektur Framework [4]

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

Gambar II.10 Konsep Template-Hook [5]

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

selesai. Job Ji diproses pada pemroses j mulai dari si sampai ci. Tupel-tupel

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 12, 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.

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

mesin ke mesin lain.

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