7

BAB 2

LANDASAN TEORI

2.1 Konsep Pemodelan Objek

Pemodelan objek merupakan suatu metode untuk menggambarkan struktur sistem

yang memperlihatkan semua objek yang ada pada sistem. (Nugroho, 2005, hal:37).
Beberapa konsep dasar dalam pemodelan objek adalah objek, kelas, atribut, operasi,
dan hubungan.

2.1.1 Objek dan Kelas

Objek merupakan sesuatu, sebuah entitas, sebuah benda, sesuatu yang dapat diangkat,
atau apapun yang dapat kamu bayangkan yang memiliki identitas masing-masing.
(ODocherty, 2005, hal:13). Ada beberapa objek yang hidup dan ada yang tidak.
Contoh objek dalam dunia nyata yaitu orang, nomor, kucing, dan mobil.

Objek adalah orang, tempat, benda, kejadian, atau konsep-konsep yang ada di
dunia nyata yang penting bagi suatu perangkat lunak. (Nugroho, 2005, hal:38). Objek
orang misalnya mahasiswa, dosen, ibu, ayah, dan sebagainya. Objek tempat misalnya
kampus, negara, jalan, kota, dan sebagainya. Objek benda misalnya mesin, buku,
mobil, komputer, dan sebagainya. Objek kejadian misalnya pembayaran, registrasi
kuliah, mengikuti kuliah, dan sebagainya.

Kelas seperti juga objek, adalah sesuatu yang membungkus (encapsulate)

informasi (atribut) dan perilaku (operasi) dalam dirinya. Dalam pengembangan sistem
tradisional, dilakukan pendekatan dengan cara memisahkan atribut pada sisi basis data
dan operasi pada sisi aplikasi pengakses. Namun hal ini berbeda pada pendekatan
 8

berorientasi objek yang menggabungkan atribut dengan operasi yang akan

mengaksesnya dalam apa yang dinamakan kelas.

Kelas didefinisikan sebagai kumpulan objek dengan atribut yang mirip, operasi
yang mirip, serta hubungan dengan objek yang lain dengan cara yang mirip.
(Nugroho, 2005).

Gambar berikut memperlihatkan suatu kelas dan objek yang mungkin

dihasilkan dengan prosedur instansiasi. Suatu objek merupakan instansiasi dari suatu
kelas jika objek itu merupakan keturunan yang nyata dari suatu kelas.

Instansiasi (Manusia) (Manusia)

Manusia
Adi Ani

Kelas Objek

Gambar 2.1 Kelas dan Objek

2.1.2 Atribut dan Operasi

Setiap objek memiliki identitas dan masing-masing dapat dibedakan. (Nugroho, 2005,
hal:38). Setiap objek memiliki atribut, misalnya sebuah mobil memiliki produsen,
jenis, warna, dan harga, sedangkan seekor kucing memiliki jenis kelamin, jenis, berat,
dan warna. Setiap objek juga memiliki operasi, misalnya mobil dapat bergerak dari
satu tempat ke tempat lain, sedangkan kucing dapat berlari, minum, dan makan.

Atribut adalah informasi-informasi yang dimiliki suatu objek dalam kelas. Dari
contoh di atas dapat ditambahkan, untuk objek Adi dan Ani dapat memiliki atribut
jenis kelamin, usia, berat badan, tinggi badan, dan lain-lain. Dari fakta-fakta ini dapat
dipahami bahwa nilai dari suatu atribut adalah karakteristik yang membedakan satu
objek dengan objek lainnya dalam kelas yang sama.
 9

Instansiasi
Manusia (Manusia) (Manusia)

Nama: String Adi Ani

Usia: Integer 21 23

Kelas dengan atribut Objek dengan nilai pada atribut

Gambar 2.2 Atribut dan Nilai

Operasi atau metode berhubungan dengan perilaku yang berhubungan dengan

suatu kelas. Operasi adalah fungsi atau transformasi yang mungkin dapat
diaplikasikan ke/oleh suatu objek dalam kelas. Contohnya suatu objek dalam kelas
manusia dapat memiliki operasi-operasi seperti tersenyum, berbicara, makan, minum,
dan sebagainya. Contoh lainnya yaitu suatu objek lingkaran memiliki atribut warna,
posisi, dan jari-jari, serta memiliki operasi geser dan pilih. Algoritma dari suatu
operasi dapat dirincikan dengan menggunakan pseudocode yang memiliki bagian-
bagian yaitu nama metode, kamus yang berisi semua nama yang ada dan tipe datanya,
serta algoritma yang berisi uraian langkah-langkah penyelesaian masalah.

