Tehnik/Metode Pengembangan (Metode Object Oriented)

Teknologi Objek

Orientasi objek merupakan paradigma baru dalam rekayasa software yang

didasarkan pada objek. Cara berpikir orientasi objek adalah segala sesuatu

dipandang sebagai objek. James Martin dan James J Odell mengemukakan objek

adalah sesuatu yang dapat dikonsepkan yang diperlukan untuk pemecahan

masalah, dalam bukunya A Foundation Object-oriented Methods (Martin/Odell

1995). Objek dapat berupa konsep, abstraksi, atau sesuatu dengan batas-batas

tegas dan mempunyai arti untuk persoalan yang ditangani. Teknologi objek

menganalogikan sistem aplikasi seperti kehidupan nyata yang didominasi oleh

objek. Didalam terminologi yang sederhana merancang suatu sistem berorientasi

objek yang terdiri atas mengindentifikasi objek apa yang terdapat dalam sistem

menyangkut perilaku dan tanggung jawab dari objek, dan bagaimana objek saling

berhubungan dengan objek-objek yang lainnya.

Object-Oriented Languages

Bahasa pemrograman berorientasi objek pertama kali muncul adalah

bahasa pemrograman SIMULA I (1962-1965) dan SIMULA 67 (1967). Simula 67

memperkenalkan konsep utama dalam pemrograman berorientasi objek yaitu

objek dan kelas, sub kelas (pewarisan), prosedur virtual dan beberapa hal lainnya.

Konsep-konsep yang ada di bahasa SIMULA kemudian digunakan oleh Bjarne

Stroustrup dalam bahasa C untuk mengembangkan bahasa C++. Perkembangan

7
 8

bahasa yang mendukung pemrograman berorientasi objek kemudian berkembang

dengan cepat.

Ada beberapa bahasa pemrograman yang berorientasi objek yaitu antara

lain adalah SmallTalk, Eiffel, C++, Objek C, Objek Pascal, dan java. Di antara

bahasa pemrograman berorientasi objek yang banyak digunakan para pengembang

perangkat lunak yang menguasai pasar adalah C++ dan java.

Object Oriented Design (OOD)

Object Oriented Design (OOD) merupakan metode untuk mengarahkan arsitektur

software yang didasarkan pada manipulasi objek – objek sistem atau subsistem.

OOD adalah sebuah metode mendesain yang mencakup proses

pendekomposisisan objek dan digambarkan dalam notasi sehingga bisa

menggambarkan static (class diagram) dan dynamic (statechart diagram) model

sistem. OOD memungkinkan software engineer untuk mengetahui object-object

 9

yang dihasilkan oleh tiap class dan hubungan antar object. Selain itu, OOD

menggambarkan bagaimana hubungan antar object bisa dilakukan, bagaimana

behavior dari object diimplementasikan dan bagaimana komunikasi antar object

diimplementasikan.

Pemodelan berorientasi objek biasa nya dituangkan dalam dokumentasi perangkat

lunak dengan menggunakan perangkat permodelan beroerientasi objek,

diantaranya adlah UML (Unified Modeling Language), Adapun tahan dari Object

Oriented Design (OOD) yaitu :

1. Desain Subsistem

Berisikan representasi masing-masing subsistem yang memungkinkan

perangkat lunak mencapai persyaratan yang didefinisikan oleh

pelanggannya dan untuk mengimplementasikan infrastruktur yang

mendukung persyaratan pelanggan. Desain subsistem ini menggambarkan

tabel-tabel yang digunakan dalam sistem. Adapun desain subsistem yang

ada pada sistem ini meliputi tabel member, tabel admin, tabel penginapan,

tabel galeri penginapan, tabel fasilitas dan tabel pasang fasilitas.

 10

2. Desain Objek dan Kelas

Berisi hirarki kelas yang memungkinkan sistem diciptakan dengan

menggunakan generalisasi dan spesialisasi yang ditarget secara perlahan.

Lapisan ini juga berisi infrastruktur yang mendukung persyaratan

pelanggan. Desain objek dan kelas ini meliputi gambaran relasi dari

tiaptiap kelas/objek yang ada pada sistem. Adapun desain objek dan kelas

pada penelitian ini meliputi tabel member yang berelasi dengan tabel

penginapan (1:M), tabel penginapan berelasi dengan tabel fasilitas (M:M)

dan tabel penginapan yang berelasi dengan tabel galeri (M:M).

3. Desain Pesan

Berisi detail yang memungkinkan masing-masing objek berkomunikasi

dengan kolaboratornya. Lapisan ini membangun interface internal dan

eksternal bagi sistem tersebut. Adapun desain pesan pada penelitian ini

meliputi Rancangan Halaman Home, Rancangan Halaman Pencarian,

Rancangan Halaman Login, Rancangan Halaman Tambah Penginapan,

Rancangan Halaman Tambah Kamar, Rancangan Halaman Tambah

Fasilitas Kamar, dan Rancangan Halaman Profil Penginapan.

Langkah langkah Object Oriented Analysis and Design (OOAD)

Langkah-langkah dalam Object-Oriented Analysis (OOA) yang dijelaskan

dapat diuraikan sebagai berikut:

 Menganalisis Masalah
 11

Langkah pertama dalam OOA adalah mengumpulkan data yang diperlukan

untuk membangun sistem, sehingga kebutuhan sistem dapat diidentifikasi.

Setelah data terkumpul, dilakukan analisis untuk merumuskan permasalahan

yang ada. Ini melibatkan pemahaman aliran sistem yang sudah ada dan

mencoba mengidentifikasi masalah-masalah yang sering terjadi. Berdasarkan

analisis ini, aliran sistem baru digambarkan untuk memecahkan masalah yang

ada.

 Menjelaskan Proses Sistem

