Class Diagram dalam Java

Class Diagram

Dalam tahap perencanaan setiap proyek, programmer harus menjelaskan method objek yang berbeda yang diperlukan untuk memenuhi urusan. Namun objek tak dapat muncul tiba-tiba, sehingga kita perlu template yang menggambarkan jenis objek yang akan sistem miliki. Sebagai hasilnya, kita perlu untuk menunjukkan diagram dengan semua kelas yang terlibat dan hubungan antar kelas. Diagram ini disebut Class Diagram. 

Menurut Wikipedia, Class Diagram "dalam Unified Modeling Language (UML) adalah jenis diagram struktur statis yang menggambarkan struktur dari suatu sistem dengan menunjukkan kelas sistem, atribut mereka, operasi (atau metode), dan hubungan di antara obyek". Meskipun definisi ini cukup jelas, kita harus memahami bahwa Class Diagram adalah bagian dari sistem model Logical View. 

Pada gambar berikut, kita akan melihat hubungannya dengan pandangan proyek lain:

Mari Ingat: Konsep Dasar PBO

Kelas A adalah cetak biru (blue print) dari objek yang dihasilkan. Termasuk atribut dan metode dari objek. Sekarang, dalam kehidupan nyata, kita dapat menemukan banyak objek individu dari jenis yang sama. Katakanlah sebuah mobil. Mungkin ada banyak mobil, tapi semua dengan komponen dasar yang sama. Dalam hal ini, konsep kelas mobil (yang dapat dimasukkan ke paket/package) dan banyak mobil di dunia adalah contoh dari kelas itu. Analogi ini berlaku untuk hampir semua hal.

Representasi Package di UML

Dalam UML, paket digambarkan dalam folder dengan tab. Nama paket tertulis di dalam folder atau di tab. Lihat pada diagram berikut:

Sebuah package mengatur elemen UML seperti kelas dan paket lainnya. Diagram berikut merupakan gambaran dari package, kelas, dan sub-package:

Dan kemudian package lebih dalam dapat menggunakan notasi alternatif yang dapat meringankan pekerjaan. Kita dapat mewakili diagram sebelumnya dengan notasi alternatif sebagai berikut:

Rekomendasi: Nama paket dalam huruf kecil. Dalam proyek-proyek kecil itu harus sederhana dan bermakna, tetapi dalam proyek-proyek yang kompleks nama harus dibagi dan spesifik.

Representasi Kelas di UML

Dalam UML, kelas digambarkan dengan sebuah persegi panjang tiga bagian. Bagian atas meliputi nama kelas, bagian tengah meliputi atribut dan bagian bawah meliputi metode. Selain itu, ada empat cara yang berbeda untuk menunjukkan kelas menggunakan notasi UML:

• Nama Kelas + Atribut + Metode

• Nama Kelas + Atribut

• Nama Kelas + Metode

• Nama Kelas

Nama kelas harus mengikuti pola CamelCase. Juga, cobalah untuk menggunakan kata benda karena merupakan objek kehidupan nyata.

Visibilitas

Untuk menerapkan enkapsulasi, kita harus membatasi akses ke atribut, metode dan kelas. Hal ini dilakukan melalui visibilitas. Ada empat jenis visibilitas. Diagram berikut merupakan gambaran dari mereka:

Public

Public memiliki karakteristik visibilitas terlemah. Notasi adalah tanda plus (+). Mendeklarasikan atribut, kelas, atau metode sebagai publik akan membuatnya dapat diakses langsung oleh setiap kelas.

Private

Private adalah visibilitas dengan karakteristik terkuat. Notasi adalah simbol minus (-). Mendeklarasikan atribut, kelas, atau metode sebagai private akan membuatnya hanya dapat diakses untuk kelas itu sendiri.

Protected