Manusia Lingkaran
-Nama -Warna
-Usia -Posisi
+Makan() -Jari-jari
+Berpindah_alamat() +Geser(in Delta : bool)
+Pilih(in Point : object) : bool

Gambar 2.3 Operasi

2.1.3 Hubungan (Relationship)

Ketika menggambarkan kelas-kelas dan objek-objek, akan terlihat bahwa kebanyakan

kelas dan objek adalah berdiri sendiri. Pada kenyataannya, hampir semua kelas dan
objek saling bekerja sama satu sama lain sehingga pada pemodelan kelas dan objek,
setelah kelas dan objek didefinisikan, juga dimodelkan bagaimana kelas-kelas dan
objek-objek saling berhubungan.
 10

2.2 UML

UML adalah keluarga notasi grafis yang didukung oleh meta-model tunggal, yang
membantu pendeskripsian dan desain sistem perangkat lunak, khususnya sistem yang
dibangun menggunakan pemrograman berorientasi objek. (Fowler, 2005, hal: 1).
UML merupakan standar yang relatif terbuka yang dikontrol oleh Object Management
Group (OMG), yang terdiri dari banyak perusahaan. UML lahir dari penggabungan
banyak bahasa pemodelan grafis berorientasi objek antara lain metode Booch oleh
Graddy Booch, metode Object Modelling Technique (OMT) oleh DR. James
Rumbaugh, dan metode Object Oriented Software Engineering (OOSE) oleh Ivar
Jacobson.

Dengan UML, dapat dibuat model untuk perangkat lunak, dimana perangkat
lunak tersebut dapat berjalan pada perangkat keras, sistem operasi dan jaringan
apapun, serta ditulis dalam bahasa pemrograman apapun. Namun, karena UML juga
menggunakan kelas dan operasi dalam konsep dasarnya, maka UML lebih cocok
untuk pemodelan perangkat lunak dalam bahasa berorientasi objek seperti C++, Java,
C# atau VB.NET.

2.2.1 Analisis Persyaratan dengan UML

Analisis persyaratan meliputi usaha untuk mengetahui apa kemampuan sebuah sistem
yang diinginkan pengguna dan pelanggan dari sebuah pengembangan perangkat lunak.
Beberapa diagram yang digunakan dalam analisis persyaratan yaitu:
1. Use case diagram yang digunakan untuk menggambarkan bagaimana orang-orang
berinteraksi dengan sistem tersebut.
2. Activity diagram yang berfungsi menunjukkan aliran kerja organisasi tersebut
yang dapat menunjukkan bagaimana aktivitas interaksi antara perangkat lunak dan
manusia. Activity diagram dapat menunjukkan konteks use case dan juga rincian
bagaimana sebuah use case berjalan.
3. Class diagram yang diambil dari sudut pandang konseptual, dapat berfungsi untuk
membangun kosakata yang besar mengenai domain tersebut.
4. Package diagram untuk mengelompokkan kelas-kelas.
 11

2.2.2 Desain dengan UML

Beberapa diagram yang digunakan dalam mendesain sistem yaitu:

1. Use case diagram yang digunakan untuk menggambarkan bagaimana orang-orang
berinteraksi dengan sistem tersebut.
2. Sequence diagram untuk mengetahui apa yang terjadi dalam perangkat lunak.
3. Class diagram dari sudut perangkat lunak. Diagram ini menunjukkan kelas yang
terdapat di dalam perangkat lunak dan bagaimana mereka saling berhubungan.
4. Package diagram untuk menunjukkan organisasi berskala besar perangkat lunak
tersebut.
5. Penggunaan deployment diagram untuk menunjukkan susunan fisik perangkat
lunak tersebut.

2.2.3 Teknik Analisis dan Desain Sistem dengan UML

Teknik yang digunakan dalam pemodelan analisis dan desain sistem menggunakan
UML diantaranya:
1. Pengidentifikasian proses bisnis sistem yang terjadi di lapangan.
2. Pengidentifikasian fungsionalitas sistem dengan penggunaan use case diagram.
3. Pengidentifikasian skenario sistem berdasarkan use case diagram dengan
penggunaan activity diagram.
4. Pengidentifikasian kelas-kelas yang terdapat dalam sistem dengan penggunaan
class diagram.
5. Pengidentifikasian hubungan inheritance antara kelas.
6. Pengidentifikasian atribut-atribut yang dimiliki setiap kelas.
7. Pengelompokan kelas-kelas dalam package-package tertentu dengan penggunaan
package diagram.
8. Pada setiap use case, dilakukan pengidentifikasian operasi-operasi yang dimiliki
setiap kelas yang terlibat dalam use case tersebut.
9. Pengidentifikasian objek-objek, serta penggunaan sequence diagram untuk
mendeskripsikan aliran komunikasi antara objek-objek pada setiap use case.
10. Desain antarmuka sistem dan spesifikasi detail dari bagian-bagian antarmuka yang
berhubungan dengan fungsi sistem.
 12

