Seberapa penting diagram UML untuk proyek yang sukses? [Tutup]


22

Saya di tengah-tengah proyek dan saya diminta untuk menulis diagram UML (use case, class diagram, dll). Proyek ini tidak terlalu rumit.

Saya bertanya-tanya apakah ini buang-buang waktu? Haruskah saya melakukan hal-hal menyenangkan lainnya seperti menulis kode? Dan kapan tidak membangun sesuatu tanpa melalui semua fase konseptual? Apakah ini semua tentang kompleksitas? Dan jika demikian, bagaimana cara mengukurnya?


Anda mungkin tertarik dengan postingan ini: programmers.stackexchange.com/questions/58084/…
c_maker

15
Maaf tapi saya menemukan "omong kosong teknis" UML, pembuang waktu dan .. Oke, saya akan berhenti di sini. Saya merasa lebih baik sekarang.
Chiron

2
"Jika Anda membutuhkan waktu lebih banyak untuk mendesainnya daripada yang mau dibayar pelanggan, Anda sudah mendesain lebih" digunakan dan akan bermanfaat :)
PhD

1
"Should I just be doing other fun stuff like writing code?"Maksudmu: "other stuff that contributes to the bottom line of the project like writing code"pasti?
StuperUser

Tentu saja Anda tahu, dan jangan panggil Anda Shirley.
StuperUser

Jawaban:


53

Saya adalah penggemar berat UML beberapa waktu lalu. Saya bahkan bersertifikat OMG. Saya menggunakannya secara luas dalam proyek perusahaan besar tempat saya terlibat.

Hari ini, saya menghentikan UML hampir sepenuhnya. Terkadang, saya menggunakan diagram urutan yang menurut saya sangat berguna untuk menggambarkan interaksi antar sistem, tetapi tidak ada diagram lain.

Saya sekarang lebih suka bekerja dengan cerita pengguna, didukung oleh (hanya) dokumentasi yang diperlukan yang ditulis oleh pemilik produk (dan analis) DAN dedikasinya kepada tim pengembangan untuk memberikan rincian lebih lanjut sesuai kebutuhan.

UML adalah alat yang dapat Anda gunakan, tetapi itu jelas bukan faktor penting untuk keberhasilan proyek Anda. Setelah bertahun-tahun, saya sekarang berpikir faktor penting adalah tim pengembangan, tidak peduli alat apa yang digunakannya.


Anda bilang Anda bersertifikat OML. Apa itu OML? Salah ketik?
BЈовић

Ya, itu adalah OMG untuk Grup Manajemen Objek, organisme di belakang UML => uml.org

12
+1 untuk paragraf terakhir. Ketika datang ke diagram perangkat lunak sistem, UML sangat bagus karena itu standar dan harus dipahami dengan baik oleh pengembang perangkat lunak lain tanpa penjelasan. Namun, itu hanya alat dan Anda mungkin tidak memerlukan alat itu, tergantung pada orang yang membangun perangkat lunak.
Thomas Owens

14
Paragraf pertama jauh lebih lucu jika Anda hanya membaca OMG dengan artinya yang biasa .
JSB ձոգչ

@ Pierre303 Saya setuju, bahwa ada opsi lain selain UML. Tetapi pertanyaannya juga tentang penggunaan spesifikasi / alat dokumentasi berbeda dengan pengkodean murni. Apakah "tidak peduli alat apa yang digunakannya" berarti "selama tim benar-benar menggunakan alat untuk tugas-tugas ini"? Apakah Anda menggunakan cerita pengguna bahkan untuk proyek "[tidak] sangat kompleks" atau mereka hanya membuang-buang waktu?
scarfridge

9

Perencanaan sangat penting, tetapi seperti yang diperingatkan oleh ahli strategi terkenal Carl von Clausewitz

Tidak ada rencana kampanye yang bertahan dari kontak pertama dengan musuh