Fungsi sistem yang akan dibangun dijelaskan berdasarkan data yang telah

dikumpulkan. Rancangan analisis digunakan untuk menggambarkan sistem,

dan dalam penelitian ini, digunakan Usecase Diagram, Class Diagram, dan

Sequence Diagram. Diagram-diagram ini membantu dalam merinci interaksi

antara pengguna dan sistem, serta struktur kelas dan urutan proses dalam

sistem.

 Identifikasi Objek

Objek-objek yang menjadi fokus dalam sistem diidentifikasi. Dalam konteks

penelitian ini, objek-objek tersebut adalah semua penginapan di Pekanbaru,

termasuk Hotel dan wisma. Identifikasi objek penting untuk memahami

entitas-entitas yang akan diatur dalam sistem.

 Menentukan Atribut

Atribut-atribut dari objek-objek tersebut ditentukan. Dalam hal ini, atribut-

atribut yang menjadi ciri khas dari sebuah penginapan termasuk nama

penginapan, alamat, koordinat, jenis kamar, harga kamar, dan fasilitas kamar.
 12

Kelas-kelas dibuat sebagai abstraksi dari entitas dunia nyata dan menetapkan

spesifikasi perilaku serta atribut.

 Mendefinisikan Operasi

Operasi-operasi atau fungsi-fungsi yang dapat diimplementasikan dalam

sistem dijelaskan. Pada penelitian ini, operasi yang mencakup pendaftaran

penginapan, pengolahan penginapan, pengolahan kamar penginapan,

pengolahan fasilitas kamar, dan pencarian penginapan berdasarkan metode

MPE dapat diimplementasikan. Namun, beberapa fitur seperti melihat jumlah

kamar kosong dan fitur pemesanan dan pembayaran e-banking tidak

diimplementasikan.

Secara keseluruhan, langkah-langkah ini menciptakan dasar untuk merancang

sistem berorientasi objek yang memenuhi kebutuhan yang telah diidentifikasi.

Sejarah Metode Beorientasi Objek

Metode beorientasi objek mulai berkembang ketika Grady Booch pada

tahun 80 an mempublikasikan suatu paper bagaimana melakukan perancangan

untuk bahasa ADA namun memberi judul paper tersebut dengan : Object-Oriented

Design. Selanjutnya ide tersebut terus ia kembangkan sampai tahun 90 an. Pada

tahun 1991 Peter Coad dan Yourdon memperkenalkan metode berorientasi objek

yang lebih sederhana dibandingkan Booch. Metode ini menjadi cepat populer

karena mendukung layanan-layanan yang terdapat pada C++. Pada waktu itu C++

merupakan bahasa pemrograman berorientasi objek yang paling populer .

 13

Pada tahun 1991 juga Rumbaugh memperkenalkan Object Modelling

Technique (OMT). Pendekatan yang digunakan tidak jauh berbeda dengan

pendekatan yang digunakan Coad Yourdon namun dengan notasi yang berbeda.

OMT tidak hanya sepenuhnya berbasis pada data driven tapi juga memisahkan

proses dari data dengan penggunan data flow diagram yang terpisah dengan

diagram kelas. OMT juga menggunakan notasi state transition diagram untuk

memodelkan aspek dinamis sistem. Pada tahun 1994 Ivar Jacobson

memperkenalkan konsep use case dan object oriented software engineering. Pada

tahun 1994 itu juga yaitu bulan Oktober 1994 Booch, Rumbaugh dan Jacobson,

mempelopori usaha untuk penyatuan notasi pendekatan berorientasi objek. Pada

tahun 1995 dihasilkan draft pertama dari UML (versi 0.8). Sejak tahun 1996

pengembangan tersebut dikoordinasikan oleh Object Management Group

Tahun 1997 UML versi 1.1 muncul, dan saat ini versi terbaru adalah versi

1.5 yang dirilis bulan Maret 2003. Booch, Rumbaugh dan Jacobson menyusun

tiga buku serial tentang UML pada tahun 1999. Sejak saat itulah UML telah

menjelma menjadi standar bahasa pemodelan untuk aplikasi berorientasi objek

[DHA03].

Kenapa Metode Beorientasi Objek ?

Menaikkan tingkat keterpakaian kembali (reusability) Perangkat lunak

bersifat dinamis. Hal ini disebabkan kebutuhan pengguna berubah dengan cepat.

Perkembangan teknologi informasi dan kebutuhan akan pengolahan informasi itu

memaksa setiap organisasi memperbarui sistemnya. Dengan demikian perangkat

lunak harus dibangun dengan reusability tinggi. Metode yang mendukung

 14

reusability tersebut adalah metode beroientasi objek.

Menghilangkan kompleksitas transisi antar tahap pada pengembangan perangkat

lunak Pada pendekatan konvensional (tertruktur), notasi yang digunakan pada

tahap analisis, perancangan dan tahap lainnya berbeda-beda. Hal ini menyebabkan

transisi antar tahap pengembangan menjadi kompleks. Pada pendekatan

berorientasi objek notasi yang digunakan pada tahap analisis, peanccangan dan

implementasi relatif sama.

Memiliki tingkat abstraksi yang lebih tinggi Pendekatan terstruktur

mendukung abstraksi pada level fungsional. Hal ini tidak bersesuaian dengan

keadaan di dunia nyata. Pada dunia nyata kebanyakan pengelompokan tidak

didasarkan pada fungsinya namun pada karakteristik alami yang melekat, yang

membedakan sesuatu dengan yang lain. Di dunia nyata yang sering kita lihat

adalah objeknya bukan fungsinya. Kita lebih akrab dengan istilah manusia, sapi,

dan harimau, ketimbang dengan pemikir, pemamah biak, atau pemangsa. Dengan

demikian pendekatan berorientasi objek membawa abstraksi kita lebih dekat

