Apakah UML praktis? [Tutup]

Di perguruan tinggi saya telah memiliki banyak kursus desain dan berorientasi UML , dan saya menyadari bahwa UML dapat digunakan untuk menguntungkan proyek perangkat lunak, terutama pemetaan kasus penggunaan , tetapi apakah itu benar-benar praktis? Saya telah melakukan beberapa istilah kerja koperasi, dan tampaknya UML tidak banyak digunakan di industri ini. Apakah sepadan dengan waktu selama proyek membuat diagram UML? Juga, saya menemukan bahwa diagram kelas umumnya tidak berguna, karena hanya lebih cepat untuk melihat file header untuk sebuah kelas. Secara khusus diagram mana yang paling berguna?

Edit: Pengalaman saya terbatas pada kecil, di bawah 10 proyek pengembang.

Sunting: Banyak jawaban bagus, dan meski bukan yang paling bertele-tele, saya percaya yang dipilih adalah yang paling seimbang.

Dalam sistem yang cukup kompleks ada beberapa tempat di mana beberapa UMLdianggap berguna.

Diagram yang berguna untuk sistem, berbeda-beda berdasarkan penerapannya.
Tetapi yang paling banyak digunakan adalah:

• Diagram Kelas
• Diagram Status
• Diagram Aktivitas
• Diagram Urutan

Ada banyak perusahaan yang bersumpah demi mereka dan banyak yang langsung menolaknya karena hanya membuang-buang waktu dan tenaga.

Sebaiknya jangan berlebihan dan memikirkan apa yang terbaik untuk proyek yang Anda jalani dan memilih hal-hal yang dapat diterapkan dan masuk akal.

Menggunakan UML seperti melihat kaki Anda saat berjalan. Itu membuat sesuatu secara sadar dan eksplisit yang biasanya dapat Anda lakukan secara tidak sadar. Pemula perlu memikirkan dengan hati-hati tentang apa yang mereka lakukan, tetapi programmer profesional sudah tahu apa yang mereka lakukan. Sebagian besar waktu, menulis kode itu sendiri lebih cepat dan lebih efektif daripada menulis tentang kode, karena intuisi pemrograman mereka disesuaikan dengan tugas.

Ini bukan hanya tentang apa yang Anda lakukan. Bagaimana dengan karyawan baru yang datang enam bulan dari sekarang dan perlu memahami kode dengan cepat? Bagaimana dengan lima tahun dari sekarang ketika semua orang yang saat ini mengerjakan proyek sudah tidak ada?

Sangat membantu untuk memiliki beberapa dokumentasi dasar terkini yang tersedia bagi siapa saja yang bergabung dengan proyek nanti. Saya tidak menganjurkan diagram UML lengkap dengan nama metode dan parameter (JAUH terlalu sulit untuk dipelihara), tetapi menurut saya diagram dasar komponen dalam sistem dengan hubungan dan perilaku dasarnya sangat berharga. Kecuali jika desain sistem berubah secara drastis, informasi ini tidak akan banyak berubah meskipun penerapannya di-tweak.

Saya telah menemukan bahwa kunci dokumentasi adalah moderasi. Tidak ada yang akan membaca 50 halaman diagram UML lengkap dengan dokumentasi desain tanpa tertidur beberapa halaman. Di sisi lain, kebanyakan orang akan senang mendapatkan 5-10 halaman diagram kelas sederhana dengan beberapa deskripsi dasar tentang bagaimana sistem disatukan.

Kasus lain di mana saya menemukan UML berguna adalah ketika pengembang senior bertanggung jawab untuk merancang komponen tetapi kemudian menyerahkan desain kepada pengembang junior untuk diimplementasikan.

