komponen dimana deployment diagram memuat satu atau lebih komponen-komponen. Diagram ini sangat berguna saat aplikasi kita
berlaku sebagai aplikasi yang dijalankan pada banyak mesin distributed computing.
Kesembilan diagram ini tidak mutlak harus digunakan dalam pengembangan perangkat lunak; semuanya dibuat sesuai dengan kebutuhan.
2.6 USDP
USDP Unified Software Development Process adalah salah satu metode rekayasa perangkat lunak berorientasi objek yang secara konsisten mencoba
beradaptasi dengan semakin besar dan semakin kompleksnya sistem- sistemperangkat lunak-perangkat lunak yang dikembangkan oleh para vendor
perangkat lunak di seluruh dunia. Nugroho, 2010
2.6.1 Karakteristik USDP
USDP, seperti yang dikemukakan oleh para penciptanya Graddy Booch, Ivar Jacobson, serta DR. James Rumbaugh yang juga merupakan para perancang
kakas tool UML, memiliki karakteristik-karakteristik sebagaimana berikut :
1. Use-case Driven. Perangkat lunak yang kelak dihasilkan semestinya
bersifat melayani para penggunanya dan sesuai dengan kebutuhan dan harapan pengguna. Dalam hal ini, terminologi pengguna dalam
diagram use case sering disebut sebagai actor tidak hanya berupa
orang-orang yang menggunakan perangkat lunak, melainkan juga sistem-sistem lain yang menggunakan sistemperangkat lunak yang
dihasilkan. Sementara use case merupakan urut-urutan interaksi antara
actor dengan sistemperangkat lunak yang kita kembangkan.
2. Architecture Centric. Peran dari arsitektur sistem perangkat lunak
mirip dengan peran arsitektur pada sistem konstruksi teknik sipil. Arsitektur sistem mencerminkan kebutuhan dan harapan pengguna
yang terlihat dengan jelas pada definisi-definisi use case, seperti arsitektur komputer yang digunakan sistem operasi, sistem manajemen
basis data DBMS-Database Management System, protokol komunikasi, komponen-komponen perangkat lunak yang dapat
digunakan-ulang, pertimbangan-pertimbangan peletakan komponen- komponen perangkat lunak di komputer-komputer yang sesuai
deployment, serta kebutuhan-kebutuhan non-fungsional kinerja, kelan, dan sebagainya.
Secara umum, arsitektur perangkat lunak merupakan keputusan-keputusan yang berkaitan dengan beberapa hal
berikut. a. Organisasi perangkat lunak.
b. Elemen-elemen penyusun perangkat lunak dan antarmuka- antarmuka yang memungkinkan elemen-elemen tersebut saling
berkolaborasi untuk mewujudkan fungsionalitas perangkat lunak yang diharapkan.
c. Komposisi dari elemen-elemen struktura dan perilaku yang kelak secara progresif menyusun subsistem yang lebih besar.
d. Gaya arsitektur yang memandu pengorganisasian perangkat
lunak, yaitu elemen-elemen dan antarmukanya, kolaborasi- kolaborasi antar elemen, serta komposisinya.
e. Penggunaan perangkat lunak, fungsionalitasnya, kinerjanya,
kemudahan penggunaannya,
penggunaan-ulang komponen-
komponen yang
merupakan penyusunnya,
batasan-batasan ekonomi serta teknologinya, serta keindahan tampilannya.
Demi kebutuhan pengorganisasian sistem, sistem harus dipahami dengan cara yang sama oleh semua orang yang memiliki kepentingan
atasnya. Alasannya sebagai berikut : a. Perangkat lunak yang kompleks harus diketahui perilakunya.
b. Perangkat lunak beroperasi dalam lingkungan yang kompleks. c. Perangkat lunak merupakan teknologi yang kompleks.
d. Perangkat lunak menggabungkan elemen-elemen perangkat lunak dengan perangkat keras di mana perangkat lunak yang bersangkutan
dieksekusi. e. Perangkat lunak harus bisa melayani segenap individu yang ada
dalam organisasiperusahaan di mana perangkat lunak tersebut diterapkan.
3. Iterative and Incremental. Pengembangan perangkat lunak komersial
