Mengapa kita semua belum melakukan pengembangan berbasis model? [Tutup]

Saya benar-benar percaya pada Model Driven Development, saya pikir ini memiliki kemungkinan untuk meningkatkan produktivitas, kualitas, dan kepastian. Saat melihat MetaEdit hasilnya luar biasa. Mendix di Belanda berkembang sangat cepat dan memiliki hasil yang luar biasa.

Saya juga tahu ada banyak masalah

• versi generator, template dan kerangka kerja
• proyek yang tidak tepat untuk pengembangan yang didorong oleh model (tidak cukup pengulangan)
• risiko lebih tinggi (ketika proyek pertama gagal, Anda memiliki hasil lebih sedikit daripada yang Anda miliki dengan pengembangan yang lebih tradisional)
• dll

Namun tetap saja masalah ini tampaknya dapat dipecahkan dan manfaatnya harus lebih besar dari upaya yang diperlukan.

Pertanyaan : Apa yang Anda lihat sebagai masalah terbesar yang membuat Anda bahkan tidak mempertimbangkan pengembangan berbasis model?

Saya ingin menggunakan jawaban ini tidak hanya untuk pemahaman saya sendiri tetapi juga sebagai sumber yang mungkin untuk serangkaian artikel internal yang saya rencanakan untuk ditulis.

Tidak ada palu emas. Apa yang berfungsi dengan baik di satu domain cukup tidak berguna di domain lain. Ada beberapa kompleksitas yang melekat dalam pengembangan perangkat lunak, dan tidak ada alat ajaib yang akan menghapusnya.

Orang mungkin juga berpendapat bahwa pembuatan kode hanya berguna jika bahasa itu sendiri (atau kerangka kerja) tidak cukup tingkat tinggi untuk memungkinkan abstraksi yang kuat yang akan membuat MDD relatif tidak ada gunanya.

Pertanyaan menarik! Saya akui, saya bukan penggemar, tetapi kemudian saya telah mencoba menggunakan pengembangan berbasis model beberapa kali dalam proyek yang sesuai dengan beberapa masalah yang baru saja Anda kemukakan.

Inilah daftar alasan saya:

• kurva belajar - alat pemodelan telah berkembang begitu cepat, sehingga saya sulit sekali menemukan insinyur yang sangat memahami alat tersebut. Saya masih menemukan Anda hanya sebagus alat pemodelan Anda. Memang, banyak masalah di bawah ini dapat melacak kembali ke masalah yang satu ini - setiap kali Anda berpikir alat terlalu terbatas, ada kemungkinan Anda tidak cukup mengenalnya.
• Terlalu terstruktur - Secara pribadi, saya pernah berada dalam situasi di mana saya menemukan bahwa alat pemodelan terlalu terstruktur untuk membiarkan saya menggambarkan semua yang saya butuhkan untuk dijelaskan. Dan begitu saya beralih ke menggambar beberapa bagian dari model di luar alat, hal-hal cepat membusuk ketika orang-orang mulai melayang di luar alat untuk menemukan informasi.
• Biaya penyetelan alat - setiap kali saya mencoba untuk membuat kode secara otomatis, saya akhirnya secara manual mengerjakan ulang kode begitu saya melihat apa yang menurut alat itu benar. Saya tahu setelah beberapa berkeliling, masalah ini berkurang, tetapi itu berarti Anda harus bertahan hidup beberapa putaran pertama. Saya biasanya merasa bahwa kami sedang bermain mol - buat model -> buat kode -> perbaiki kode -> perbarui model -> perbaiki model, bilas & ulangi.
• Model Configuration Management - karena model ini menggambarkan sebagian besar proyek, pada tingkat tertentu model CM akan lebih banyak memotong silang daripada kode yang dibangun. Mengkotak-kotakkan file pemodelan adalah seni tersendiri - lakukan kesalahan dan Anda sering berakhir dengan kebuntuan pengembang, atau model ketinggalan zaman saat orang menyerah dan turun ke kode.
• waktu ke pasar - Saya telah mengalami masalah yang pasti ketika dalam situasi di mana kebutuhan untuk perangkat lunak yang bekerja sangat mendesak. Jika proyek dan tim cukup kecil, saya tidak melihat alasan untuk membuang waktu pada alat pemodelan ketika waktu dapat dihabiskan untuk pengkodean dan pengujian. Tidak setiap proyek cukup besar untuk membutuhkan investasi seperti itu.
• Biaya kegagalan - ketika saya melihat proyek lari dari alat pemodelan, itu karena biaya kegagalan yang tinggi - untuk menggunakan alat, Anda memerlukan setiap pengembang untuk terlibat. Itu investasi besar dalam pelatihan dan pembelajaran langsung, dan kesalahan yang sangat mahal jika seseorang membuat model dengan buruk. Pengalaman saya adalah bahwa butuh dua atau tiga rilis untuk mendapatkan model yang benar - begitu banyak proyek tidak bertahan kesalahan pemodelan cukup lama untuk menyadari manfaatnya.

