Ketika memformalkan arsitektur sistem, penting bagi Anda untuk memahami tidak hanya nilai di balik apa yang akan dibawa arsitektur ke meja, tetapi juga untuk memahami dan menghargai apa yang seharusnya.
Tujuan utama Perangkat Lunak atau Arsitektur Teknis adalah untuk mengidentifikasi persyaratan Non-Fungsional yang diwujudkan oleh Atribut Kualitas yang akan mendorong Arsitektur Sistem .
Pada Persyaratan Non-Fungsional:
Persyaratan non-fungsional adalah persyaratan yang menentukan kriteria yang dapat digunakan untuk menilai operasi suatu sistem, bukan perilaku tertentu. Mereka kontras dengan persyaratan fungsional yang menentukan perilaku atau fungsi tertentu. Rencana untuk menerapkan persyaratan fungsional dirinci dalam desain sistem. Rencana untuk menerapkan persyaratan non-fungsional dirinci dalam arsitektur sistem.
Secara umum, persyaratan fungsional menentukan apa yang seharusnya dilakukan sistem dan persyaratan non-fungsional menentukan bagaimana seharusnya suatu sistem. ... Persyaratan non-fungsional sering disebut "atribut kualitas" dari suatu sistem. Istilah lain untuk persyaratan non-fungsional adalah "kualitas", "sasaran kualitas", "kualitas persyaratan layanan", "kendala" dan "persyaratan non-perilaku"
Tentu saja mengidentifikasi persyaratan yang signifikan secara arsitektur masuk akal ketika berada di proyek greenfield, namun ketika bekerja dengan perangkat lunak yang ada, yang terbaik adalah disiplin mungkin. Anda tidak ingin arsitektur perangkat lunak Anda dipengaruhi oleh sistem yang ada.
Arsitektur perangkat lunak agar berwibawa benar-benar perlu 3 hal.
Deklaratif
Ini adalah bagian dari dokumentasi di mana Anda menyatakan BUKAN APA ITU, tetapi bagaimana hal-hal HARUS. Kami melakukan ini melalui penggunaan berbagai Tampilan Arsitektur sistem. Kami mendefinisikan komponen yang seharusnya, bagaimana mereka berinteraksi, dan kemudian kami secara opsional menelusuri ke dalam setiap komponen untuk tampilan yang lebih terperinci yang menyatakan bagaimana sistem harus dirancang.
Ini adalah perbedaan penting. Desain Sistem harus dibatasi oleh Arsitektur Sistem, mereka sebenarnya terpisah tetapi hal-hal terkait.
Alasan
Dasar pemikiran Arsitektur Perangkat Lunak Anda adalah apa yang memberikan legitimasi dan otoritas terhadap keputusan arsitektur yang dibuat. Mungkin keputusan dibuat untuk menggunakan pendengar acara Pub / Sub lebih dari MQ untuk memicu pekerjaan batch dan Anda diagramnya?
Mengapa keputusan ini dibuat? Kami menjelaskan mengapa di bagian Dasar Pemikiran dan menghubungkan kembali penjelasan kami ke Persyaratan Non-Fungsional, Sasaran Atribut Kualitas, atau Persyaratan Penting Secara Arsitektur. (Mis. Pekerjaan harus asinkron dan berulang, Dapat dipertahankan sebagai atribut kualitas mendorong bahwa jika terjadi kegagalan pekerjaan batch yang pekerjaan dapat dimulai kembali melalui pesan MQ, Sistem harus memiliki Kehilangan Pesan Nol dengan komunikasi asinkron, dll. ..)
Risiko
Sekarang setelah Anda mendeklarasikan bagaimana arsitektur seharusnya dan membuktikannya dengan Dasar Pemikiran Anda, Anda sekarang dapat mengidentifikasi Risiko pada kondisi sistem saat ini ke tempat ini tidak tinggal.
(Misalnya. Validasi sisi server sedang diduplikasi pada kode Javascript sisi klien. Ini merupakan pelanggaran prinsip KERING dan ini bertentangan dengan Atribut Kualitas Pemeliharaan. Tidak ada persyaratan Non-Fungsional yang didefinisikan seputar Kinerja di area ini sehingga ada ada Dasar Pemikiran untuk perilaku sistem saat ini)
Risiko Anda juga dapat menggambarkan di mana keadaan saat ini menyimpang dari Arsitektur. Risiko-risiko ini dapat diatasi oleh tim pengembangan sekarang, baik melalui rencana proyek mereka atau dengan menambahkan ini ke dalam simpanan.