Jadi ketika saya di universitas saya dididik tentang manfaat UML dan masa depannya dalam pengembangan kode.

Tetapi dari pengalaman industri saya, saya telah menemukan bahwa sementara kami menggunakan diagram — mulai dari diagram ER, diagram kelas, diagram negara, hingga diagram alur kerja — semua itu untuk keperluan komunikasi.

Yaitu, saya tidak pernah membuat kode secara otomatis dari diagram, dan dari sudut pandang komunikasi, saya biasanya mencoba membuat diagram saya sesederhana dan semudah mungkin dimengerti.

Tetapi ketika saya melihat Visio dan Enterprise Architect, sepertinya mereka memiliki banyak jenis grafik, bentuk, objek properti, yang sebagian besar tidak saya gunakan.

Apakah orang menggunakan UML untuk melakukan hal-hal yang lebih canggih seperti pembuatan kode atau basis data?

Ya, alat UML CASE adalah salah satu item paling populer di tahun 90-an ... dan kemudian gagal dikirim.

Alasan mendasar untuk hal ini adalah diagram UML (atau hampir semua jenis lainnya) membantu untuk memahami masalah dan / atau program menyelesaikannya hanya sepanjang diagram mengabstraksi rincian implementasi kode aktual. Jadi (untuk setiap potongan kode nontrivial), diagram yang mudah dipahami secara inheren tidak berguna untuk pembuatan kode , karena tidak memiliki rincian yang diperlukan. Dan sebaliknya, diagram yang langsung dapat digunakan untuk pembuatan kode tidak banyak membantu Anda memahami program lebih baik daripada kode itu sendiri. Jika Anda pernah melihat diagram kelas UML yang direkayasa balik dari kode produksi, Anda mungkin tahu apa yang saya maksud.

Satu-satunya pengecualian potensial untuk hal ini yang saya ketahui adalah diagram Entity-Relationship, yang tidak mencakup kode per se, hanya (sesuai namanya) potongan data dan hubungan mereka. Tetapi saya belum pernah mendengar tentang upaya yang berhasil untuk menggunakan segala jenis diagram UML untuk pembuatan kode nyata [Pembaruan] - yaitu lebih dari kerangka kelas dan kode sepele seperti getter / setter -, kecuali dalam alat / area tujuan khusus seperti ORM, seperti yang disaksikan oleh Doc Brown di bawah [/ Perbarui] , dan saya pikir ini bukan kebetulan.

Saya pribadi tidak membenci UML - Saya pikir diagram UML dapat menjadi alat komunikasi yang hebat - untuk menunjukkan maksud dan ide Anda selama diskusi desain, atau untuk memvisualisasikan arsitektur aplikasi Anda. Tetapi yang terbaik adalah mempertahankannya, dan jangan mencoba menggunakannya untuk hal-hal yang tidak mereka sukai.

Jadi ketika saya di uni (beberapa waktu lalu sekarang), saya diberi tahu bahwa UML adalah masa depan, UML akan mengganti pemrograman dan kami hanya akan menghasilkan kode dari diagram dll.

Mereka salah. Itu akan terjadi tentang waktu orang meninggalkan pidato dan kembali ke lukisan gua.

Masalah dunia nyata, dan program yang menyelesaikannya, memiliki kompleksitas esensial yang tidak dapat dikurangi. Untuk menghasilkan program yang berfungsi, kompleksitas itu harus ditangkap dan diekspresikan dalam beberapa bahasa yang dapat dieksekusi. Pertanyaannya adalah apakah beberapa bahasa pemrograman diagram bisa lebih efektif daripada bahasa pemrograman tekstual. Kami telah bereksperimen dengan pemrograman diagram selama sekitar tiga puluh tahun, dan sejauh ini buktinya sangat mendukung pemrograman tekstual. Saya tidak mengetahui adanya aplikasi penting yang telah dihasilkan oleh pembuatan kode dari diagram.

TIDAK

Legenda didasarkan pada asumsi gagal bahwa menulis:

