Menggunakan model dalam proses pengembangan Anda

Di Visual Studio, Anda dapat menggunakan model untuk membantu Anda memahami dan mengubah sistem, aplikasi, atau komponen. Model dapat membantu Anda memvisualisasikan dunia tempat sistem Anda bekerja, mengklarifikasi kebutuhan pengguna, menentukan arsitektur sistem Anda, menganalisis kode, dan memastikan bahwa kode Anda memenuhi persyaratan.

Untuk melihat versi Visual Studio mana yang mendukung setiap jenis model, lihat Dukungan versi untuk arsitektur dan alat pemodelan.

Model dapat membantu Anda dalam beberapa cara:

• Diagram pemodelan gambar membantu Anda mengklarifikasi konsep yang terlibat dalam persyaratan, arsitektur, dan desain tingkat tinggi. Untuk informasi selengkapnya, lihat Persyaratan pengguna model.

• Bekerja dengan model dapat membantu Anda mengekspos inkonsistensi dalam persyaratan.

• Berkomunikasi dengan model membantu Anda berkomunikasi konsep penting kurang ambigu daripada dengan bahasa alami. Untuk informasi selengkapnya, lihat Memodelkan arsitektur aplikasi Anda.

• Terkadang Anda dapat menggunakan model untuk menghasilkan kode atau artefak lain seperti skema database atau dokumen. Misalnya, komponen pemodelan Visual Studio dihasilkan dari model. Untuk informasi selengkapnya, lihat Membuat dan mengonfigurasi aplikasi Anda dari model.

Anda dapat menggunakan model dalam berbagai proses, dari agile ekstrem hingga upacara tinggi.

Menggunakan model untuk mengurangi ambiguitas

Bahasa pemodelan kurang ambigu daripada bahasa alami, dan dirancang untuk mengekspresikan ide-ide yang biasanya diperlukan selama pengembangan perangkat lunak.

Jika proyek Anda memiliki tim kecil yang mengikuti praktik tangkas, Anda dapat menggunakan model untuk membantu Anda mengklarifikasi cerita pengguna. Dalam diskusi dengan pelanggan tentang kebutuhan mereka, pembuatan model dapat menghasilkan pertanyaan yang berguna jauh lebih cepat, dan di seluruh area produk yang lebih luas, dibandingkan dengan menulis kode spike atau prototipe.

Jika proyek Anda besar dan mencakup tim di berbagai bagian dunia, Anda dapat menggunakan model untuk membantu mengomunikasikan persyaratan dan arsitektur jauh lebih efektif daripada yang Anda bisa dalam teks biasa.

Dalam kedua kasus, menciptakan model hampir selalu menghasilkan pengurangan inkonsistensi dan ambiguitas yang signifikan. Pemangku kepentingan yang berbeda sering memiliki pemahaman yang berbeda tentang dunia bisnis tempat sistem bekerja, dan pengembang yang berbeda sering memiliki pemahaman yang berbeda tentang cara kerja sistem. Menggunakan model sebagai fokus diskusi biasanya mengekspos perbedaan ini. Untuk informasi selengkapnya tentang cara menggunakan model untuk mengurangi inkonsistensi, lihat Persyaratan pengguna model.

Gunakan model dengan artefak lain

Model bukan dengan sendirinya spesifikasi persyaratan atau arsitektur. Ini adalah alat untuk mengekspresikan beberapa aspek dari hal-hal ini dengan lebih jelas, tetapi tidak semua konsep yang diperlukan selama desain perangkat lunak dapat diekspresikan. Oleh karena itu, model harus digunakan bersama dengan sarana komunikasi lainnya, seperti halaman atau paragraf OneNote, dokumen Microsoft Office, item kerja di Team Foundation, atau catatan tempel di dinding ruang proyek. Selain item terakhir, semua jenis objek ini dapat ditautkan ke bagian elemen model.