Jadi itu bukan buang-buang waktu untuk merencanakan bagaimana awalnya menyerang masalah. Tetapi kemungkinan membuang-buang waktu untuk mendokumentasikan kode Anda untuk programmer masa depan. Untuk menggunakan metafora militer, Anda memerlukan rencana pertempuran, tetapi Anda tidak akan memberikan rencana itu kepada para sejarawan untuk digunakan sebagai laporan setelah tindakan.

Lebih konkretnya, Anda dapat menggunakan diagram ini untuk mengomunikasikan niat Anda di antara tim Anda dan memikirkan rencana serangan Anda sebelum dan selama proyek. Tetapi kemungkinannya adalah bahwa apa yang Anda hasilkan perlu diubah saat Anda kode dan belajar lebih banyak tentang masalah tersebut. Hampir selalu rencana / desain awal Anda perlu diubah karena Anda tidak dapat mengetahui semuanya di muka.


3
But likely a waste of time for documenting your code for future programmers.Jika sebuah proyek ingin menggunakan UML sebagai bentuk dokumentasi, biasanya dibuat menggunakan alat rekayasa terbalik. Ada berbagai alat yang dapat menghasilkan diagram kelas dan urutan (dan kadang-kadang beberapa lainnya) dari kode sumber, dan output dari alat ini ditangkap sebagai dokumentasi.
Thomas Owens

9

Saya pikir diagram UML hanya dapat berguna jika mereka mengekspresikan sesuatu dalam tingkat abstraksi yang lebih tinggi daripada kode Anda .

Menulis UML hanya demi menulis UML menjadi birokrasi yang tidak dibutuhkan dan membuat proyek dan kode kurang mudah beradaptasi dengan perubahan tanpa manfaat apa pun.

Misalnya, diagram kelas UML yang menunjukkan semua kelas pada suatu paket, dengan semua atribut dan metode mereka - sesuatu yang dapat dengan mudah dibuat secara otomatis - tidak memberikan nilai sama sekali: ia berada pada level abstraksi yang sama dengan kode Anda . Plus, kode pasti akan menjadi sumber yang lebih baik untuk informasi itu karena akan selalu mutakhir, dan mungkin akan didokumentasikan dan diatur dengan cara yang lebih mudah untuk mengetahui metode / atribut / hal mana yang lebih penting.

Di sisi lain, jika Anda memiliki konsep tingkat abstraksi yang lebih tinggi daripada apa yang dapat diekspresikan diungkapkan pada kode, mendokumentasikannya pada diagram dapat menjadi ide yang bagus.

Sebagai contoh, diagram yang menunjukkan modul abstrak tingkat lebih tinggi pada sistem yang kompleks, dengan dependensinya dan mungkin sedikit deskripsi tentang tanggung jawab mereka dan paket / namespace apa yang mereka petakan dalam kode sumber dapat sangat berguna bagi anggota tim baru yang perlu diperkenalkan ke proyek, atau juga dapat digunakan untuk mencari tahu di mana kelas / fungsi baru harus dibuang.

Contoh lain dari diagram yang berguna bisa berupa diagram urutan yang menunjukkan langkah-langkah tingkat tinggi yang harus diambil dalam protokol komunikasi. Mungkin setiap langkah memiliki sedikit keunikan dan kompleksitas, tetapi mungkin cukup untuk menggambarkannya dalam kode itu sendiri. Diagram tingkat yang lebih tinggi dapat membantu seorang programmer untuk memahami "gambaran besar" berbagai hal dengan mudah tanpa perlu khawatir tentang kompleksitas setiap interaksi.

Bagaimanapun, itu hanya beberapa contoh; ada banyak kasus di mana diagram sederhana bisa sangat membantu. Ingatlah bahwa Anda harus melakukannya hanya ketika Anda tidak dapat mengekspresikan sesuatu dalam kode itu sendiri. Jika Anda menemukan diri Anda menggunakan diagram UML untuk menjelaskan kode-sumber itu sendiri, buatlah kode-goda lebih banyak mendokumentasikan diri.

Akhirnya, beberapa aturan umum yang berlaku untuk kode juga dapat diterapkan pada diagram: hindari pengulangan, tetap sederhana, jangan takut mengubah hal-hal (hanya karena sesuatu didokumentasikan pada diagram UML tidak berarti tidak bisa diubah) dan selalu pikirkan siapa yang akan membaca / memelihara diagram tersebut di masa depan (mungkin diri Anda di masa depan) saat menulisnya :)


