Kebanyakan, jika tidak semua orang IT yang saya kenal percaya bahwa itu bermanfaat untuk memodelkan perangkat lunak dengan UML atau jenis diagram lain sebelum pengkodean. (Pertanyaan saya bukan tentang UML secara khusus, bisa berupa deskripsi grafis atau tekstual dari desain perangkat lunak.)
Saya tidak begitu yakin tentang itu. Alasan utamanya adalah: Kode tidak berbohong. Itu diperiksa oleh kompiler atau interpreter. Mudah-mudahan ini memiliki tes otomatis dan harus lulus analisis kode statis. Jika suatu modul tidak berinteraksi dengan benar dengan modul lain, biasanya jelas dalam kode karena Anda mendapatkan pesan kesalahan.
Semua ini tidak dapat dilakukan dengan diagram dan dokumen lainnya. Ya, ada alat yang memeriksa UML, tetapi semua yang saya lihat sejauh ini sangat terbatas. Oleh karena itu dokumen-dokumen ini cenderung tidak lengkap, tidak konsisten atau palsu.
Bahkan jika diagram itu sendiri konsisten, Anda tidak dapat memastikan bahwa kode tersebut benar-benar mengimplementasikannya. Ya, ada pembuat kode, tetapi mereka tidak pernah menghasilkan semua kode.
Kadang-kadang saya merasa seperti obsesi dengan hasil pemodelan dari asumsi bahwa kode pasti merupakan kekacauan yang tidak dapat dipahami oleh arsitek, desainer, atau orang-orang bergaji tinggi lainnya yang mendapatkan gambaran besar tidak harus berurusan dengan itu. Kalau tidak, itu akan menjadi terlalu mahal. Oleh karena itu semua keputusan desain harus dipindahkan dari kode. Kode itu sendiri harus diserahkan kepada spesialis (monyet kode) yang dapat menulis (dan mungkin membaca) tetapi tidak harus berurusan dengan hal lain. Ini mungkin masuk akal ketika assembler adalah satu-satunya pilihan, tetapi bahasa modern memungkinkan Anda untuk kode pada tingkat abstraksi yang sangat tinggi. Oleh karena itu saya tidak benar-benar melihat perlunya pemodelan lagi.
Apa argumen untuk pemodelan sistem perangkat lunak yang saya lewatkan?
Ngomong-ngomong, saya percaya bahwa diagram adalah cara yang bagus untuk mendokumentasikan dan mengkomunikasikan aspek-aspek tertentu dari desain perangkat lunak, tetapi itu tidak berarti kita harus mendasarkan desain perangkat lunak pada mereka.
Klarifikasi:
Pertanyaan itu ditunda karena tidak jelas. Karena itu izinkan saya menambahkan beberapa penjelasan:
Saya bertanya apakah masuk akal untuk menggunakan (bukan kode) dokumen yang memodelkan perangkat lunak sebagai sumber utama kebenaran tentang desain perangkat lunak. Saya tidak memiliki kasus di mana sebagian besar kode secara otomatis dihasilkan dari dokumen-dokumen ini. Jika ini masalahnya, saya akan menganggap dokumen itu sendiri sebagai kode sumber dan bukan sebagai model.
Saya mencantumkan beberapa kelemahan dari prosedur ini yang membuat saya bertanya-tanya mengapa begitu banyak orang (menurut pengalaman saya) menganggapnya sebagai cara yang lebih baik dalam melakukan perancangan perangkat lunak.
sumber
Jawaban:
Manfaat pemodelan sistem perangkat lunak vs. semua dalam kode adalah: Saya dapat memuat model di papan tulis.
Saya sangat percaya pada keajaiban komunikasi di selembar kertas. Jika saya mencoba meletakkan kode di papan tulis, ketika mengajarkan sistem kami kepada pembuat kode baru, tidak ada kode apa pun pada tingkat abstraksi yang diperlukan yang pas di papan tulis.
Saya tahu obsesi dengan pemodelan yang Anda maksud. Orang-orang melakukan sesuatu karena itulah yang telah mereka lakukan sebelumnya, tanpa memikirkan mengapa mereka melakukannya. Saya datang untuk menyebutnya formalisme. Saya lebih suka bekerja secara informal karena lebih sulit untuk menyembunyikan kekonyolan di balik tradisi.
Itu tidak berarti saya tidak akan membuat sketsa UML sekarang dan kemudian. Tapi saya tidak akan pernah menjadi orang yang menuntut Anda menyerahkan dokumen UML sebelum Anda bisa kode. Saya mungkin meminta Anda mengambil 5 menit dan menemukan BEBERAPA cara untuk menjelaskan apa yang Anda lakukan karena saya tidak tahan dengan keberadaan kode yang hanya dimengerti oleh satu orang.
Fowler mengidentifikasi berbagai cara orang menggunakan UML yang ia sebut mode UML . Yang berbahaya dengan mereka semua adalah mereka dapat digunakan untuk bersembunyi dari melakukan pekerjaan yang bermanfaat. Jika Anda melakukannya untuk kode menggunakan mouse, baik saya telah melihat banyak yang mencoba. Belum pernah melihat orang yang benar-benar bekerja. Jika Anda melakukannya untuk berkomunikasi, Anda sebaiknya memastikan orang lain memahami Anda. Jika Anda melakukannya untuk merancang Anda sebaiknya mencari dan memperbaiki masalah saat Anda bekerja. Jika semuanya berjalan dengan lancar dan sebagian besar waktu Anda dihabiskan untuk membuat anak panah terlihat bagus kemudian matikan dan kembali bekerja.
Yang terpenting, jangan membuat diagram yang Anda harapkan valid lebih dari sehari. Jika Anda entah bagaimana bisa, Anda gagal. Karena perangkat lunak dimaksudkan untuk menjadi lunak. Jangan menghabiskan berminggu-minggu untuk mendapatkan diagram dengan benar. Katakan saja padaku apa yang terjadi. Jika harus, gunakan serbet.
Yang mengatakan, saya lebih suka coders yang tahu UML dan pola desain mereka. Mereka lebih mudah untuk berkomunikasi. Selama mereka tahu bahwa membuat diagram bukanlah pekerjaan penuh waktu.
sumber
Tidak. Ini tidak pernah masuk akal. Kode Anda adalah dokumen desain utama Anda, yaitu "sumber utama kebenaran tentang desain perangkat lunak". Hanya kode yang menjelaskan dengan tepat apa yang dilakukan aplikasi saat kompiler mengambil desain itu dan membuat aplikasi darinya.
Dengan segala cara, gunakan diagram sebagai dokumen desain tambahan, meskipun jika mereka tidak dihasilkan secara otomatis dari kode, berhati-hatilah karena mereka menceritakan kisah yang berbeda dengan desain sebenarnya. Jika UML mengapung perahu Anda, gunakan itu. Jika tidak, gunakan sesuatu yang lain.
Beberapa orang merasa berguna untuk membuat sketsa pemikiran mereka dalam bentuk diagram sebelum mulai menulis kode. Tapi ingat apa yang dikatakan Paman Bob tentang masalah ini:
Jika Anda benar-benar menggunakan UML untuk menjelajahi suatu desain, buanglah ketika Anda mulai membuat kode. Tulis tes, lalu tulis beberapa kode untuk membuatnya lulus. Ulangi. Dengan begitu, Anda akan berakhir dengan desain yang divalidasi. UML tidak dapat menawarkan tingkat validasi desain yang sama kepada Anda.
sumber
actionPerformed()metode ada di lapisan presentasi, dan bahwa itu hanya harus melewati kontrol ke lapisan domain, adalah aspek kunci pemisahan. (Contoh sepele, tetapi dapat diterapkan untuk semua jenis strategi desain yang tidak mudah ditampilkan hanya dalam kode).Saya tidak setuju bahwa semua orang yang Anda kenal percaya ini, tapi saya pikir itu tidak umum terjadi. Pada tahun 1970, Winston Royce tahu bahwa pengembangan perangkat lunak memiliki beberapa tingkat iterasi antara kegiatan desain dan kode. Pada tahun 1992, Jack Reeves menulis tentang pengkodean sebagai aktivitas desain yang sebenarnya (juga dibahas pada C2 Wiki ).
Ini tidak berarti bahwa orang telah mencoba membuat alat pengembangan berbasis model. Ada alat yang mencoba untuk menghasilkan kode dari model UML (dan bukan hanya diagram kelas, tetapi menghubungkan berbagai jenis diagram bersama-sama dan menghasilkan kode dari mereka). Tapi itu bukan, setidaknya dari apa yang saya lihat, alat yang banyak digunakan.
Ini juga tidak berarti bahwa Anda harus langsung dari persyaratan menjadi kode penulisan. Ada keputusan desain tertentu yang sangat penting untuk dilakukan sejak dini dan beberapa tingkat pemodelan dapat berguna untuk memastikan bahwa semua orang memahami pilihan, dampaknya, dan dapat berkomunikasi. Beberapa orang (termasuk saya) menyebut ini "arsitektur perangkat lunak" .
Ini benar-benar jantung dari beberapa aspek Pemodelan Agile, terutama Spesifikasi yang Dapat Dieksekusi dan Sumber Informasi Tunggal . Saya tidak perlu setuju dengan TDD, tetapi gagasan memiliki kode Anda dan tes terkait (dari unit melalui tes penerimaan, sebaiknya ditangkap sebagai tes otomatis) menjadi satu-satunya sumber kebenaran adalah ide yang bagus.
Saya pikir sebagai aturan umum, pergi dari model-> kode adalah cara yang salah. Sebaliknya, kode harus menghasilkan model. Artinya, alat harus dapat memeriksa kode dan menghasilkan representasi grafis dan tabel yang dapat lebih ditingkatkan saat para insinyur menulis teks di sekitarnya. Dan generasi model ini dari kode harus menjadi bagian mulus dari proses build dan release.
Ada alat yang, untuk tingkat yang berbeda, mendukung hal ini untuk berbagai bahasa. Mengingat sifat bahasa dan paradigma, lebih mudah bagi sebagian orang daripada yang lain.
Saya tidak berpikir bahwa orang-orang ini perlu memahami rekayasa perangkat lunak dan desain perangkat lunak. Saya pikir orang-orang ini melihat apa yang dilakukan disiplin ilmu teknik lain dan memetakannya ke hal-hal yang menurut mereka harus dilakukan oleh para insinyur perangkat lunak. Tetapi mereka mengabaikan satu perbedaan besar. Disiplin teknik lainnya menciptakan model dan simulasi terlebih dahulu karena sangat mahal dan memakan waktu untuk membangun produk yang sebenarnya. Dalam rekayasa perangkat lunak, kita dapat mengambil bagian dari desain kita dan menghasilkan sesuatu yang dapat diuji di lingkungan dunia nyata dalam waktu yang sangat sedikit dan dengan biaya yang sangat sedikit. Ekonomi sangat berbeda.
Ketika Anda memiliki sistem perangkat lunak yang sangat kompleks, memiliki model berarti memiliki sesuatu yang lebih mudah dipahami. Ini adalah tingkat abstraksi yang berbeda, sesuatu untuk membantu orang memahami berbagai aspek sistem Anda. Ini adalah salah satu alasan mengapa ada begitu banyak bahasa pemodelan yang berbeda dan berbagai jenis model yang diizinkan oleh setiap bahasa pemodelan atau notasi - untuk memungkinkan pemangku kepentingan yang berbeda untuk memahami, secara konseptual, sistem perangkat lunak dengan cepat dan mudah.
sumber
Banyak dokumen non-kode berguna sebagai cetak biru . Artinya, "kebenaran" desain harus mengikuti arahan ini. Ini adalah cara untuk memodelkan elemen yang harus dipenuhi oleh suatu desain. Anda bisa menyebut mereka dokumen persyaratan, tapi itu mungkin terlalu kuat dalam semua contoh yang bisa saya berikan. Saya telah menggunakan PlantUML melalui PlantText.com untuk menghasilkan ini.
Diagram use-case dapat menunjukkan fitur dan interaksi yang dimaksud dengan pengguna atau sistem eksternal.
Diagram aktivitas dapat menunjukkan proses bisnis yang perlu didukung oleh perangkat lunak.
State diagram dapat menunjukkan dinamika yang dimaksudkan di situs web:
Pola desain Geng Empat disajikan sebagai model statis dan dinamis. Misalnya, Memento:
Jika Anda tertarik pada beberapa informasi nyata tentang penggunaan UML di luar pengalaman Anda, ada beberapa studi yang dilakukan (saya mencoba menemukan tautan ke artikel non-paywall):
sumber
Kami para pengembang suka menggunakan gambar untuk menjelaskan dunia kami, jadi inilah satu dengan produksi mobil:
Di dunia kita, ini sering terjadi daripada mereka yang membuat dan membuat dokumen desain sama dengan yang menghasilkan kode. Itu tidak benar di bidang lain. Namun itu tidak berarti Anda benar-benar bisa mendapatkan tingkat kualitas yang sama dengan melakukan semuanya bersama-sama.
Dengan membuat dokumen-dokumen itu terlebih dahulu tanpa coding (tidak termasuk apa pun seperti bukti konsep untuk kemudahan, ...):
Catatan: penegasan tersebut mengira bahwa kode tersebut benar-benar mencerminkan desain dan keduanya tetap terbaru ...
sumber