Haruskah kita melakukan pemodelan entitas-hubungan atau pemodelan berorientasi objek terlebih dahulu?


Jawaban:


13

Anda mungkin ingin mencoba mengamati prinsip menunda keputusan arsitektur selama mungkin. Pikiran itu berlanjut, bahwa Anda akan tahu lebih banyak di masa depan tentang domain masalah Anda daripada yang Anda lakukan sekarang - jadi, setiap keputusan yang Anda buat hari ini adalah dugaan.

Prinsip lain yang baik untuk memasangkan ini mungkin dengan mencoba untuk mencoba bagian paling berisiko dari persyaratan Anda terlebih dahulu - pemikirannya adalah bahwa jika Anda melakukan bagian yang mudah, kemudian menemukan bahwa bagian yang berisiko menggerakkan Anda ke arah yang berbeda, Anda tidak memiliki untuk melakukan kembali bagian yang mudah. Berisiko di sini berarti hal-hal yang Anda tidak yakin bagaimana Anda harus melakukannya.

Dengan kedua hal ini, dan mengingat bahwa saya sering mencoba untuk mendekati hal-hal dari perspektif OO, Anda mungkin mencoba untuk memulai dengan model OO dari bagian paling berisiko dari aplikasi Anda terlebih dahulu, dan menerapkan jumlah kode yang paling tidak mungkin yang dapat bekerja yang memuaskan persyaratan berisiko. Kemudian, mulailah memperluas model OO Anda sesuai kebutuhan untuk menambah fungsionalitas yang akan Anda butuhkan. Sementara itu, Anda dapat benar-benar menunda keputusan Anda apakah akan menggunakan SQL atau NoSQL atau flatfiles atau penyimpanan cloud atau apa pun ... dan Anda mungkin akhirnya menemukan Anda tidak ingin berhubungan sama sekali (menghindari kebutuhan untuk model ER).


7

Model ER menentukan bagaimana data aplikasi akan bertahan, dan model OO memutuskan bagaimana data yang sama akan disimpan dalam memori, atau saat aplikasi sedang berjalan. Jadi, desain skema Database (model ER) dan desain struktur kelas (model OO) adalah pertimbangan desain terkait, dan biasanya bahkan dapat dipikirkan bersamaan. Bahkan, jika Anda menggunakan alat Object-relational mapping (ORM) , model ER Anda dan model OO Anda mungkin satu dan sama. Dengan kata lain, kelas Anda (model OO) dapat dianotasi sedemikian rupa sehingga mereka sendiri, menentukan model ER.

Namun, sebelum mendesain, pastikan Anda memiliki gagasan yang sangat baik tentang persyaratan aktual perangkat lunak, untuk apa perangkat lunak itu digunakan, bagaimana akan digunakan, dan siapa yang akan menggunakannya. Banyak pengembang mulai berpikir tentang keputusan desain sebelum mereka sepenuhnya memahami kebutuhan untuk ditangani oleh produk, dan berakhir dengan desain yang tidak sesuai untuk tujuan sebenarnya dari aplikasi.


+1 untuk mengidentifikasi perbedaan antara 2 jenis pemodelan. Saya tidak sepenuhnya setuju bahwa Anda dapat memikirkan 2 model secara bersamaan. Juga, beberapa penggemar OO menganggap bahwa Model OO dan ER Anda tidak harus selalu sama. Namun, model OO dapat digunakan sebagai dasar dari desain database tetapi transformasi ini agak rumit.
NoChance

@EmmadKareem Anda benar, tidak selalu tepat untuk memikirkan kedua model secara bersamaan. Saya berbicara sehubungan dengan ide untuk menggunakan kelas ORM dan anotasi sehingga desain model ER terintegrasi ke dalam model OO, sehingga untuk berbicara. Beberapa orang memilih untuk mengembangkan aplikasi dengan cara ini, yang pada dasarnya mengimplementasikan OO dan ER secara bersamaan.
CFL_Jeff

Jangan salah mengira model domain Anda untuk model data - Jangan bingung objek (yang mewakili satu contoh) dengan tabel database (yang berisi kumpulan hal-hal)
Narender Parmar
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.