8

UML memiliki nilai jika anggota tim secara kolektif memahaminya dan menganggapnya sebagai cara yang berguna untuk merangkum dan mengomunikasikan keputusan desain. Anda tidak perlu tahu semuanya, hanya bagian yang berguna bagi tim.

Juga, Anda tidak perlu menggambar diagram yang dipoles sempurna. Diagram sekuens yang digambarkan secara sketsa di papan tulis atau diagram kelas di mana kelas menempelkannya di papan tulis mungkin cukup, tergantung pada konteksnya.


3
+1: Memang: lihat UML sebagai Sketsa .
Richard

6

Saya pernah mengerjakan pertunjukan di mana saya perlu mengelola tim pengembang kontrak di luar negeri.

Beberapa hal yang mereka hasilkan cukup menghebohkan (gejala umum coders kontrak jarak jauh - mereka tidak terlalu peduli dengan kode Anda, mereka hanya ingin menyelesaikannya dengan cepat).

Untuk mengelola proyek, saya menemukan diri saya memproduksi diagram UML dan menyerahkannya kepada mereka untuk dikodekan. Itu sangat sukses - tidak butuh waktu lama bagi saya untuk menulis sebuah program di UML, jauh lebih cepat daripada di Jawa, dan itu adalah sesuatu yang bisa diikuti oleh kontraktor dan diukur.

Satu peringatan - mereka kadang-kadang ingin menjadi kreatif dan menyimpang dari model saya, namun dalam kasus itu mereka benar, dan secara keseluruhan UML meningkatkan kualitas produk akhir


+1 - Salah satu manfaat utama dari pemodelan adalah untuk dapat membuat, mengubah, memahami, dan menjelajahi berbagai ide jauh lebih cepat daripada yang dapat Anda lakukan dalam kode.
Dunk

3

Jika seseorang meminta Anda untuk menyiapkan diagram UML dan seseorang membayar gaji Anda, maka itu bukan buang-buang waktu. Ini mungkin atau mungkin tidak membuang-buang waktu seseorang.

Jika seseorang itu berencana untuk memahami proyek Anda dengan membaca diagram UML Anda, maka itu mungkin bukan buang-buang waktu.


2

Saya merasa berguna pada tahap desain awal untuk mendapatkan ide di atas kertas atau di papan tulis. Saya terutama menggunakan diagram kelas UML, tanpa kepatuhan ketat terhadap standar. Berguna untuk meninjau kembali desain asli UML Anda saat Anda sedang dalam proses dan juga di akhir proyek. Ini telah membantu saya untuk melihat basis kode pada tingkat abstraksi yang lebih tinggi yang pernah Anda bisa dengan membaca kode, dan bahkan telah membantu menemukan bug potensial.

Ada poin bagus yang dibuat di sini oleh ragu.pattabi membedakan antara dua jenis UML ...

Saya pikir rasa lincah UML (mis. Sketsa papan tulis cepat) lebih berhasil daripada rasa air terjun UML (misalnya diagram rumit dengan semua detail berdarah untuk dokumentasi, pembuatan kode, dll untuk membuat manajer yang mengerti dokumen senang).

Ketika UML dipandang sebagai keterampilan 'harus memiliki' (10 tahun yang lalu atau lebih), saya mungkin menentangnya karena pandangan banyak penggemar pada saat itu. Tetapi sekarang karena tidak lagi disukai, saya mendapati diri saya melihatnya apa adanya - alat yang berguna yang memiliki manfaat tetapi bukan peluru perak pengembangan perangkat lunak.


1
+1 - Satu-satunya saat saya melihat UML sebagai pembuang waktu adalah ketika orang mencoba mematuhi "standar" dan lebih buruk lagi, untuk benar-benar menghasilkan kode darinya. Penggunaan yang tepat adalah menggunakannya sebagai mekanisme komunikasi dan cara untuk mengeksplorasi berbagai ide, bahkan jika itu berarti "menyesuaikannya" sesuai dengan kebutuhan Anda. Ini jauh lebih efisien daripada pengkodean dulu, kecuali jika aplikasi itu sepele.
Dunk

