Diagram komponen

Diagram komponen adalah diagram yang menggambarkan struktur fisik dari sebuah sistem dan digunakan untuk mengilustrasikan bagaimana kode program dibagi menjadi beberapa komponen, dan mendeksripsikan hubungan antar komponen.^[1] Diagram komponen memberikan gambaran tingkat tinggi dan sederhana dari sebuah sistem. Mengklasifikasikan sekelompok kelas menjadi komponen akan membantu pertukaran dan penggunaan kembali dari sebuah kode. Tujuan dari diagram komponen adalah menunjukkan hubungan struktural antar komponen dalam sebuah sistem.^[2]

Contoh Diagram Komponen

Notasi Diagram Komponen

Notasi Diagram Komponen

Nama	Deskripsi	Simbol
Component	Komponen digambar sebagai persegi panjang dengan kompartemen yang ditumpuk secara vertikal. Sebuah komponen dapat digambarkan hanya dengan persegi panjang dengan nama komponen dan stereotip teks/ikon komponen. Stereotip teks komponen adalah <<component>> dan stereotip ikon komponen adalah persegi panjang dengan 2 persegi panjang menonjol di sisi kirinya.[2]
Provided Interface	Mendefinisikan seperangkat atribut dan operasi publik yang harus disediakan oleh kelas yang mengimplementasikan interface.[2]
Required Interface	Mendefinisikan seperangkat atribut dan operasi publik yang dibutuhkan oleh kelas yang bergantung pada interface.[2]
Ball-and-Socket Joint	Komponen dapat terhubung untuk membentuk subsistem dengan menggunakan ball-and-socket joint (gabungan antara provided interface dan required interface).[2]
Port	Mengindikasikan bahwa komponen tersebut tidak menyediakan interface yang dibutuhkan (contoh: required atau provided). Sebagai gantinya, komponen mendelegasikan interface ke kelas internal.[2]

Stereotip Standar Komponen

Stereotip Standar UML pada Komponen

Nama	Deskripsi
<<BuildComponent>>	Kumpulan elemen yang didefinisikan untuk kegiatan pengembangan pada level sistem, seperti kompilasi dan versi.[3]
<<Entity>>	Komponen informasi yang mewakili konsep bisnis, contohnya 'konsumen'.[3]
<<Implement>>	Komponen yang tidak ditujukan untuk memiliki spesifikasi tersendiri. Sebaliknya, komponen ini merupakan implementasi untuk <<spesification>> terpisah yang memiliki ketergantungan (dependency).[3]
<<Process>>	Komponen berbasis transaksi.[3]
<<Realization>>	Classifier yang menentukan domain dari sebuah objek dan juga mendefinisikan implementasi fisik dari objek tersebut. Contohnya, komponen berstereotip <<Realization>> hanya akan memiliki realizing classifier yang mengimplementasikan behavior yang ditentukan oleh komponen <<Spesification>>. Hal ini berbeda dari <<ImplementationClass>> karena implementation class merupakan realisasi dari kelas yang dapat memiliki fitur seperti atribut dan operasi yang berguna bagi desainer sistem.[3]
<Service>>	Komponen fungsional tanpa status.
<<Spesification>>	Classifier yang menentukan domain dari sebuah objek tanpa mendefinisikan implementasi fisik dari objek tersebut. Contohnya, komponen berstereotip <<Specification>> hanya akan memiliki provided dan required interfaces, dan tidak ditujukan untuk memiliki realizing classifier sebagai bagian dari definisinya. <<Spesification>> dan <<Realization>> digunakan untuk memodelkan komponen dengan spesifikasi dan realisasi khusus, di mana satu spesifikasi dapat memiliki banyak realisasi.[3]
<<Subsystem>>	Komponen yang merepresentasikan unit dekomposisi hirarkis untuk sistem besar dan digunakan untuk memodelkan komponen berskala besar. Sebuah subsistem dapat memiliki elemen spesifikasi dan realisasi.[3]

Sejarah

Notasi komponen sebagai classifier berbentuk persegi panjang dengan kata kunci <<component>> dikenalkan dalam UML 2.0. Pada versi sebelumnya, UML 1.x, notasi komponen berbentuk persegi panjang dengan dua persegi panjang kecil menonjol dari sisinya. Untuk alasan kesesuaian, notasi ini masih boleh digunakan pada UML 2.5.

Pada UML 1.4.2 stereotip <<entity>> merepresentasikan kelas pasif, contohnya kelas yang objeknya tidak menginisiasi interaksi pada dirinya sendiri. <<Entity>> menjadi komponen informasi tetap pada UML 2.0.

Stereotip <<process>> menentukan classifier yang merepresentasikan aliran kontrol pada UML 1.4.2. <<Process>> menjadi komponen berbasis transaksi pada UML 2.0.

Pada UML 1.4.2. <<subsystem>> merupakan jenis khusus dari package yang digunakan untuk merepresentasikan unit behavioral pada sistem, dan dalam model, dan berperan sebagai unit spesifikasi untuk behavior dari elemen-elemen model yang terkandung di dalamnya. <<Subsystem>> menjadi stereotip komponen untuk mewakili unit dekomposisi hirarkis untuk sistem besar di UML 2.0.

UML 2.0 juga mengenalkan stereotip komponen <<BuildComponent>>, <<Implement>> dan <<Service>>.^[3]