Bagikan melalui

Memodelkan arsitektur aplikasi Anda

Untuk membantu memastikan bahwa sistem atau aplikasi perangkat lunak Anda memenuhi kebutuhan pengguna, Anda dapat membuat model di Visual Studio sebagai bagian dari deskripsi Anda tentang struktur dan perilaku keseluruhan sistem atau aplikasi perangkat lunak Anda. Dengan menggunakan model, Anda juga dapat menggambarkan pola yang digunakan di seluruh desain. Model-model ini membantu Anda memahami arsitektur yang ada, mendiskusikan perubahan, dan mengomunikasikan niat Anda dengan jelas.

Untuk melihat edisi Visual Studio mana yang mendukung fitur ini, lihat Dukungan edisi untuk arsitektur dan alat pemodelan.

Tujuan model adalah untuk mengurangi ambiguitas yang terjadi dalam deskripsi bahasa alami, dan untuk membantu Anda dan kolega Anda memvisualisasikan desain dan untuk membahas desain alternatif. Model harus digunakan bersama dengan dokumen atau diskusi lain. Dengan sendirinya, model tidak mewakili spesifikasi lengkap arsitektur.

Catatan

Sepanjang topik ini, "sistem" berarti perangkat lunak yang Anda kembangkan. Ini mungkin merupakan koleksi besar dari banyak komponen perangkat lunak dan perangkat keras, atau satu aplikasi, atau bagian dari aplikasi.

Arsitektur sistem dapat dibagi menjadi dua area:

  • Desain tingkat tinggi. Ini menjelaskan komponen utama dan bagaimana mereka berinteraksi satu sama lain untuk memenuhi setiap persyaratan. Jika sistem besar, setiap komponen mungkin memiliki desain tingkat tinggi sendiri yang menunjukkan bagaimana sistem terdiri dari komponen yang lebih kecil.

  • Pola desain dan konvensi yang digunakan di seluruh desain komponen. Pola menjelaskan pendekatan tertentu untuk mencapai tujuan pemrograman. Dengan menggunakan pola yang sama di seluruh desain, tim Anda dapat mengurangi biaya membuat perubahan dan mengembangkan perangkat lunak baru.

Desain tingkat tinggi

Desain tingkat tinggi menjelaskan komponen utama sistem Anda dan bagaimana mereka berinteraksi satu sama lain untuk mencapai tujuan desain. Kegiatan dalam daftar berikut terlibat dalam mengembangkan desain tingkat tinggi, meskipun belum tentu dalam urutan tertentu.

Jika Anda memperbarui kode yang ada, Anda mungkin mulai dengan menjelaskan komponen utama. Pastikan Anda memahami perubahan apa pun pada persyaratan pengguna lalu menambahkan atau memodifikasi interaksi antar komponen. Jika Anda mengembangkan sistem baru, mulailah dengan memahami fitur utama kebutuhan pengguna. Anda kemudian dapat menjelajahi urutan interaksi untuk kasus penggunaan utama, lalu mengonsolidasikan urutan ke dalam desain komponen.

Dalam setiap kasus, sangat membantu untuk mengembangkan berbagai aktivitas secara paralel, dan mengembangkan kode dan pengujian pada tahap awal. Hindari mencoba menyelesaikan salah satu aspek ini sebelum Anda memulai yang lain. Biasanya, persyaratan dan pemahaman Anda tentang cara terbaik untuk merancang sistem akan berubah saat Anda menulis dan menguji kode. Oleh karena itu, Anda harus mulai dengan memahami dan mengkoding fitur utama persyaratan dan desain Anda. Isi detail dalam iterasi proyek nanti.

  • Memahami Persyaratan. Titik awal desain apa pun adalah pemahaman yang jelas tentang kebutuhan pengguna.

  • Pola Arsitektur. Pilihan yang Anda buat tentang teknologi inti dan elemen arsitektur sistem.

  • Model Data Komponen dan Antarmuka. Anda dapat menggambar diagram kelas untuk menjelaskan informasi yang diteruskan di antara komponen dan disimpan di dalam komponen.

Memahami Persyaratan

Desain tingkat tinggi dari aplikasi lengkap paling efektif dikembangkan bersama dengan model persyaratan atau deskripsi lain tentang kebutuhan pengguna. Untuk informasi lebih lanjut tentang model persyaratan, lihat Persyaratan pengguna model .

Jika sistem yang Anda kembangkan adalah komponen dalam sistem yang lebih besar, sebagian atau semua persyaratan Anda mungkin diwujudkan dalam antarmuka terprogram.