Menggunakan UML seperti melihat kaki Anda saat berjalan. Itu membuat sesuatu secara sadar dan eksplisit yang biasanya dapat Anda lakukan secara tidak sadar. Pemula perlu memikirkan dengan hati-hati tentang apa yang mereka lakukan, tetapi programmer profesional sudah tahu apa yang mereka lakukan. Sebagian besar waktu, menulis kode itu sendiri lebih cepat dan lebih efektif daripada menulis tentang kode, karena intuisi pemrograman mereka disesuaikan dengan tugas.

Pengecualiannya adalah mengapa Anda menemukan diri Anda berada di hutan pada malam hari tanpa obor dan hujan mulai turun - maka Anda perlu melihat kaki Anda untuk menghindari jatuh. Ada kalanya tugas yang Anda lakukan lebih rumit daripada yang dapat ditangani oleh intuisi Anda, dan Anda perlu memperlambat dan menyatakan struktur program Anda secara eksplisit. Maka UML adalah salah satu dari banyak alat yang dapat Anda gunakan. Lainnya termasuk pseudocode, diagram arsitektur tingkat tinggi, dan metafora aneh.

Alur kerja generik dan DFD bisa sangat berguna untuk proses yang kompleks. Semua pembuatan diagram lainnya (TERUTAMA UML), menurut pengalaman saya, tanpa kecuali menyia-nyiakan waktu dan tenaga.

Saya harus setuju, UML digunakan di mana-mana - di mana pun proyek TI sedang dirancang, UML biasanya akan ada di sana.

Sekarang apakah itu digunakan dengan baik adalah masalah lain.

Seperti yang dikatakan Stu, saya menemukan Use Case (bersama dengan deskripsi use case) dan diagram aktivitas menjadi yang paling berguna dari sudut pandang pengembang.

Diagram kelas bisa sangat berguna saat mencoba menunjukkan hubungan, serta atribut objek, seperti persistensi. Ketika datang untuk menambahkan atribut atau properti tunggal, mereka biasanya berlebihan, terutama karena sering menjadi ketinggalan zaman dengan cepat setelah kode ditulis.

Salah satu masalah terbesar dengan UML adalah jumlah pekerjaan yang diperlukan untuk menjaganya tetap mutakhir setelah kode dibuat, karena ada beberapa alat yang dapat merekayasa ulang UML dari kode, dan hanya sedikit yang melakukannya dengan baik.

Saya akan memenuhi jawaban saya dengan menyebutkan bahwa saya tidak memiliki pengalaman dalam lingkungan pengembangan perusahaan yang besar (seperti IBM).

Cara saya melihat UML dan Proses Terpadu Rasional adalah bahwa ini lebih BERBICARA tentang apa yang akan Anda lakukan daripada benar-benar MELAKUKAN apa yang akan Anda lakukan.

(Dengan kata lain, ini hanya membuang-buang waktu)

Buang hanya menurut pendapat saya. UML adalah alat yang hebat untuk mengkomunikasikan ide, satu-satunya masalah adalah ketika Anda menyimpan dan memeliharanya karena pada dasarnya Anda membuat dua salinan dari informasi yang sama dan di sinilah biasanya hal itu terjadi. Setelah tahap awal implementasi, sebagian besar UML harus dibuat dari kode sumber, jika tidak UML akan kedaluwarsa dengan sangat cepat atau memerlukan banyak waktu (dengan kesalahan manual) untuk tetap mutakhir.

Saya mengajar bersama kursus proyek pengembangan tingkat senior dua semester terakhir saya di sekolah. Proyek ini dimaksudkan untuk digunakan dalam lingkungan produksi dengan nirlaba lokal sebagai klien yang membayar. Kami harus yakin bahwa kode melakukan apa yang kami harapkan dan bahwa siswa menangkap semua data yang diperlukan untuk memenuhi kebutuhan klien.

Waktu kelas terbatas, begitu juga waktu saya di luar kelas. Karena itu, kami harus melakukan peninjauan kode di setiap rapat kelas, tetapi dengan 25 siswa yang terdaftar, waktu peninjauan individu sangat singkat. Alat yang kami temukan paling berharga dalam sesi review ini adalah ERD, diagram kelas dan diagram urutan. ERD dan diagram kelas hanya dikerjakan di Visual Studio, sehingga waktu yang dibutuhkan untuk membuatnya sangat mudah bagi siswa.

