Mengapa tidak pantas menggunakan diagram UML untuk merencanakan bagaimana kode Anda akan diatur?

Jadi, ya, diagram terkadang tidak sesuai. Kapan itu tidak pantas? Ketika Anda membuat mereka tanpa kode untuk memvalidasinya, dan kemudian bermaksud untuk mengikutinya. Tidak ada yang salah dengan menggambar diagram untuk mengeksplorasi ide.

_{Pengembangan Perangkat Lunak Agile: Prinsip, Pola, dan Praktek - Robert C. Martin}

Apa sebenarnya yang dia maksudkan dengan ini? Bukankah UML dirancang untuk membantu merencanakan bagaimana menyusun kode Anda sebelum "menyelam"? Apa gunanya menggunakannya jika Anda tidak mengikuti diagram yang Anda buat?

Konteks: Dalam bab ini, Paman Bob membuat diagram UML untuk Penjaga Skor dari game Bowling. Kemudian dia melanjutkan untuk mengembangkan program dengan cara yang didorong oleh tes, tanpa berkonsultasi dengan diagram UML. Program yang dihasilkan tidak seperti diagram UML, dan Paman Bob sampai pada kesimpulan yang dikutip di atas.

— q126y
sumber

Poin Paman Bob adalah bahwa arsitektur yang muncul dari Test-Driven Development dapat berbeda secara radikal dari diagram UML.

— Robert Harvey

Baca juga apakah desain sudah mati? Oleh Martin fowler untuk diskusi seimbang tentang topik ini dan gerakan gesit

— Eliezer Steinbock

Membalikkan pertanyaan ini sebagai tanggapan atas penilaian yang buruk dari @RobertHarvey dkk dalam memberikan suara untuk menutup apa yang merupakan pertanyaan penting dan berguna.

— David Arno

@DavidArno Jika Anda memiliki pendapat yang kuat tentang apa yang harus ditutup atau tidak, saya akan sangat menyarankan Anda untuk terlibat dalam diskusi di situs meta kami. Semua orang yang saat ini memposting di sana (termasuk saya) mungkin berada di bawah "@RobertHarvey et al" kecuali beberapa karyawan SE, dan kami khawatir ada sudut pandang lain yang tidak terwakili, tetapi sejauh ini tidak ada yang pernah muncul untuk mewakilinya .

— Ixrec

@Irrec, saya tidak pernah melibatkan diri saya dengan diskusi meta sebelumnya, selain sekali untuk memeriksa apakah saya bisa merujuk ke perpustakaan open source saya sendiri dalam jawaban (jawabannya adalah saya bisa). Mungkin saya harus menerima saran Anda dan lebih terlibat. Terima kasih untuk sarannya.

— David Arno

Jawaban:

Untuk menjelaskan ini dengan benar, kita perlu pelajaran sejarah singkat. Pada masa awal rekayasa perangkat lunak, analogi yang sering digunakan adalah membangun rumah. Seorang arsitek dan insinyur struktur mendiskusikan rencana dengan pelanggan dan membuat desain. Pembangun kemudian mengikuti desain itu untuk membangun rumah yang sebenarnya. Menulis kode dipandang setara dengan membangun rumah yang sebenarnya. Dengan demikian, ada kebutuhan yang dirasakan untuk desain di muka sebelum membangun itu bisa terjadi. Berbagai alat desain grafis dibuat, dengan UML menjadi salah satunya.

Ide awalnya dengan UML, adalah bahwa seseorang akan sepenuhnya mendesain sistem dengan UML, kemudian menyerahkannya ke coders untuk menerjemahkan desain itu ke dalam kode. Pada kenyataannya, ini tidak berhasil, dan menyebabkan programmer bertahun-tahun dipandang sebagai "pelaksana", bukan "desainer", proyek terlambat, desain harus terus berubah setelah mereka seharusnya selesai dll.

Alasannya sederhana. Pengkodean adalah desain . Dengan analogi rumah, kode adalah gambar arsitek. Compiler adalah pembangun yang mengambil desain itu dan membangun program darinya. Realisasi ini kemudian mengarah pada teknik lincah, TDD dll dilahirkan: alat untuk membantu meningkatkan kualitas desain kode itu.

Sama seperti seorang arsitek dapat menghasilkan sketsa awal untuk membantunya dan timnya memvisualisasikan desain keseluruhan, sehingga pengembang dapat menggunakan UML, atau alat lain, untuk membantu memvisualisasikan desain yang dibutuhkan. Sama seperti sketsa-sketsa itu tidak diikuti secara membabi buta, jadi UML tidak boleh diikuti secara membabi buta. Desain kode harus berkembang dari iterasi gesit dan menggunakan TDD. Demikian juga, seperti halnya arsitek mungkin membangun model rumah untuk membantunya dan timnya memvisualisasikan gambar, sehingga UML dapat digunakan untuk membantu memvisualisasikan struktur kode.

Seperti kata Paman Bob, Anda tidak dapat memvalidasi UML, Anda hanya dapat memvalidasi kode. Oleh karena itu kode adalah dokumentasi desain utama dan UML, jika digunakan, adalah dokumentasi sekunder saja.

— David Arno
sumber

Saya memiliki bagian atap rumah saya terangkat awal tahun ini dan itu cukup mendidik. Arsitek benar-benar tidak lagi menggambarkan seperti apa produk akhir itu seharusnya. Dia menyerahkan perhitungan keras dan desain struktural kepada seorang insinyur bangunan. Pembangun kemudian harus mencocokkan desain teoritis dengan aktualitas rumah (setelah eternit dimatikan, balok-balok itu ditemukan berada di tempat yang sedikit berbeda) sehingga desain terjadi pada setiap langkah.

— Jaydee

Ini adalah jawaban yang bermanfaat, namun terlalu menyederhanakan beberapa aspek. Salah satu alasan utama mengapa UML tidak bekerja dengan baik sebagai "notasi desain tingkat tinggi" adalah IMHO penemu mereka terlalu keras kepala untuk menambahkan diagram aliran data. Itu adalah satu-satunya jenis notasi yang saya tahu cocok untuk desain top-town, memungkinkan untuk mengekspresikan abstraksi untuk komponen dan antarmuka di antara mereka dari skala yang berbeda, dan juga dapat memiliki pemetaan kode yang didefinisikan dengan baik. Sebaliknya, UML mengandung banyak omong kosong yang benar-benar dibutuhkan siapa pun.

— Doc Brown

Saya kira tidak semua idiom pemrograman (atau desain, atau kode) cocok dengan UML (yang saya akui saya tidak tahu - hanya membaca beberapa buku tentang itu -, saya tidak pernah menggunakannya, dan saya mungkin tidak menyukainya).

Kode C biasa (mis. Kode sumber kernel Linux) mungkin tidak dimodelkan dengan tepat oleh UML.

Kode Ocaml (dengan modul dan functorsnya) atau bahkan kode C ++ 11 (dengan lambdas dan templat) mungkin tidak cocok dengan UML.

Pemrograman multistage à la MetaOcaml mungkin tidak cocok dengan UML.

Kode prolog atau kode Common Lisp mungkin tidak cocok dengan UML.

Lihat juga ini jawaban & ini pertanyaan saya.

Bacalah Pragmatik Bahasa Pemrograman Scott dan Konsep, Teknik, dan Model Pemrograman Komputer Van Roy , lalu tanyakan pada diri Anda apakah setiap model pemrograman di sana sesuai dengan UML.

Lihat juga Martin Fowler's Is Design Dead? blog.

— Basile Starynkevitch
sumber