Sudah dikutip, tetapi No Silver Bullet membahas poin ini dengan cukup baik:

Esensi dari entitas perangkat lunak adalah konstruksi konsep yang saling terkait: set data, hubungan antara item data, algoritma, dan pemanggilan fungsi. Esensi ini abstrak karena konstruksi konseptual seperti itu adalah sama di bawah banyak representasi yang berbeda. Meskipun demikian sangat tepat dan kaya detail.

Saya percaya bagian sulit dari membangun perangkat lunak adalah spesifikasi, desain, dan pengujian konstruk konseptual ini, bukan kerja keras untuk merepresentasikannya dan menguji kesetiaan representasi. Kami masih membuat kesalahan sintaks, pasti; tetapi mereka fuzz dibandingkan dengan kesalahan konseptual di sebagian besar sistem.

Jika ini benar, membangun perangkat lunak akan selalu sulit. Secara inheren tidak ada peluru perak.

Belakangan, Brooks menunjukkan hal berikut tentang konsep "pemrograman otomatis":

Selama hampir 40 tahun, orang telah mengantisipasi dan menulis tentang "pemrograman otomatis," atau pembuatan program untuk memecahkan masalah dari pernyataan spesifikasi masalah. Beberapa hari ini menulis seolah-olah mereka mengharapkan teknologi ini untuk memberikan terobosan berikutnya.

Parnas menyiratkan bahwa istilah tersebut digunakan untuk glamor, bukan untuk konten semantik, menyatakan, "Singkatnya, pemrograman otomatis selalu menjadi eufemisme untuk pemrograman dengan bahasa tingkat yang lebih tinggi daripada yang saat ini tersedia untuk programmer."

Dia berpendapat, pada dasarnya, bahwa dalam banyak kasus itu adalah metode solusi, bukan masalah, yang spesifikasinya harus diberikan.

Pada dasarnya, saya berpendapat bahwa MDD hanyalah eufemisme lain untuk pemrograman dengan bahasa tingkat yang lebih tinggi dari yang sebelumnya tersedia.

Itu bukan untuk mengatakan bahwa pemrograman dalam bahasa tingkat yang lebih tinggi tidak dapat membantu - pada kenyataannya seringkali bisa. Tetapi esensi masalah tetap sama: tidak peduli seberapa hebat alat atau seberapa hebat bahasa yang Anda gunakan, pada akhirnya Anda harus memikirkan semua masalah dan menyelesaikan masalah. Alat terbaik atau proses apa pun dapat dilakukan adalah menghapus "fuzz" sehingga Anda dapat fokus pada masalah penting, yaitu, seperti kata Brooks, " spesifikasi , desain , dan pengujian konstruksi konseptual ini ".

Karena tidak semua pemrograman berorientasi objek, yang sepertinya diharapkan oleh semua alat MDD. UML sendiri didasarkan pada anggapan objek. Tentu Anda dapat menggunakan diagram urutan untuk memodelkan fungsi, tetapi berkali-kali itu kikuk.

Karena ada programmer seperti saya yang mendapatkan lebih banyak kemajuan dan hasil dari TDD daripada MDD.

Karena Pemodelan! = Pemrograman.

Karena biaya / manfaatnya terlalu tinggi di sisi biaya dan tidak cukup di sisi manfaat. Ini mungkin telah berubah sejak saya terakhir melihat MDD, saat itu Anda diharuskan membayar> $ 6000 / seat (USD) untuk alat yang cukup mampu untuk MDD.

Karena model yang cukup menggambarkan fungsi untuk menghasilkan kode tidak lagi berguna sebagai model.

Karena ada programmer seperti saya yang hanya menggunakan model pada level tinggi, dan kemudian mengerjakan perinciannya dengan kode. Anda melihat berbagai hal secara berbeda dalam kode daripada yang Anda lakukan dalam pemodelan perangkat lunak.

