Bab 2 : Software Architecture

 

Nama : Mutia ardelia rokhima

NIM : 240605110075

Bab 2 : Software Architecture

Bagian 1 : Dasar Dasar Arsitektur Perangkat Lunak

A.    Definisi Dan Komponen Arsitektur

1.     Definisi Software Architecture

      Software architecture adalah rancangan dasar yang menjelaskan bagaimana suatu sistem perangkat lunak dibangun dan diorganisasikan. Arsitektur ini menggambarkan struktur utama sistem, pembagian fungsi ke dalam bagian-bagian tertentu, serta hubungan antar bagian tersebut. Dengan adanya arsitektur perangkat lunak, proses pengembangan sistem dapat dilakukan secara terencana sehingga sistem yang dihasilkan lebih mudah dikembangkan, dipelihara, dan disesuaikan dengan kebutuhan pengguna.

2.     Tiga Komponen Utama dalam Arsitektur Perangkat Lunak

a.     Komponen (Components)

Komponen merupakan bagian penyusun sistem yang memiliki fungsi dan tanggung jawab tertentu. Setiap komponen dirancang untuk menangani tugas spesifik, seperti pengolahan data, pengelolaan logika sistem, atau penyajian informasi kepada pengguna.

b.     Konektor (Connectors

Konektor berfungsi sebagai penghubung antar komponen agar dapat saling berkomunikasi. Melalui konektor, data dan informasi dapat dikirim serta diproses antar bagian sistem, sehingga keseluruhan sistem dapat berjalan secara terintegrasi.

c.     Konfigurasi (Configuration)  

Konfigurasi menunjukkan cara pengaturan dan hubungan antara komponen serta konektor dalam sistem. Konfigurasi ini menentukan bagaimana komponen bekerja bersama dan membentuk struktur sistem secara keseluruhan.

3.  Contoh gambar diagram sederhana yang menunjukkan struktur arsitektur perangkat lunak dari sistem e comers atau sistem manajemen perpustakaan digital



B.    Peran Dan Pemangku Kepentingan Dalam Arsitektur Perangkat Lunak

1.     Peran Tiga Pemangku Kepentingan dalam Arsitektur Perangkat Lunak

a.     Pengembang

Pengembang berperan dalam merancang dan mengimplementasikan arsitektur sistem. Mereka bertanggung jawab memastikan struktur sistem dapat diwujudkan secara teknis, mudah dikembangkan, serta mendukung pemeliharaan jangka panjang.

b.     Pengguna

Pengguna merupakan pihak yang memanfaatkan sistem secara langsung. Peran pengguna penting dalam memberikan masukan terkait kebutuhan fungsional, kemudahan penggunaan, serta kenyamanan saat sistem dijalankan.

c.     Manajer Proyek

Manajer proyek berperan dalam mengatur perencanaan, pengawasan, dan pengendalian pengembangan sistem. Dalam konteks arsitektur, manajer proyek memastikan bahwa rancangan sistem sesuai dengan tujuan proyek, waktu, dan sumber daya yang tersedia.

2.     Pengaruh Kebutuhan Pemangku Kepentingan terhadap Keputusan Arsitektural

Kebutuhan dari setiap pemangku kepentingan dapat memengaruhi keputusan dalam perancangan arsitektur perangkat lunak. Pengembang cenderung membutuhkan arsitektur yang modular dan fleksibel agar sistem mudah dikembangkan. Pengguna menginginkan sistem yang mudah digunakan, responsif, dan stabil. Sementara itu, manajer proyek lebih menekankan pada efisiensi biaya, ketepatan waktu penyelesaian, serta pengelolaan risiko. Perbedaan kebutuhan tersebut harus dipertimbangkan agar arsitektur yang dirancang mampu menyeimbangkan aspek teknis dan non-teknis.

3.     Tabel Pencocokan Pemangku Kepentingan dan Kepentingannya

Pemangku Kepentingan

Kepentingan dalam Arsitektur

Pengembang

Arsitektur yang terstruktur, mudah dipahami, serta mendukung pengembangan dan pemeliharaan sistem

Pengguna

Sistem yang mudah digunakan, cepat diakses, dan sesuai dengan kebutuhan operasional

Manajer Proyek

Arsitektur yang mendukung efisiensi biaya, ketepatan waktu, dan keberhasilan proyek

Bagian 2 : Deskripsi Dan Pola Arsitektur Perangkat Lunak

A.    View Dan Viewpoints Dalam Arsitektur

1.     Konsep View dan Viewpoints

View merupakan cara untuk menampilkan atau melihat suatu sistem perangkat lunak dari sudut pandang tertentu. Setiap view hanya menyoroti aspek tertentu dari sistem agar lebih mudah dipahami, misalnya struktur modul atau alur komunikasi. Sementara itu, viewpoints adalah pedoman atau aturan yang menentukan bagaimana suatu view dibuat, termasuk fokus, elemen yang ditampilkan, serta pihak yang berkepentingan terhadap view tersebut. Dengan adanya view dan viewpoints, arsitektur sistem dapat dijelaskan secara lebih jelas dan terstruktur kepada berbagai pihak.

2.     Tiga Jenis View dalam Arsitektur dan Contoh Penerapannya

a.     Logical View

Logical view menggambarkan struktur logika sistem, seperti modul, kelas, atau fungsi utama.
Contoh: Diagram kelas pada sistem perpustakaan digital yang menampilkan modul buku, anggota, dan transaksi.

b.     Development View (Proses View)

Development view menunjukkan bagaimana sistem diorganisasikan dalam lingkungan pengembangan, seperti pembagian paket atau modul kode.
Contoh: Struktur folder proyek aplikasi web yang dipisahkan antara frontend, backend, dan database.

c.     Deployment View

Deployment view menggambarkan penempatan sistem pada infrastruktur fisik atau virtual.
Contoh: Aplikasi web yang dijalankan pada server cloud dengan pemisahan antara server aplikasi dan server basis data.

3.     Diagram Sederhana Salah Satu Jenis View


B.    Pola Arsitektur Perangkat Lunak

1.     Penjelasan Pola Arsitektur dan Contoh Penggunaannya

a.     Layered Architecture

Layered Architecture membagi sistem ke dalam beberapa lapisan yang memiliki tanggung jawab berbeda, seperti lapisan presentasi, logika bisnis, dan data.
Contoh penggunaan: Sistem informasi akademik yang memisahkan tampilan pengguna, proses akademik, dan pengelolaan basis data.

b.     Microservices Architecture

Microservices Architecture memecah sistem menjadi layanan-layanan kecil yang berdiri sendiri dan saling berkomunikasi melalui API.
Contoh penggunaan: Aplikasi e-commerce yang memiliki layanan terpisah untuk pembayaran, katalog produk, dan pengiriman.

c.     Event-Driven Architecture

Event-Driven Architecture bekerja berdasarkan peristiwa atau kejadian tertentu yang memicu proses lain dalam sistem.
Contoh penggunaan: Sistem notifikasi yang mengirim pesan otomatis saat terjadi transaksi.

2.     Tabel Perbandingan Pola Arsitektur

Pola Arsitektur

Kelebihan

Kekurangan

Contoh Penerapan

Layered Architecture

Struktur sistem jelas dan mudah dipahami

Kurang fleksibel untuk sistem skala besar

Sistem informasi sekolah

Microservices

Mudah dikembangkan dan diskalakan

Kompleks dalam pengelolaan dan komunikasi

Aplikasi e-commerce

Event-Driven

Responsif dan mendukung proses real-time

Sulit ditelusuri alur prosesnya

Sistem notifikasi transaksi

3.     Penerapan Pola Arsitektur dalam Sistem Berbasis Cloud

Salah satu pola arsitektur yang cocok untuk sistem berbasis cloud adalah Microservices Architecture. Pola ini memungkinkan setiap layanan dijalankan secara terpisah pada lingkungan cloud sehingga mudah diskalakan sesuai kebutuhan. Jika terjadi peningkatan pengguna, layanan tertentu dapat ditingkatkan kapasitasnya tanpa memengaruhi layanan lain. Selain itu, penggunaan microservices mendukung fleksibilitas pengembangan dan pemeliharaan sistem dalam lingkungan cloud.

Bagian 3: Proses Perancangan Dan Evaluasi Arsitektur

A.    Teknik Perancangan Arsitektur

1.     Tiga Pendekatan dalam Proses Desain Arsitektur Perangkat Lunak

a.     Pendekatan Top-Down

Pendekatan top-down dimulai dari perancangan sistem secara umum, kemudian dipecah menjadi komponen-komponen yang lebih kecil. Fokus utama pendekatan ini adalah memahami kebutuhan sistem secara menyeluruh sebelum masuk ke detail teknis.

b.     Pendekatan Bottom-Up

Pendekatan bottom-up dimulai dari perancangan komponen-komponen kecil yang sudah ada atau direncanakan, kemudian digabungkan menjadi sistem yang lebih besar. Pendekatan ini sering digunakan ketika sistem memanfaatkan komponen atau modul yang sudah tersedia.

c.     Pendekatan Berbasis Kebutuhan (Requirement-Driven Design)

Pendekatan ini berfokus pada kebutuhan fungsional dan non-fungsional sebagai dasar perancangan arsitektur. Setiap keputusan arsitektural diambil berdasarkan kebutuhan sistem, seperti keamanan, performa, dan skalabilitas.

2.     Diagram Tahapan Proses Perancangan Arsitektur



3.     Pendekatan Desain yang Paling Sesuai untuk Studi Kasus

Studi Kasus: Sistem Manajemen Rumah Sakit Berbasis Web

Pendekatan yang paling sesuai adalah pendekatan berbasis kebutuhan. Hal ini dikarenakan sistem rumah sakit memiliki kebutuhan yang kompleks, seperti keamanan data pasien, keandalan sistem, ketersediaan layanan, serta kemudahan akses bagi berbagai pengguna. Dengan pendekatan berbasis kebutuhan, arsitektur sistem dapat dirancang agar mampu memenuhi tuntutan operasional dan regulasi yang berlaku di lingkungan rumah sakit.

B.    Evaluasi Arsitektur Perangkat Lunak

1.     Tujuan Evaluasi Arsitektur Perangkat Lunak

Evaluasi arsitektur bertujuan untuk memastikan bahwa rancangan arsitektur telah sesuai dengan kebutuhan sistem dan mampu mendukung tujuan pengembangan. Selain itu, evaluasi dilakukan untuk mengidentifikasi potensi risiko sejak dini, meningkatkan kualitas sistem, serta mengurangi kemungkinan terjadinya masalah pada tahap implementasi.

2.     Metode Evaluasi Arsitektur dan Contoh Penerapannya

Metode Evaluasi

Deskripsi

Contoh Penerapan

Architecture Tradeoff Analysis Method (ATAM)

Metode evaluasi yang menganalisis kompromi antara berbagai atribut kualitas seperti performa, keamanan, dan skalabilitas

Digunakan untuk menilai arsitektur sistem perbankan sebelum implementasi

Software Architecture Review Board (SARB)

Evaluasi arsitektur oleh tim ahli atau panel independen

Review arsitektur sistem pemerintahan sebelum peluncuran

Scenario-Based Evaluation

Evaluasi arsitektur berdasarkan skenario penggunaan sistem

Menguji respons sistem terhadap lonjakan pengguna

3.     Simulasi Evaluasi Arsitektur Aplikasi Mobile Banking

Dalam aplikasi mobile banking, salah satu risiko arsitektural adalah keamanan data pengguna. Risiko ini dapat muncul akibat komunikasi data yang tidak aman atau pengelolaan autentikasi yang lemah. Cara mengatasinya adalah dengan menerapkan enkripsi data, autentikasi berlapis, serta pemisahan layanan sensitif. Selain itu, risiko kinerja sistem saat terjadi lonjakan transaksi dapat diatasi dengan penerapan arsitektur yang mendukung skalabilitas dan pemantauan sistem secara berkala.

Bagian 4 : Dokumentasi Dan Alat Bantu Arsitektur Perangkat Lunak

A.    Dokumentasi Arsitektur

1.     Pentingnya Dokumentasi Arsitektur Perangkat Lunak

Dokumentasi arsitektur perangkat lunak sangat penting sebagai panduan dalam pengembangan dan pemeliharaan sistem. Dokumentasi ini membantu seluruh pihak yang terlibat untuk memahami struktur sistem, hubungan antar komponen, serta keputusan desain yang telah diambil. Dengan dokumentasi yang baik, proses pengembangan menjadi lebih terarah, risiko kesalahan dapat dikurangi, dan proses pengembangan lanjutan dapat dilakukan dengan lebih mudah.

2.     Tiga Jenis Dokumentasi dalam Arsitektur Perangkat Lunak

1.     Dokumentasi Struktural

Dokumentasi ini menjelaskan struktur sistem, termasuk komponen utama dan hubungan antar komponen. Biasanya disajikan dalam bentuk diagram arsitektur.

2.     Dokumentasi Fungsional

Dokumentasi fungsional menjelaskan fungsi-fungsi utama sistem dan bagaimana sistem bekerja dalam memenuhi kebutuhan pengguna.

3.     Dokumentasi Teknis

Dokumentasi teknis berisi detail implementasi, seperti teknologi yang digunakan, antarmuka sistem, dan konfigurasi lingkungan pengembangan.

3.     Contoh Dokumentasi Sederhana Arsitektur Sistem Berbasis REST API

Deskripsi Sistem:
Sistem REST API digunakan untuk mengelola data pengguna dan data transaksi.

Komponen Utama:

·       Client (Web/Mobile Application)

·       REST API Server

·       Database

Alur Kerja:

·       Client mengirim permintaan (request) melalui HTTP.

·       REST API memproses permintaan sesuai endpoint.

·       Database menyimpan dan menyediakan data yang dibutuhkan.

·       REST API mengirim respons ke client dalam format JSON.

B.    Alat Bantu Untuk Perancangan Arsitektur

1.     Tiga Alat Bantu Perancangan Arsitektur Perangkat Lunak

a.     Enterprise Architect

Digunakan untuk membuat model arsitektur secara detail, termasuk diagram UML dan dokumentasi sistem.

b.     ArchiMate

Digunakan untuk memodelkan arsitektur enterprise dengan fokus pada hubungan bisnis, aplikasi, dan teknologi.

c.     UML (Unified Modeling Language)

Digunakan untuk menggambarkan struktur dan perilaku sistem melalui berbagai jenis diagram.

2.     Tabel Perbandingan Alat Bantu Arsitektur

Nama Alat Bantu

Fitur Utama

Kelebihan

Kekurangan

Enterprise Architect

Diagram UML lengkap, dokumentasi terintegrasi

Detail dan komprehensif

Berbayar dan kompleks

ArchiMate

Pemodelan arsitektur enterprise

Fokus pada hubungan lintas domain

Kurang detail teknis

UML

Standar pemodelan sistem

Mudah dipahami dan luas digunakan

Tidak spesifik ke enterprise

3.     Alat Bantu yang Dipilih untuk Sistem IoT

Untuk merancang arsitektur sistem berbasis IoT, alat bantu yang paling sesuai adalah UML. Alasan pemilihan UML adalah karena UML mampu menggambarkan struktur sistem, alur komunikasi, serta interaksi antar perangkat dan layanan secara jelas. Selain itu, UML mudah dipahami dan fleksibel untuk digunakan pada berbagai jenis sistem IoT.

Kesimpulan dan Refleksi

1.     Kesimpulan

Berdasarkan pembahasan yang telah dilakukan, dapat disimpulkan bahwa software architecture merupakan elemen penting dalam pengembangan perangkat lunak. Pemahaman terhadap konsep arsitektur membantu pengembang dalam merancang sistem yang terstruktur, scalable, dan mudah dipelihara. Dengan arsitektur yang baik, risiko kesalahan dapat diminimalkan dan kualitas sistem dapat ditingkatkan.

2.     Refleksi Pribadi

Tantangan terbesar dalam memahami dan merancang arsitektur perangkat lunak adalah menyeimbangkan antara kebutuhan teknis dan kebutuhan pengguna. Selain itu, menentukan pola arsitektur yang tepat juga menjadi tantangan tersendiri karena setiap sistem memiliki karakteristik yang berbeda.

Penerapan konsep software architecture dalam dunia nyata sangat membantu dalam pengembangan sistem berskala besar. Konsep-konsep yang dipelajari dapat digunakan untuk merancang sistem yang lebih terstruktur, efisien, dan siap dikembangkan di masa depan.



 

Komentar

Postingan populer dari blog ini

Bab 1 : Software Requirements

Bab 4 : Software Construction

Bab 9 : Software Engineering Management