dengan dunia nyata. Artinya, kita dibawa kepada level abstraksi yang lebih tinggi.

Kelebihan dan Kekurangan

Kelebihan

Dibandingkan dengan metode SSAD, OOAD lebih mudah digunakan

dalam pembangunan sistem Dibandingkan dengan SSAD, waktu pengembangan,

level organisasi, ketangguhan,dan penggunaan kembali (reuse) kode program

lebih tinggi dibandingkan dengan metode OOAD (Sommerville, 2000). Tidak ada
 15

pemisahan antara fase desain dan analisis, sehingga meningkatkan komunikasi

antara user dan developer dari awal hingga akhir pembangunan sistem.

Analis dan programmer tidak dibatasi dengan batasan implementasi

sistem, jadi desain dapat diformliasikan yang dapat dikonfirmasi dengan berbagai

lingkungan eksekusi. Relasi obyek dengan entitas (thing) umumnya dapat di

mapping dengan baik seperti kondisi pada dunia nyata dan keterkaitan dalam

sistem. Hal ini memudahkan dalam mehami desain (Sommerville, 2000).

Memungkinkan adanya perubahan dan kepercayaan diri yang tinggi terhadap

kebernaran software yang membantu untuk mengurangi resiko pada pembangunan

sistem yang kompleks (Booch, 2007). Encapsliation data dan method,

memungkinkan penggunaan kembali pada proyek lain, hal ini akan memperingan

proses desain, pemrograman dan reduksi harga.

OOAD memungkinkan adanya standarisasi obyek yang akan memudahkan

memahami desain dan mengurangi resiko pelaksanaan proyek. Dekomposisi

obyek, memungkinkan seorang analis untuk memcah masalah menjadi pecahan-

pecahan masalah dan bagian-bagian yang dimanage secara terpisah. Kode

program dapat dikerjakan bersama-sama. Metode ini memungkinkan

pembangunan software dengan cepat, sehingga dapat segera masuk ke pasaran

dan kompetitif. Sistem yang dihasilkan sangat fleksibel dan mudah dalam

memelihara.

Kekurangan

Pada awal desain OOAD, sistem mungkin akan sangat simple. Pada

OOAD lebih fockus pada coding dibandingkan dengan SSAD. Pada OOAD tidak
 16

menekankan pada kinerja team seperti pada SSAD. Pada OOAD tidak mudah

untuk mendefinisikan class dan obyek yang dibutuhkan sistem. Sering kali

pemrogramam berorientasi obyek digunakan untuk melakukan anlisisis terhadap

fungsional siste, sementara metode OOAD tidak berbasis pada fungsional sistem.

OOAD merupakan jenis manajemen proyek yang tergolong baru, yang

berbeda dengan metode analisis dengan metode terstruktur. Konsekuensinya

adalah, team developer butuh waktu yang lebih lama untuk berpindah ke OOAD,

karena mereka sudah menggunakan SSAD dalam waktu yang lama ( Hantos,

2005). Metodologi pengembangan sistem dengan OOAD menggunakan konsep

reuse. Reuse merupakan salah satu keuntungan utama yang menjadi alasan

digunakannya OOAD. Namun demikian, tanpa prosedur yang emplisit terhadap

reuse, akan sangat sliit untuk menerapkan konsep ini pada skala besar (Hantos,

2005).

Object-Oriented Languages

Bahasa pemrograman berorientasi objek pertama kali muncul adalah

bahasa pemrograman SIMULA I (1962-1965) dan SIMULA 67 (1967). Simula 67

memperkenalkan konsep utama dalam pemrograman berorientasi objek yaitu

objek dan kelas, sub kelas (pewarisan), prosedur virtual dan beberapa hal lainnya.

Konsep-konsep yang ada di bahasa SIMULA kemudian digunakan oleh Bjarne

Stroustrup dalam bahasa C untuk mengembangkan bahasa C++. Perkembangan

bahasa yang mendukung pemrograman berorientasi objek kemudian berkembang

dengan cepat.
 17

Ada beberapa bahasa pemrograman yang berorientasi objek yaitu antara

lain adalah SmallTalk, Eiffel, C++, Objek C, Objek Pascal, dan java. Di antara

bahasa pemrograman berorientasi objek yang banyak digunakan para pengembang

perangkat lunak yang menguasai pasar adalah C++ dan java.

Metodologi Orientasi Objek

Metodologi adalah cara sistematis untuk mengerjakan pekerjaan analisis

dan desain. Dengan metodologi, pihak yang membangun suatu sistem dapat

merencanakan dan mengulangi pekerjaan di lain waktu. Metodologi

menghilangkan kesalahpahaman dan menghilangkan perbedaan notasi untuk suatu

hal yang sama. Metode yang digunakan harus sesuai dengan kebutuhan aplikasi

yang akan dibangun. Selain itu metode juga harus mudah digunakan dan

dimengerti oleh pengembang perangkat lunak. Metodologi orientasi objek yang

digunakan dalam analisis berorientasi objek antara lain:

a. Metode Booch

Dikenal dengan nama Metode Desain Object Oriented. Metode ini

menjadikan proses analisis dan desain ke dalam empat tahapan yang iteratif (dapat

berulang), yaitu identifikasi kelas-kelas dan objek-objek, identifikasi semantik dan

hubungan objek dan kelas tersebut, perincian interface dan implementasi.

b. Metode Rumbaugh (Object Modelling Technique - OMT)

 18

Metode ini berdasarkan pada analisis terstruktur dan pemodelan entity-

relationship. Tahapan utama dalam metodologi ini adalah analisis, desain sistem

dan desain objek, dan implementasi. Keunggulan metode ini adalah dalam

penotasian yang mendukung semua konsep object oriented.

c. Metode Jacobson (Object Oriented Software Engineering - OOSE)