Diagram mengkomunikasikan banyak informasi dengan sangat cepat. Dengan memiliki ikhtisar singkat tentang desain siswa, kami dapat dengan cepat mengisolasi area masalah dalam kode mereka dan melakukan tinjauan yang lebih detail di tempat.

Tanpa menggunakan diagram, kami harus meluangkan waktu untuk membaca satu per satu file kode siswa untuk mencari masalah.

Saya datang ke topik ini sedikit terlambat dan hanya akan mencoba menjelaskan beberapa poin kecil. Menanyakan apakah UML berguna sejauh ini. Kebanyakan orang sepertinya menjawab pertanyaan dari UML yang umum / populer sebagai perspektif alat gambar / komunikasi. Catatan: Martin Fowler dan penulis buku UML lainnya merasa UML paling baik digunakan untuk komunikasi saja. Namun, ada banyak kegunaan lain dari UML. Di atas segalanya, UML adalah bahasa pemodelan yang notasi dan diagramnya dipetakan ke konsep logis. Berikut beberapa kegunaan UML:

• Komunikasi
• Dokumentasi Desain / Solusi Standar
• Definisi DSL (Domain Specific Language)
• Definisi Model (Profil UML)
• Pola / Penggunaan Aset
• Pembuatan Kode
• Model ke Model transformasi

Mengingat daftar penggunaan di atas, posting oleh Pascal tidak cukup karena hanya berbicara tentang pembuatan diagram. Sebuah proyek dapat memperoleh manfaat dari UML jika salah satu faktor di atas merupakan faktor penentu keberhasilan atau merupakan area masalah yang memerlukan solusi standar.

Diskusi harus diperluas dari bagaimana UML dapat menjadi over kill atau diterapkan pada proyek-proyek kecil untuk membahas kapan UML masuk akal atau benar-benar akan meningkatkan produk / solusi seperti saat UML harus digunakan. Ada situasi di mana UML untuk satu pengembang dapat merasakan juga, seperti Aplikasi Pola atau Pembuatan Kode.

UML telah bekerja untuk saya selama bertahun-tahun. Ketika saya mulai, saya membaca Fowler's UML Distilled di mana dia mengatakan "lakukan cukup pemodelan / arsitektur / dll.". Gunakan saja apa yang Anda butuhkan !

Dari perspektif QA Engineer, diagram UML menunjukkan potensi kekurangan dalam logika dan pemikiran. Membuat pekerjaan saya lebih mudah :)

Saya pikir UML berguna, saya pikir spesifikasi 2.0 telah membuat apa yang dulunya spesifikasi yang jelas agak membengkak dan tidak praktis. Saya setuju dengan edisi diagram waktu dll karena mereka mengisi kekosongan ...

Belajar menggunakan UML secara efektif membutuhkan sedikit latihan. Poin yang paling penting adalah berkomunikasi dengan jelas, menjadi model saat dibutuhkan dan menjadi model sebagai sebuah tim. Papan tulis adalah alat terbaik yang pernah saya temukan. Saya belum pernah melihat "perangkat lunak papan tulis digital" yang berhasil menangkap kegunaan papan tulis yang sebenarnya.

Karena itu, saya menyukai alat UML berikut:

1. Violet - Jika lebih sederhana, itu akan menjadi selembar kertas

2. Altova UModel - Alat yang bagus untuk Java dan C # Modeling

3. MagicDraw - Alat komersial favorit saya untuk Pemodelan

4. Poseidon - Alat yang layak dengan hasil yang bagus

5. StarUML - Alat pemodelan open source terbaik