1

Saya menggunakan UML (atau yang mirip dengan UML :)) ketika saya berbicara dengan teman tentang sesuatu yang akan kami lakukan. Untuk mendiskusikan ide. Tidak menyiapkan proyek UML yang akan membuat kode autogenerate untuk saya. Saya tidak bisa membayangkan membuat kelas saya di UML kemudian menghasilkan kode dan tidak men-tweak nanti. Ini tidak pernah terjadi. Jadi, Anda harus membawa perubahan dari kode ke UML. Dan ketika saya menggunakan UML saya menggambar di papan tulis atau kertas. Tidak pernah dalam alat seperti Enterprise Architect.

Satu-satunya alasan untuk mendokumentasikan seluruh kode saya di UML adalah kontrak tempat klien menuntutnya. Misalnya ketika dia ingin memiliki opsi untuk mengubah toko perangkat lunak setelah bagian dari perangkat lunak selesai.


1

Dokumentasi pekerjaan proyek merupakan penyampaian mendasar dari proyek profesional. Berapa cukup? Yah itu tentu saja tergantung pada banyak faktor. Namun, menurut pendapat saya, kasus penggunaan, diagram kelas, diagram alir proses, dll. Tidak membuang-buang waktu sama sekali. Mereka memiliki nilai dalam berbagai fase proyek. Satu-satunya masalah dengan dokumentasi biasanya sumber daya.

Beberapa programmer menganggap dokumentasi adalah pemborosan waktu. Tetapi ini tidak benar. Jika Anda melihat dokumentasi sebagai tampilan dari desain dan aturan sistem Anda dengan cara yang elegan dan jelas, Anda bisa lebih menghargainya. Juga, seseorang perlu menempatkan diri pada posisi orang yang perlu mempertahankan sistem. Dilemparkan 500 file kode dan diminta untuk memperbaiki masalah dengan mereka agak buruk tetapi tidak jarang.

Saya sarankan Anda mengalokasikan waktu dalam proyek Anda dan menghasilkan diagram dalam siklus. Yang pertama akan mencakup aspek-aspek tingkat tinggi dari proyek Anda dan tingkat selanjutnya bisa lebih detail.

Kasus penggunaan khususnya tidak dapat disimpulkan dengan mudah dari kode (tidak seperti banyak aspek lain dari suatu sistem). Pastikan Anda melakukan itu.


-1: Jika Anda melihat dokumentasi sebagai tampilan desain dan aturan sistem dengan cara yang elegan dan jelas : Tidak, saya tidak pernah melakukannya; karena selalu usang. // Saya tidak yakin di mana Anda tinggal, tetapi di Planet Earth, perangkat lunak berkembang terlalu cepat untuk membenarkan dokumentasi "kelas profesional".
Jim G.

@ Jim. Itu bisa benar atau tidak benar, tergantung pada seberapa rinci dokumentasi itu. Jika Anda menyimpan dokumentasi Anda tingkat tinggi (komponen, detail utama kelas utama), maka dokumentasi tidak akan cepat basi. Jika Anda secara manual mendokumentasikan setiap anggota dari setiap kelas, maka pekerjaan Anda akan sia-sia dengan cepat.
Danny Varod

1
@ Jimg., Saya yakin Anda tidak sendirian dalam berpikir seperti ini. Fakta bahwa perangkat lunak berubah, tidak membuat analisis, desain, dan dokumen implementasi sepenuhnya usang. Pengetahuan seperti itu berkembang selama siklus hidup sistem. Jika Anda harus menyerahkan sistem ke organisasi yang melakukan Audit TI, Anda harus menunjukkan dokumentasi dan bukan hanya kode dan binari.
NoChance

@Emmad Kareem: Mengenai org yang melakukan audit TI - Sebagian besar dokumentasi itu asal-asalan dan hanya ditujukan untuk audit. Sebagian besar pengembang perangkat lunak tidak akan mempercayainya.
Jim G.