Metode yang mengandung elemen-elemen dari Object Oriented lainnya.

Metode ini memberi penekanan lebih pada use-case. OOSE memiliki tiga tahapan

yaitu membuat model requirement dan analisis, desain dan implementasi, dan

model pengujian (tes model). Keunggulan metode ini adalah mudah untuk

dipelajari karena memiliki notasi yang sederhana, mencakup seluruh tahapan

dalam rekayasa software.

d. Metode Coad dan Yourdon

Metode ini didasarkan pada pemodelan Object Oriented dan entity-

relationship. Metode ini mempunyai perancangan yang berfokus pada empat

komponen yaitu Problem domain componet, Human interaction componet, Data

management component dan Task management component.

e. Metode Wirfs-Brock

Responsibility Driven Design/-Class Responsibility Collaboration

(RDD/CFC) Metode ini diarahkan pada desain, tetapi sangat berguna untuk

memunculkan ide dalam tahap analisis. Keunggulannya adalah mudah digunakan,

metode ini juga mengidentifikasikan hirarki kelas dan subsistem-subsistem.

f. Metode Shlair-Mellor Object Oriented Analysis/Design (OOA/D)

 19

Metode yang menggunakan teknik pemodelan informasi tradisional yang

menjelaskan entitas dalam sistem, menggunakan state diagram untuk

memodelkan keadaan (state) entitas, menggunakan data flow diagram untuk

memodelkan alur data dalam sistem. Metode ini menghasilkan tiga jenis model

yaitu: information model, state model dan process model. Keunggulan metode ini

adalah dalam memandang masalah dari sudut pandang yang berbeda, mudah

dibuat (dikonversi) dari metode struktural.

Analisis dan Disain Berorientasi Objek menggunakan Unified Modelling

Language (UML)

Teknologi pemodelan berorientasi objek merupakan metodologi yang

digunakan untuk membangun sistem berorientasi objek, yang dimulai dari tahap

analisis kebutuhan sistem, perancangan sistem dan tahap implementasinya.

Pemodelan dan perancangan berorientasi objek sebagai teknik yang mudah, cepat

dan efisien dalam pelaksanaan daur hidup (life cycle) pembutan perangkat lunak.

Orientasi Objek dalam pemodelan dengan Unified Modelling Language

merupakan suatu konsep orientasi objek yang berhubungan dengan Object

Oriented Analysis and Design (OOAD) yang dimana dapat didefinisikan sebagai

Object Oriented Analysis yaitu metode analisis yang memeriksa requirements

(syarat/keperluan yang harus dipenuhi oleh suatu sistem) dari sudut pandang

kelas-kelas dan objek-objek yang ditemui dalam ruang lingkup permasalahan.

Dan Object Oriented Design yaitu metode untuk mengarahkan arsitektur software

yang didasarkan pada manipulasi objek-objek sistem atau subsistem.

 20

Beberapa konsep dasar dalam Object Oriented Analysis and Design

(OOAD) adalah:

a. Objek

Objek (Object) adalah “benda”, secara fisik atau konseptual, yang terdapat

disekeliling kita. Sebuah objek memiliki keadaan sesaat (state) dan perilaku

(behavior). State dari sebuah objek adalah kondisi objek tersebut atau himpunan

dari keadaan yang menggambarkan objek tersebut. Sebagai contoh, salah satu

state dari objek jam adalah waktu saat ini.

State dinyatakan dengan nilai dari atribut (attribute) objeknya. Atribut

adalah nilai internal suatu objek, kondisi sesaat, koneksi dengan objek lain dan

identitas. Perubahan state dicerminkan oleh perilaku (behavior) objek tersebut.

Behavior (perilaku) suatu objek mendefinisikan bagaimana sebuah objek

bertindak (bereaksi) dan memberi reaksi. Behavior ditentukan oleh himpunan

semua atau beberapa operasi yang dapat dilakukan dalam objek itu sendiri.

Behavior dari sebuah objek dicerminkan oleh:

a. Interface, adalah pintu untuk mengakses service objek.

b. Service, adalah fungsi yang bisa diemban oleh objek.

c. Method, adalah mekanisme internal objek yang mencerminkan perilaku

(behavior) objek tersebut.

b. Kelas (Class)
 21

Kelas (class) adalah definisi umum (pola, tamplate atau cetak biru) untuk

himpunan objek sejenis. Kelas menetapkan spesifikasi perilaku (behavior) atau

atribut objek-objek tersebut. Kelas adalah keniskalan atau abterasi dari entitas

dalam dunia nyata. Objek adalah “contoh” (instance) dari sebuah kelas.

c. Kotak hitam dan Interface

Interface melindungi internal state sebuah objek dari “campur tangan”

pihak luar. Oleh karena itu, objek sering digambarkan sebagai kotak hitam (black

box) yang menerima dan mengirim pesan-pesan (message). Dalam object oriented

programming, kotak hitam berisi kode (himpunan instruksi dengan bahasa yang

dipahami komputer) dan data (informasi dimana instruksi tersebut berinteraksi

dengan komputer tersebut).

d. Encapsulation

Encapsulation adalah proses menyembunyikan detail implementasi sebuah

objek. Untuk dapat berkomunikasi dengan objek diperlukan pesan (message).

Message adalah permintaan untuk objek penerima (receiver object) untuk

membawa metode yang ditunjukkan atau perilaku dan mengembalikan result dari

aksi tersebut kepada objek pengirim (sender object).

e. Association dan Aggregation

Association (asosiasi) adalah hubungan antar objek yang saling

membutuhkan. Aggregation (agregasi) adalah bentuk khusus dari asosiasi yang

menggambarkan seluruh bagian dari suatu objek dimana objek tersebut

merupakan bagian dari objek lainnya.

Unified Modelling Language (UML)

 22

Unified Modeling Language (UML) merupakan salah satu bentuk