Diagram UML berguna untuk menangkap dan mengkomunikasikan persyaratan dan memastikan bahwa sistem memenuhi persyaratan tersebut. Mereka dapat digunakan secara berulang dan selama berbagai tahap perencanaan, desain, pengembangan, dan pengujian.

Dari topik: Menggunakan Model dalam Proses Pengembangan di http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

Model dapat membantu Anda memvisualisasikan dunia tempat sistem Anda bekerja, mengklarifikasi kebutuhan pengguna, menentukan arsitektur sistem Anda, menganalisis kode, dan memastikan bahwa kode Anda memenuhi persyaratan.

Anda mungkin juga ingin membaca tanggapan saya untuk posting berikut ini:

Bagaimana cara mempelajari "desain / arsitektur perangkat lunak yang baik"? di /programming/268231/how-to-learn-good-software-design-architecture/2293489#2293489

Meskipun diskusi ini sudah lama tidak aktif, saya memiliki beberapa hal-hal penting yang perlu saya tambahkan.

Kode Buggy adalah satu hal. Jika dibiarkan melayang ke hilir, kesalahan desain bisa menjadi sangat membengkak dan jelek. UML, bagaimanapun, memvalidasi diri sendiri. Maksud saya, dengan memungkinkan Anda menjelajahi model Anda dalam beberapa dimensi yang tertutup secara matematis dan saling memeriksa, ini menghasilkan desain yang kuat.

UML memiliki aspek penting lainnya: ia "berbicara" langsung dengan kemampuan terkuat kami, yaitu visualisasi. Seandainya, misalnya, ITIL V3 (pada intinya cukup sederhana) dikomunikasikan dalam bentuk diagram UML, itu bisa saja diterbitkan pada beberapa lusin lipatan A3. Sebaliknya, itu muncul dalam beberapa buku besar dengan proporsi yang benar-benar alkitabiah, menelurkan seluruh industri, biaya yang menakjubkan dan kejutan katatonik yang meluas.

Saya melihat diagram urutan dan diagram aktivitas cukup sering digunakan. Saya melakukan banyak pekerjaan dengan sistem "real-time" dan tertanam yang berinteraksi dengan sistem lain, dan diagram urutan sangat membantu dalam memvisualisasikan semua interaksi.

Saya suka membuat diagram kasus penggunaan, tetapi saya belum pernah bertemu terlalu banyak orang yang menganggapnya berharga.

Saya sering bertanya-tanya apakah Rational Rose adalah contoh yang baik dari jenis aplikasi yang Anda dapatkan dari desain berbasis model UML. Ini kembung, buggy, lambat, jelek, ...

Saya menemukan UML tidak terlalu berguna untuk proyek yang sangat kecil, tetapi sangat cocok untuk proyek yang lebih besar.

Pada dasarnya, tidak masalah apa yang Anda gunakan, Anda hanya perlu mengingat dua hal:

• Anda menginginkan semacam perencanaan arsitektur
• Anda ingin memastikan bahwa setiap orang dalam tim benar-benar menggunakan teknologi yang sama untuk perencanaan proyek

Jadi UML hanya itu: Sebuah standar tentang bagaimana Anda merencanakan proyek Anda. Jika Anda mempekerjakan orang baru, kemungkinan besar Anda akan mengetahui standar yang ada - baik itu UML, Flowchard, Nassi-Schneiderman, apa pun - daripada barang internal Anda yang sudah ada.

Menggunakan UML untuk satu pengembang dan / atau proyek perangkat lunak sederhana tampaknya berlebihan bagi saya, tetapi ketika bekerja dalam tim yang lebih besar, saya pasti menginginkan beberapa standar untuk perangkat lunak perencanaan.

UML bermanfaat, ya memang! Kegunaan utama yang saya buat adalah:

• Brainstorming tentang cara kerja perangkat lunak. Itu memudahkan untuk mengkomunikasikan apa yang Anda pikirkan.
• Mendokumentasikan arsitektur sistem, polanya, dan hubungan utama kelasnya. Ini membantu ketika seseorang memasuki tim Anda, ketika Anda pergi dan ingin memastikan penerus Anda akan memahaminya, dan ketika Anda akhirnya lupa untuk apa kelas kecil itu dimaksudkan.
• Mendokumentasikan pola arsitektur apa pun yang Anda gunakan pada semua sistem Anda, untuk alasan yang sama dengan titik di atas

Saya hanya tidak setuju dengan Michael ketika dia mengatakan bahwa menggunakan UML untuk pengembang tunggal dan / atau proyek perangkat lunak sederhana tampaknya berlebihan baginya. Saya telah menggunakannya pada proyek pribadi kecil saya, dan mendokumentasikannya menggunakan UML menghemat banyak waktu ketika saya kembali kepada mereka tujuh bulan kemudian dan benar-benar lupa bagaimana saya telah membangun dan mengumpulkan semua kelas itu.

Saya yakin mungkin ada cara untuk memanfaatkan ikan UML gaya Cockburn, layang-layang, dan kasus penggunaan di permukaan laut seperti yang dijelaskan oleh Fowler dalam bukunya "UML Distilled." Ide saya adalah menggunakan kasus penggunaan Cockburn sebagai bantuan untuk keterbacaan kode.

Jadi saya melakukan percobaan dan ada posting di sini tentang itu dengan Tag "UML" atau "FOWLER." Itu adalah ide sederhana untuk c #. Temukan cara untuk memasukkan kasus penggunaan Cockburn ke dalam ruang nama konstruksi pemrograman (seperti ruang nama kelas dan kelas dalam atau dengan menggunakan ruang nama untuk enumerasi). Saya percaya ini bisa menjadi teknik yang layak dan sederhana tetapi masih memiliki pertanyaan dan membutuhkan orang lain untuk memeriksanya. Ini bisa bagus untuk program sederhana yang membutuhkan semacam pseudo-Domain Specific Language yang bisa ada tepat di tengah-tengah kode c # tanpa ekstensi bahasa.

Silakan lihat posting jika Anda tertarik. Pergi ke sini .

Salah satu masalah yang saya miliki dengan UML adalah pemahaman spesifikasinya. Ketika saya mencoba untuk benar-benar memahami semantik dari diagram tertentu, saya segera tersesat dalam labirin meta-model dan meta-meta-model. Salah satu nilai jual UML adalah bahasa ini kurang ambigu dibandingkan bahasa alami. Namun, jika dua, atau lebih, insinyur menafsirkan diagram secara berbeda, itu gagal pada tujuan.

Selain itu, saya telah mencoba mengajukan pertanyaan khusus tentang dokumen super-struktur di beberapa forum UML, dan kepada anggota OMG itu sendiri, dengan sedikit atau tanpa hasil. Saya rasa komunitas UML belum cukup dewasa untuk mendukung dirinya sendiri.

Berasal dari seorang mahasiswa, saya menemukan bahwa UML memiliki sedikit kegunaan. Saya merasa ironis bahwa PROGAMERS belum mengembangkan program yang secara otomatis akan menghasilkan hal-hal yang Anda katakan diperlukan. Akan sangat sederhana untuk merancang fitur ke dalam Visual Studio yang dapat menarik potongan data, mencari definisi, dan jawaban produk yang memadai sehingga siapa pun dapat melihatnya, besar atau kecil, dan memahami program. Ini juga akan membuatnya tetap mutakhir karena akan mengambil informasi langsung dari kode untuk menghasilkan informasi.

UML digunakan segera setelah Anda merepresentasikan kelas dengan bidang dan metodenya meskipun itu hanya semacam diagram UML.

Masalah dengan UML adalah buku pendirinya terlalu kabur.

UML hanyalah sebuah bahasa, ini bukanlah sebuah metode.

Bagi saya, saya benar-benar merasa terganggu dengan kurangnya skema UML untuk Proyek OpenSource. Ambil sesuatu seperti Wordpress, Anda hanya memiliki skema database, tidak ada yang lain. Anda harus berkeliling di sekitar api kodeks untuk mencoba mendapatkan gambaran besarnya.

