2.3.  Definisi Object dan Class

            Object adalah gambaran dari entity, baik dunia nyata atau konsep dengan batasan-batasan dan pengertian yang tepat. Objek bisa mewakili sesuatu yang nyata seperti komputer,mobil atau dapat berupa konsep seperti proses kimia, transaksi bank, permintaan pembelian, dll. Setiap objek dalam sistem memiliki tiga karakteristik yaitu State(Status), Behaviour(Sifat) dan Indentity(identitas).

            Class adalah deskripsi  sekelompok objek dari property(atribut), sifat (operasi), relasi antar objek  dan sematik yang umum. Class merupakan template untuk membentuk objek. Setiap objek  merupakan contoh dari beberapa class dan objeck tidak dapat menjadi contoh lebih dari satu class.

            Penamaan Class menggunakan kata benda tunggal yang merupakan abstraksi yang terbaik. Pada UML Class digambarkan dengan segi empat yang dibagi. Bagian atas merupakan nama dari class. Bagian yang tengah merupakan struktur dari class(atribut) dan bagian bawah merupakan sifat dari class(operasi).

Gambar 3. Class

2.4.   Status( State ), Behaviour dan Identify

            Status dari Objek adalah satu kondisi yang mungkin ada. Status dari objek akan berubah setiap waktu dan ditentukan oleh sejumlah properti(atribut) dengan nilai dari proprti, ditambah relasi objek dengan objek lainnya.

            Sifat( Behaviour ) menentukan bagaimana objek merespon permintaan dari objek lain dan melambangkan setiap objek yang dapat dilakukan. Sifat ini diimplementasikan dengan sejumlah operasi untuk objek.

Identitas( Identify ) artinya setiap objek yang unik

Pada UML Objek digambarkan dengan segiempat dan nama dari objek diberi garis bawah.

 Gambar 4. Objek

2.5. Mendefinisikan Class

Seperti telah dijelaskan sebelumnya, stereotypes memberikan kemampuan untuk membuat elemen pemodelan yang baru. Beberapa stereotype untuk class adalah : entity, boundary, control, utility dan exception.

Class dengan stereotypes digambarkan dengan menambahkan  <<jenis_stereotype>>  atau dengan menggambarkan dengan suatu icon. Contoh

Gambar 5. Class dengan Stereotype

Rational Objectory Process menyarankan untuk menemukan class-class dalam sistem yang sedang dibangun dengan mencari class : boundary, control dan entity. Ketiga stereotypes ini menggambarkan sebuah sudut pandang model-view-controller sehingga membuat analis dapat membagi sistem dengan memisahkan sudut pandang dari domain dari control yang dibutuhkan oleh sistem.

Karena proses analisa dan desain adalah iterasi, daftar class akan berubah sesuai waktu. Class awal mungkin tidak akan menjadi class yang akan diimplementasikan. Sehingga kandidat class sering digunakan untuk menggambarkan himpunan awal dari class yang ditemukan pada sistem.

1. Entity Class

Entity class memodelkan informasi dan operasi yang biasanya berumur panjang/lama.  Tipe class ini menggambarkan entitas dunia nyata atau entitas yang dibutuhkan untuk melakukan tugas internal sistem.Mereka biasanya tidak terikat oleh komunikasi antara sistem dengan lingkungannya. Kebanyakan, mereka tidak terikat oleh aplikasi, artinya mereka dapat digunakan lebih dari satu aplikasi. Entity class biasanya merupakan class yang dibutuhkan sistem untuk menyelesaikan beberapa kewajiban. Entity class biasanya ditemukan dalam phasa eloborasi. Entity class sering disebut domain class karena mereka berhubungan dengan dunia nyata.

2. Boundary Class

Boundary class menangani komunikasi antara lingkungan sistem dan kedalam sistem. Mereka dapat menjamin interface ke pengguna atau sistem lain ( misalnya, interface ke actor ). Boundary class digunakan untuk memodelkan sistem interface.