class ClassName extends SomeThing
{

}

... sulit dan membutuhkan otomatisasi .

Anda mungkin masih menemukan orang percaya yang sesekali, atau kerumunan orang percaya.
Tapi begitulah halnya dengan agama dan kultus.

Berada di sana, tidak merasa terlalu berguna.

Secara umum diagram yang cukup spesifik untuk menghasilkan beberapa kode dari mereka, terutama diagram kelas, tidak menambahkan banyak cara untuk benar-benar memahami program dan Anda tidak dapat menghasilkan kode dari diagram ikhtisar seperti use case atau aktivitas tingkat-ikhtisar yang sangat penting untuk dokumentasi. Salah satu diagram yang berguna untuk memahami dan dapat menghasilkan kode adalah state chart, yang berguna ketika Anda benar-benar membutuhkan mesin negara. Tetapi umumnya Anda harus mencoba untuk menghindari itu, karena mereka secara inheren rawan kesalahan.

Pada satu proyek kami diminta untuk merancang kode di modeller UML (Rhapsody) dan menghasilkannya dari sana. Ini semacam bekerja dan mungkin sedikit lebih mudah daripada mengetik header (itu C ++) dan prototipe dengan tangan. Kemampuan untuk menjaga keduanya konsisten secara otomatis agak berguna.

Badan metode masih harus diisi dengan tangan, karena diagram tidak dapat benar-benar mewakili itu dengan pengecualian kerangka mesin negara.

Di sisi lain itu agak rumit, jadi Anda harus belajar banyak hal tambahan dan yang lebih penting adalah rasa sakit untuk bergabung. Penggabungan diteliti dengan baik untuk file teks dan bekerja dengannya, tetapi belum ada yang menemukan cara mudah untuk menggabungkan perubahan pada diagram. Rhapsody sebenarnya menyimpan bagian dari informasi dalam kode yang dihasilkan dan mem-parsingnya kembali, jadi itu tidak sepenuhnya tidak dapat digunakan, tetapi masih merupakan komplikasi serius.

Meskipun tentu saja mungkin untuk menghasilkan kode (dan bahkan seluruh sistem) langsung dari model UML, saya belum pernah melihatnya digunakan dengan cara ini.

Dalam pengalaman saya, sebagian besar perusahaan tampaknya menggunakannya sebagai alat komunikasi untuk persyaratan, atau "MS Paint untuk menggambar diagram".

Satu perbedaan penting yang ingin saya buat adalah bahwa sebagian besar alat pemodelan UML memungkinkan Anda membangun satu model sistem Anda. Visio, misalnya, memiliki pemahaman yang cukup baik tentang cara kerja UML, dan ada banyak hal yang dapat Anda tambahkan yang tidak terkait langsung dengan diagram. Diagram yang sebenarnya hanyalah perspektif yang berbeda pada bagian-bagian model, memungkinkan Anda untuk menyoroti berbagai aspek sistem.

semua itu (diagram pemodelan) adalah untuk keperluan komunikasi

Pemodelan memiliki 4 penggunaan penting dalam proses pengembangan perangkat lunak:

1. Alat Desain Terintegrasi

2. Alat komunikasi

3. Bantuan untuk pembuatan perangkat lunak

4. Cara untuk mengurangi kerumitan masalah kata-sebenarnya (saya belajar ini dari tanggapan @kevin cline di atas)

5. Proses pemodelan membuat beberapa desainer berpikir tentang detail yang tidak dipertimbangkan saat pengkodean (dan sebaliknya). Pemodelan pada waktu desain memungkinkan Anda untuk mempertimbangkan gambar yang lebih besar daripada mengkode metode atau kelas dalam bahasa.

Pemodelan menurut saya sangat penting untuk membangun basis data (Diagram ER), memahami alur proses (Activity Diagram) dan memahami interaksi sistem pengguna (Diagram Use Case).

Apakah orang menggunakan UML untuk melakukan hal-hal yang lebih canggih seperti pembuatan kode atau basis data?