@ Jimg., Apa yang telah Anda jelaskan di komentar terakhir Anda adalah situasi yang ingin saya lihat pergi. Saya akan senang melihat pengembangan perangkat lunak menjadi bisnis yang lebih dapat diprediksi yang akan membuat kehidupan pengembang lebih baik dan akan mengurangi risiko yang ditelan organisasi karena mereka tidak tahu bahaya yang harus mereka hadapi. Bagaimanapun, saya kira itu adalah subjek yang panjang tapi menarik (bagi saya).
NoChance

1

UML adalah alat, tidak lebih, dan apakah itu berguna atau bahkan sangat tergantung pada pengembangan dan alur kerja desain Anda. Ada banyak cara ke Roma, dan beberapa di antaranya melibatkan UML, sementara yang lain tidak.

Jika alur kerja Anda bergantung pada UML untuk mendokumentasikan atau merencanakan arsitektur Anda, maka menjatuhkannya akan konyol. Jika UML adalah cara terbaik untuk mengkomunikasikan struktur proyek kepada anggota tim lain (dalam arti yang lebih luas), maka dengan segala cara, gunakanlah. Tetapi jika proyek berfungsi dengan baik tanpa UML, maka membuat diagram UML hanya demi itu adalah omong kosong.


1

Saya punya beberapa pemikiran tentang ini. Bahasa dapat digunakan dan disalahgunakan, memaksa dan mengalihkan perhatian, memicu dan menidurkan. UML hanyalah bahasa lain yang cocok untuk serangkaian masalah tertentu dan sama seperti bahasa lainnya, UML akan membutuhkan waktu dan upaya untuk belajar berbicara dengan lancar dan memahaminya dengan benar.

Keputusan tentang apa yang harus dikomunikasikan jauh lebih penting daripada bahasa yang dikomunikasikan. UML tidak akan secara ajaib membuat desain buruk Anda dapat dimengerti. Sama seperti bahasa lain, mudah tersesat dalam detail atau meninggalkan terlalu banyak imajinasi.

UML mendapat nama buruk karena banyaknya IDE yang mengerikan, yang memungkinkan prototipe bolak-balik, manipulasi grafik intensif klik dan kesulitan mengubah apa pun. UML 2.0 mungkin cukup kompleks untuk memuaskan akademisi tertentu, tetapi meta-modelnya tampaknya tidak menarik banyak aplikasi praktis.

Namun, saya menggunakan UML dari waktu ke waktu. Untuk mengevaluasi desain tingkat tinggi (desain yang baik memiliki kompleksitas di pinggiran dan kesederhanaan di pusat). Untuk mengkomunikasikan ide kepada kolega dan menerima umpan balik. Untuk menemukan hubungan tersembunyi, normalisasi, dll. Tapi itu selalu merupakan cerminan dari sesuatu yang sudah ada di kepala saya. Secara umum, saya menggambar UML dengan pena dan kertas, sebaiknya jauh dari komputer mana pun. Jika perlu, ketika desain mengkristal, saya membuat representasi visual dalam program menggambar.


1

UML benar-benar fantastis untuk mendapatkan tampilan grafis arsitektur Anda menggunakan diagram kelas. Interaksi menggunakan diagram urutan adalah keajaiban bagi saya. Karena itu masalahnya bukan UML tetapi MDD untuk saya.

Maksud saya jika UML adalah penampil kode maka sangat membantu untuk keperluan dokumentasi tetapi tentu saja tidak untuk pembuatan kode. Proyek harus kode sentris dan tentunya bukan Model driven centric. UML harus digunakan pada tahap implementasi menggunakan kode langsung dan sinkronisasi model. Maksud saya tidak hanya pada tingkat persyaratan yang memerlukan terlalu banyak investasi untuk pengembalian kecil dalam produktivitas dan kualitas.


0

Saya menemukan mereka sangat berlebihan. Saya menganggap mereka satu-satunya gambar yang tidak melukis seribu kata.