Itulah beberapa alasan mengapa saya pribadi tidak melakukan MDD. Saya sudah terpapar itu, tetapi tidak ada yang bisa membuat saya menjadi mualaf. Mungkin aku sekolah terlalu tua. Mungkin aku sekolah yang terlalu baru (apa pun itu). Hanya saja bukan alat yang saya dapat membayar sendiri.

Microsoft / Apple / Google tidak mendorongnya :)

Perkembangan macam apa yang dipopulerkan banyak hubungannya dengan alat, pendukung, dan penginjilan. Sangat sulit untuk menerobos sesuatu tanpa memiliki pendukung yang besar (Ruby on rails mungkin menjadi pengecualian tetapi masih kecil dibandingkan dengan Java / C # / Python)

Karena hukum sederhana yang memengaruhi semua alat pemodelan ini, Anda tahu, KASUS, UML, dan semacamnya:

Mendapatkan antara programmer dan kodenya sangat mahal.

Jika Anda melakukannya, Anda perlu membangun compiler / interpreter yang tepat, generator kode menghasilkan alur kerja yang mengerikan dan umpan balik yang mengerikan untuk programmer (pesan kesalahan dan semacamnya).

Salah satu wawasan hebat dari Desain Domain Driven adalah bahwa Model harus dalam kode, bukan dalam sesuatu yang eksternal untuk kode.

Pada akhirnya pertanyaannya adalah: Mengapa model Anda tidak cocok dengan kode? Jika Anda melakukan pengembangan tersemat dan terjebak dengan C atau perlu membuat kode untuk platform yang berbeda, pembuatan kode mungkin sepadan dengan biayanya. Untuk orang lain, bahasa pemrograman yang lebih kuat dan desain kode yang lebih baik biasanya lebih baik daripada merancang kode dalam sesuatu selain kode.

• Tampak seperti kerumitan raksasa untuk sedikit manfaat.
• Sepertinya aku selalu berkutat dengan case edge dan hal-hal aneh, hal-hal ajaib sepertinya tidak pernah berhasil.
• OO bukan peluru perak; menggertak metodologi pembuatan perangkat lunak ke OO tidak membuatnya perak.

Tapi saya tidak menyukai solusi perusahaan secara umum.

Saya telah berdiskusi, dan ingin melakukan MDA, tetapi kelemahan terbesar adalah dukungan alat untuk saat ini. Saya menggunakan derivasi MDA yang saya suka sebut "Evaluasi Model Runtime", tetapi lebih lanjut tentang itu nanti.

Kelemahan dari MDA adalah, seperti yang saya tahu:

• Dukungan Refactoring Hilang: Mari kita tebak saya ingin memodelkan entitas datamodel saya dengan MDA (Typical usecase No. 1). Jika saya memiliki model saya, katakanlah, diagram UML, dan saya mengubahnya, tidak ada kode yang berubah dengannya (setidaknya kelas yang dihasilkan), dan alih-alih masih memiliki aplikasi yang berfungsi dengan atribut yang lebih baik, saya mendapatkan banyak kesalahan yang harus saya perbaiki secara manual.
• Dukungan debug yang hilang: Biasanya terjemahan dari model ke kode dilakukan dengan memiliki beberapa bahasa transformasi. Ini biasanya bukan masalah, tetapi ketika kita melakukan debug, kita secara optimal tidak perlu khawatir akan kode yang kita hasilkan, dan seorang debugger harus melangkah ke dalam model transformasi. Alih-alih itu melangkah ke kode yang dihasilkan, dan seperti yang kita semua tahu, transformasi harus terlihat baik, bukan kode yang dihasilkan. Oke, kita bisa mencetaknya dengan cantik, tetapi di dunia yang optimal kode yang dihasilkan adalah artefak kompiler, dan seharusnya tidak boleh dibuka di editor untuk sesi debugging (saya bisa hidup dengan itu, dan argumen ini sedikit secara teoritis, tetapi itu adalah salah satu alasan menentang MDA)
• Model berkode mudah: Dalam contoh lain, Model dapat memodelkan beberapa aspek domain, dan yang kemudian dikompilasi ke dalam kode. Ya, ini adalah MDA, tetapi sebagian besar model MDA hanyalah file konfigurasi canggih, yang dapat dengan mudah ditangani saat runtime.
• Transformasi sulit untuk diuji: Jika Anda menggunakan transformasi dalam IDE khusus, mereka dilakukan oleh "kompiler" IDE. Tetapi transformasi harus dilihat sebagai bagian dari kode aplikasi, dan karena itu juga harus menjalani tes dan persyaratan cakupan kode aplikasi.

Apa yang saat ini saya sukai adalah "Evaluasi Model Runtime" (jika seseorang mengetahui nama yang diterima untuk ini, mohon beri tahu saya). Entitas saya disimpan dalam kelas Java biasa, dan semua yang saya butuhkan untuk "model" dibuat oleh anotasi yang saya baca di awal aplikasi. Tidak ada transformasi yang diperlukan, itu hanya sedikit sulit untuk mendapatkan model meta saya dengan benar.

Segala sesuatu yang lain dilakukan dengan file properti atau XML untuk data hierarkis. Jika Anda memiliki model, itu selalu hierarkis, jadi tidak ada yang dapat Anda modelkan yang tidak dapat Anda ungkapkan juga dengan XML. Dan jika Anda memerlukan editor model khusus, yang mungkin harus Anda tulis juga, Anda juga dapat membangun editor yang bahkan berfungsi saat runtime aplikasi, dan membuat aplikasi lebih dapat dikonfigurasi daripada semua yang Anda bisa modelkan.

Saya merasa bahwa kebanyakan orang menggunakan No Silver Bullet dari Fred Brooks untuk menjelaskan mengapa orang tidak melakukan MDD kehilangan poin yang dibuat Brooks. Tentu, kesimpulan akhir adalah bahwa kompleksitas intrinsik aktual dalam pengembangan perangkat lunak tidak akan pernah hilang dan MDD tidak akan menyelesaikannya.

Tetapi salah satu alasan mengapa Brooks bahkan membahas kompleksitas intrinsik ini adalah untuk membandingkannya dengan jumlah besar waktu yang biasanya kita habiskan untuk bertarung dengan bahasa, perpustakaan, dan alat, yaitu tidak berurusan dengan kompleksitas intrinsik masalah yang kita coba selesaikan. Jadi di sinilah MDD bersinar: memotong semua fuzz dan menciptakan bahasa yang disesuaikan, model atau formalisme lain untuk menghadapi kompleksitas nyata yang ada.

Jadi dari perspektif ini, No Silver Bullet adalah alasan yang sangat baik untuk berinvestasi di MDD. Yaitu, jika bukan karena masalah yang saya yakini menghambat adopsi MDD: pengembangan sebenarnya dari lingkungan model-driven yang memungkinkan Anda untuk fokus sepenuhnya pada kompleksitas intrinsik masalah yang Anda coba selesaikan jauh lebih sulit daripada hanya menyelesaikan masalah dalam bahasa tujuan umum secara langsung. Sebagian besar karena tooling MDD yang ada sangat kompleks.

Bandingkan seperti ini: jauh lebih mudah untuk menulis sebuah program dalam C daripada menulis kompiler C. Alih-alih hanya menyelesaikan masalah dan berurusan dengan cruft dalam bahasa tujuan umum, membuat lingkungan MDD untuk pengembang lain mengharuskan Anda untuk menulis program yang pada dasarnya menyelesaikan semua masalah yang terkait dengan cruft di ruang masalah di muka. Itu cukup menantang.

Sepengetahuan saya, MDE dan MDA tidak cukup memenuhi kebutuhan pengembang kontroler tertanam. Model tentu saja dapat digunakan untuk menggambarkan suatu sistem, tetapi saya tidak berpikir pengembang tertanam siap untuk mempercayai model untuk memberikan yang terbaik, atau bahkan memperbaiki kode sumber.

Ada beberapa plug-in untuk Eclipse yang memungkinkan pengembang menggunakan salah satu model untuk membuat / memperbarui kode Java, atau kode Java untuk membuat / memperbarui model. Ini sepertinya alat yang berguna. Sayangnya, semua pengembangan saya dilakukan dalam ANSI / ISO C, dan tidak ada plug-in, yang saya sadari, yang akan memungkinkan saya untuk melakukan hal yang sama.

Selain itu, bagaimana pengembang dapat menginstruksikan model untuk mengimplementasikan kode sebagai HSM yang digerakkan oleh peristiwa, atau beberapa pola desain lainnya, di atas pola desain lainnya (atau anti-pola)? Jika kode diperbarui secara manual untuk menggunakan pola desain yang tidak dikenal, dapatkah model menggambarkan itu secara akurat?

Bagaimana Anda mengimplementasikan fungsi-fungsi yang tidak sesuai dengan model?

Jawaban singkat ... karena model didorong sering terkait dengan pembuatan kode dan kode rapuh; yang kita butuhkan adalah penghapusan kode dan model didorong pasti cara untuk pergi.

Beberapa telah menolak pertanyaan dengan alasan bahwa tidak ada palu emas dan bahwa pengembangan perangkat lunak pada dasarnya kompleks.

Saya sepenuhnya setuju dengan mereka bahwa tidak ada palu emas tapi saya tidak berpikir bahwa model didorong adalah pencarian palu emas atau peluru perak!

Saya ingin melangkah lebih jauh dengan kompleksitas; ada dua jenis kompleksitas yang saya sebut kompleksitas organik atau alami, kompleksitas yang melekat pada bisnis dan prosesnya, tetapi kami juga memiliki kompleksitas seremonial.

Kompleksitas yang merayap ke dalam sistem instruksi dengan instruksi, hari demi hari. Kompleksitas seremonial - kompleksitas yang tidak perlu - muncul pada dasarnya dari pengelolaan kode teknis yang tidak terkontrol dengan kode berorientasi bisnis, tetapi juga dari kurangnya struktur dan keseragaman dalam sistem.

Saat ini seluruh kerumitan yang menghantui pengembangan sistem informasi dan menyebabkan kegagalan dan pinggang adalah kompleksitas seremonial; kompleksitas yang bisa dihilangkan.

Kompleksitas seremonial adalah pemborosan, pemborosan yang disebabkan oleh kode, nilai lebih sedikit, perubahan merugikan, kode invarian; kode yang harus dikurangi seminimal mungkin.

Bagaimana cara melakukannya? Mudah! Hanya saja jangan menulisnya, dan jangan menghasilkannya, sejak awal!

Kode teknis invarian yang diperlukan; kode yang digunakan untuk membaca / menulis, menampilkan, berkomunikasi ... Di situlah model masuk, dengan menggambarkan struktur logis data - saya akan menambahkan dengan cara relasional - model dapat memungkinkan penanganan generik membaca / menulis standar, menampilkan dan berkomunikasi dari data.

Sama seperti sistem operasi, Anda tidak menulis ulang untuk setiap proyek yang Anda gunakan. Jadi yang dibutuhkan adalah mesin teknis yang menangani aspek invarian dari perangkat lunak yang diberikan model. Saya menyebutnya mesin AaaS (Arsitektur sebagai Layanan).

Adapun kode yang tidak perlu, baik itu kode yang tidak perlu jadi mungkin juga tidak tertulis.

Itu membuat kita perlu, kode berorientasi bisnis yang harus ditulis, data berorientasi bisnis yang diperlukan yang harus dirancang dan antarmuka pengguna yang diperlukan dan pengalaman yang harus dirancang dan dibayangkan.

Dengan menghilangkan kode yang rapuh, kita dapat merangkul Arsitektur sebagai Layanan sebuah paradigma baru untuk pengembangan perangkat lunak yang lebih didasarkan pada pemodelan dan desain daripada pada kode.

Saya percaya bahwa ada beberapa alasan tetapi ada satu yang pasti bahwa MDD tidak ada dalam kurikulum universitas. Biasanya yang terdekat adalah kursus yang mengajarkan pemodelan dan ada model yang tetap sebagai sketsa (tanpa pengecekan, pembuatan kode, debugging di tingkat model). Kursus "pemodelan" ini sering juga memperkenalkan UML dan para siswa bingung mengapa mempelajari notasi yang begitu besar dan kompleks ketika nilai model yang dibuat rendah.

Bandingkan ini dengan bidang teknik lainnya seperti pengembang perangkat keras tertanam atau insinyur kontrol tempat siswa mendapatkan pengalaman yang sangat berbeda. Dengan alat-alat seperti Simulink atau Labview, siswa dapat menggambar model dan kemudian menghasilkan Anda kode, atau setidaknya Anda dapat menjalankannya dalam simulasi.

Di universitas sebelumnya mengajarkan kompiler dan parser, tetapi sekarang mereka harus mengajarkan cara membuat generator, menerapkan DSL, dll.

Pengembangan Model Driven adalah tidak masuk akal karena ini adalah model top-down untuk pendekatan kode. Tidak mungkin membuat aplikasi yang berjalan penuh hanya dari model dan oleh karena itu MDD tidak berguna !!

Yang saya lakukan adalah hanya menggunakan UML di tingkat abstraksi yang lebih tinggi untuk membuat kerangka aplikasi saya. Maksud saya membuat Paket, kelas dll ... kemudian mulai segera kode dalam bahasa Java.

Saya menemukan bahwa sinkronisasi langsung dengan alat-alat seperti Togethersoft, Omondo sangat berguna ketika saya pertama kali memulai pemodelan pada tahun 2004. Tahap baru baru-baru ini diperkenalkan oleh Omondo yang merupakan semacam pemetaan antara Java, model dan basis data ID. Sangat kuat dan bekerja dengan baik di proyek saya.

Diagram UML saya membantu saya sekarang untuk mempercepat proyek saya dan tidak lagi sia-sia :-)

