Apa standar untuk pemodelan aplikasi modern sebelum pengembangan?


9

Saya mengambil aplikasi tingkat perusahaan pertama saya dan saya ingin tim saya untuk memodelkan seluruh aplikasi ASP.NET MVC C # bahkan sebelum kita mengeluarkan satu baris kode.

UPDATE: Ini tidak dimaksudkan untuk menjadi diskusi filosofis tentang kapan harus mendokumentasikan / memodelkan suatu aplikasi. Harap hanya berikan jawaban untuk "bagaimana" untuk mendokumentasikan / model.

Yang benar adalah bahwa saya selalu berhemat di departemen ini dan saya tidak pernah benar-benar menjadi model aplikasi sebelumnya. Apa cara standar untuk melakukan ini? Apa jenis diagram yang harus digunakan dan seperti apa bentuk dokumentasi? Tautan ke diagram contoh dan dokumentasi sangat dihargai.

Ketika mencari saya dapat menemukan banyak hal di internet tetapi saya ingin melihat apakah ada konsensus modern saat ini tentang bagaimana cara melakukan ini.

Terima kasih sebelumnya!

Pernyataan penutup

Saya tidak tahu ini adalah subjek yang lengket. Terima kasih kepada Anda semua yang dapat mengesampingkan kontroversi yang jelas dan memberikan jawaban yang bermanfaat. Itu adalah diskusi yang menarik untuk sedikitnya :)

Tautan bermanfaat lain yang saya temukan adalah ini: /programming/61487/do-you-use-uml-in-agile-development-practices/61519#61519


6
Anda ingin terjun?
Etienne de Martel

1
@ Etienne, air terjun? Jika itu semacam referensi yang tidak enak maka saya tidak mengerti. Kritik / saran yang membangun dihargai. Bagaimana kalau alih-alih memperbarui komentar yang tidak berguna, Anda menambahkan komentar Anda sendiri untuk membantu saya memahami masalah ini.

6
"Saya ingin tim saya memodelkan seluruh aplikasi ASP.NET MVC C # sebelum kita bahkan mengeluarkan satu baris kode." Benci untuk mengatakan ini, tetapi Anda hampir membuat diri Anda gagal sebelum Anda mulai. Cakupan penuh kegunaan, persyaratan pengguna, rawatan sama sekali tidak terlihat sampai Anda benar-benar mulai menulis kode; jika Anda bersikeras pada desain besar di depan, Anda akan menghabiskan lebih banyak waktu memperbarui desain Anda daripada menulis aplikasi Anda. Desain tingkat tinggi ok , tapi mendokumentasikan seluruh aplikasi? Benar-benar tidak.
Juliet

3
@Chevex: Air terjun adalah metode pengembangan yang melibatkan banyak desain muka. Tampaknya cukup diterima di komunitas pengembangan perangkat lunak bahwa metode pengembangan ini bekerja dengan buruk.
quentin-starin

1
touche @Chevex, touche ... diam-diam berjalan pergi
mcgrailm

Jawaban:


6

konsensus modern saat ini

Yang benar adalah: saat ini, itu adalah sesuatu yang kurang pengembangan perangkat lunak modern - sebuah konsensus tentang pemodelan. UML tampaknya merupakan semacam pembagi umum terkecil, tetapi dalam kenyataannya hanya ada konsensus tentang notasi, bukan tentang semantik. Ada puluhan pendapat berbeda tentang bagaimana UML harus ditafsirkan untuk membuat kode (mungkin Anda dapat menemukan satu interpretasi yang baik untuk tim Anda).

Di sisi lain, ada perang suci yang terjadi antara orang-orang "gesit" yang mengatakan "jangan membuat model formal, lebih baik menulis kode kerja" dan orang-orang "BDUF" (desain besar di depan) yang berpikir seperti " MDA "(model driven architecture) adalah solusinya.

Orang lain (kembali) menemukan pemrograman berbasis aliran untuk desain perangkat lunak modern sebagai alternatif untuk UML. Baca di sini dan di sini untuk mengetahui lebih lanjut tentang itu.


