Diagram UML mana yang masih banyak digunakan? [Tutup]

Saya mengajar rekayasa perangkat lunak di tingkat sarjana dan saya punya pertanyaan untuk praktisi UML.

Sebagian besar buku teks rekayasa perangkat lunak melakukan upaya serius dalam meliput diagram UML. Tetapi di sisi lain, saya mendengar dari banyak lulusan bahwa UML tampaknya tidak digunakan lagi di parit.

Diagram UML apa yang masih banyak digunakan dalam praktik profesional, dan mengapa? Apakah ada diagram yang tidak lagi digunakan dan mengapa?

NB: Untuk menghindari perdebatan dan diskusi berdasarkan pendapat, mohon ilustrasikan jawaban Anda dengan elemen faktual dan objektif (jika mungkin, dapat diverifikasi) atau pengamatan netral pada pengalaman pribadi.

Dari banyak diagram yang diusulkan oleh UML, diagram kelas dan diagram urutan masih banyak digunakan, tentunya diikuti oleh diagram keadaan:

• mereka dapat dengan mudah digunakan di papan tulis untuk menguraikan dan mendiskusikan desain sebelum memasukkan kode
• mereka memungkinkan untuk menyampaikan ikhtisar yang sangat cepat yang tidak dapat diberikan oleh kode itu dengan mudah, dan tidak ada pengganti yang layak untuk itu.

Saya pikir use case dalam kehidupan nyata digunakan dengan cara yang lebih sesekali. Dalam proyek-proyek besar, dengan ratusan kasus penggunaan, diagram sulit untuk digambarkan dan memberikan sedikit manfaat dibandingkan bentuk tabel. BPMN untuk desain proses, pemetaan cerita pengguna , atau dekomposisi tabel acara dalam gaya Cockburn lebih banyak digunakan. Mengapa Karena mereka lebih mudah dibagikan dengan pengguna bisnis untuk bekerja secara efisien persyaratan.

Saya yakin mereka adalah tempat di mana UML masih banyak dan sistematis digunakan. Saya tidak membayangkan bahwa perangkat lunak kedirgantaraan atau sistem kendali pembangkit listrik tenaga nuklir diproduksi tanpa set lengkap dokumentasi UML. Tapi saya percaya itu lebih merupakan pengecualian daripada aturan.

Saya merasa dikonfirmasi dalam pernyataan ini ketika mencari di toko buku. Beberapa tahun yang lalu, Anda bisa menemukan banyak buku di UML 2.0. Saat ini, jika Anda mencari UML 2.5, pilihannya agak terbatas. Lebih buruk lagi: banyak penulis bahkan tidak berupaya untuk merevisi buku-buku sebelumnya agar tetap mutakhir (contoh: Pengantar bagus " UML distilasi " Fowler yang masih berasal dari tahun 2003 dengan UML 2.0 dan elemen yang sama dengan Ambler 's " dari gaya UML 2.0 "!).

Saya tidak berpikir bahwa tren penurunan ini akan berubah, melihat generalisasi tangkas dan promosi "perangkat lunak yang berfungsi di atas dokumentasi yang komprehensif".

Pada akhirnya, saya dengan sangat provokatif menyatakan bahwa metode pemodelan tampaknya mengikuti skema darwinistik: hanya teknik diagram yang paling cocok yang akan bertahan, yang memberikan keuntungan jelas atas pendekatan informal (misalnya ilustrasi serbet) dan kode terperinci (mis. mengapa menggambar diagram aktivitas A1, ketika kode yang sesuai bisa muat pada lembar A4?) ;-)

Di sisi lain, saya mendengar dari banyak lulusan bahwa UML sepertinya tidak digunakan lagi di parit.

Mereka semua digunakan dalam praktik. Tetapi tidak semua orang menggunakannya. Beberapa orang menghindari desain sepenuhnya, dan langsung beralih ke pengkodean. Anda tidak dapat mengandalkan bukti anekdotal untuk mengetahui apa yang dilakukan "semua orang".

Alat seperti UML berfungsi paling baik jika Anda gunakan saat mereka menambah nilai ; misalnya

• untuk proyek yang lebih besar
• untuk bagian rumit dari suatu proyek
• ketika desain proyek membutuhkan input dari banyak orang

Menciptakannya hanya untuk melakukannya (atau karena prosesnya mengatakan Anda harus) tidak produktif. Praktik terbaik adalah selektif pada apa yang Anda diagram, dan apa jenis yang Anda gunakan. Gunakan UML kapan dan di mana itu membantu ... dan itu termasuk selektif jenis diagram UML yang Anda gunakan.

Juga ... UML dirancang terutama sebagai alat desain. Ini tidak begitu efektif (hari ini) sebagai alat dokumentasi. IDE khas membantu Anda untuk memvisualisasikan banyak aspek jika struktur basis kode dengan cepat. Ini sering lebih baik daripada mengandalkan diagram UML yang mungkin sudah usang / tidak akurat.

UML masih digunakan di parit. Tetapi, seperti biasa, orang menggunakan sebagian dari itu. Subset mana yang mengalami masalah yang dihadapi.

UML hadir dalam banyak versi. Tetapi, seperti biasa, orang menggunakan simbol itu secara informal dan tidak langsung.

UML adalah cara kami memahami banyak pola buku di luar sana. Ini juga salah satu cara kami berkomunikasi di papan tulis. Itu tidak hilang. Tapi itu tidak akan pernah digunakan secara formal sebagai kode.

Alih-alih menghasilkan siswa yang dapat mengoreksi diagram UML apa pun untuk mematuhi UML versi 2.5 , atau apa pun yang terbaru, lebih baik siswa yang dapat memahami apa yang diagram tersebut coba komunikasikan walaupun tidak sepenuhnya konsisten dengan versi UML tertentu karena itu bagaimana UML digunakan di parit. Muncul dalam dialek lokal yang aneh, dicampur dengan sistem lain, dan kadang-kadang kita hanya membuat simbol kita sendiri.

Ajari mereka bahwa tidak apa-apa untuk bertanya apa artinya. Jangan mengajari mereka memperbaiki orang lain yang melanggar beberapa aturan yang dibayangkan. Kami hanya berusaha berkomunikasi di sini.

Penggunaan terbaik yang pernah saya lihat adalah membiarkan seorang programmer baru menunjukkan kepada kita rencana mereka untuk memecahkan masalah. Itu dengan cepat menunjukkan kepada kita bagian-bagian dari sistem yang mereka abaikan atau tidak sadari ada.

Saya juga telah bekerja di tempat-tempat yang membutuhkan UML bahkan ketika tidak diperlukan. Kami selalu menggunakan pola yang sama jadi itu hanya formalitas. Kami sampai pada titik bahwa kami baru saja mem-foto nama-nama baru ke dalam diagram lama. Jangan mendorong penggunaan semacam ini.

Tapi saya pikir kita semua tahu ada perbedaan antara kepala panah normal dan kepala panah terbuka. Baik?

Saya akan lebih spesifik sesuai dengan pengalaman saya: - Diagram penyebaran - Diagram urutan - Diagram kelas Ketiga adalah yang paling banyak digunakan dalam proyek apa pun, mereka memberikan nilai komunikasi nyata dengan tim di tingkat yang berbeda.