Ya memang. ERD (bukan diagram UML) dan Class Diagram dapat digunakan (tergantung pada kemampuan alat Anda) untuk menghasilkan:

1 - Data Definition Language (DDL)

2 - Prosedur Tersimpan untuk CRUD dan Diagram Kelas dalam bahasa pilihan Anda (kurang berguna karena alat ORM melakukan lebih banyak tentang ini)

Di antara fitur yang paling berharga dari alat pemodelan adalah:

1 - Kemampuan untuk menjaga integritas model. Jika Anda melakukan perubahan, itu menyebar dalam model

2 - Kemampuan untuk menjawab pertanyaan yang digunakan di mana (di mana 'akun' digunakan dalam model saya?)

3 - Kemampuan untuk memungkinkan pengguna bersamaan untuk bekerja pada model

4 - Cari dalam representasi grafis

5 - Kontrol pencetakan

6 - Layering (mengatur elemen diagram Anda di layer) sehingga Anda dapat fokus pada layer-at-a-time

7 - Pembuatan kode basis data untuk beberapa sistem basis data

8 - Validasi model (memeriksa konsistensi, kunci yang hilang, siklus, dll.)

Jadi, alat pemodelan, khususnya yang bagus, melakukan lebih dari sekadar Paint.

Kami menggunakan Arsitek Perangkat Lunak untuk melakukan desain tingkat tinggi dan mendokumentasikan beberapa interaksi komponen yang lebih misterius dalam barang-barang kami. Terkadang kami membuat kerangka aplikasi dari diagram, tetapi setelah selesai, kami mempertahankan keduanya secara terpisah, kami tidak mencoba merekayasa balik kode kembali ke diagram setelah selesai. Saya dulu menggunakan alat yang disebut Rasional XDE yang bekerja cukup baik untuk program kecil, tetapi itu akan hilang ketika Anda mulai menambahkan dalam penangan acara Swing atau mencoba bekerja dengan Struts.

Saya pikir sebagian besar alasan mengapa orang tidak menulis di UML adalah karena dibutuhkan lebih banyak pekerjaan untuk sepenuhnya menentukan semua yang ada di UML dan kemudian menghasilkan kode dari diagram Anda. Saya tahu US DoD bekerja dengan OMG untuk mengembangkan beberapa alat yang akan menghasilkan kode "terbukti" dari diagram yang telah diverifikasi dengan benar, tetapi kesan saya adalah bahwa Anda akan berakhir dengan urutan metadata yang lebih besar daripada kode sebenarnya. Yang mungkin bagus (ini dokumentasi, setelah semua), tetapi menghasilkan metadata tidak lebih cepat dari menulis kode, sehingga Anda menghabiskan lebih banyak waktu secara proporsional.

UML sendiri adalah sistem notasi, sehingga merupakan alasan untuk komunikasi dan dokumentasi. Sangat jarang untuk menghasilkan kode dari model UML, tapi ya ada yang melakukannya. Pengguna Rhapsody melakukannya lebih sering daripada Rose. Bagian yang sulit adalah menjaga model dan kode disinkronkan, untuk sebagian besar proyek nyata, biayanya terlalu tinggi.