11. Pengidentifikasian arsitektur fisik sistem dan kebutuhan sistem dengan

penggunaan deployment diagram.

Teknik yang digunakan tidak terbatas pada teori yang diperoleh, namun
berdasarkan kebutuhan pada saat analisis dan desain sistem. Dalam pembangunan
suatu sistem, jenis diagram yang digunakan disesuaikan dengan kebutuhannya.

2.2.4 Diagram-Diagram dalam UML

Dalam UML, dikenal diagram-diagram yang digunakan untuk membantu dalam

analisis dan desain sistem. Dalam skripsi ini, ada beberapa diagram yang digunakan,
yaitu use case diagram, activity diagram, class diagram, sequence diagram, package
diagram, dan deployment diagram.

2.2.4.1 Use Case Diagram

Use case diagram mendeskripsikan interaksi tipikal antara para pengguna sistem
dengan sistem itu sendiri, dengan memberi sebuah narasi tentang bagaimana sistem
tersebut digunakan. (Fowler, 2005). Use case diagram menampilkan aktor, use case,
dan hubungan diantara mereka yang dijabarkan sebagai berikut:

1. Aktor
Aktor adalah seseorang atau sesuatu yang berinteraksi dengan sistem yang sedang
dikembangkan. Aktor bersifat eksternal, yaitu berada di luar lingkup sistem yang
sedang dikembangkan. (Nugroho, 2005). Pengguna sistem merupakan aktor yang
umum di setiap sistem. Aktor disimbolkan dengan:

Aktor

Gambar 2.4 Aktor

 13

Setiap use case diagram memiliki aktor utama yang meminta sistem untuk
memberi sebuah layanan. Aktor utama adalah aktor dengan tujuan yang akan
dipenuhi oleh use case diagram. Aktor selain aktor utama dikenal sebagai aktor
sekunder.

2. Use Case
Use case menggambarkan bagaimana seseorang akan mengunakan atau
memanfaatkan sistem. Use case dapat membantu untuk berfokus pada apa yang
penting, yaitu menentukan apa yang dibutuhkan serta harapan pengguna terhadap
sistem yang dikembangkan. Pengidentifikasian use case dapat dilakukan dengan
melakukan identifikasi pekerjaan-pekerjaan dan fungsi-fungsi apa yang dilakukan
aktor untuk sistem. Use case disimbolkan dengan:

Use case

Gambar 2.5 Use Case

3. Hubungan (relationship)
Aktor dan use case masing-masing tidak berdiri sendiri, melainkan saling
terhubung dengan apa yang dinamakan hubungan. Ada beberapa hubungan yang
dikenal dalam use case diagram, yaitu:
a. Hubungan asosiasi (association relationship)
Hubungan asosiasi merupakan hubungan yang biasa terjadi antara aktor dan
use case yang menggambarkan bahwa aktor melakukan apa yang dinyatakan
dalam use case. Hubungan disimbolkan dengan:

Use case
Aktor

Gambar 2.6 Hubungan Asosiasi

 14

b. Hubungan cakupan (include relationship)

Hubungan cakupan memungkinkan suatu use case untuk menggunakan
fungsionalitas yang disediakan oleh use case lainnya. Hubungan ini dapat
membantu dalam beberapa kasus seperti pada kasus dimana dua atau lebih use
case memiliki sejumlah besar fungsi yang identik, maka fungsi-fungsi yang
sama dapat dipisahkan menjadi suatu use case tersendiri, sehingga use case
lain dapat memiliki hubungan cakupan dengan use case yang baru. Hubungan
cakupan disimbolkan dengan:

<<incl ude>>

NewUseCase1 NewUseCase2

Gambar 2.7 Hubungan Cakupan

c. Hubungan perluasan (extends relationship)

Hubungan perluasan memungkinkan suatu use case memiliki kemungkinan
untuk memperluas fungsionalitas yang disediakan use case lainnya. Hubungan
perluasan disimbolkan dengan:

<<extend>>

NewUseCase1 NewUseCase2

Gambar 2.8 Hubungan Perluasan

d. Hubungan generalisasi (generalization relationship)

Hubungan generalisasi digunakan untuk memperlihatkan bahwa beberapa
aktor atau use case memiliki sesuatu hal yang bersifat umum. Generalisasi
berguna untuk mengelompokkan sifat-sifat yang umum dari sejumlah aktor
 15

