Apakah kode umumnya dihasilkan dari UML? [Tutup]


39

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?


6
@ SK - Kita semua tahu kode ANDA hebat dan ditulis sedemikian jernih sehingga bahkan anak berusia 5 tahun dapat memahami seluruh proyek dengan membaca hanya beberapa metode Anda. Namun, bagi kita semua yang tidak memiliki kemampuan supernatural untuk menulis kode sebening kristal, diagram sangat bermanfaat dalam menggambarkan cara kerja sistem dengan cara yang ringkas dan Diagram UML adalah cara standar menggambar diagram tersebut. Saya tidak mengklaim mereka adalah cara terbaik, hanya cara standar yang berfungsi sebagian besar.
Dunk

2
@Dunk, mungkin Anda sudah merindukan saat itu ketika kita semua menemukan pidato bukannya lukisan gua. Diagram hampir selalu merupakan cara untuk mengaburkan apa pun yang seharusnya mereka wakili. Teks biasa selalu lebih baik. Dan semakin besar sistem Anda, semakin kompleks perilakunya, semakin besar jurang antara gaya melukis komunikasi era manusia gua dan bahasa Inggris modern. Saya belum pernah melihat diagram yang bisa saya pahami tanpa menerjemahkannya secara manual ke dalam teks terlebih dahulu.
SK-logic

9
@ SK-logic - Saya pikir gambar melukis seribu kata?
Michael Arnell

5
@ SK-logic: Jadi ada beberapa hal yang lebih baik dikomunikasikan melalui teks. Dan percaya atau tidak, yang lain lebih baik dikomunikasikan melalui diagram, dan itu termasuk desain sistem, dan tidak hanya desain OO. Dan bahkan mungkin berbeda untuk orang yang berbeda dan tidak, preferensi Anda untuk informasi tekstual bukanlah tanda superioritas yang diberikan Tuhan.
Michael Borgwardt

3
@ Sk - sementara pendapat Anda memiliki beberapa poin yang valid, sebagai diagram saja hampir tidak pernah cukup dan beberapa teks perlu ditambahkan. Saya hanya akan terus menggunakan apa yang Anda yakini sebagai diagram yang tidak berguna sementara saya terus berhasil membangun sistem yang cukup besar dengan tenggat waktu hampir mustahil pada tim yang cukup besar karena saya belum melihat cara yang lebih baik untuk berkomunikasi dengan pengembang lain. Saya tahu Anda punya banyak waktu untuk duduk dan memandu setiap pengembang secara individual, tetapi saya terlalu sibuk menyelesaikan pekerjaan.
Dunk

Jawaban:


64

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.


5
Persis. Tapi kemudian muncul pertanyaan mengapa UML dengan semua aturan ketat yang tidak ada gunanya, dan alat yang membengkak akibatnya untuk membuat UML, di tempat pertama? Poligon dan elips sederhana, yang dihubungkan oleh garis dan panah melakukan pekerjaan yang sama baiknya, jika bukan yang lebih baik, dalam menyampaikan maksud seperti halnya UML.
Dexter

1
1 untuk hype 90-an, desain Perangkat Keras bahkan bergerak ke arah yang berlawanan pada saat yang sama, jauh dari penangkapan skematis dan menuju HDL.
jk.

2
Dari 1996 hingga 2002 saya bekerja di perusahaan tempat kami berhasil menggunakan diagram UML sebagai model ER "lebih baik". Kami memiliki generator kode kami sendiri untuk menghasilkan kode C ++ untuk kerangka kerja ORM kami, SQL / DDL dan dokumentasi semua dari satu model.
Doc Brown

2
Penggunaan diagram UML yang bagus juga merupakan perancah. Buat kelas, dengan getter / setter, mungkin pohon direktori Anda, dll.
Clement Herreman

5
@Dexter: masalahnya adalah "Poligon dan elips sederhana, dihubungkan dengan garis dan panah" membuat banyak terbuka untuk interpretasi. Mungkin saja UML berusaha terlalu keras untuk memiliki simbol khusus untuk semuanya, tetapi tentu ada nilai dalam memiliki notasi standar yang memungkinkan Anda untuk membedakan secara visual antara kelas dan sistem perangkat keras, dan antara hubungan warisan dan saluran komunikasi.
Michael Borgwardt

36

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.


2
+1, terima kasih telah mengemukakan masalah tentang kompleksitas masalah kata yang sebenarnya. Poin yang bagus.
NoChance

bagaimana dengan G, bahasa pemrograman grafis yang digunakan dalam LabVIEW?
Angelo.Hannes

1
@ Angelo.Hannes: Memecahkan masalah dunia nyata di labview, pendekatan tak berubah tampak seperti ini: img.thedailywtf.com/images/201104/labview.jpg
whatsisname

@whatsisname diagram ini sangat berantakan. Tapi saya telah melihat diagram terstruktur dan sangat "mudah dibaca" di LabVIEW memecahkan masalah dunia nyata.
Angelo.Hannes

@ Angelo.Hannes: Saya telah menggunakan sistem yang mirip dengan LabVIEW. Mereka baik untuk membangun aplikasi kecil dalam domain terbatas.
kevin cline

9

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.


4
Saya benar-benar merasakan perlunya jawaban dengan TIDAK besar di suatu tempat.
ZJR

6

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.


@ mouviciel: Saya tidak berpikir ada alat yang tidak akan memiliki masalah seperti itu. Rhapsody benar-benar mencoba untuk mengurangi masalah terburuk dengan menggunakan kode yang dihasilkan, yaitu teks, sebagai otoritatif bagi anggota.
Jan Hudec

3

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.


1

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.


3
Saya ingin menunjukkan 2 hal: 1. Anda suka daftar yang dipesan.
talnicolas

@talnicolas, Anda benar!
Iya

0

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.


0

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.


-1

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.


-4

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.


-5

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!


1
Itu bukan jawaban, hanya keluhan. Saya setuju sedikit tentang mengapa coders masih menulis setiap kode baris sementara itu MUDAH untuk membuat konstruktor kode kecil dengan drag dan drop. Anda sepenuhnya benar tentang bisnis yang melakukan implementasi teknologi yang lebih baik daripada pengguna yang menggunakannya. Anda dapat membuat seluruh mesin yang telah dikonfigurasi sebelumnya dengan aplikasi Anda dalam hitungan detik, tetapi Anda tidak dapat membuat perangkat lunak dengan beberapa (ribuan) klik atau pukulan tombol. Tambahan. Saya telah bahwa Día dan Pythonnect dapat melakukan kode eksekusi yang bagus langsung dari UML Anda, tetapi belum diuji.
m3nda
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.