Dalam proyek terbaru saya, saya menggunakan UML-Lab (https://www.uml-lab.com). Ini adalah alat yang bagus yang memungkinkan model untuk direkayasa balik juga. Alat ini menghasilkan kode java dan bahkan anotasi JPA yang cukup akurat.

Tantangannya adalah ketika bekerja dalam sebuah tim. Model ini statis dan berada dalam satu sumber daya tunggal yang membuatnya tetap sinkron dengan beberapa pengembang perubahan sedikit sulit. Ada versi uji coba yang tersedia selama 1 bulan yang merupakan waktu yang tepat untuk mengeksplorasi dan membandingkan dengan yang lain jika Anda sedang menyelidiki.

Ini adalah pertama kalinya saya melihat produk melakukan pemodelan objek dan pemodelan data dalam satu kesempatan bersama dengan pembuatan kode juga.

Kalau tidak, dalam proyek saya yang lalu, saya selalu melihat model basi yang tidak akurat atau terlalu detail.

Dalam proyek masa lalu saya, kadang-kadang saya membuat diagram dengan teknik terbalik. Sebagian besar waktu saya menemukan diagram berantakan dan saya lebih suka menggambar mereka secara manual menyaring semua suara.

Saya pikir kita bisa menggunakan UML untuk menghasilkan kode. Bukan logika bisnis, karena logika bisnis bukan standar dan beragam aplikasi ke aplikasi. Diagram kelas bersama dengan diagram ER dapat digunakan untuk menghasilkan antarmuka, kelas, entitas hibernate, metode dao dasar, dll. Kode boilerplate lainnya seperti implementasi fasad, konverter tipe data (misalnya entitas untuk mentransfer objek) juga dapat dihasilkan dengan bantuan digram objek .

Juga, sebagaimana disebutkan dalam komentar sebelumnya, skema basis data, skrip DDL, dll. Dapat dibuat menggunakan model.

Menggunakan OAW, dan alat pemodelan seperti Enterprise Architect, kita dapat menulis generator kode yang lebih kuat, yang bahkan dapat membantu dalam menghasilkan file konfigurasi, kode pabrik menggunakan stereotip dan nilai yang ditandai.

Saya masih tidak mengerti mengapa intelijen bisnis dengan alat-alat seperti Business Object dapat menganalisis dan memanfaatkan semua informasi perusahaan sementara di tingkat teknologi kami masih bekerja pada level kode saja atau pada level abstrak dengan UML !!

Masalahnya bukan UML tetapi transformasi model antara UML dan MOF dan pembuatan kode dari diagram clas atau xmi menggunakan templat. UML dikatakan memberikan pandangan abstrak tentang dunia nyata sehingga Anda hanya melihat apa yang benar-benar penting. Setelah mengatakan bahwa bagaimana menghasilkan kode yang akurat jika diagram UML hanyalah pandangan dari dunia nyata? Tidak mungkin dan karena itu pengembangan yang didorong oleh model yang akan menghasilkan kode dari suatu model telah gagal.

Solusinya adalah mengubah untuk memetakan dunia nyata dan karena itu semua kode proyek menjadi model UML tunggal. Memiliki model tunggal dan logika penuh proyek Anda kemudian dapat menghasilkan tampilan dari model dan bukan dari kode setiap kali. Ada inisiatif berani yang dibuat oleh Omondo dalam teknologi Java / Jee. Konsepnya adalah sinkronisasi langsung MOF dan UML langsung dengan kode dan ORM. Diagram UML sekarang hanyalah tampilan tingkat tinggi dari model yang memetakan seluruh proyek. Anda dapat membuat ratusan tampilan, menambahkan ratusan catatan dll .... untuk memiliki pemahaman yang lebih baik tentang proyek. Kode hanya akan dihasilkan jika elemen diubah atau dibuat. Teknologi luar biasa di mana Java Id dipetakan ke id UML tanpa jembatan transformasi tradisional antara MOF dan UML.

Apa yang juga fantastis adalah dapat memodelkan domain saya di tingkat UML dan mendapatkan anotasi ORM saya langsung dalam kode dan oleh karena itu menggunakan Hibernate saya dapat membuat, menghapus, membuat database saya, menyebarkan dll ... dalam integrasi berkelanjutan permanen di mana UML adalah bagian dari semua arsitektur dan bukan arsitektur itu sendiri dari proyek.

Saya tidak pernah kecewa dengan UML sebagai penampil tingkat tinggi jika sinkronisasi langsung dengan kode tetapi benar-benar hancur oleh penggunaan tradisional MDA dengan pembuatan model templat pengembangan yang digerakkan Model. Pembuatan kode dari model seperti halaman HTML yang berasal dari dokumen kata. Bagaimana cara mengubahnya setelah dibuat? Tidak mungkin memperbarui dan Anda menghabiskan lebih banyak waktu untuk membersihkan kode daripada menulis dari awal!