Setiap pasangan actor/skenario ( sebuah instance dari use case,   ) diperiksa untuk menemukan boundary class. Boundary class yang ditemukan pada phasa elaboration biasanya pada high level. Sebagai contoh, anda sedang mendesign windows tetapi anda tidak memodelkan semua dialog box dan tombol. Anda hanya sedang mendokumentasikan kebutuhan antar muka, bukan mengimplementasikan antar mukanya. Pada saat design, class-class ini diperbaiki untuk dipertimbangkan memilih antar mukanya

3. Control Class

Control class memodelkan urutan kelakukan ( behavior ) khusus untuk satu atau lebih use case. Pada awal phasa Elaboration, sebuah control class ditambahkan untuk setiap pasangan actor atau use case. Control class bertanggung jawab untuk aliran kejadian-kejadian dalam use case.

Penambahan control class per pasangan actor atau use case hanya merupakan initial cut, pada analisa dan design, control class mungkin dihilangkan, dipecah atau digabung.

Untuk merancang class diagram, Rational Unified Process yang merupakan hasil pengembangan dari Rational Objectory Process menggunakan Use case realization yang menggambarkan bagaimana realisasi dari setiap use case yang ada pada use case model. Untuk menggambarkan bagaimana realisasi dari suatu use case dapat menggunakan beberapa diagram, diantaranya adalah Class Diagram owned by Use Case Realization serta Interaction Diagram.

Untuk menggambarkan use case realization disini akan menggunakan class diagram owned by use case realization. Setiap use case yang ada dibreakdown sehingga akan dapat terlihat entitas-entitas apa saja yang terlibat dalam merealisasikan sebuah use case. Entitas-entitas ini akan menjadi kandidat kelas dalam Class Diagram.

2.6. Relasi dalam Object

Semua sistem terdiri dari class-class dan object. Kelakuan sistem dicapai melalui kerjasama antar object, contohnya : seorang mahasiswa ditambahkan dalam daftar kelas, jika daftar kelas memperoleh message  untuk menambahkan mahasiswa. Interaksi antar object disebut object relationship. Dua tipe relationship yang ditemukan pada saat analisis adalah association dan aggregation. 

1. Association Relationships

Association adalah hubungan semantik bidirectional diantara class-class. Ini bukan aliran data sebagaimana pada pemodelan design dan analisa terstruktur, data diperbolehkan mengalir dari kedua arah. Association diantara class-class artinya ada hubungan antara object-object pada kelas-kelas yang berhubungan. Banyaknya object yang terhubung tergantung dengan multiplicity pada association, yang akan dibahas nanti.

Gambar 6.  Relasi Association

2. Aggregation Relationships

Aggregation Relationships adalah bentuk khusus dari association dimana induk terhubung dengan bagian-bagiannya.  Notasi UML untuk relasi aggregation adalah sebuah association dengan diamond putih  melekat pada class yang menyatakan induk. Contoh, Course Tugas Akhir terdiri atas CourseOffering Tugas Akhir 1 dan CourseOffering Tugas Akhir 2.

Gambar 7.  Relasi Aggregation

3. Penamaan Relationship

Sebuah association dapat diberi nama. Biasanya digunakan kata kerja aktif atau klausa kata kerja dengan cara pembacaan dari kiri ke kanan atau atas ke bawah. Agregation tidak diberi nama karena agregation menggunkan kata “mempunyai” atau “terdiri”.

4. Indikator Multiplicity

Walaupun multiplicity ditentukan untuk class, multiplicity menentukan banyaknya object yang terlibat dalam relasi. Multiplicity menentukan banyaknya obyek yang terhubung satu dengan yang lainnya. Indikator multiplicity terdapat pada masing-masing akhir garis relasi, baik pada association maupun aggregation. Beberapa contoh multiplicity adalah :

1               Tepat satu

0..*           Nol atau lebih

1..*           Satu atau lebih

0..1           Nol atau satu

5..8           range 5 s.d. 8

4..6,9        range 4 s.d. 6 dan 9

Gambar 8.  Multiplicity

 