Scott yang hebat! Sejauh ini, inilah jawaban yang paling bagus untuk pertanyaan ini. Gambaran singkat pemodelan yang ringkas dan bagus di industri dan di mana tempatnya. Terima kasih doc! +1.21 jiggawatt!

7

Saya ingin tim saya memodelkan seluruh aplikasi ASP.NET MVC C # sebelum kita bahkan mengeluarkan satu baris kode

Masalah yang biasanya saya temukan dengan pendekatan semacam itu adalah bahwa pemahaman saya tentang solusi selalu tidak lengkap di awal. Hanya melalui penyempurnaan saat pekerjaan berlanjut, saya sampai pada solusi akhir.

Mencoba mendesain seluruh aplikasi di muka, sebelum kode apa pun (semuanya kecuali aplikasi yang paling sederhana) biasanya bodoh.

Apakah Anda benar-benar yakin dapat memetakan setiap kelas dan metode serta struktur data secara terperinci sebelumnya?

Saya hanya ingin tahu beberapa solusi pemodelan yang baik.

Adapun alat yang sebenarnya untuk membuat model, saya sudah mencoba beberapa dan selalu kembali ke Microsoft Visio.

Dari semua produk yang saya coba, tampaknya yang paling lurus ke depan dan, sebenarnya, stabil (pengalaman saya dengan alat pemodelan adalah bahwa mereka sangat buggy). Agar adil, saya melakukan sangat sedikit pemodelan, jadi ambillah rekomendasi ini dengan sebutir garam.

EDIT: Sebenarnya, saya harus mengatakan bahwa sebagian besar pemodelan saya dilakukan pada notepad yang ada di meja saya. Karena saya melakukan sedikit pemodelan, saya mencoba untuk tetap terang dan to the point. Membuat diagram dengan pena dan kertas jauh lebih efisien bagi saya daripada menggunakan perangkat lunak.

Anda mungkin menemukan diagram tulisan tangan berguna untuk membentuk ide-ide Anda, sebelum meletakkannya dalam perangkat lunak diagram.

Apa jenis diagram yang harus digunakan dan seperti apa bentuk dokumentasi?

Sebagian besar yang saya modelkan hari ini adalah diagram interaksi. Sekali lagi, saya tidak melakukan banyak pemodelan - hanya di mana saya benar-benar merasakan latihan menggambar model membantu memperkuat pemahaman saya.


Kita dapat menyesuaikan pemodelan kita seiring berjalannya waktu. Lagi pula bukan itu intinya, saya hanya ingin tahu beberapa solusi pemodelan yang baik.

Jadi, Anda ingin mencoba dan menjaga agar model dan kode Anda tetap sinkron. Ini tidak berfungsi untuk sebagian besar. Mereka pasti akan menyimpang, dan perbedaan akan menyebabkan masalah. Plus, Anda akan menghabiskan banyak waktu untuk mencoba
quentin-starin

Silakan baca pertanyaan yang diperbarui.

@Chevex: Saya menambahkan semua yang saya bisa sehubungan dengan pertanyaan Anda yang diedit.
quentin-starin

@ qes, maksud saya adalah bahwa Anda menjawab pertanyaan yang tidak ingin saya tanyakan. Lihat bagian "PEMBARUAN" dari pertanyaan.

3

Diagram UML adalah tempat yang baik untuk memulai, ada banyak cara mudah untuk melakukan ini dengan perangkat lunak gratis atau berbayar. Salah satu contoh sederhana alat untuk membuat UML adalah sesuatu seperti gambar google docs, paket yang lebih maju adalah Visio atau OmniGraffle.

EDIT: Seperti yang disebutkan oleh banyak orang, jika Anda pergi ke jalur UML, itu tidak berarti Anda harus sepenuhnya memodelkan segalanya, tetapi Anda dapat mencapai konsensus tentang apa yang Anda modelkan, dan seberapa detail model yang diperlukan untuk menjadi. Diagram UML sederhana seringkali dapat membantu mengeluarkan kode Anda sebelum menulisnya, dan menjernihkan beberapa masalah potensial sebelum muncul.