Model persyaratan menyediakan informasi penting ini:

  • Antarmuka yang disediakan. Antarmuka yang disediakan mencantumkan layanan atau operasi yang harus diberikan sistem atau komponen kepada penggunanya, apakah mereka adalah pengguna manusia atau komponen perangkat lunak lainnya.

  • Antarmuka yang diperlukan. Antarmuka yang diperlukan mencantumkan layanan atau operasi yang dapat digunakan sistem atau komponen. Dalam beberapa kasus, Anda akan dapat merancang semua layanan ini sebagai bagian dari sistem Anda sendiri. Dalam kasus lain, terutama jika Anda merancang komponen yang dapat dikombinasikan dengan komponen lain dalam banyak konfigurasi, antarmuka yang diperlukan akan diatur oleh pertimbangan eksternal.

  • Kualitas persyaratan layanan. Performa, keamanan, ketahanan, dan tujuan serta batasan lainnya yang harus dipenuhi sistem.

    Model persyaratan ditulis dari sudut pandang pengguna sistem Anda, baik mereka adalah orang atau komponen perangkat lunak lainnya. Mereka tidak tahu apa-apa tentang pekerjaan internal sistem Anda. Sebaliknya, tujuan Anda dalam model arsitektur adalah untuk menggambarkan pekerjaan internal dan menunjukkan bagaimana mereka memenuhi kebutuhan pengguna.

    Memisahkan persyaratan dan model arsitektur berguna karena memudahkan untuk mendiskusikan persyaratan dengan pengguna. Ini juga membantu Anda merefaktor desain dan mempertimbangkan arsitektur alternatif sambil menjaga persyaratan tidak berubah.

    Jumlah detail yang harus Anda masukkan ke dalam persyaratan atau model arsitektur tergantung pada skala proyek dan ukuran dan distribusi tim. Tim kecil pada proyek pendek mungkin tidak lebih jauh dari membuat sketsa diagram kelas konsep bisnis dan beberapa pola desain; proyek besar yang didistribusikan lebih dari satu wilayah akan membutuhkan detail yang jauh lebih detail.

Pola Arsitektur

Di awal pengembangan, Anda harus memilih teknologi dan elemen utama tempat desain bergantung. Area di mana pilihan ini harus dibuat meliputi yang berikut ini:

  • Pilihan teknologi dasar, seperti pilihan antara database dan sistem file, dan pilihan antara aplikasi berjaringan dan klien web, dan sebagainya.

  • Pilihan kerangka kerja, seperti pilihan antara Windows Workflow Foundation atau ADO.NET Entity Framework.

  • Pilihan metode integrasi, misalnya antara bus layanan perusahaan atau saluran titik-ke-titik.

    Pilihan ini sering ditentukan oleh kualitas persyaratan layanan seperti skala dan fleksibilitas, dan dapat dibuat sebelum persyaratan terperinci diketahui. Dalam sistem yang besar, konfigurasi perangkat keras dan perangkat lunak sangat saling terkait.

    Pilihan yang Anda buat memengaruhi cara Anda menggunakan dan menginterpretasikan model arsitektur. Misalnya, dalam sistem yang menggunakan database, asosiasi dalam diagram kelas mungkin mewakili hubungan atau kunci asing dalam database, sedangkan dalam sistem yang didasarkan pada file XML, asosiasi mungkin menunjukkan referensi silang yang menggunakan XPath. Dalam sistem terdistribusi, pesan dalam diagram urutan dapat mewakili pesan pada kawat; dalam aplikasi mandiri, mereka dapat mewakili panggilan fungsi.

Pola Desain

Pola desain adalah garis besar cara merancang aspek tertentu dari perangkat lunak, terutama yang berulang di berbagai bagian sistem. Dengan mengadopsi pendekatan seragam di seluruh proyek, Anda dapat mengurangi biaya desain, memastikan konsistensi dalam antarmuka pengguna, dan mengurangi biaya pemahaman dan mengubah kode.

Beberapa pola desain umum seperti Observer terkenal dan berlaku secara luas. Selain itu, ada pola yang berlaku hanya untuk proyek Anda. Misalnya, dalam sistem penjualan web, akan ada beberapa operasi dalam kode tempat perubahan dilakukan pada pesanan pelanggan. Untuk memastikan bahwa status pesanan ditampilkan secara akurat di setiap tahap, semua operasi ini harus mengikuti protokol tertentu untuk memperbarui database.

Bagian dari pekerjaan arsitektur perangkat lunak adalah menentukan pola apa yang harus diadopsi di seluruh desain. Ini biasanya merupakan tugas yang sedang berlangsung, karena pola dan peningkatan baru pada pola yang ada akan ditemukan saat proyek berlangsung. Sangat membantu untuk mengatur rencana pengembangan sehingga Anda menjalankan setiap pola desain utama Anda pada tahap awal.

Sebagian besar pola desain dapat sebagian diwujudkan dalam kode kerangka kerja. Bagian dari pola dapat dikurangi untuk mengharuskan pengembang menggunakan kelas atau komponen tertentu, seperti lapisan akses database yang memastikan database ditangani dengan benar.

Pola desain dijelaskan dalam dokumen, dan biasanya mencakup bagian-bagian ini:

  • Nama.

  • Deskripsi konteks yang berlaku. Kriteria apa yang harus membuat pengembang mempertimbangkan untuk menerapkan pola ini?

  • Penjelasan singkat tentang masalah yang dipecahkannya.

  • Model bagian utama dan hubungan mereka. Ini mungkin kelas atau komponen dan antarmuka, dengan asosiasi dan dependensi di antara mereka. Elemen biasanya termasuk dalam dua kategori:

  • Konvensi penamaan.

  • Deskripsi tentang bagaimana pola memecahkan masalah.

  • Deskripsi variasi yang mungkin dapat diadopsi pengembang.

Konten terkait