MDD menambahkan langkah lain ke proses pengembangan, yang merupakan kelemahan dalam situasi di mana tidak ada model yang baik dan solusi parsial pertama yang tidak dapat diprediksi atau hampir rusak untuk pasar mungkin memenangkan yang paling kelereng.

Sangatlah penting untuk memiliki model proses bisnis yang dapat dieksekusi. Secara teori Anda tidak perlu programmer untuk itu sama sekali. Praktek menunjukkan, bahwa dengan MDE, bahwa mendapatkan model aktual untuk bekerja sama rumitnya dengan menulis kode.

Saya akan mengatakan untuk pengembang berpengalaman akan jauh lebih mudah untuk mengisi kelas yang dihasilkan dari UML, daripada repot-repot dengan misalnya ExecutableUML. Di sisi lain, untuk ExecutableUML Anda memerlukan sejumlah besar pengetahuan ilmu komputer, sehingga Anda tidak dapat mengandalkan manajer bisnis yang membuatnya sendiri. Secara teori dia hanya akan menggabungkan blok siap (kelas), tetapi sebenarnya "lem" adalah yang menyebabkan masalah.

Juga, kegunaan MDE terbatas pada sistem dengan banyak komponen yang digunakan kembali.

MBSE - Rekayasa Perangkat Lunak Berbasis Model adalah istilah yang lebih relevan.