• Sebuah object MK Ditawarkan berelasi dengan tepat satu object Dosen, misal : MK Perancangan Basis Data berelasi dengan Prof. Scott Tiger.
• Sebuah object Dosen berelasi dengan nol atau empat MK ditawarkan. Misal : Prof. Scott Tiger berelasi dengan Sistem Berkas, Perancangan Basis Data, Metode Berorientasi Obyek dan Basis Data Lanjut.

5. Reflexive Relationships

Multiple object pada class yang sama dapat saling berkomunikasi satu dengan yang lainnya. Hal ini ditunjukkan pada class diagram sebagai reflexive association atau aggregation. Penamaan role lebih disukai untuk digunakan pada reflexive relationships daripada penamaan association relationship.

Gambar 9.  Relasi Reflexive

6. Package Relationship

Relasi yang digunakan dalam package relationship adalah dependency relationship. Jika sebuah package A tergantung pada package B, hal ini berakibat satu atau lebih class-class di package A memulai berkomunikasi dengan satu atau lebih public class di package B. Package A disebut Client package dan Package B disebut Supplier package.

Gambar 10.  Relasi Package

7. Menemukan Relationships

Untuk menemukan relationships class-class yang ada dapat dilakukan dengan memeriksa skenario dan pertukaran message diantara class-class yang ada. Pada tahap analisa, dua relationship yang ditemukan adalah association dan aggregation. Dikarenakan metode yang digunakan merupakan iterative maka relationship akan berubah seiring dengan phasa analisis dan design.

2.7  Class Diagram

Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek. Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi).

Class adalah kumpulan objek-objek yang mempunyai struktur umum, behavior umum, relasi umum, dan semantic/kata yang umum. Class ini sebenarnya merupakan blue print dari  sebuah objek.  Dengan  mendeklarasikan  suatu  class,  maka  kita  telah  mendeklarasikan  suatu tipe data baru (tipe data referensi).

Class diagram  menggambarkan struktur dan deskripsi  class, package  dan objek beserta hubungan satu sama lain seperti  containment , pewarisan, asosiasi, dan lain-lain.

Class memiliki tiga area pokok :

1. Nama (dan stereotype)
2. Atribut
3. Metoda

Atribut dan metoda dapat memiliki salah satu sifat berikut :

• Private , tidak dapat dipanggil dari luar class yang bersangkutan
• Protected , hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya
• Public , dapat dipanggil oleh siapa saja

Class dapat merupakan implementasi dari sebuah  interface , yaitu  class abstrak yang hanya memiliki metoda. Interface  tidak dapat langsung diinstansiasikan, tetapi harus diimplementasikan dahulu menjadi sebuah class.  Dengan demikian interface  mendukung resolusi metoda pada saat  run-time .

Penggambaran  dari  sebuah class  berupa  icon  persegi  yang  memiliki  tiga  bagian  ruang didalamnya seperti gambar berikut ini:

–  Kolom paling atas merupakan representasi dari nama kelas.

–  Kolom  yang  tengah  berisi  atribut-atribut  yang  dimiliki  kelas tersebut.

–  Kolom yang terakhir (paling bawah) berisi operasi atau method

Sesuai dengan perkembangan class model, class dapat dikelompokkan menjadi  package. Kita juga dapat membuat diagram yang terdiri atas  package.

Hubungan Antar Class 

1. Asosiasi, yaitu hubungan statis antar  class . Umumnya menggambarkan  class yang memiliki atribut berupa  class lain, atau class yang harus mengetahui eksistensi  class lain. Panah navigability  menunjukkan arah  query antar  class.
2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”).
3. Pewarisan, yaitu hubungan hirarkis antar class.  Class dapat diturunkan dari  class lain dan mewarisi semua atribut dan metoda class asalnya dan menambahkan fungsionalitas baru, sehingga ia disebut anak dari  class yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi.
4. Hubungan dinamis, yaitu rangkaian pesan (message) yang di- passing dari satu  class kepada class lain. Hubungan dinamis dapat digambarkan dengan menggunakan  sequence diagram yang akan dijelaskan kemudian.