language atau bahasa, menurut pencetusnya UML di definisikan sebagai bahasa

visual untuk menjelaskan, memberikan spesifikasi, merancang, membuat model,

dan mendokumentasikan aspek-aspek dari sebuah sistem. Definisi ini merupakan

definisi yang sederhana. Pada kenyataannya, pendapat orang-orang tentang UML

berbeda satu sama lain. Hal ini dikarenakan oleh sejarahnya sendiri dan oleh

perbedaan persepsi tentang apa yang membuat sebuah proses rancang-bangun

perangkat lunak efektif (Martin 2005:1).

Pada tahap analisis, meliputi usaha untuk mengetahui apa kemampuan

sebuah sistem yang diinginkan pengguna dan pelanggan dari sebuah perangkat

lunak. Beberapa teknik yang dapat membantu dalam tahapan analisis (Martin

2005:44) :

1. Use case Diagram adalah gambaran umum sistem dari sudut pandang

pengguna sistem. Tujuan dari use case adalah untuk menggambarkan

apa yang sistem dapat lakukan. Use case diagram dibentuk dari

skenario tentang kegunaan sistem yang dinotasikan dengan sebuah use

case. Setiap skenario menjelaskan suatu alur kegiatan. Setiap skenario

dapat diinisialisasi oleh pengguna sistem atau yang disebut aktor.

2. Class diagram merupakan salah satu diagram struktur statis yang

menggambarkan struktur dan hubungan antar kelas. Class diagram

digunakan untuk mensimulasikan objek-objek dalam dunia nyata ke

dalam sistem yang akan dibangun. Notasi UML pada class diagram

adalah sebuah persegi yang dibagi menjadi 3 area, yaitu nama kelas,
 23

atribut, dan operasi (method). Class diagram dapat juga

menggambarkan keanekaragaman (multiplicity), yaitu jumlah objek

dari suatu kelas yang berhubungan dengan sebuah objek dari kelas

yang berasosiasi.

3. Sequence diagram digunakan terutama untuk menunjukkan interaksi

antar objek dalam urutan sekuensial. Sequence diagram sangat

berguna untuk mengkomunikasikan bagaimana objek-objek

berinteraksi dalam suatu proses bisnis. Analis sistem umumnya

menggunakan sequence diagram untuk memperjelas use case.

Sequence diagram terdiri dari objek-objek yang digambarkan dengan

sebuah persegi yang memiliki nama. Objek- objek tersebut diletakkan

di atas dan diurutkan dari kiri ke kanan. Dari setiap objek, ada garis

putus-putus memanjang ke bawah yang menggambarkan garis hidup

(Life line) suatu objek. Di atas garis hidup tersebut, ada kotak kecil

memanjang yang dinamakan aktivasi. Aktivasi merepresentasikan

eksekusi dari operasi yang objek lakukan.

Pengembangan UML dimulai dari kerja sama Grady Booch dan James

Rumbaugh pada tahun 1994 untuk mengkombinasikan dua metode Booch dan

OMT, kemudian Ivar Jacobson, pencipta metode OOSE (Object Oriented

Software Engineering) berbagung.

UML adalah bahasa grafis untuk mendokumentasi, menspesifikasikan, dan

membangun sistem perangkat lunak. UML merupakan bahasa pemodelan untuk

menspesifikasikan, memvisualisasikan, membangun dan mendokumentasikan

 24

artifak-artifak dari sistem. UML dapat digunakan untuk menerangkan sistem yang

berorientasi pada objek secara lebih jelas dan detail disajikan dalam bentuk

diagram atau gambar yang meliputi class beserta atribut dan operasinya, serta

hubungan antar class yang meliputi inherintance, association, dan komposisi.

Adapun tujuan utama perancangan UML adalah sebagai berikut :

1. Menyediakan bahasa pemodelan visual yang ekpresif dan siap pakai untuk

mengembangkan dan pertukaran mode-model objek yang berarti.

2. Menyediakan mekanisme perluasan dan spesialisasi untuk memperluas

konsep-konsep inti.

3. Mendukung spesifikasi independen bahasa pemrograman dan proses

pengembangan tertentu.

4. Menyediakan basis formal untuk pemahaman bahasa pemodelan.

5. Mendorong pertumbuhan alat bantu yang berorientasi objek.

6. Mendukung konsep-konsep pengembangan level lebih tinggi seperti

komponen, kolaborasi, framework, dan pattern.

UML menyediakan beberapa notasi dan artifak standar yang bisa

digunakan sebagai alat komunikasi bagi para pelaku dalam proses analisis dan

disain. Adapun notasi-notasi dan artifak-artifak yang digunakan dalam Unified

Modelling Language (UML) antara lain sebagai berikut :

Notasi-notasi dalam UML

a. Actor
 25

Actor adalah segala sesuatu yang berinteraksi dengan sistem aplikasi

komputer. Jadi actor ini bisa berupa orang, perangkat keras, atau

mungkin juga objek lain dalam sistem yang sama. Biasanya yang

dilakukan oleh actor adalah memberikan informasi pada sistem dan atau

memerintahkan sistem untuk melakukan sesuatu.

b. Class

Class merupakan pembentuk utama dari sistem berorientasi objek karena

class menunjukkan kumpulan objek yang memiliki atribut dan operasi

yang sama. Class digunakan untuk mengimplementasikan interface.

Class digunakan untuk mengabstraksikan elemen-elemen dari sistem

yang sedang dibangun. Class bisa untuk mempresentasikan baik

perangkat keras maupun perangkat lunak, baik konsep maupun benda

nyata. Notasi class berbentuk persegi panjang berisi tiga bagian, yaitu

persegi paling atas untuk nama class, persegi paling bawah untuk operasi

dan persegi panjang ditengah untuk atribut. Atribut digunakan untuk

