Ada berbagai cara untuk menggunakan UML. Martin Fowler memanggil mode UML ini dan mengidentifikasi empat: UML sebagai Notes , UML sebagai Sketsa , UML sebagai Cetak Biru , dan UML sebagai Bahasa Pemrograman .
UML sebagai Bahasa Pemrograman tidak pernah benar-benar lepas landas. Ada beberapa pekerjaan di bidang ini dengan nama yang berbeda, seperti Model Driven Architecture atau Model Based Software Engineering. Dalam pendekatan ini, Anda membuat model yang sangat rinci dari sistem perangkat lunak Anda dan menghasilkan kode dari model-model itu. Mungkin ada beberapa kasus penggunaan di mana pendekatan ini berguna, tetapi tidak untuk perangkat lunak umum dan terutama tidak di luar perusahaan besar yang mampu membeli alat yang mendukung pendekatan ini. Ini juga merupakan proses yang memakan waktu - saya dapat mengetikkan kode untuk suatu kelas lebih cepat daripada saya dapat membuat semua model grafis yang diperlukan untuk mengimplementasikannya.
UML sebagai Cetak Biru sering menunjukkan proyek "desain besar di muka" . Tidak harus, tentu saja. Model ini dapat sepenuhnya dijelaskan untuk kenaikan tertentu, juga. Tetapi idenya adalah bahwa waktu dihabiskan untuk membuat desain dalam bentuk model UML yang kemudian diserahkan kepada seseorang untuk dikonversi menjadi kode. Semua detail dijabarkan dan konversi ke kode cenderung lebih mekanis.
UML sebagai Sketsa dan UML sebagai Notes pada dasarnya serupa, tetapi berbeda berdasarkan pada saat digunakan. Menggunakan UML sebagai Sketsa berarti bahwa Anda akan membuat sketsa desain menggunakan notasi UML, tetapi diagram tersebut kemungkinan tidak lengkap, tetapi akan fokus pada aspek-aspek tertentu dari desain yang Anda butuhkan untuk berkomunikasi dengan orang lain. UML sebagai Notes serupa, tetapi model dibuat setelah kode untuk membantu memahami basis kode.
Ketika Anda mempertimbangkan ini, saya pikir semua hal di atas berlaku untuk semua jenis notasi pemodelan. Anda dapat menerapkannya pada diagram hubungan entitas, diagram IDEF , notasi pemodelan proses bisnis, dan sebagainya. Terlepas dari notasi pemodelan, Anda dapat memilih kapan Anda menerapkannya (sebelum sebagai spesifikasi, setelah sebagai representasi alternatif) dan berapa banyak detail (detail lengkap untuk aspek-aspek utama).
Sisi lain dari ini adalah budaya open source.
Seringkali, proyek open source memulai untuk memecahkan masalah yang dialami individu (atau, hari ini, perusahaan). Jika diluncurkan oleh seorang individu, jumlah pengembang adalah 1. Dalam hal ini, overhead komunikasi sangat rendah dan ada sedikit kebutuhan untuk berkomunikasi tentang persyaratan dan desain. Dalam sebuah perusahaan, kemungkinan ada tim kecil. Dalam hal ini, Anda mungkin perlu mengomunikasikan kemungkinan desain dan mendiskusikan pertukaran. Namun, begitu Anda telah membuat keputusan desain, Anda perlu mempertahankan model Anda karena basis kode Anda berubah seiring waktu atau membuangnya. Dalam istilah Agile Modeling , "dokumentasikan terus menerus" dan pertahankan "satu sumber informasi" .
Sebagai tambahan singkat, ada gagasan bahwa kode adalah desain dan bahwa model hanyalah pandangan alternatif dari desain. Jack Reeves menulis tiga esai tentang kode sebagai desain , dan ada diskusi tentang wiki C2 juga, membahas ide-ide bahwa kode sumber adalah desain , desain adalah kode sumber , dan kode sumber serta pemodelan . Jika Anda berlangganan kepercayaan ini (yang saya lakukan), maka kode sumber adalah kenyataan dan diagram apa saja harus ada untuk membuat memahami kode dan, yang lebih penting, alasan di balik mengapa kode itu seperti apa adanya.
Proyek open source yang sukses, seperti yang Anda sebutkan, memiliki kontributor di seluruh dunia. Kontributor ini cenderung kompeten secara teknis dalam teknologi yang mendukung perangkat lunak dan cenderung juga menjadi pengguna perangkat lunak. Kontributor adalah orang yang dapat membaca kode sumber semudah model, dan dapat menggunakan alat (IDE dan alat rekayasa balik) untuk memahami kode (termasuk menghasilkan model, jika mereka merasa perlu). Mereka juga dapat membuat sketsa aliran sendiri.
Dari empat mode yang dijelaskan Fowler, saya tidak berpikir Anda akan menemukan proyek open source, atau sangat banyak proyek di mana saja, yang menggunakan bahasa pemodelan sebagai bahasa pemrograman atau cetak biru. Ini meninggalkan catatan dan sketsa sebagai kegunaan yang mungkin untuk UML. Catatan akan dibuat oleh kontributor untuk kontributor, jadi Anda mungkin tidak akan menemukannya diunggah di mana pun. Sketsa berkurang nilainya karena kode menjadi lebih lengkap dan kemungkinan tidak akan dipertahankan karena itu hanya perlu upaya dari pihak kontributor.
Banyak proyek open source tidak memiliki model yang tersedia karena tidak menambah nilai. Namun, itu tidak berarti bahwa model tidak dibuat oleh seseorang di awal proyek atau bahwa individu belum membuat model sistem mereka sendiri. Hanya saja lebih efektif untuk memelihara satu sumber informasi desain: kode sumber.
Jika Anda ingin menemukan orang yang bertukar informasi desain, saya sarankan melihat forum atau milis apa pun yang digunakan oleh kontributor. Seringkali, forum dan milis ini berfungsi sebagai dokumentasi desain untuk proyek. Anda mungkin tidak menemukan UML formal, tetapi Anda mungkin menemukan semacam representasi grafis dari informasi desain dan model di sana. Anda juga dapat masuk ke ruang obrolan atau saluran komunikasi lain untuk proyek - jika Anda melihat orang berbicara tentang keputusan desain, mereka mungkin berkomunikasi dengan model grafis. Tetapi mereka kemungkinan tidak akan menjadi bagian dari repositori karena mereka tidak bernilai begitu mereka telah melayani tujuan mereka dalam komunikasi.