Definisi Class Diagram 

Class diagram adalah diagram yang digunakan untuk menampilkan beberapa kelas serta paket-paket  yang  ada  dalam sistem/perangkat  lunak  yang  sedang  kita kembangkan dimana diagram  ini memberi  kita gambaran  (diagram  statis)  tentang  sistem/perangkat  lunak dan relasi-relasi yang ada di dalamnya.

–  Atribut : merupakan  properti  dari  sebuah  kelas yang  melambangkan  nilai-nilai yang mungkin ada pada kelas tersebut.

Atribut merupakan data yang dimiliki suatu objek dalam  kelas. Setiap atribut akan memiliki nilai berbeda untuk setiap objek

Contoh: Kelas manusia misalnya memiliki atribut Nama dan Umur. Untuk kebutuhan  aplikasi  hanya  atribut – atribut  penting  saja  yang  ditampilkan, atribut yang penting disini mungkin berlainan  untuk setiap aplikasi.

Misalnya,  aplikasi  pencatatan  mahasiswa  yang  kuliah  di  perguruan  tinggi tertentu mungkin tidak membutuhkan atribut tinggi badan serta berat badan sedangkan aplikasi untuk event olahraga tertentu mungkin membutuhkan atribut- atribut  tersebut.  Atribut  yang  penting  bagi  aplikasi  tertentu membutuhkan kajian yang mendalam oleh para analis sistem.

–  Operation  atau Method : merupakan behavior(tingkah  laku)  atau  fungsi  yang dapat dilakukan oleh kelas tersebut.

Operasi dan Metode merupakan  fungsi  atau  transformasi  yang  mungkin  dapat  diaplikasikan ke/oleh suatu objek dalam kelas. Misalnya, suatu objek da lam kelas manusia mungkin memiliki fungsi- fungsi: tersenyum, marah, makan, minum dsb.

Operasi  yang  sama  dapat  diterapkan  pada  kelas- kelas  yang  berbeda. Misalnya fungsi makan dapat diterapkan baik pada kelas manusia maupun pada kelas kera, konsep ini yang dimaksud dengan konsep Polimorfisme.

Relasi antar class 

UML  mendefinisikan  beberapa  cara untuk  merepresentasikan  relasi(hubungan) antara kelas, diantaranya adalah sebagai berikut:

1. Association

Dapat  diartikan sebagai relasi “.. has  a..”.  Digambarkan  sebagai  garis  lurus  antara  dua kelas. Namun  tidak  berarti  bahwa  kelas satu  memiliki/dimiliki kelas  yang  lain,  tetapi kelas lain dapat berelasi juga dengan kelas yang sama.

2.  Directed Association

Relasi  seperti asosiasi namun menggambarkan  objek  atau  aliran  kejadian  berasal  dari salah satu kelas, sedang kelas yang lainnya bersifat pasif.

3. Aggregation

Dapat  diartikan  sebagai “..owns  a  ..”(“terdiri  atas..”). Terdapat  kelas sebagai  part  class (kelas  bagian)  yang  merupakan bagian  dari  kelas  lain(whole  class). Namun  jika whole class tidak ada, part class masih dapat berdiri sendiri.

Apabila  kelas  person dihilangkan, maka  alamat  rumah  masih  dapat berdiri sendiri.

4. Composition

Bisa disebut  juga sebagai strong  agregation, dapat diartikan “..is part of..” (“..bagian dari..”). Seperti halnya relasi agregasi, namun apabila whole class hilang, maka mustahil part class untuk ada.

Apabila kelas mobil dihilangkan, maka tangki BBM mobil ikut hilang.

5. Generalization

Dapat  diartikan  sebagai  relasi “..is a..” Digunakan untuk merepresentasikan  pewarisan. Suatu kelas (child class) dapat diturunkan dari kelas lain dan mewarisi semua atribut dan method induknya (parent class) dan dapat menambah method atau atribut baru.

Sebagai contoh kucing, srigala, singa, macan adalah hewan. Maka bisa dibuat relasi antar kelas seperti berikut ini:

