“UML adalah hal terburuk yang pernah terjadi pada MDD.” Mengapa?


17

William Cook dalam sebuah tweet menulis bahwa:

" UML adalah hal terburuk yang pernah terjadi pada MDD. Untungnya banyak orang sekarang menyadari ini ... "

Saya ingin tahu alasan di balik klaim itu (rupanya, saya tidak merujuk pada pendapat pribadinya).

Saya perhatikan bahwa banyak orang di luar sana yang tidak terlalu menyukai UML. Juga perlu disebutkan bahwa ia berada di dunia akademis, di mana UML adalah preil banyak cawan suci desain dan pemodelan yang efektif.


15
Saya akan mengatakan bahwa MDD adalah hal terburuk yang pernah terjadi pada MDD.
Michael Borgwardt

Jawaban:


39

Yah, saya akademisi yang memposting tweet asli. Tweet tidak dimaksudkan sebagai artikel ilmiah. Mereka adalah iklan, dan saya pikir mereka juga bisa menjadi kontroversial. Inilah tweet tindak lanjut saya:

1) UML dibuat untuk memodelkan desain OO. Efeknya Anda memodelkan kode suatu sistem, bukan perilaku sistem. UML berada di level yang salah.

2) gagasan bahwa 7 (atau 13) format diagram di UML dapat mencakup semuanya gila. Bagaimana dengan GUI, gambar rangka web, otorisasi, dll. ???

3) UML telah mendorong gagasan bahwa model harus grafis. Konyol! Model teks dan grafik berguna dan sering kali dapat dipertukarkan

4) UML sekaligus terlalu besar dan kompleks dan pada saat yang sama sangat terbatas. Stereotipe dan profil tidak efektif untuk ekstensi yang dapat digunakan.

Perhatikan bahwa saya tidak selalu mengatakan UML buruk. Saya hanya mengatakan bahwa itu tidak membantu tujuan "pengembangan model-driven", yang merupakan hal yang saya minati. Saya tidak mengerti komentar tentang "holy grail".


10
+1 untuk menemukan dan menjawab pertanyaan tentang prog.SE tentang tweet Anda sendiri!
Warren P

Jadi pengembangan yang didorong oleh Model selalu bagi saya tentang memiliki model visual. Dan jika bukan UML, lalu apa? (catatan, saya tidak pernah menyukai MDD, dan saya membenci UML. Tetapi saya bersedia untuk mencoba MDD-sans-UML. Apa yang harus saya coba?
Warren P

1
@ Warren P: apa yang tidak Anda sukai tentang MDD, dan UML?
dan_l

1
Saya telah menghapus jawaban saya karena jelas saya salah tentang apa yang Anda maksudkan. Tetapi saya mendukung pernyataan bahwa UML, seperti bahasa apa pun, adalah alat komunikasi, bukan alat desain. Anda menjawab bahwa 'Banyak bahasa pemrograman memiliki kata "bahasa" dalam nama mereka, tetapi itu tidak berarti mereka hanya untuk komunikasi, bukan eksekusi' - Saya pikir Anda kehilangan titik bahwa eksekusi adalah komunikasi dengan komputer. Anda juga tidak akan menggunakan COBOL sebagai alat desain.
pdr

Saya pikir komentar "cawan suci" mengacu pada frekuensi yang diajarkan.

8

UML setara dengan mengambil obeng dan palu dan merekatkannya menjadi satu dan menyebutnya sebagai "Alat Pengikat Universal." Secara teori dapat digunakan untuk mewakili banyak hal dengan sangat rinci, dalam praktiknya sekelompok alat yang kurang terintegrasi mengklaim sebagai alat tunggal, yang membuat melakukan satu tugas jauh lebih sulit daripada memiliki alat yang tepat untuk memulai.



3

Saya pikir ada juga kasus yang dibuat bahwa MDD adalah hal terburuk yang terjadi pada UML (mengapa lagi kita memiliki UML2 yang kita miliki?), Tetapi mengabaikannya untuk saat ini ...

MDD = Model Didorong <Desain | Pengembangan>. Idenya adalah untuk dapat mengembangkan solusi pada tingkat abstraksi yang sesuai dengan domain masalah - yaitu, itu adalah upaya untuk mengekspresikan solusi untuk masalah dalam sintaksis yang paling alami untuk mengekspresikan solusi tersebut. Domain masalah itu sendiri ditandai dengan model operasional (yaitu, dengan model yang dapat dieksekusi oleh komputer). Jadi, MDD bisa menjadi pendekatan yang sangat menarik, meskipun satu dengan dua persyaratan utama:

  1. Seseorang harus dapat mengkompilasi bahasa itu ke dalam bentuk yang sesuai untuk eksekusi komputer (model harus operasional ); dan
  2. Seseorang harus membuat bahasa pemodelan untuk domain masalah.

Ini pemahaman saya bahwa upaya UML2 dimaksudkan untuk mengatasi poin 1, mungkin di bawah keyakinan bahwa pengalaman industri dengan UML menunjukkan bahwa poin 2 puas untuk beberapa subset domain masalah besar. Sayangnya, dan inilah yang saya pikirkan tentang William Cook, UML tidak memenuhi poin 2 karena berada di dekat ruang lingkup masalah yang dipikirkan. Saya tidak berbicara dari pengalaman pribadi, tetapi saya pikir pengalaman industri menggunakan MDD dengan UML memiliki dua hasil umum:

  • Entah kode sumber yang dihasilkan dari UML perlu diubah untuk menyelesaikan celah kecil antara desain UML dan persyaratan program (memaksa pengembang untuk bekerja dengan kode yang dihasilkan yang memiliki standar berbeda untuk pemeliharaan dan mengurangi penerapan artefak UML ke dalam implementasi ); ATAU
  • UML menjadi berantakan dengan banyak detail yang mengurangi kegunaannya sebagai bahasa untuk berkomunikasi tentang desain.

    Dalam kedua kasus itu, janji MDD tidak terpenuhi. UML mungkin dianggap sebagai hal terburuk yang terjadi pada MDD karena ia menarik perhatian pengembang alat MDD dengan mengesampingkan model yang mungkin benar-benar berfungsi (walaupun untuk sejumlah kecil masalah perangkat lunak).


  • -2

    UML bagus asalkan hanya bahasa pemodelan. Jika Anda mencoba menghubungkan MDD ke UML untuk mendapatkan tampilan grafis maka itu tidak berguna. MDD akan lebih baik tanpa UML serta UML tanpa MDD.

    Katakanlah UML dan MDD telah bercerai hari ini untuk memiliki kehidupan yang lebih baik tidak bersama lagi :-)


    Ini tidak "hebat" di level mana pun. Seorang pengguna bahasa pemrograman ADA bencana (Booch) menciptakan beberapa diagram kekanak-kanakan dan dihubungkan dengan beberapa pendekatan diagram kelas yang lebih serius untuk membuat UML. UML segera berubah menjadi penghasil pendapatan vendor perangkat lunak besar. Itu mengerikan, tetapi diselamatkan dengan hanya memasukkan tipe diagram baru (UML pra-tanggal) seperti urutan, aliran data, dll. Tidak ada yang bisa diperpanjang tentang hal itu. Tidak ada skema basis data, tidak ada diagram lapisan, itu penuh dengan celah dan penuh diagram tidak berguna pada saat yang sama.
    Rick O'Shea
    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.