Saya telah mendengar tentang UML. Punya rekomendasi tempat untuk memulai? Adakah alat bagus yang Anda rekomendasikan?

@Chevex - baru saja melakukan pencarian google cepat, dan menemukan ini: agilemodeling.com/artifacts/classDiagram.htm Tampaknya menjadi titik awal yang layak
Brett

@ qes - Bergantung pada berapa banyak waktu / minat / investasi yang dia miliki untuk menempuh jalan seperti ini, itu bisa menjadi pengalaman belajar yang baik dan mungkin membantunya memahami beberapa bagian dari kode sebelum dia menulisnya (bahkan jika hanya UML sederhana) ... Tapi saya setuju, dia mungkin harus memiliki waktu dan minat pribadi yang cukup untuk melakukan ini.
Brett

@ pertanyaan, silakan baca pertanyaan yang diperbarui.

2
@Chevex - Anda mungkin ingin memulai dengan membaca beberapa tipe diagram, dan apa yang dimaksudkan untuk dikomunikasikan. UML adalah bahasa pemodelan yang bisa sangat deskriptif, tetapi juga memiliki banyak nuansa. UML dalam Singkatnya membantu saya keluar sedikit ( oreilly.com/catalog/9781565924482 ). Yang sedang berkata Anda sering dapat bertahan dengan mengupas versi set diagram lengkap. Selama orang-orang membuat diagram dan orang-orang yang membaca diagram sepakat tentang apa yang mereka maksud.

2

Seperti yang disarankan @Brett, diagram UML adalah yang terbaik. Dengan UML ada baiknya memiliki diagram Kelas dan diagram alur kerja. Keduanya akan memenuhi sebagian besar kebutuhan desain.

Dengan diagram kelas, Anda dapat memodelkan anggota dari setiap entitas, tingkat keamanannya, dll.

Dengan diagram alur kerja, Anda dapat memodelkan metode mana yang memanggil panggilan mana, apa hasil dari alur kerja dan apa yang akan menjadi pengecualian yang mungkin muncul.


Terima kasih atas jawaban ini. Rekomendasikan alat yang berguna? Apakah studio visual mendukung UML dengan cara apa pun?

Studio visual menyediakan bantuan untuk melakukan diagram kelas. Ini tidak baik untuk alur kerja. Alat rasional terbaik untuk desain / pemodelan UML tersebut. Pemodel perangkat lunak rasional adalah apa yang saya kenal. Saya telah mendengar bahwa Rational rose akan menjadi alat hebat lainnya.

2

Sementara saya sangat percaya dalam membuat beberapa gambar arsitektur dasar sebelum menulis kode, saya pikir membuat gambar rinci dari seluruh aplikasi terlalu banyak pekerjaan.

Saya biasanya membuat beberapa gambar garis besar di Visio, sering menggunakan blok bangunan "flowchart" untuk memvisualisasikan apa yang saya maksud. Menggunakan UML sering terasa diformalkan dan mengundang terlalu banyak detail. Gambar Visio menunjukkan blok bangunan dasar aplikasi dan jenis fungsi mana yang digunakan. Jika Anda menggunakan kerangka kerja MVC Anda sebagian besar dilakukan hanya dengan mengambil sampel menggambar dari web dan menyalinnya.

Ide yang bagus adalah membuat beberapa gambar dari sudut pandang lain. Alih-alih menggambar semuanya, saya sering lebih suka mengambil satu fungsi spesifik dari sistem dan kemudian memvisualisasikannya sebagai:

  • Gunakan diagram kasus (UML)
  • Diagram alir atau UML Swim-lane (level sangat tinggi)
  • Ikhtisar komponen arsitektur.

Lalu kita mulai coding. Sementara pengkodean saya menggunakan doxygen dengan integrasi titik untuk mendapatkan diagram kelas on-the-fly, pewarisan dll. Melihat gambaran umum yang dihasilkan doxygen seringkali merupakan cara yang sangat baik untuk melihat struktur kode.

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.