6. Dependency

Merupakan hubungan  ketergantungan  antar  kelas.  Suatu  kelas  memiliki ketergantungan terhadap  kelas  lain,  tetapi  tidak  berlaku  sebaliknya. Perubahan  pada  salah  satu  elemen kelas (pemasok) berdampak pada kelas lain (klien).

7. Realization

Adalah sebuah relasi antar dua class yang mengharuskan class yang satu harus mengikuti aturan  dari  class  yang  lainnya.  Biasanya  terjadi  antara  kelas  dengan antarmuka (interface)

Visibility 

Untuk menentukan visibilitas (nilai yang diijinkan untuk dilihat atau di akses) anggota kelas  (yaitu,  atribut  atau  method)  terdapat  notasi  berikut  yang  harus  ditempatkan  sebelum nama anggota kelas.

+  public  :  visibilitas yang  menunjukkan  bahwa  anggota  kelas  tersebut dapat  diakses oleh  kelas  lain  sekalipun  tidak  mewarisi  kelas  yang bersangkutan namun masih memiliki relasi dengan kelas tersebut.

#  protected  :  menunjukkan  bahwa  anggota  kelas  tersebut hanya  dapat  dipanggil oleh kelas yang bersangkutan dan kelas anak yang mewarisinya.

– private : menunjukkan bahwa anggota kelas tersebut hanya dapat dipanggil oleh kelas yang bersangkutan dan tidak dapat dipanggil oleh kelas lain.

~  package  :  menunjukkan  atribut  tersebut  dapat dilihat oleh kelas lain  yang  masih terdapat dalam paket yang sama.

Cardinalitas 

Cardinalitas  atau  multiplicity adalah  simbol  yang menunjukkan  jumlah instansiai dari satu kelas terkait dengan kelas lainnya.

Multiplisitas 

Multiplisitas menunjukan jumlah suatu objek yang bisa berhubungan dengan objek lain. Multiplisitas biasa ditunjukan dengan “satu” serta “banyak”, tetapi secara khusus dapat ditunjukan pula dengan bilangan integer lebih besar atau sama dengan nol. Contoh – contoh bilangan yang bisa digunakan adalah “1”  (satu- dan – hanya- satu),  “1+”  (satu  atau  lebih),  “1 – 4”  (satu  hingga empat), “1,3,5” (satu atau tiga atau lima), dan seterusnya.

Selain itu juga dikenali simbol- simbol khusus yang dapat diterapkan dalam multiplisitas ini. Lingkaran berisi menunjukan “banyak”, sedangkan lingkaran kosong  berarti  “bukan  keharusan”  (opsional),  yaitu  nol  atau  satu.  Garis tanpa lingkaran (baik kosong maupun berisi) menunjukan hubungan satu- ke- satu.

Berikut contoh multiplisitas

Gambar  diatas  menunjukan  bahwa  suatu  perusahaan  memiliki  “banyak” karyawan sedangkan seorang karyawan pasti bekerja di suatu perusahaan tertentu.

Pada umumnya multiplisitas (seperti halnya kardinalitas dalam ERD) memiliki nilai “satu” atau “banyak”.

Contoh  1

Implementasi class diagram buku ke dalam program

Contoh 2

BAB III

PENUTUP

3.1.  Kesimpulan

Objek adalah model eksekusi. Sementara kelas adalah deskripsi statik dan objek yang mungkin lahir pada saat eksekusi. Pada saat eksekusi yang kita punya adalah objek, sementara dalam pemodelan (analisis dan perancangan) dan teks program yang  kita lihat adalah kelas.

               Unified Modeling Language (UML) adalah bahasa pemodelan umum yang digunakan untuk melakukan spesifikasi, visualisasi, konstruksi dan dokumentasi artifak dari software system. UML bukanlah sebuah standar proses pengembangan dalam metode pengembangan sistem tertentu, namun pada umumnya UML dipakai dalam memodelkan sistem yang dibangun berbasiskan objek. Dengan menggunakan UML kita dapat membuat model untuk semua jenis aplikasi piranti lunak, dimana aplikasi tersebut dapat berjalan pada piranti keras, sistem operasi dan jaringan apapun, serta ditulis dalam bahasa pemrograman apapun.