Aspek spesifikasi lain yang biasanya digunakan bersama dengan model termasuk yang berikut ini. Bergantung pada skala dan gaya proyek Anda, Anda mungkin menggunakan beberapa aspek ini atau tidak menggunakan sama sekali:

• Cerita pengguna. Cerita pengguna adalah deskripsi singkat, yang dibahas dengan pengguna dan pemangku kepentingan lainnya, dari aspek perilaku sistem yang akan dikirimkan dalam salah satu iterasi proyek. Cerita pengguna yang khas dimulai "Pelanggan akan dapat...." Cerita pengguna mungkin memperkenalkan sekelompok kasus penggunaan, atau dapat menentukan ekstensi kasus penggunaan yang telah dikembangkan sebelumnya. Menentukan atau memperluas kasus penggunaan membantu membuat cerita pengguna lebih jelas.

• Ubah Permintaan. Permintaan perubahan dalam proyek yang lebih formal sangat mirip dengan cerita pengguna dalam proyek yang gesit. Pendekatan tangkas memperlakukan semua persyaratan sebagai perubahan pada apa yang dikembangkan dalam iterasi sebelumnya.

• Gunakan deskripsi kasus. Kasus penggunaan mewakili salah satu cara pengguna berinteraksi dengan sistem untuk mencapai tujuan tertentu. Deskripsi lengkap mencakup tujuan, urutan utama dan alternatif peristiwa, dan hasil yang luar biasa. Diagram kasus penggunaan membantu meringkas dan memberikan gambaran umum kasus penggunaan.

• Skenario. Skenario adalah deskripsi yang cukup rinci tentang urutan peristiwa yang menunjukkan bagaimana sistem, pengguna, dan sistem lainnya bekerja sama untuk memberikan nilai kepada pemangku kepentingan. Mungkin berupa peragaan slide antarmuka pengguna atau prototipe antarmuka pengguna. Ini dapat menjelaskan satu kasus penggunaan atau urutan kasus penggunaan.

• Daftar istilah. Glosarium persyaratan proyek menggambarkan kata-kata yang dengannya pelanggan mendiskusikan dunia mereka. Antarmuka pengguna dan model persyaratan juga harus menggunakan istilah-istilah ini. Diagram kelas dapat membantu mengklarifikasi hubungan antara sebagian besar istilah ini. Membuat diagram dan glosarium tidak hanya mengurangi kesalahpahaman antara pengguna dan pengembang, tetapi juga hampir selalu mengekspos kesalahpahaman antara pemangku kepentingan bisnis yang berbeda.

• Aturan bisnis. Banyak aturan bisnis dapat dinyatakan sebagai batasan invarian pada asosiasi dan atribut dalam model kelas persyaratan, dan sebagai batasan pada diagram urutan.

• Desain tingkat tinggi. Menjelaskan bagian-bagian utama dan bagaimana mereka cocok bersama. Komponen, urutan, dan diagram antarmuka adalah bagian utama dari desain tingkat tinggi.

• Pola desain. Jelaskan aturan desain yang dibagikan di berbagai bagian sistem.

• Spesifikasi pengujian. Skrip pengujian dan desain untuk kode pengujian dapat memanfaatkan aktivitas dan diagram urutan dengan baik untuk menjelaskan urutan langkah-langkah pengujian. Pengujian sistem harus dinyatakan dalam hal model persyaratan sehingga dapat dengan mudah diubah ketika persyaratan berubah.

• Rencana proyek. Rencana proyek atau backlog menentukan kapan setiap fitur akan dikirimkan. Anda dapat menentukan setiap fitur dengan menyatakan kasus penggunaan dan aturan bisnis apa yang diterapkan atau diperluas. Anda dapat merujuk ke kasus penggunaan dan aturan bisnis langsung dalam paket, atau Anda dapat menentukan serangkaian fitur dalam dokumen terpisah, dan menggunakan judul fitur dalam paket.

Menggunakan model dalam perencanaan iterasi