Menempatkan masalah berbagai alat yang ada di solusi titik efek, MBSE membutuhkan alur kerja proyek yang berbeda. DSML (bahasa pemodelan spesifik domain) harus berada pada tingkat abstraksi yang diperlukan untuk mengkomunikasikan persyaratan untuk ditinjau secara efektif dengan para pemangku kepentingan. Maka Anda perlu mengubah model melalui tingkat penyempurnaan yang semakin meningkat untuk akhirnya menghasilkan kode.

Ketika Anda memiliki DSML dan proses transformasi / pembangkitan diimplementasikan secara penuh dan benar maka pembangkitan artefak datang dengan biaya yang sangat rendah. Tetapi sampai Anda mencapai tingkat alat debugged itu sangat menyakitkan.

Sebagian besar kisah sukses untuk MDD adalah di bidang Product Line Engineering (PLE) di mana suksesi produk serupa dihasilkan menggunakan tooling yang sudah mapan. Tentu saja, banyak generator kode Java adalah versi MDD yang sangat sederhana. Beberapa XML masuk dan keluar kode.

Kau menulis:

Saya juga tahu ada banyak masalah ... proyek yang tidak tepat untuk pengembangan berbasis model (pengulangan tidak cukup)

Jika kode Anda berulang-ulang, maka Anda telah memilih bahasa pemrograman yang buruk, atau Anda menggunakannya dengan buruk. Dengan bahasa yang lebih baik, tidak perlu pengulangan. Pertimbangkan pustaka Catatan Aktif Ruby. Tabel database dibuat dengan menulis migrasi. Tidak perlu mengulang definisi skema di tempat lain. Anda tidak harus mendefinisikan kelas dengan anggota data yang sesuai dengan kolom tabel. Satu baris kode menghubungkan kelas ke sebuah tabel.

Saya melihat pengembangan model didorong sebagai penyelesaian yang kompleks dan tidak efisien untuk bahasa pemrograman yang lemah.