3.2.  Saran

UML adalah suatu bahasa perancangan modern yang paling umum dipakai pada saat ini, dimana UML ini sering dikaitkan dengan bahasa pengembangan piranti lunak berbasis objek. Dengan menggunakan UML sebagai bahasa perancangan maka kita dapat membuat suatu rancangan piranti lunak yang dimana bahasa tersebut menyatukan berbagai praktik-praktik terbaik dalam permodelan, sehingga hasil rancangan kita dapat dimengerti secara umum dan universal.

Dengan menggunakan UML, maka kita dapat berinteraksi lebih mudah dengan para perancang piranti lunak yang lain, karena kita memakai bahasa perancangan UML yang bersifat universal, dan diketahui oleh hampir semua perancang piranti lunak. Sehingga kita dapat saling bertukar pikiran atas rancangan yang kita buat dengan perancang lain, dan menghilangkan gap dalam perbedaan bahasa permodelan.

DAFTAR PUSTAKA

[1]    Grady Booch, Object-Oriented Analysis and Design with Application, Benjamin/Cummings, 1991.

[2]    Peter Coad and Edward Yourdon, Object-Oriented Analysis, Yourdon Press, 1991.

[3]    Ivar Jacobson, Magnus Christerson, Patrik Jonson, and Gunnar Overgaard, Object Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992.

[4]    James Rumbaugh, Michael Blaha, William Premer lani, Frederick Eddy, and William Lorenson, Object-Oriented Modeling and Design, Prentice Hall, 1991.

[5]    Sally Shlaer and Stephen J. Mellor, Object-Oriented System Analysis: Modeling the World in Data, Yourdon Press, 1988.

[6]    Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener, Designing Object-Oriented Software, Prentice Hall, 1990.

[7]    Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999.

[8]    Ivar Jacobson, Grady Booch, and James Rumbaugh, The Unified Software Development Process, Addison-Wesley, 1999.

[9]    James Rumbaugh, Ivar Jacobson, and Grady Booch, The Unified Modeling Language Reference Manual, Addison-Wesley, 1999.

[10]   Unified Modeling Language Specification, Object Management Group, www.omg.org, 1999.

[11]   Introduction to OMG UML [http://www.om g.org/gettingstarted/what_is_uml.htm]

[12]   UML Tutorial [http://www.sparxsystems.com.au/UML_Tutorial.htm]

[13]   Embarcadero Tech Support [http://www.embarcadero.com/support/uml_central.asp]

[14] Practical UML A Hands-On Introduction for Developers, [http://www.togethersoft.com/s ervices/practical_guides/umlonlinecourse/index.html]

[15]   Architecture and Design: Unified Modeli ng Language (UML), [http://www.cetus-links.org/oo_uml.html]

[16]http://publib.boulder.ibm.com/infocenter/rtnlhelp/v6r0m0/index.jsp topic=%2Fcom.ibm.xtools.modeler.doc%2Ftopics%2Fcdepend.html

[17] http://www.vogella.de/articles/UML/article.html

[18] http://www.smartdraw.com/resources/tutorials/uml-class-diagrams/

[19] http://www.docstoc.com/docs/7634105/CLASS-DIAGRAM-UML

[20]wsilfi.staff.gunadarma.ac.id/Downloads/files/…/Pengenalan+UML.pdferwinharianto.files.wordpress.com/2009/06/totolan-erwin-uml.doc

[21] http://id.wikipedia.org/wiki/UML

[22]http://www.gangsir.com/download/4PendekatanPengembanganSistemBerorientasiObjekdanPenggunaanAlatalatPemodelan.pdf

[23] http://www.scribd.com/doc/26601970/SISTEM-BERORIENTASI-OBJEK

[24] http://www.scribd.com/doc/190201386/Modul-2-Class-Diagram

[25] UML Class Diagram  –  Zulkarnaen NS