Meskipun semua proyek berbeda dalam skala dan organisasi mereka, proyek khas direncanakan sebagai serangkaian iterasi antara dua dan enam minggu. Penting untuk merencanakan iterasi yang cukup untuk memungkinkan umpan balik dari iterasi awal digunakan untuk menyesuaikan cakupan dan rencana untuk perulangan nanti.

Anda mungkin menemukan saran berikut berguna untuk membantu mewujudkan manfaat pemodelan dalam proyek berulang.

Pertajam fokus seiring setiap iterasi mendekat

Saat setiap perulangan mendekati, gunakan model untuk membantu menentukan apa yang akan dikirimkan di akhir perulangan.

• Jangan memodelkan semuanya secara rinci di iterasi awal. Dalam iterasi pertama, buat diagram kelas untuk item utama dalam glosarium pengguna, gambar diagram kasus penggunaan utama, dan gambar diagram komponen utama. Jangan jelaskan salah satu dari ini secara rinci, karena detailnya akan berubah nanti dalam proyek. Gunakan istilah yang ditentukan dalam model ini untuk membuat daftar fitur atau cerita pengguna utama. Tetapkan fitur ke iterasi sehingga kira-kira menyeimbangkan perkiraan beban kerja di seluruh proyek. Tugas-tugas ini akan berubah nanti dalam proyek.

• Cobalah untuk menerapkan versi yang disederhanakan dari semua kasus penggunaan yang paling penting dalam perulangan awal. Perluas kasus penggunaan tersebut dalam iterasi berikutnya. Pendekatan ini membantu mengurangi risiko menemukan kelemahan dalam persyaratan atau arsitektur terlalu terlambat dalam proyek sehingga tidak dapat ditangani.

• Di dekat akhir setiap iterasi, adakan lokakarya persyaratan untuk menentukan secara rinci persyaratan atau cerita pengguna yang akan dikembangkan dalam iterasi berikutnya. Undang pengguna dan pemangku kepentingan bisnis yang dapat memutuskan prioritas, serta pengembang dan penguji sistem. Izinkan tiga jam untuk menentukan persyaratan untuk iterasi selama dua minggu.

• Tujuan dari lokakarya adalah agar semua orang menyetujui apa yang akan dicapai pada akhir perulangan berikutnya. Gunakan model sebagai salah satu alat untuk membantu mengklarifikasi persyaratan. Output dari lokakarya adalah backlog iterasi: yaitu, daftar tugas pengembangan di Team Foundation dan suite pengujian di Microsoft Test Manager.

• Dalam lokakarya persyaratan, diskusikan desain hanya sejauh yang diperlukan untuk menentukan perkiraan tugas pengembangan. Jika tidak, fokuskan diskusi pada perilaku sistem yang dapat dialami pengguna secara langsung. Pisahkan model persyaratan dari model arsitektur.

• Pemangku kepentingan nonteknis biasanya tidak memiliki masalah dalam memahami diagram UML, dengan beberapa panduan dari Anda.

Menautkan model ke item kerja

Setelah lokakarya persyaratan, urai detail model persyaratan, dan tautkan model ke tugas pengembangan. Anda dapat melakukan ini dengan menautkan item kerja di Team Foundation ke elemen dalam model.

Anda dapat menautkan elemen apa pun ke item kerja, tetapi elemen yang paling berguna adalah sebagai berikut:

• Komentar yang menjelaskan aturan bisnis atau kualitas persyaratan layanan. Untuk informasi selengkapnya, lihat Persyaratan pengguna model.

Menautkan model ke pengujian

Gunakan model persyaratan untuk memandu desain pengujian penerimaan. Buat pengujian ini secara bersamaan dengan pekerjaan pengembangan.

Untuk mempelajari selengkapnya tentang teknik ini, lihat Mengembangkan pengujian dari model.

Memperkirakan sisa pekerjaan