atau use case menjadi aktor atau use case tunggal, kemudian bisa mewariskan
sifat-sifat umum tadi ke sejumlah aktor atau use case yang lain. Hubungan
generalisasi disimbolkan dengan:

Gambar 2.9 Hubungan generalisasi

2.2.4.2 Activity Diagram

Activity diagram secara sepintas mirip dengan diagram alir (flowchart) yang
memperlihatkan aliran kendali dari suatu activity ke activity lainnya. Activity diagram
juga dapat digunakan untuk memodelkan langkah-langkah dalam sebuah use case.
(Reed, 2001).

Dalam membangun activity diagram dikenal beberapa komponen, yaitu:

1. Awal dan akhir activity
Simbol yang digunakan untuk awal activity yaitu:

Mulai

Gambar 2. 10 Simbol Awal Activity

Mirip dengan simbol awal activity, simbol yang digunakan untuk

menandakan akhir dari activity diagram yaitu:
 16

Gambar 2. 11 Simbol Akhir Activity

2. Action state dan activity state

Action state merupakan langkah-langkah dalam activity diagram, dimana state
mencerminkan eksekusi dari suatu aksi pada objek. Misalnya pemanggilan operasi
pada sebuah objek, menciptakan objek, atau menghancurkan objek. Pekerjaan
suatu action state secara umum dipertimbangkan mengambil waktu eksekusi yang
tidak signifikan. Action state pada umumnya bersifat atomik, pekerjaannya tidak
dapat didekomposisi lebih lanjut. Action state pada activity diagram disimbolkan
dengan:

X= X+1

Gambar 2.12 Action State

Activity state dapat didekomposisi lebih lanjut, activity state dapat

ditampilkan dengan activity diagram yang lain. Activity state tidak bersifat atomik,
yang secara umum berarti membutuhkan beberapa waktu untuk terselesaikan
dengan tuntas. Activity state pada activity diagram disimbolkan dengan:
17
 18

keluar. Pada joining, aliran konkuren yang masuk akan saling menunggu satu
sama lain sebelum melanjutkan ke titik-titik selanjutnya. Forking dan joining
dilambangkan dengan:
 19

Gambar 2.17 Kelas, atribut, dan operasi

2. Hubungan
Hubungan memiliki beberapa bentuk, yaitu:
a. Asosiasi
Asosiasi merupakan hubungan antara dua atau lebih kelas yang
menspesifikasikan hubungan antara bagian-bagian mereka. Hubungan antara
dua buah kelas mengindikasikan bahwa objek pada kelas yang satu
mengenali objek pada kelas yang lain dan dapat mengirimkan pesan kepada
objek tersebut. Asosiasi memiliki multiplisitas yang memberi petunjuk tentang
banyaknya instansi dari suatu kelas berhubungan dengan satu instansi kelas
yang lain pada satu waktu tertentu. Dalam UML, notasi-notasi multiplisitas
yang dapat digunakan yaitu:

Tabel 2.1 Multiplisitas

Multiplisitas Arti
Satu 1
Nol atau banyak (tak terbatas) * (0..*)
Satu atau banyak 1..*
Nol atau satu (asosiasi pilihan) 0..1
Jangkauan tertentu 2..4
Multiple, jangkauan disjoint 2, 4..6, 8

Asosiasi biasanya diberi nama untuk menggambarkan artinya. Asosiasi

juga memiliki role, yaitu ujung dari suatu asosiasi yang terhubung ke kelas.
 20

Gambar 2.18 Asosiasi

b. Agregasi dan komposisi

Agregasi merupakan bentuk hubungan antara suatu keseluruhan ke bagian-
bagiannya.

Gambar 2.19 Agregasi

Komposisi adalah bentuk yang lebih kuat dari agregasi. Bagiannya

merupakan milik satu-satunya dari keseluruhan.

Gambar 2.20 Komposisi

c. Generalisasi
Generalisasi diperlukan untuk memperlihatkan hubungan pewarisan
(inheritance) antarunsur dalam class diagram. Pewarisan memungkinkan suatu
 21

kelas mewarisi semua atau sebagian atribut, operasi, hubungan, serta semantik
dari kelas yang berada di atasnya dalam hierarki pewarisan.

Gambar 2.21 Generalisasi