menyimpan informasi. Nama atribut menggunakan kata benda yang bisa

dengan jelas mempresentasikan informasi yang bisa dilakukan oleh

objek, dan menggunakan kata kerja.

c. Interface

Interface merupakan kumpulan operasi tanpa implementasi dari suatu

class. Implementasi operasi interface dijabarkan oleh operasi dalam

class. Oleh karena itu keberadaan interface selalu disertai oleh class
 26

yang mengimplementasikan operasinya. Interface ini merupakan salah

satu cara mewujudkan prinsip enkapsulasi dalam objek.

d. Use Case

Use case menjelaskan urutan kegiatan yang dilakukan actor dan sistem

untuk mencapai suatu tujuan tertentu. Walaupun menjelaskan kegiatan,

use case hanya menjelaskan apa yang dilakukan oleh actor dan sistem,

bukan bagaimana actor dan sistem melakukan kegiatan tersebut.

Di dalam use case terdapat teks untuk menjelaskan urutan kegiatan yang

disebut dengan use case spesification, yang terdiri dari:

1. Nama Use Case

Mencantumkan nama dari use case yang bersangkutan. Sebaiknya

diawali dengan kata kerja untuk menunjukkan aktivitas.

2. Deskripsi Singkat (Brief Description)

Menjelaskan secara singkat dalam satu atau dua kalimat tentang

tujuan dari use case ini.

3. Aliran Normal (Basic Flow)

Adalah jantung dari use case. Menjelaskan interaksi antara actor dan

sistem dalam kondisi normal, yaitu segala sesuatu berjalan dengan

lancar, tiada halangan atau hambatan dalam mencapai tujuan dari use

case

4. Aliran Alternatif (Alternate Flow)

 27

Merupakan pelengkap dari basic flow karena tidak ada yang

sempurna dalam setiap kali use case berlangsung. Di dalam alternate

flow ini dijelaskan apa yang akan terjadi bila suatu halangan atau

hambatan terjadi sewaktu use case berlangsung. Ini terutama

berhubungan dengan error yang mungkin terjadi, misalnya karena

sistem kekurangan data untuk diolah.

5. Special Requirement

Berisi kebutuhan lain yang belum tercakup dalam aliran normal dan

alternatif. Biasanya secara tegas dibedakan bahwa basic flow dan

alternate flow menangani kebutuhan fungsional dari use case,

sedangkan special requirement yang tidak berhubungan dengan

kebutuhan fungsional, misalnya kapasitas akses yaitu jumlah user

yang akan mengakses dalam waktu yang bersamaan.

6. Pre Condition

Menjelaskan persyaratan yang harus dipenuhi sebelum use case bisa

dimulai.

7. Post Condition

Menjelaskan kondisi yang berubah atau terjadi pada saat use case

selesai dieksekusi.

e. Interaction

Digunakan untuk menunjukkan baik aliran pesan atau informasi antara

objek maupun hubungan antar objek. Biasanya interaction ini dilengkapi

 28

juga dengan teks bernama Operation Signature yang tersusun dari nama

operasi, parameter yang dikirim dan tipe parameter yang dikembalikan.

f. Package

Adalah kontainer atau wadah konseptual yang digunakan untuk

mengelompokkan elemen-elemen dari sistem yang sedang dibangun,

sehingga bisa dibuat model yang lebih sederhana. Tujuannya adalah

untuk mempermudah penglihatan (visibility) dari model yang sedang

dibangun.

g. Note

Digunakan untuk memberikan keterangan dan komentar tambahan dari

suatu elemen sehingga langsung terlampir dalam model. Note ini bisa

ditempelkan ke semua elemen notasi yang lain.

h. Dependency

Merupakan relasi yang menunjukkan bahwa perubahan dari salah satu

elemen memberikan pengaruh pada elemen lain. Elemen yang ada

dibagian tanda panah adalah elemen yang tergantung pada elemen yang

ada dibagian tanpa tanda panah. Terdapat dua stereotype dependency,

yaitu:

1. Include

Menunjukkan bahwa suatu bagian dari elemen (yang ada digaris

tanpa panah) memicu eksekusi bagian dari elemen lain (yang

berada di garis dengan tanda panah), misalnya untuk notasi A 

 29

B, dibaca: operasi yanga ada di class A memicu dieksekusinya

operasi yang ada di class B.

2. Extend

Menunjukkan bahwa suatu bagian dari elemen digaris tanpa

panah bisa disisipkan ke dalam elemen yang ada di garis dengan

panah. Misalnya untuk notasi A  B, dibaca: suatu fungsi dari

use case A bisa disisipkan ke dalam use case B atau dengan kata

lain A optional untuk B.

Kedua stereotype ini direpresentasikan dengan menambah teks include

atau extend di notasi dependency.

i. Association

Menggambarkan navigasi antar class (Navigation), berupa banyak objek

lain yang berhubungan dengan satu objek (Multiplicity antar Class), dan

apakah suatu class menjadi bagian dari class lainnya (Aggregation).

Navigation dilambangkan dengan penambahan tanda panah di akhir

garis. Bidirectional Navigation menunjukkan bahwa dengan mengetahui

salah satu class bisa didapatkan informasi dari class lainnya.

Undirectional Navigation hanya dengan mengetahui class diujung garis

association tanpa panah kita bisa mendapatkan informasi dari class di

ujung dengan panah, tetapi tidak sebaliknya.

Multiplicity dinotasikan dengan menambahkan teks (1), (0..1), (0..*),

(1..*) atau bilangan terentu (3) dimasing-masing ujung garis association.

Misalnya terdapat hubungan sebagai berikut: A(1..*)---(0..*)B. Cara

 30

membacanya adalah bahwa untuk setiap objek B harus berhubungan

dengan lebih dari satu objek A atau setiao objek A bisa berhubungan