Letakkan cat dan kuas di tangan seseorang yang tidak terampil dan semua hasilnya berantakan untuk dibersihkan. Namun, letakkan cat dan kuas di tangan seorang seniman dan lahirlah seni. Hal yang sama berlaku untuk diagram UML.
Dunk

0

UML hanya bernilai jika orang yang merancang sistem tidak dapat menulis kode sendiri. yaitu, UML adalah 'bahasa' yang mengkomunikasikan konsep arsitektur kepada orang lain, sekarang jika Anda adalah orang yang merancang kode dan mengimplementasikannya, lalu mengapa Anda perlu menunjukkan kepada diri sendiri apa yang akan Anda lakukan ?! Dapatkan dan langsung menuju pengkodean. Anda masih harus mendokumentasikan apa yang Anda lakukan nanti, tetapi efisiensi keseluruhan lebih cepat.

Tapi, jika Anda seorang arsitek sistem yang ingin memberi tahu tim pengembang outsourcing tentang apa yang Anda inginkan, maka Anda harus memberi tahu mereka, dan di situlah UML masuk. Namun, saya pikir ada banyak cara alternatif untuk melakukan tugas ini saat ini, dan terus terang, kompleksitas diagram UML berarti setiap orang harus memahami cara membacanya, yang agak merugikan diri sendiri jika tidak.


LMAO, hitam / putih? Metode pengembangan "yang disarankan" Anda adalah alasan saya dipanggil untuk membersihkan dan memperbaiki proyek bencana begitu sering. Kode bukan desainnya. Ada beberapa orang yang dapat membuat sistem yang bahkan cukup kompleks (saya kira saya harus meninggalkan pernyataan itu sebagai berdiri sendiri). Dan ada jauh, jauh lebih sedikit yang bisa melakukannya dengan melompat langsung ke kode. Juga, Anda mungkin memiliki sistem "rusak" lebih cepat, tetapi Anda tidak akan memiliki sistem "berfungsi" lebih cepat dengan melompat langsung ke kode. Tapi saya kira itu semua tergantung pada jenis proyek yang Anda miliki. Jika setengah bekerja tidak masalah, maka pendekatan Anda baik-baik saja.
Dunk

0

Saya tidak pernah menjadi penggemar UML, tetapi saya telah menilai diagram urutan yang baik untuk menggambarkan interaksi antara sistem atau tugas.

Namun diagram kelas sudah usang sebelum dilahirkan. Desain kasar tidak memerlukan UML, dan dokumentasi menyeluruh lebih baik secara otomatis diekstraksi (langsung) dari basis kode. Javadoc dan Doxygen benar-benar membuat usang kebutuhan diagram kelas manual.

Hal tentang dokumentasi adalah bahwa ada dua tingkatan:

  • keputusan tingkat tinggi (arsitektur) harus berupa dokumentasi secara manual
  • fakta level rendah (hubungan entitas) harus diekstraksi secara otomatis

Hampir semua CASE Tools dapat merekayasa balik diagram kelas Anda. Dengan mengatakan itu, saya pikir diagram kelas adalah tentang diagram yang paling tidak berguna yang ada, kecuali mungkin untuk menunjukkan masalah warisan dan ketergantungan (dalam hal ini hanya nama kelas yang cukup). Yang paling menggemparkan untuk uang dalam UML adalah diagram urutan. Sayangnya, tidak ada alat yang melakukan pekerjaan yang wajar untuk diagram urutan rekayasa terbalik. Kurangnya kemampuan ini adalah alasan utama mengapa sangat sulit untuk menggunakan UML untuk mendokumentasikan desain Anda apa adanya. Sebagai gantinya, UML hanya menyediakan peta jalan sebelum implementasi.
Dunk

0

Saya biasanya beralih antara diagram kode dan UML. Saya menemukan bahwa diagram membantu untuk menunjukkan gambaran besar dan jalur yang solid ke depan dan mereka dapat diubah agak cepat ketika masalah ditemukan. Juga, ketika saya memiliki diagram, pengkodean cenderung menjadi sepele.