d. Dependency
Dependency menghubungkan dua kelas atau lebih dimana jika terdapat
perubahan pada kelas yang satu, maka akan memaksa terjadinya perubahan
pada kelas yang lainnya walaupun tidak terdapat asosiasi yang jelas diantara
mereka.
e. Realisasi
Hubungan realisasi digunakan untuk memperlihatkan hubungan antara suatu
kelas dengan interface-nya, antara package dengan interface-nya, antara
komponen dengan interface-nya, atau antara use case dengan realisasi use case
yang bersangkutan.

Gambar 2.22 Hubungan Realisasi

3. Constraint dan notes

Constraint dan notes memberikan keterangan pada bagian-bagian seperti asosiasi,
atribut, operasi, dan kelas. Constraint merupakan batasan semantik yang ditandai
dengan ekspresi boolean.
 22

Gambar 2.23 Constraint dan Notes

4. Stereotype
Kelas mempunyai stereotype, yang menyediakan kemampuan untuk membuat
elemen pemodelan yang baru. Beberapa stereotype yang umum untuk suatu kelas
adalah : entiti, boundary, dan control.

Kelas entiti merefleksikan entiti dunia nyata. Kelas entiti biasanya

independent dari sekitarnya, dan tidak tahu bagaimana cara sekitarnya
berkomunikasi dengan sistem. Aplikasinya independent, artinya bisa digunakan
untuk lebih dari satu aplikasi. Kelas entiti disebut dengan kelas domain karena
berhubungan dengan abstraksi entiti dunia nyata. Kelas boundary menangani
komunikasi antara lingkungan sistem dan yang ada di dalam sistem, menyediakan
interface bagi user atau sistem lain (misalnya interface ke aktor). Kelas control
memodelkan urutan behavior spesifik terhadap satu atau lebih use case. Kelas
control mengkoordinasi event yang diperlukan untuk merealisasikan behavior
spesifik dalam use case. Kelas control biasanya merupakan kelas yang tergantung
pada aplikasi. Kelas control bertanggung jawab terhadap arus event dalam use
case.

2.2.4.4 Sequence Diagram

Sequence diagram digunakan untuk melihat behavior beberapa objek di dalam

use case tunggal. Sequence diagram baik untuk memperlihatkan kolaborasi
antarobjek.

Masing-masing sequence diagram menggambarkan aliran-aliran pada suatu

use case. Sequence diagram dapat dibaca dengan melihat pada objek-objek dan pesan-
 23

pesan (message). Objek-objek yang berperan dalam aliran diperlihatkan pada kotak
empat persegi panjang yang melintas pada bagian atas diagram. Setiap objek memiliki
garis hidup (lifeline), yang digambarkan sebagai garis vertikal di bawah nama suatu
objek. Garis hidup dimulai pada saat objek terbentuk. Pesan-pesan digambarkan di
antara garis hidup yang dimiliki dua objek untuk memperlihatkan bagaimana objek-
objek itu saling berkomunikasi.

objek1:Class1 objek2:Class2

: Aktor

Gambar 2.24 Sequence Diagram

2.2.4.5 Package Diagram

Kelas menunjukkan bentuk dasar penyusunan sebuah sistem borerientasi objek.

Meskipun kelas berguna, dibutuhkan sesuatu yang lebih untuk menyusun sistem-
sistem yang lebih besar. Sebuah package adalah sebuah bentuk pengelompokan yang
memungkinkan untuk mengambil setiap bentuk di UML dan mengelompokkan
elemen-elemennya dalam tingkatan unit yang lebih tinggi. Kegunaan package yang
umum adalah mengelompokkan kelas. Sebuah package dapat terdiri dari sub package
dan kelas. Setiap kelas harus memiliki nama unik di dalam packagenya. Dalam
diagram, package disimbolkan dengan sebuah folder berlabel:
 24

NewPackage

Gambar 2.25 Package

2.2.4.6 Deployment Diagram

Deployment diagram menunjukkan susunan fisik sebuah sistem, menunjukkan bagian

perangkat lunak mana yang berjalan pada perangkat keras yang mana. Deployment
diagram menggambarkan simpul (node) yang saling berhubungan. Simpul adalah
elemen fisik yang ada saat aplikasi dijalankan dan mencerminkan suatu sumber daya
komputasi, secara umum menggunakan kapasitas memori dan kemampuan
pemrosesan. Diagram dengan simpul umum digunakan pada pemodelan client server
dimana komponen-komponen suatu aplikasi disebarkan pada tiap-tiap server dengan
tujuan mencapai kinerja yang optimum. Simpul disimbolkan dengan kubus. Hubungan
antarsimpul dilambangkan dengan garis lurus.

Processor
Device

Gambar 2.26 Simpul-Simpul pada Deployment Diagram

Processor
Device

Gambar 2.27 Hubungan Antarsimpul