dengan objek B atau tidak sama sekali. Aggregation mengacu pada

hubungan “has-a”, yaitu bahwa suatu class memiliki class lain.

j. Generalization

Menunjukkan hubungan antara elemen yang lebih umum ke elemen

yang lebih spesifik. Dengan generalization, class yang lebih spesifik

(subclass) akan menurunkan atribut dan operasi dari class yang lebih

umum (superclass).

k. Realization

Menunjukkan hubungan bahwa elemen-elemen yang ada di bagian tanpa

panah akan merealisasikan apa yang dinyatakan oleh elemen yang ada

dibagian dengan tanda panah. Misalnya class merealisasikan package,

component merealisasikan class atau interface.

Artifak-artifak dalam UML

Artifak adalah sepotong informasi yang digunakan atau menghasilkan

dalam suatu proses rekayasa software. Artifak dapat berupa model, deskripsi, atau

software. Adapun Artifak-artifak dalam UML adalah sebagai berikut :

a. Use Case Diagram (UCD)

 31

UCD menjelaskan apa yang akan dilakukan oleh sistem yang akan

dibangun dan siap yang berinteraksi dengan sistem. UCD menjadi

dokumen kesepakatan antara customer, user, dan developer. User

menggunakan dokumen UCD untuk memahami sistem dan mengeveluasi

bahwa benar yang dilakukan sistem adalah untuk memecahkan masalah

yang user ajukan atau sedang dihadapi. Developer menggunakan UCD ini

sebagai rujukan yang benar dalam pengembangan sistem. UCD pada

umumnya tersusun dari elemen actor, use case, dependency,

generalization, dan assocition. UCD ini memberikan gambaran statis dari

sistem yang sedang dibangun dan merupakan artifak dari peoses analisis.

b. Realization Diagram

Sebuah use case realization menggambarkan bagaimana sebuah use case

direalisasikan dalam bentuk kolaborasi dari berbagai objek. Use case

dibuat terpisah dari use case realization, hal ini memungkinkan untuk

dapat mengatur satu persatu dan dapat mengubah desain dari use case-use

case tanpa berpengaruh pada “garis dasar” atau “alur” yang ada dalam use

case tersebut. Untuk tiap-tiap use case dalam model use case, terdapat

sebuah use case realization di dalam model desain.

c. Collaboration Diagram

Ini digunakan untuk melihat interaksi dan hubungan terstruktur antar

objek. Tipe diagram ini menekankan pada hubungan (relationship) antar

objek. Dalam collaboration diagram terdapat beberapa object, link, dan

message. Collaboration diagram digunakan sebagai alat untuk

 32

menggambarkan interaksi yang mengungkapkan keputusan mengenai

perilaku sistem.

d. Class Diagram

Class diagram menunjukkan hubungan antara class dalam sistem yang

sedang dibangun dan bagaimana mereka saling berkolaborasi untuk

mencapai satu tujuaan.

Class diagram umumnya tersusun dari elemen-elemen class, interface,

dependency, generalization, association. Relasi dependency menunjukkan

bagaimana ketergantungan terjadi antar class yang ada. Relasi

generalization menunjukkan bagaimana suatu class yang ada menjadi

super-class dari class lainnya dan class yang lain tersebut menjadi sub-

class dari class tersebut. Relasi association menggambarkan navigasi antar

class, berapa banyak objek lain yang bisa berhubungan dengan satu objek

(Multiplicity antar class), dan apakah suatu class menjadi bagian dari class

lainnya (aggregation). Class diagram digunakan untuk menggambarkan

desain statis dari sistem yang dibangun.

e. Sequence Diagram

Sequence Diagram menjelaskan secara detail urutan proses yang

dilakukan dalam sistem untuk mencapai tujuan dari use case, yaitu

interaksi yang terjadi antar class, operasi apa saja yang terlibat, urutan

antar operasi, dan informasi yang diperlukan oleh masing-masing operasi.

Pembuatan sequence diagram merupakan aktivitas yang paling kritikal

 33

dari proses desain karena artifak ini yang nantinya akan menjadi pedoman

dalam proses pemrograman dan berisi aliran kontrol dari progam.

Sequence diagram biasanya tersusun dari elemen-elemen objek,

interaction dan message. Interaction menghubungkan dua objek dengan

pesannya. Diagram ini menjelaskan aspek dinamis dari sistem yang sedang

dibangun.

Untuk satu use case bisa dibuat beberapa sequence diagram, karena satu

use case biasanya terdiri dari beberapa aktivitas yang harus dilakukan dan

masing-masing aktivitas ini bisa direpresentasikan ke dalam satu sequence

diagram.

Rational Rose

Rational Rose adalah software yang memiliki perangkat-perangkat

pemodelan secara visual untuk membangun suat solusi dalam rekayasa sotware

dan pemodelan bisnis. Ratioanal Rose dikeluarkan oleh perusahaan software yang

bernama Rational Software, perusahaan yang mencetuskan ide pembentukan

konsorsium bagi perusahaan-perusahaan yang memakai standar UML sebagai

bahasa pemodelan diperusahaannya. Rational Rose memakai UML sebagai bahasa

pemodelannya, ditambah dengan bebarapa fitur lain yang membuat Rational Rose

menjadi software pemodelan visual yang terkemuka. Beberapa fitur terkemuka

diantaranya Rational Rose memiliki Rational Unified Process (RUP). Selain itu,

Rational Rose memiliki kemampuan membuat solusi client/server, yang kemudian

dapat diterapkan dan didistribusikan dalam lingkungan perusahaan.

 34

Adapun beberapa keunggukan Rational Rose dalam pemodelan adalah sebagai

berikut :

1. Bahasa yang digunakan adalah bahasa pemodelan standar yaitu

UML, akan meningkatkan komunikasi intra tim.