Sebaliknya, ketika saya menggambar kode dalam gambar itu memperlihatkan masalah ketergantungan dan membuat peluang peningkatan desain jelas, yang mungkin tidak akan diperhatikan jika kita memiliki kode untuk bekerja. Secara khusus, jika itu adalah rasa sakit untuk menggambar, maka itu juga akan menjadi sakit untuk kode dan mimpi buruk untuk dipertahankan.

Saya telah menemukan bahwa iterasi diperlukan, karena hanya menggambar gambar selalu meleset dari aspek-aspek penting, sementara hanya coding hasil dalam desain yang bermasalah.

Namun, seperti kata poster lain, semuanya bermuara pada orang-orang. Jika mereka terampil "menggunakan" diagram UML maka UML sangat berharga. Jika tidak maka diagram tidak ada nilainya.

Jadi, jawaban untuk pertanyaan Anda sebenarnya adalah, "itu tergantung". Dalam hal ini, itu tergantung pada orang-orang, kompleksitas proyek dan seberapa penting sistem bekerja dengan baik.


0

Dari pengalaman saya, UML penting untuk komunikasi antara pengembang tentang pola kode dan untuk arsitektur secara umum aplikasi.


0

Saya suka diagram, tetapi jika saya diminta membuat satu (terutama UML!), Saya akan mengajukan dua pertanyaan:

  1. Untuk siapa ini?
  2. Apakah mereka membutuhkannya sekarang?

Diagram langsung ketinggalan zaman. Jadi, kecuali jika Anda menggunakannya untuk berkomunikasi dengan seseorang sekarang, itu hanya akan membusuk. Dan jika orang yang Anda ajak berkomunikasi akan lebih baik dengan deskripsi teks, atau panggilan telepon, atau digram informal di papan tulis - sarankan sebagai gantinya.


0

Salah satu keluhan utama bagi saya tentang diagram UML seperti yang saya lihat sejauh ini adalah bahwa sebagian besar hanya cenderung berfungsi sebagai "gambar cantik" di dinding seseorang atau sebagai halaman terlipat di tempat yang mengikat dan jarang berfungsi sebagai garis dasar untuk kode produksi.

Dalam jenis skenario ini - diagram UML (atau apa pun rasa bahasa pemodelan yang Anda gunakan) jarang berguna dalam jangka panjang, karena mereka cenderung menderita kehilangan relevansi seiring berjalannya waktu dan proyek berkembang. Gambar-gambar awal ini sebagian besar tidak berguna dan salah dalam waktu beberapa tahun dan memiliki sekitar sebagian besar berbahaya.

Yang mengatakan, menggunakan alat pemodelan (tidak harus UML) tidak sepenuhnya merupakan praktik yang tidak berguna, jika model memberikan input langsung dan relevan untuk kode berjalan aktual. Jika deskripsi model adalah artefak kode yang berguna, itu harus diperlakukan sebagai kode:

Baik dengan menggunakannya sebagai sumber langsung metadata untuk membuat keputusan dinamis berdasarkan konsep yang dimodelkan, atau menggunakan pembuatan kode untuk menghasilkan artefak kode statis yang digunakan dalam kode kerja yang sebenarnya.


0

Tidak tahu apakah pertanyaannya adalah tentang kelebihan UML, atau tentang kelebihan merancang arsitektur program.

Tentang UML. Anda biasanya hanya perlu: use cases, diagram kelas, dan diagram urutan. Sederhana dan mudah, walaupun Anda bisa melakukannya dengan tipe diagram Anda sendiri. Dalam hal ini, UML adalah standar yang semua orang akan mengerti.

Tentang merancang program.

  1. Setiap program memiliki desain, bahkan jika Anda tidak merencanakannya. Ketika kode ini ditulis, hanya merekayasa baliknya. Jika Anda tidak merencanakannya, bertaruh itu akan menjadi desain yang buruk.

  2. Desain akan menghemat waktu Anda, dengan menggunakan pola yang diketahui untuk masalah berulang.

  3. Jika Anda bekerja dalam sebuah tim, desain diperlukan untuk membahas solusi, untuk mengirimkan ide, dan sangat praktis tetapi perlu, untuk mendistribusikan pekerjaan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.