UML ada tempatnya. Ini menjadi semakin penting seiring dengan bertambahnya ukuran proyek. Jika Anda memiliki proyek yang berjalan lama, maka yang terbaik adalah mendokumentasikan semuanya dalam UML.

UML tampaknya bagus untuk proyek besar dengan tim besar. Namun saya telah bekerja dalam tim kecil di mana komunikasi lebih baik.

Menggunakan diagram seperti UML itu bagus, terutama dalam tahap perencanaan. Saya cenderung berpikir dalam kode, jadi saya merasa menulis spesifikasi besar itu sulit. Saya lebih suka menuliskan input 'dan output' dan membiarkan pengembang merancang bit di tengah.

Saya percaya UML berguna hanya karena fakta bahwa ia membuat orang berpikir tentang hubungan antara kelas mereka. Ini adalah titik awal yang baik untuk mulai memikirkan hubungan seperti itu, tetapi ini jelas bukan solusi untuk semua orang.

Keyakinan saya adalah bahwa penggunaan UML bersifat subyektif terhadap situasi di mana tim pengembangan bekerja.

Dalam pengalaman saya:

Kemampuan untuk membuat dan mengkomunikasikan diagram kode yang berarti adalah keterampilan yang diperlukan untuk setiap insinyur perangkat lunak yang mengembangkan kode baru, atau mencoba memahami kode yang ada.

Mengetahui secara spesifik UML - kapan harus menggunakan garis putus-putus, atau titik akhir lingkaran - tidak terlalu diperlukan, tetapi masih bagus untuk dimiliki.

UML berguna dalam dua cara:

• Sisi teknis: banyak orang (manajer dan beberapa analis fungsional) berpikir bahwa UML adalah fitur mewah karena kodenya adalah dokumentasi: Anda memulai pengkodean, setelah Anda men-debug dan memperbaiki . Sinkronisasi diagram UML dengan kode dan analisis memaksa Anda untuk memahami dengan baik permintaan pelanggan;

• Sisi manajemen: diagram UMl adalah cermin dari kebutuhan pelanggan yang tidak akurat: jika Anda membuat kode tanpa UML, mungkin Anda dapat menemukan bug di dalam membutuhkan setelah berjam-jam bekerja. Diagram UML memungkinkan Anda untuk menemukan kemungkinan poin kontroversi dan menyelesaikannya sebelum coding => membantu perencanaan Anda.

Umumnya, semua proyek tanpa diagram UML memiliki analisis dangkal atau ukurannya pendek.

jika Anda tergabung dalam grup SISTEM ENGINEERS , lihat diskusi lama saya .

Pada akhirnya UML hanya ada karena RUP. Apakah kita membutuhkan UML atau hal-hal terkait lainnya untuk menggunakan Java / .Net? Jawaban praktisnya adalah mereka memiliki dokumentasi sendiri (javadoc dll) yang cukup dan memungkinkan kami menyelesaikan pekerjaan kami!

UML no thanx.

UML sangat membantu seperti halnya junit. Itu semua tergantung bagaimana Anda menjual idenya. Program Anda akan bekerja tanpa UML seperti program bekerja tanpa pengujian unit. Karena itu, Anda harus membuat do UML karena selama itu terhubung ke kode Anda, yaitu ketika Anda memperbarui diagram UML, kode Anda akan diperbarui, atau ketika Anda memperbarui kode itu secara otomatis menghasilkan UML. Jangan lakukan hanya demi melakukannya.

UML jelas memiliki tempatnya di industri. Bayangkan Anda sedang membangun perangkat lunak untuk pesawat Boing atau sistem kompleks lainnya. UML dan RUP akan sangat membantu di sini.

UML hanyalah salah satu metode komunikasi di dalam manusia. Papan tulis lebih baik.