2. Rational Rose mendukung round-trip engineering, sehingga

dapat men-generate model kedalam kode (Java, C++, Visual Basic,

dan sebagainya) dan melakukan reverse engineering untuk

menampilkan arsitektur software dari kode yang ada. Hal ini dapat

dilakukan secara bolak-balik sebagai proses iterative selama proses

rekayasa software.

3. Model dan kode senantiasa singkron selama dalam development

cycle.

4. Membangun software menggunakan Rational Rose memudahkan

dalam memperbaiki software tersebut karena apabila suatu saat

ditemukan requirement baru, kita dapat kembali menggambarkan lagi

software tersebut dalam UML.

5. Para user Rational Rose dapat berkomunikasi walaupun bekerja

dalam sistem operasi yang berbeda (Windows atau UNIX).

C++ Builder

Borland C++ Builder adalah pemrograman yang berorientasi objek,

dengan lingkungan pemrograman visual untuk RAD (Rapid Aplication

Development). Dengan C++ Builder dapat membuat aplikasi windows dengan

 35

efisiensi yang tinggi dengan meminilasi pengkodean manual. C++ Builder

merupakan alat bantu pemrograman yang dikembangkan oleh Borland. Program

ini dikembangkan karena semakin banyaknya perangkat lunak berbasis Windows

dan Linux yang dikembangkan dengan bahasa C dan C++, sehingga software

yang dihasilkan lebih efesien serta meningkatkan performance dan functionallity.

Lingkungan pengembangan C++ Builder atau disebut IDE, mempunyai

beberapa bagian fleksibel yang dapat dipindahkan dimanapun pada layar.

Lingkungan pengembang C++ Builder terdiri dari menu utama, toolbar, dan

component pallete. Bagian lain yang disertakan dan secara otomatis akan

ditampilkan saat C++ Builder start adalah object inspector, code editor, dan

sebuah form.

Dalam C++ Builder terdapat component library yang disertakan yaitu

VCL GUI display components, VCL GUI data-aware components, VCL GUI

input components, VCL GUI control components, dan VCL GUI dialog. Pada

saat ini C++ Builder dipergunakan secara meluas di industri perangkat lunak

untuk mengembangkan produk-produk utamanya serta perangkat lunak lain yang

berguna untuk pengembangan sistem informasi. Selain itu C++ Builder yang

dibangun dari bahasa C++ digunakan untuk memperkenalkan konsep baru di

dunia pemrograman yaitu pemrograman beroreintasi objek.

Gambaran Umum Perusahaan

Perusahaan Gudang Tembakau Langgeng Jaya merupakan perusahaan

perseorangan yang bergerak dalam usaha perdagangan tembakau kering.

 36

Perusahaan Gudang Tembakau Langgeng Jaya didirikan oleh H Mahmud Effendi

pada tanggal 20 Juni 1997. Letak perusahaan ini berada di Kabupaten

Temanggung yang merupakan pusat penghasil tembakau. Pada saat musim panen

para petani menjual tembakaunya kepada gudang yang telah siap menerima

tembakau hasil olahan yang disebut juga dengan tembakau kranjangan.

Perusahaan ini merupakan perusahaan perseorangan yang hanya memiliki

seorang pemimpin perusahaan sekaligus sebagai pemilik perusahaan. Dalam hal

ini perusahaan juga mempunyai bagian-bagian personal untuk menjalankan

operasionalnya. Tembakau yang dibeli dari petani akan melewati beberapa proses

sebelum akhirnya masuk ke gudang. Para petani atau supplier datang ke

perusahaan dengan sampel tembakau yang akan mereka jual yang memiliki

kwalitas yang berbeda-beda. Maka dari itu perusahaan telah menyiapkan personal

yang disebut dengan Kir Master, personal ini bertugas untuk menentukan kwalitas

dan harga dari tembakau yang akan dibeli oleh perusahaan.

Setelah mengetahui jenis kwalitas dan harga tembakau kemudian akan

melewati proses penimbangan. Tembakau dari supplier akan ditimbang

seluruhnya untuk mengetahui total berat. Tembakau yang sudah melewati proses

akan masuk ke gudang dimana pada bagian ini personal gudang akan mencatat

tembakau yang masuk yang telah ditentukan jenis kwalitas, harga, dan total

beratnya. Bagian ini juga akan mencatat bila ada tembakau yang keluar dari

gudang. Adapun dalam perusahaan ini telah ada ketentuan harga dan ketentuan

berat sebagai berikut :

a. Ketentuan Harga
 37

Dalam istilah perusahaan jenis tembakau yang juga kwalitas tembakau sering

disebut dengan tiam barang. Tiam barang ini digunakan untuk menentukan

tipe-tipe tembakau yang masuk kegudang yang meliputi kwalitas dan harga.

Adapun tiam barang telah ditentukan oleh perusahaan dikodekan dengan

huruf. Musim panen pertama tembakau biasanya dikodekan huruf A dengan

harga Rp8000,00 panen tembakau selanjutnya dikodekan dengan B dengan

harga Rp16.000,00 demikian proses tersebut berjalan sampai musim panen

habis dengan harga akan bertambah tiap-tiap kelipatan harga sebesar

Rp8000,00 yang telah ditetapkan oleh perusahaan.

b. Ketentuan Berat

Tembakau masuk yang dibawa supplier terlebih dahulu ditimbang akan

menghasilkan berat bruto dan berat netto. Berat bruto yang juga berat kotor

dikurangi 1 Kg. sehingga akan didapatkan berat bersih atau netto. Berat netto

ini digunakan sebagai patokan untuk menentukan total harga yang diperoleh

supplier. Sedangkan untuk tembakau keluar gudang perusahaan akan

menggunakan berat bruto saja sebagai patokan untuk total harga untuk

pelanggan.