Model persyaratan dapat membantu memperkirakan ukuran total proyek sehubungan dengan ukuran setiap iterasi. Menilai jumlah dan kompleksitas kasus dan kelas penggunaan dapat membantu Anda memperkirakan pekerjaan pengembangan yang akan diperlukan. Ketika Anda telah menyelesaikan beberapa iterasi pertama, perbandingan persyaratan yang tercakup dan persyaratan yang masih harus dicakup dapat memberikan perkiraan ukuran biaya dan cakupan proyek lainnya.

Di dekat akhir setiap perulangan, tinjau penetapan persyaratan untuk iterasi di masa mendatang. Ini dapat berguna untuk mewakili status perangkat lunak Anda di akhir setiap iterasi sebagai subsistem dalam diagram kasus penggunaan. Dalam diskusi Anda, Anda dapat memindahkan kasus penggunaan dan ekstensi kasus dari salah satu subsistem ini ke subsistem lainnya.

Tingkat abstraksi

Model memiliki berbagai abstraksi dalam kaitannya dengan perangkat lunak. Model paling konkret secara langsung mewakili kode program, dan model yang paling abstrak mewakili konsep bisnis yang mungkin atau mungkin tidak diwakili dalam kode.

Model dapat dilihat melalui beberapa jenis diagram. Untuk informasi tentang model dan diagram, lihat Membuat model untuk aplikasi Anda.

Berbagai jenis diagram berguna untuk menggambarkan desain pada tingkat abstraksi yang berbeda. Banyak jenis diagram berguna pada lebih dari satu tingkat. Tabel ini memperlihatkan bagaimana setiap jenis diagram dapat digunakan.

Tingkat desain	Jenis diagram
Proses Bisnis Memahami konteks di mana sistem Anda akan digunakan membantu Anda memahami apa yang dibutuhkan pengguna darinya.	- Diagram kelas konseptual menjelaskan konsep bisnis yang digunakan dalam proses bisnis.
Persyaratan pengguna Definisi apa yang dibutuhkan pengguna dari sistem Anda.	- Aturan bisnis dan kualitas persyaratan layanan dapat dijelaskan dalam dokumen terpisah.
Desain tingkat tinggi Struktur keseluruhan sistem: komponen utama dan bagaimana mereka berpasangan.	- Diagram Dependensi menjelaskan bagaimana sistem disusun menjadi bagian yang saling bergantung. Anda dapat memvalidasi kode program terhadap diagram dependensi untuk memastikan bahwa kode tersebut mematuhi arsitektur.
Analisis kode Diagram dapat dihasilkan dari kode.	- Diagram dependensi menunjukkan dependensi antar kelas. Kode yang diperbarui dapat divalidasi terhadap diagram dependensi. - Diagram kelas menunjukkan kelas dalam kode.

Sumber daya eksternal

Kategori	Links
Video	Video MSDN: Bagaimana Cara Membuat dan Menggunakan Model dan Diagram UML (Visual Studio Ultimate) MSDN Seri Cara: Alat UML dan Ekstensibilitas (Visual Studio Ultimate)
Forum	- Alat Visualisasi & Pemodelan Visual Studio - Visual Studio Visualisasi & Pemodelan SDK (Alat DSL)
Blog	Microsoft DevOps
Artikel teknis dan Jurnal	Pusat Arsitektur MSDN

Konten terkait

• Menggunakan model dalam pengembangan Agile
• Membuat model untuk aplikasi Anda
• Persyaratan pengguna model
• Memodelkan arsitektur aplikasi Anda
• Mengembangkan pengujian dari model
• Menyusun solusi pemodelan Anda

Nota

Komponen Transformasi Templat Teks diinstal secara otomatis sebagai bagian dari beban kerja pengembangan ekstensi Visual Studio . Anda juga dapat menginstalnya dari tab Komponen individual penginstal Visual Studio, di bawah kategori SDK, pustaka, dan kerangka kerja . Instal komponen SDK Pemodelan dari tab Komponen individual .