Protected adalah salah satu visibilitas karakteristik netral. Notasi adalah simbol hash (#). Mendeklarasikan atribut, kelas, atau metode sebagai protected akan membuatnya lebih terlihat daripada atribut dan metode private, tetapi kurang terlihat daripada yang public. Dengan kata lain, unsur-unsur yang protected dapat diakses oleh kelas yang mewarisi dari kelas kita apakah itu dalam paket yang sama atau tidak.

Package

Package adalah visibilitas dengan karakteristik netral lainnya. Notasi adalah simbol tilde (~). Mendeklarasikan atribut, kelas, atau metode sebagai package akan membuatnya hanya terlihat oleh setiap kelas dalam package yang sama. Tidak masalah jika kelas lain dari package lain mewarisi dari kelas dalam package utama.

Rekomendasi

• Private adalah yang paling berguna ketika kita memiliki atribut, atau metode yang kita inginkan menjadi independen dari seluruh sistem.
• Atribut harus selalu private dan hanya dalam kasus yang ekstrim protected, tidak pernah bersifat public.
• Protected sangat penting jika kita ingin mengizinkan akses ke atribut, atau metode di kelas dasar tanpa mengekspos atribut, atau metode untuk seluruh sistem.
• Jika kita ingin menggunakan kembali metode antara kelas tetapi tidak terekspos terhadap seluruh sistem maka kita akan memerlukan visibiilty Package.
• Protected dan Packaged visibilitiasnya tidak sama.

Atribut

Sebuah atribut dapat direpresentasikan pada diagram kelas dengan menempatkan mereka di dalam bagian tengah kotak kelas atau oleh asosiasi dengan kelas lain. Penting atribut memiliki karakteristik visibilitas, nama yang tepat dan jenis data. Lihat diagram berikut untuk lebih jelasnya:

Nama atribut harus dalam kasus campuran. Nama-nama harus mewakili nilai apa yang diwakilinya. Hindari menggunakan nama pendek.

Atribut

Sebuah metode dapat direpresentasikan pada diagram kelas dengan menempatkan mereka di dalam bagian bawah kotak kelas. Adalah penting bahwa metode ini memiliki karakteristik visibilitas, nama yang tepat, tanda kurung untuk parameter dan tipe kembali. Lihat diagram berikut untuk lebih jelasnya:

Parameter yang digunakan untuk menentukan input yang diperlukan untuk memungkinkan metode untuk menyelesaikan tugasnya. Notasi adalah sebagai berikut: name : datatype . Jika kita tidak menggunakan return type void. Kita harus menentukan setidaknya satu parameter. Dalam skenario beberapa parameter, kita harus memisahkan mereka dengan koma.

Return type ditentukan setelah akhir tanda operasi. Nama metode harus dalam kasus campuran. Gunakan kata kerja untuk menggambarkan apa metode tersebut.

Representasi Elemen statis dalam UML

Dalam object-oriented programming atribut non-statis dan metode yang terkait dengan setiap objek individu yang tercipta dari sebuah kelas. Di sisi lain, atribut statis dan metode yang terkait dengan kelas. Hal ini memungkinkan untuk berbagi nilai-nilai di antara semua objek dari jenis kelas.

Sebuah atribut atau metode dibuat statis dalam UML dengan garis bawah. Lihat ini pada diagram berikut:

Hubungan Antar Kelas

Ini adalah fakta bahwa kelas hidup berdampingan dan bekerja sama melalui releationships berbeda. Kekuatan hubungan kelas tergantung pada bagaimana terlibat adalah masing-masing kelas dengan lainnya: erat atau longgar. Diagram berikut menunjukkan jenis yang berbeda lima dari hubungan kelas:

Dependency

Menyatakan bahwa kelas perlu tahu tentang kelas lain untuk menggunakan objek dari kelas tersebut. Representasinya adalah panah putus-putus.

Association

Berarti kelas akan berisi referensi ke sebuah obyek dari kelas lain dalam bentuk atribut. Perwakilannya adalah garis lurus, nama asosiasi dan atribut (atau Kelas) yang terlibat. Contohnya adalah "Student --take -> Course".

Aggregation

Menunjukkan bahwa kelas dapat berbagi objek dari kelas lain. Representasinya adalah dengan berlian kosong, garis lurus, nama agregasi dan atribut bersama. Contohnya adalah "Orang ◊ ---- Address".

Composition

Ini bekerja mirip seperti Agregasi tetapi dalam cara yang lebih kuat. Representasinya adalah dengan berlian penuh, garis lurus, nama agregasi dan atribut bersama. Contohnya adalah "Orang ----- Nama ⧫".

Generalisasi

Hal ini juga disebut Warisan(Inheritance). Digunakan untuk menggambarkan kelas yang adalah jenis kelas lain. Representasinya adalah dengan segitiga kosong dan garis lurus. Contohnya adalah "Mammal ----- ▷ Dog".

Representasi Kelas Abstrak di UML

Kelas abstrak adalah kelas yang memperpanjang oleh kelas-kelas lain. Tidak seperti kelas konkrit, kelas abstrak tidak dapat dipakai dan hanya memiliki metode. Tujuan utama dari itu adalah memiliki kode public untuk digunakan dalam subclass. Notasi adalah sama seperti kelas tapi tanpa atribut dan teks dalam huruf miring.

Referensi

1. Miles, R .; Hamilton, K. Belajar UML 2.0. Bab 4. Pemodelan Struktur Logical Systems. Memperkenalkan Kelas dan Class Diagram. O'Reilly Media, Inc Amerika Serikat. April 2006.
2. Miles, R .; Hamilton, K. Belajar UML 2.0. Bab 5. Pemodelan Struktur Logical Systems. Lanjutan Class Diagram. O'Reilly Media, Inc Amerika Serikat. April 2006.