Model Arsitektur
Arsitektur perangkat lunak melibatkan struktur tingkat tinggi dari abstraksi sistem perangkat lunak, dengan menggunakan dekomposisi dan komposisi, dengan gaya arsitektur dan atribut kualitas. Sebuah desain arsitektur perangkat lunak harus sesuai dengan fungsionalitas utama dan persyaratan kinerja sistem, serta memenuhi persyaratan non-fungsional seperti keandalan, skalabilitas, portabilitas, dan ketersediaan.
Arsitektur perangkat lunak harus menjelaskan kelompok komponennya, koneksi mereka, interaksi di antara mereka dan konfigurasi penyebaran semua komponen.
Arsitektur perangkat lunak dapat didefinisikan dengan banyak cara -
UML (Unified Modeling Language) - UML adalah salah satu solusi berorientasi objek yang digunakan dalam pemodelan dan desain perangkat lunak.
Architecture View Model (4+1 view model) - Model tampilan arsitektur mewakili persyaratan fungsional dan non-fungsional dari aplikasi perangkat lunak.
ADL (Architecture Description Language) - ADL mendefinisikan arsitektur perangkat lunak secara formal dan semantik.
UML
UML adalah singkatan dari Unified Modeling Language. Ini adalah bahasa bergambar yang digunakan untuk membuat cetak biru perangkat lunak. UML dibuat oleh Object Management Group (OMG). Draf spesifikasi UML 1.0 diusulkan ke OMG pada Januari 1997. Draft ini berfungsi sebagai standar untuk analisis kebutuhan perangkat lunak dan dokumen desain yang menjadi dasar untuk mengembangkan perangkat lunak.
UML dapat digambarkan sebagai bahasa pemodelan visual tujuan umum untuk memvisualisasikan, menentukan, membangun, dan mendokumentasikan sistem perangkat lunak. Meskipun UML umumnya digunakan untuk memodelkan sistem perangkat lunak, UML tidak dibatasi dalam batasan ini. Ini juga digunakan untuk memodelkan sistem non perangkat lunak seperti aliran proses di unit manufaktur.
Elemen-elemen tersebut seperti komponen yang dapat dikaitkan dengan berbagai cara untuk membuat gambar UML lengkap, yang dikenal sebagai a diagram. Jadi, sangat penting untuk memahami diagram yang berbeda untuk menerapkan pengetahuan dalam sistem kehidupan nyata. Kami memiliki dua kategori besar diagram dan mereka dibagi lagi menjadi sub-kategori yaituStructural Diagrams dan Behavioral Diagrams.
Diagram Struktural
Diagram struktur merepresentasikan aspek statis dari suatu sistem. Aspek-aspek statis ini merepresentasikan bagian-bagian diagram yang membentuk struktur utama dan oleh karena itu stabil.
Bagian statis ini diwakili oleh kelas, antarmuka, objek, komponen, dan node. Diagram struktural dapat dibagi lagi sebagai berikut -
- Diagram kelas
- Diagram objek
- Diagram komponen
- Diagram penyebaran
- Diagram paket
- Struktur komposit
Tabel berikut memberikan deskripsi singkat tentang diagram ini -
Sr.No. | Diagram & Deskripsi |
---|---|
1 | Class Merupakan orientasi objek dari suatu sistem. Menunjukkan bagaimana kelas terkait secara statis. |
2 | Object Merepresentasikan sekumpulan objek dan hubungannya saat runtime dan juga merepresentasikan tampilan statis sistem. |
3 | Component Menjelaskan semua komponen, keterkaitannya, interaksi dan antarmuka sistem. |
4 | Composite structure Menjelaskan struktur bagian dalam komponen termasuk semua kelas, antarmuka komponen, dll. |
5 | Package Menjelaskan struktur dan organisasi paket. Mencakup kelas dalam paket dan paket dalam paket lain. |
6 | Deployment Diagram penyebaran adalah sekumpulan node dan hubungannya. Node ini adalah entitas fisik tempat komponen disebarkan. |
Diagram Perilaku
Diagram perilaku pada dasarnya menangkap aspek dinamis dari suatu sistem. Aspek dinamis pada dasarnya adalah bagian yang berubah / bergerak dari suatu sistem. UML memiliki tipe diagram perilaku berikut -
- Gunakan diagram kasus
- Diagram urutan
- Diagram komunikasi
- Diagram diagram negara
- Diagram aktivitas
- Ringkasan interaksi
- Diagram urutan waktu
Tabel berikut memberikan deskripsi singkat tentang diagram ini -
Sr.No. | Diagram & Deskripsi |
---|---|
1 | Use case Menjelaskan hubungan antara fungsi dan pengontrol internal / eksternalnya. Pengendali ini dikenal sebagai aktor. |
2 | Activity Menjelaskan aliran kendali dalam suatu sistem. Ini terdiri dari aktivitas dan tautan. Alurnya bisa berurutan, bersamaan, atau bercabang. |
3 | State Machine/state chart Merepresentasikan perubahan status yang didorong peristiwa dari suatu sistem. Ini pada dasarnya menggambarkan perubahan status kelas, antarmuka, dll. Digunakan untuk memvisualisasikan reaksi sistem oleh faktor internal / eksternal. |
4 | Sequence Memvisualisasikan urutan panggilan dalam sistem untuk menjalankan fungsi tertentu. |
5 | Interaction Overview Menggabungkan diagram aktivitas dan urutan untuk memberikan gambaran aliran kontrol sistem dan proses bisnis. |
6 | Communication Sama seperti diagram sekuens, hanya saja diagram tersebut berfokus pada peran objek. Setiap komunikasi dikaitkan dengan urutan urutan, nomor ditambah pesan sebelumnya. |
7 | Time Sequenced Menjelaskan perubahan berdasarkan pesan dalam status, kondisi, dan peristiwa. |
Model Tampilan Arsitektur
Model adalah deskripsi lengkap, dasar, dan sederhana dari arsitektur perangkat lunak yang terdiri dari beberapa pandangan dari perspektif atau sudut pandang tertentu.
Pandangan adalah representasi dari seluruh sistem dari perspektif serangkaian masalah terkait. Ini digunakan untuk menggambarkan sistem dari sudut pandang pemangku kepentingan yang berbeda seperti pengguna akhir, pengembang, manajer proyek, dan penguji.
4 + 1 Tampilan Model
Model Tampilan 4 + 1 dirancang oleh Philippe Kruchten untuk mendeskripsikan arsitektur sistem intensif perangkat lunak berdasarkan penggunaan tampilan ganda dan bersamaan. Ini adalah sebuahmultiple viewmodel yang membahas berbagai fitur dan masalah sistem. Ini menstandarkan dokumen desain perangkat lunak dan membuat desain mudah dipahami oleh semua pemangku kepentingan.
Ini adalah metode verifikasi arsitektur untuk mempelajari dan mendokumentasikan desain arsitektur perangkat lunak dan mencakup semua aspek arsitektur perangkat lunak untuk semua pemangku kepentingan. Ini memberikan empat pandangan penting -
The logical view or conceptual view - Ini menjelaskan model objek dari desain.
The process view - Ini menggambarkan aktivitas sistem, menangkap aspek konkurensi dan sinkronisasi dari desain.
The physical view - Ini menggambarkan pemetaan perangkat lunak ke perangkat keras dan mencerminkan aspek distribusinya.
The development view - Ini menggambarkan organisasi statis atau struktur perangkat lunak dalam pengembangan lingkungannya.
Model tampilan ini dapat diperpanjang dengan menambahkan satu tampilan lagi yang disebut scenario view atau use case viewuntuk pengguna akhir atau pelanggan sistem perangkat lunak. Ini koheren dengan empat tampilan lainnya dan digunakan untuk menggambarkan arsitektur yang berfungsi sebagai tampilan "plus satu", (4 + 1) model tampilan. Gambar berikut menjelaskan arsitektur perangkat lunak menggunakan model lima tampilan bersamaan (4 + 1).
Mengapa disebut 4 + 1, bukan 5?
Itu use case viewmemiliki signifikansi khusus karena merinci persyaratan tingkat tinggi dari suatu sistem sementara pandangan lain merinci - bagaimana persyaratan tersebut direalisasikan. Ketika keempat tampilan lainnya diselesaikan, itu secara efektif menjadi mubazir. Namun, semua pandangan lain tidak akan mungkin terjadi tanpanya. Gambar dan tabel berikut menunjukkan tampilan 4 + 1 secara detail -
Logis | Proses | Pengembangan | Fisik | Skenario | |
---|---|---|---|---|---|
Deskripsi | Menunjukkan komponen (Objek) sistem serta interaksinya | Menunjukkan proses / aturan alur kerja sistem dan bagaimana proses tersebut berkomunikasi, berfokus pada tampilan sistem yang dinamis | Memberikan tampilan blok penyusun sistem dan mendeskripsikan organisasi statis dari modul sistem | Menunjukkan instalasi, konfigurasi dan penerapan aplikasi perangkat lunak | Menunjukkan desain sudah selesai dengan melakukan validasi dan ilustrasi |
Viewer / Stake holder | Pengguna Akhir, Analis, dan Desainer | Integrator & pengembang | Programmer dan manajer proyek perangkat lunak | Insinyur sistem, operator, administrator sistem, dan pemasang sistem | Semua pandangan mereka dilihat dan evaluator |
Mempertimbangkan | Persyaratan fungsional | Persyaratan Non Fungsional | Organisasi Modul Perangkat Lunak (Penggunaan kembali manajemen perangkat lunak, kendala alat) | Persyaratan nonfungsional terkait dengan perangkat keras yang mendasarinya | Konsistensi dan validitas Sistem |
UML - Diagram | Kelas, Negara Bagian, Objek, urutan, Diagram Komunikasi | Diagram Aktivitas | Komponen, diagram Paket | Diagram penyebaran | Gunakan diagram kasus |
Arsitektur Deskripsi Bahasa (ADL)
ADL adalah bahasa yang menyediakan sintaksis dan semantik untuk mendefinisikan arsitektur perangkat lunak. Ini adalah spesifikasi notasi yang menyediakan fitur untuk memodelkan arsitektur konseptual sistem perangkat lunak, yang dibedakan dari implementasi sistem.
ADL harus mendukung komponen arsitektur, koneksi, antarmuka, dan konfigurasinya yang merupakan blok penyusun deskripsi arsitektur. Ini adalah bentuk ekspresi untuk digunakan dalam deskripsi arsitektur dan memberikan kemampuan untuk mendekomposisi komponen, menggabungkan komponen, dan menentukan antarmuka komponen.
Bahasa deskripsi arsitektur adalah bahasa spesifikasi formal, yang mendeskripsikan fitur-fitur perangkat lunak seperti proses, utas, data, dan subprogram serta komponen perangkat keras seperti prosesor, perangkat, bus, dan memori.
Sulit untuk mengklasifikasikan atau membedakan ADL dan bahasa pemrograman atau bahasa pemodelan. Namun, ada persyaratan berikut untuk sebuah bahasa yang diklasifikasikan sebagai ADL -
Ini harus sesuai untuk mengkomunikasikan arsitektur kepada semua pihak terkait.
Ini harus sesuai untuk tugas pembuatan arsitektur, perbaikan, dan validasi.
Ini harus memberikan dasar untuk implementasi lebih lanjut, sehingga harus dapat menambahkan informasi ke spesifikasi ADL untuk memungkinkan spesifikasi sistem akhir diturunkan dari ADL.
Ini harus memiliki kemampuan untuk mewakili sebagian besar gaya arsitektur umum.
Ini harus mendukung kemampuan analitis atau menyediakan implementasi prototipe yang menghasilkan cepat.