BAB V SOFTWARE ARSITEKTUR
Setiap
sistem yang kompleks terdiri dari subsistem yang berinteraksi di bawah kendali
desain sistem sehingga sistem menyediakan perilaku yang diharapkan. Sebagai
sistem perangkat lunak yang semakin menjadi didistribusikan dan lebih kompleks,
arsitektur menjadi langkah penting dalam membangun sistem.Arsitektur juga
merupakan tempat awal ketika properti seperti keandalan dan kinerja dapat
dievaluasi untuk sistem, sebuah kemampuan yang semakin menjadi penting.
5.1 Peran
Software Arsitektur
Secara umum, arsitektur sistem
memberikan pandangan tingkat yang sangat tinggi dari bagian-bagian dari sistem
dan bagaimana mereka berhubungan untuk membentuk seluruh sistem. Setiap sistem
yang kompleks dapat dipartisi dalam banyak cara berbeda. Hal yang sama berlaku
untuk sistem-tidak ada struktur yang unik dari sistem.
Karena kemungkinan ini memiliki
beberapa struktur, salah satu definisi yang paling banyak diterima dari
arsitektur perangkat lunak adalah bahwa arsitektur perangkat lunak sistem
adalah struktur dari sistem, yang terdiri software el-ements, sifat eksternal
terlihat dari hubungan
mereka.
Deskripsi arsitektur sistem karena itu akan menggambarkan di perubahan struktur dari sistem. Pertanyaan alami berikutnya adalah mengapa harus tim membangun sistem perangkat lunak untuk beberapa pelanggan tertarik dalam menciptakan dan mendokumentasikan struktur dari sistem yang diusulkan.beberapa penting kegunaan software arsitektur:
Deskripsi arsitektur sistem karena itu akan menggambarkan di perubahan struktur dari sistem. Pertanyaan alami berikutnya adalah mengapa harus tim membangun sistem perangkat lunak untuk beberapa pelanggan tertarik dalam menciptakan dan mendokumentasikan struktur dari sistem yang diusulkan.beberapa penting kegunaan software arsitektur:
1. Memahami dan
komunikasi. Deskripsi arsitektur adalah utamanya untuk
berkomunikasi arsitektur untuk berbagai pemangku kepentingan, yang di-clude
pengguna yang akan menggunakan sistem, klien yang ditugaskan sistem, pembangun
yang akan membangun sistem, dan, tentu saja. Melalui penjelasan ini para
pemangku kepentingan memperoleh pemahaman tentang beberapa sifat makro dari
sistem dan bagaimana sistem bermaksud untuk mengisi persyaratan fungsional dan
kualitas.
2. Reuse. Jika
seseorang ingin membangun sebuah produk perangkat lunak di mana komponen yang
ada dapat digunakan kembali, maka arsitektur menjadi titik kunci. arsitektur harus mepilih sedemikian rupa bahwa komponen
yang harus digunakan kembali dapat cocok dengan baik dan bersama-sama dengan
komponen lain yang dapat dikembangkan. Arsitektur juga facili-tates menggunakan
kembali antara produk-produk yang keluarga produk serupa dan bangunan sehingga
bagian-bagian umum ini di berbeda tetapi produk serupa dapat digunakan kembali
3. Konstruksi dan
Evolution. Arsitektur partisi sistem menjadi bagian-bagian, beberapa partisi
arsitektur yang disediakan dapat digunakan secara alami untuk membangun sistem,
yang juga mensyaratkan bahwa sistem akan dipecah menjadi bagian-bagian sehingga
tim secara terpisah dapat bekerja pada bagian berbeda. bagian-bagian
yang ditentukan dalam arsitektur relatif indepen-dent (ketergantungan antara
bagian-bagian yang datang melalui hubungan mereka), mereka dapat dibangun
secara mandiri.
4. Analisis. Hal
ini sangat diinginkan jika dapat ditentukan beberapa sifat penting tentang tingkahlaku dari sistem
sebelum sistem ini benar-benar dibangun. Hal ini akan memungkinkan para
desainer untuk mempertimbangkan alternatif dan memilih salah satu yang terbaik
akan sesuai dengan kebutuhan. Dalam beberapa
proyek komunikasi mungkin sangat penting, tapi analisis kinerja rinci mungkin
tidak diperlukan (karena sistem yang terlalu kecil atau dimaksudkan untuk hanya
beberapa pengguna). Dalam beberapa sistem lain, analisis kinerja mungkin
penggunaan utama arsitektur.
5.2 Arsitektur Views
Dalam pandangan modul, sistem ini
dipandang sebagai kumpulan unit kode, masing-masing menerapkan beberapa bagian
dari fungsi sistem. Artinya, unsur-unsur utama dalam pandangan ini adalah
modul. pandangan-pandangan ini adalah kode-based dan tidak secara eksplisit rep-membenci
setiap struktur runtime dari sistem. Contoh modul paket, kelas, prosedur,
metode, koleksi fungsi, dan koleksi kelas. Hubungan antara modul ini juga
berbasis kode dan tentang bagaimana kode modul berinteraksi dengan modul lain.
Contoh hubungan dalam pandangan ini (yaitu, modul B adalah bagian dari modul A)
atau tergantung pada modul A menggunakan jasa dari modul B untuk melakukan
fungsi dan kebenaran modul sendiri sebuah tergantung pada kebenaran modul B dan
generalisasi atau spesialisasi (modul B adalah generalisasi dari modul A).
Dalam komponen dan konektor sistem ini dipandang sebagai pembacaan entitas runtime Artinya, komponen adalah unit yang memiliki identitas dalam sistem mengeksekusi. Objects adalah sebuah kolektifitas benda, dan proses adalah contoh dari komponen. Sementara pelaksana adalah komponen yang harus berinteraksi dengan orang lain untuk mendukung layanan sistem. Konektor menyediakan sarana untuk interaksi ini. Contoh konektor pipa dan soket. Data juga dapat bertindak sebagai konektor. Jika komponen menggunakan beberapa middleware untuk berkomunikasi dan berkoordinasi, maka middleware adalah konektor. Oleh karena itu, unsur-unsur utama dari pandangan ini adalah komponen dan konektor.
Pandangan alokasi berfokus pada bagaimana unit software erent dialokasikan ke sumber daya seperti perangkat keras, sistem file, dan orang-orang. Artinya, pandangan alokasi menentukan hubungan antara unsur-unsur perangkat lunak dan elemen lingkungan di mana sistem perangkat lunak dijalankan. Mereka mengekspos sifat struktural seperti dimana proses berjalan pada prosesor mana, dan bagaimana file sistem diatur pada sistem file.
Deskripsi arsitektur terdiri dari pandangan jenis dengan setiap tampilan mengekspos beberapa struktur dari sistem. views modul menunjukkan bagaimana peranti lunak ini disusun sebagai satu set unit implementasi, C & C views menunjukkan bagaimana perangkat lunak ini disusun sebagai berinteraksi elemen runtime, dan pandangan alokasi menunjukkan bagaimana perangkat lunak berhubungan dengan struktur nonsoftware. Ketiga jenis pandang sistem yang sama membentuk arsitektur sistem.
Perhatikan bahwa pandangan tersebut tidak berhubungan. Mereka semua merupakan sistem yang sama. Oleh karena itu, ada hubungan antara unsur-unsur dalam satu tampilan dan dalam pandangan lain. Hubungan ini mungkin sederhana atau mungkin rumit.
Misalnya, hubungan antara modul dan komponen mungkin menjadi satu dalam satu modul mengimplementasikan dalam salah satu komponen. Di sisi lain, mungkin cukup kompleks dengan modul yang digunakan oleh beberapa komponen, dan komponen menggunakan beberapa modul. Sekaligus menciptakan tampilan dan para desainer harus menyadari hubungan ini.
Pertanyaan berikutnya adalah apakah pandangan standar yang harus diungkapkan untuk menggambarkan arsitektur sistem? Untuk menjawab pertanyaan ini, analogi dengan bangunan dapat lagi membantu. Jika seseorang membangun sebuah rumah kecil yang sederhana, maka mungkin tidak ada kebutuhan untuk memiliki pandangan yang terpisah menjelaskan darurat dan sistem kebakaran. Demikian pula, jika tidak ada AC di gedung, ada perlu tidak pandangan untuk itu. Di sisi lain, sebuah bangunan mungkin akan membutuhkan kedua pandangan ini, selain tampilan lain menggambarkan pipa, ruang, kabel, dll
Namun, meskipun fakta bahwa ada beberapa gambar yang menunjukkan tampila bangunan, ada satu pandangan yang mendominasi dalam konstruksi-yang struktur fisik. Pandangan ini membentuk dasar dari tampilan lain dalam bahwa pandangan lain dapat benar-benar diselesaikan kecuali pandangan ini bisa dilakukan. pandangan lain mungkin atau mungkin tidak diperlukan untuk membangun sebuah bangunan, tergantung pada sifat proyek. Oleh karena itu, dalam arti, pandangan memberikan struktur bangunan dapat dianggap sebagai pandangan utama dalam hal itu hampir selalu digunakan, dan tampilan lain bergantung pada pandangan ini secara substansial. Pandangan juga menangkap mungkin properti yang paling penting untuk dianalisis pada tahap awal, yaitu bahwa organisasi ruang.
Situasi dengan arsitektur perangkat lunak juga agak mirip. Namun, pandangan ini telah menjadi pandangan de facto utama dan salah satu yang hampir selalu siap ketika arsitektur dirancang.
Catatan tentang hubungan antara arsitektur dan desain adalah dalam rangka. Sebagai partisi sistem menjadi bagian-bagian yang lebih kecil dan menyusun sistem dari bagian-bagian ini juga merupakan tujuan dari desain. Ini bertujuan untuk mencapai tujuan yang sama dan tampaknya fundamental mengandalkan membagi dan menaklukkan aturan. Pertama, harus jelas bahwa arsitektur adalah desain dalam hal itu adalah dalam domain solusi dan berbicara tentang struktur dari sistem yang diusulkan. Selanjutnya, pandangan arsitektur memberikan tampilan tingkat tinggi dari sistem.
Dalam komponen dan konektor sistem ini dipandang sebagai pembacaan entitas runtime Artinya, komponen adalah unit yang memiliki identitas dalam sistem mengeksekusi. Objects adalah sebuah kolektifitas benda, dan proses adalah contoh dari komponen. Sementara pelaksana adalah komponen yang harus berinteraksi dengan orang lain untuk mendukung layanan sistem. Konektor menyediakan sarana untuk interaksi ini. Contoh konektor pipa dan soket. Data juga dapat bertindak sebagai konektor. Jika komponen menggunakan beberapa middleware untuk berkomunikasi dan berkoordinasi, maka middleware adalah konektor. Oleh karena itu, unsur-unsur utama dari pandangan ini adalah komponen dan konektor.
Pandangan alokasi berfokus pada bagaimana unit software erent dialokasikan ke sumber daya seperti perangkat keras, sistem file, dan orang-orang. Artinya, pandangan alokasi menentukan hubungan antara unsur-unsur perangkat lunak dan elemen lingkungan di mana sistem perangkat lunak dijalankan. Mereka mengekspos sifat struktural seperti dimana proses berjalan pada prosesor mana, dan bagaimana file sistem diatur pada sistem file.
Deskripsi arsitektur terdiri dari pandangan jenis dengan setiap tampilan mengekspos beberapa struktur dari sistem. views modul menunjukkan bagaimana peranti lunak ini disusun sebagai satu set unit implementasi, C & C views menunjukkan bagaimana perangkat lunak ini disusun sebagai berinteraksi elemen runtime, dan pandangan alokasi menunjukkan bagaimana perangkat lunak berhubungan dengan struktur nonsoftware. Ketiga jenis pandang sistem yang sama membentuk arsitektur sistem.
Perhatikan bahwa pandangan tersebut tidak berhubungan. Mereka semua merupakan sistem yang sama. Oleh karena itu, ada hubungan antara unsur-unsur dalam satu tampilan dan dalam pandangan lain. Hubungan ini mungkin sederhana atau mungkin rumit.
Misalnya, hubungan antara modul dan komponen mungkin menjadi satu dalam satu modul mengimplementasikan dalam salah satu komponen. Di sisi lain, mungkin cukup kompleks dengan modul yang digunakan oleh beberapa komponen, dan komponen menggunakan beberapa modul. Sekaligus menciptakan tampilan dan para desainer harus menyadari hubungan ini.
Pertanyaan berikutnya adalah apakah pandangan standar yang harus diungkapkan untuk menggambarkan arsitektur sistem? Untuk menjawab pertanyaan ini, analogi dengan bangunan dapat lagi membantu. Jika seseorang membangun sebuah rumah kecil yang sederhana, maka mungkin tidak ada kebutuhan untuk memiliki pandangan yang terpisah menjelaskan darurat dan sistem kebakaran. Demikian pula, jika tidak ada AC di gedung, ada perlu tidak pandangan untuk itu. Di sisi lain, sebuah bangunan mungkin akan membutuhkan kedua pandangan ini, selain tampilan lain menggambarkan pipa, ruang, kabel, dll
Namun, meskipun fakta bahwa ada beberapa gambar yang menunjukkan tampila bangunan, ada satu pandangan yang mendominasi dalam konstruksi-yang struktur fisik. Pandangan ini membentuk dasar dari tampilan lain dalam bahwa pandangan lain dapat benar-benar diselesaikan kecuali pandangan ini bisa dilakukan. pandangan lain mungkin atau mungkin tidak diperlukan untuk membangun sebuah bangunan, tergantung pada sifat proyek. Oleh karena itu, dalam arti, pandangan memberikan struktur bangunan dapat dianggap sebagai pandangan utama dalam hal itu hampir selalu digunakan, dan tampilan lain bergantung pada pandangan ini secara substansial. Pandangan juga menangkap mungkin properti yang paling penting untuk dianalisis pada tahap awal, yaitu bahwa organisasi ruang.
Situasi dengan arsitektur perangkat lunak juga agak mirip. Namun, pandangan ini telah menjadi pandangan de facto utama dan salah satu yang hampir selalu siap ketika arsitektur dirancang.
Catatan tentang hubungan antara arsitektur dan desain adalah dalam rangka. Sebagai partisi sistem menjadi bagian-bagian yang lebih kecil dan menyusun sistem dari bagian-bagian ini juga merupakan tujuan dari desain. Ini bertujuan untuk mencapai tujuan yang sama dan tampaknya fundamental mengandalkan membagi dan menaklukkan aturan. Pertama, harus jelas bahwa arsitektur adalah desain dalam hal itu adalah dalam domain solusi dan berbicara tentang struktur dari sistem yang diusulkan. Selanjutnya, pandangan arsitektur memberikan tampilan tingkat tinggi dari sistem.
5.3 Komponen dan
Konektor view
Batas-batas antara arsitektur
dan desain tingkat tinggi tidak sepenuhnya jelas. Pada tingkat arsitektur,
salah satu kebutuhan untuk hanya menampilkan bagian-bagian yang diperlukan untuk
melakukan evaluasi yang diinginkan. Struktur internal bagian-bagian ini tidak
penting. Di sisi lain selama desain merancang struktur bagian-bagian. Namun, bagian mana dari struktur harus
diperiksa
terlebih dahulu. Dan arsitektur,desain adalah masalah pilihan. Secara
umum, detail yang tidak diperlukan untuk melakukan jenis analisis yang ingin
kita lakukan pada saat arsitektur yang tidak perlu dan harus dibiarkan untuk
desain.
Arsitektur sistem memiliki dua elemen utama yaitu,komponen dan konektor. Komponen biasanya elemen komputasi atau toko data yang memiliki beberapa kehadiran selama pelaksanaan sistem. Konektor menentukan sarana interaksi antara komponen-komponen ini. pandangan sistem dan komponen yang terhubung ke mana dan melalui konektor apa. Struktur pada dasarnya adalah sebuah grafik, dengan motivasional sebagai node dan konektor sebagai tepi.
Arsitektur sistem memiliki dua elemen utama yaitu,komponen dan konektor. Komponen biasanya elemen komputasi atau toko data yang memiliki beberapa kehadiran selama pelaksanaan sistem. Konektor menentukan sarana interaksi antara komponen-komponen ini. pandangan sistem dan komponen yang terhubung ke mana dan melalui konektor apa. Struktur pada dasarnya adalah sebuah grafik, dengan motivasional sebagai node dan konektor sebagai tepi.
5.3.1 Komponen
5.1 Contoh komponen
Komponen adalah dari jenis komponen, di
mana jenis merupakan komponen generik, mendefinisikan komputasi umum dan
interface komponen dari jenis yang harus memiliki. Perhatikan bahwa meskipun
komponen memiliki tipe, di C & C tampilan arsitektur, kita memiliki
komponen (yaitu, contoh aktual) dan tidak jenis. Contoh jenis ini adalah klien,
server, filter, dll Di ff domain erent mungkin memiliki jenis generik lainnya
seperti kontroler, aktuator, dan sensor (untuk domain sistem kontrol).
Dalam diagram mewakili C & C lihat arsitektur sistem, itu sangat diinginkan untuk memiliki di ff erent representasi untuk jenis komponen di ff erent, sehingga jenis erent di ff dapat diidentifikasi secara visual. Dalam diagram kotak-dan-line, sering semua komponen yang direpresentasikan sebagai kotak persegi panjang. Pendekatan seperti ini akan mengharuskan jenis komponen dijelaskan secara terpisah dan pembaca harus membaca deskripsi untuk mengetahui jenis-jenis komponen. Hal ini jauh lebih baik untuk menggunakan di ff erent simbol / notasi untuk setiap di ff jenis komponen erent. Beberapa simbol yang umum digunakan untuk mewakili jenis komponen umum ditemukan ditunjukkan pada Gambar 5.1.
Dalam diagram mewakili C & C lihat arsitektur sistem, itu sangat diinginkan untuk memiliki di ff erent representasi untuk jenis komponen di ff erent, sehingga jenis erent di ff dapat diidentifikasi secara visual. Dalam diagram kotak-dan-line, sering semua komponen yang direpresentasikan sebagai kotak persegi panjang. Pendekatan seperti ini akan mengharuskan jenis komponen dijelaskan secara terpisah dan pembaca harus membaca deskripsi untuk mengetahui jenis-jenis komponen. Hal ini jauh lebih baik untuk menggunakan di ff erent simbol / notasi untuk setiap di ff jenis komponen erent. Beberapa simbol yang umum digunakan untuk mewakili jenis komponen umum ditemukan ditunjukkan pada Gambar 5.1.
5.3.2 Konektor
5.2 Contoh konektor
Komponen erent di ff dari sistem
cenderung berinteraksi sementara sistem dalam operasi untuk menyediakan layanan
yang diharapkan dari sistem. Interaksi antar komponen dapat melalui cara
sederhana yang didukung oleh infrastruktur pelaksanaan proses yang mendasari
sistem operasi. Misalnya, komponen dapat berinteraksi dengan yang lain
menggunakan mekanisme panggilan prosedur (konektor), yang disediakan oleh
lingkungan runtime untuk bahasa pemrograman. Namun, interaksi mungkin
melibatkan mekanisme yang lebih kompleks juga. Contoh mekanisme seperti
panggilan prosedur jauh, port TCP / IP, dan protokol seperti HTTP. Beberapa
simbol yang umum digunakan untuk mewakili jenis konektor yang biasa ditemukan
ditunjukkan pada Gambar 5.2.
Sebuah konektor juga memiliki nama yang harus menggambarkan sifat interaksi konektor mendukung. Perlu menunjukkan bahwa pelaksanaan konektor mungkin cukup kompleks. Jika konektor disediakan oleh sistem yang mendasari, maka komponen hanya perlu memastikan bahwa mereka menggunakan konektor sesuai spesifikasi mereka. Namun, jika sistem yang mendasarinya tidak menyediakan konektor yang digunakan dalam arsitektur, maka seperti disebutkan di atas, konektor harus dilaksanakan sebagai bagian dari proyek untuk membangun sistem. Artinya, selama pengembangan, tidak hanya akan komponen perlu dikembangkan, tetapi sumber daya harus ditugaskan untuk juga mengembangkan konektor. (Situasi ini mungkin timbul karena sistem khusus yang membutuhkan konektor yang khusus untuk masalah domain.) Secara umum, sekaligus menciptakan arsitektur, adalah bijaksana untuk arsitek untuk menggunakan konektor yang tersedia pada sistem di mana perangkat lunak akan dikerahkan.
Sebuah konektor juga memiliki nama yang harus menggambarkan sifat interaksi konektor mendukung. Perlu menunjukkan bahwa pelaksanaan konektor mungkin cukup kompleks. Jika konektor disediakan oleh sistem yang mendasari, maka komponen hanya perlu memastikan bahwa mereka menggunakan konektor sesuai spesifikasi mereka. Namun, jika sistem yang mendasarinya tidak menyediakan konektor yang digunakan dalam arsitektur, maka seperti disebutkan di atas, konektor harus dilaksanakan sebagai bagian dari proyek untuk membangun sistem. Artinya, selama pengembangan, tidak hanya akan komponen perlu dikembangkan, tetapi sumber daya harus ditugaskan untuk juga mengembangkan konektor. (Situasi ini mungkin timbul karena sistem khusus yang membutuhkan konektor yang khusus untuk masalah domain.) Secara umum, sekaligus menciptakan arsitektur, adalah bijaksana untuk arsitek untuk menggunakan konektor yang tersedia pada sistem di mana perangkat lunak akan dikerahkan.
5.4
Gaya Arsitektur untuk C & C View
5.4.1 Pipa dan Filter
Pipa-dan-filter bergaya arsitektur
cocok untuk sistem yang terutama melakukan transformasi data dan tujuan dari
sistem ini adalah untuk menghasilkan beberapa data output dengan sesuai
mengubah input data. Sebuah filter mungkin memiliki lebih dari satu input dan
lebih dari satu output. Filter tidak perlu tahu identitas dari filter yang
mengirim input data atau identitas filter yang akan mengkonsumsi data yang
mereka hasilkan .
5.4.2 Data
Bersama Style
Ada dua variasi dari gaya ini. Dalam
gaya papan, jika beberapa data yang diposting di repositori data, semua
komponen accessor yang perlu tahu tentang hal itu diinformasikan. Dalam
database, bentuk gaya sering didukung melalui pemicu. Yang lain adalah gaya
repositori, dimana penyimpanan data hanya repositori pasif yang menyediakan
penyimpanan permanen dan kontrol terkait untuk mengakses data.
Banyak aplikasi database menggunakan gaya arsitektur ini. Banyak sistem Web sering mengikuti gaya ini di back end-dalam menanggapi permintaan pengguna, script erent di ff (accesor data) akses dan memperbarui beberapa data bersama.
Sebagai contoh sistem yang menggunakan gaya arsitektur, mari kita perhatikan sistem pendaftaran mahasiswa di sebuah universitas. Sistem ini jelas memiliki repositori pusat yang berisi informasi tentang kursus, siswa, prasyarat, dll memiliki komponen Administrator yang menentukan repositori, hak untuk di ff erent orang, dll Komponen Pendaftaran memungkinkan siswa untuk reg-ister dan memperbarui informasi bagi siswa dan kursus. Komponen Persetujuan adalah untuk memberikan persetujuan bagi mereka program yang membutuhkan persetujuan instruktur. Komponen Laporan menghasilkan laporan mengenai siswa yang terdaftar di program erent di ff pada akhir pendaftaran. Komponen Course Feedback digunakan untuk mengambil umpan balik dari siswa pada akhir kursus. Arsitektur ini ditunjukkan pada Gambar 5.7.
Banyak aplikasi database menggunakan gaya arsitektur ini. Banyak sistem Web sering mengikuti gaya ini di back end-dalam menanggapi permintaan pengguna, script erent di ff (accesor data) akses dan memperbarui beberapa data bersama.
Sebagai contoh sistem yang menggunakan gaya arsitektur, mari kita perhatikan sistem pendaftaran mahasiswa di sebuah universitas. Sistem ini jelas memiliki repositori pusat yang berisi informasi tentang kursus, siswa, prasyarat, dll memiliki komponen Administrator yang menentukan repositori, hak untuk di ff erent orang, dll Komponen Pendaftaran memungkinkan siswa untuk reg-ister dan memperbarui informasi bagi siswa dan kursus. Komponen Persetujuan adalah untuk memberikan persetujuan bagi mereka program yang membutuhkan persetujuan instruktur. Komponen Laporan menghasilkan laporan mengenai siswa yang terdaftar di program erent di ff pada akhir pendaftaran. Komponen Course Feedback digunakan untuk mengambil umpan balik dari siswa pada akhir kursus. Arsitektur ini ditunjukkan pada Gambar 5.7.
Perhatikan diagram diatas, bahwa komponen
perhitungan yang berbeda tidak perlu berkomunikasi dengan satu sama lain dan
bahkan tidak perlu tahu tentang keberadaan masing-masing.
Misalnya, jika kemudian diputuskan
bahwa penjadwalan kursus bisa otomatis berdasarkan data pada pendaftaran (dan informasi lain
tentang ruang kelas dll), maka komponen lain yang disebut Penjadwalan hanya dapat menambahkan.
Ada satu jenis konektor dalam gaya ini, baca / tulis. Perhatikan bagaimana gaya konektor umum dapat mengambil bentuk yang lebih tepat dalam arsitektur tertentu. Misalnya,database dapat dilihat sebagai pendukung membaca dan update untuk program berinteraksi. Namun, sistem database dapat pula memberikan transaksi layanan. .
Perhatikan juga bahwa dalam banyak kasus lainnya, konektor melibatkan pertimbangan jumlah infrastruktur yang mendasarinya. Misalnya, membaca dan menulis ke sistem file melibatkan cukup banyak perangkat lunak sistem file yang melibatkan seperti direktori, buffering,penguncian, dan sinkronisasi. Demikian pula, banyak software masuk ke database untuk mendukung jenis koneksi, seperti menyediakanquery, update, dan transaksi.
Ada satu jenis konektor dalam gaya ini, baca / tulis. Perhatikan bagaimana gaya konektor umum dapat mengambil bentuk yang lebih tepat dalam arsitektur tertentu. Misalnya,database dapat dilihat sebagai pendukung membaca dan update untuk program berinteraksi. Namun, sistem database dapat pula memberikan transaksi layanan. .
Perhatikan juga bahwa dalam banyak kasus lainnya, konektor melibatkan pertimbangan jumlah infrastruktur yang mendasarinya. Misalnya, membaca dan menulis ke sistem file melibatkan cukup banyak perangkat lunak sistem file yang melibatkan seperti direktori, buffering,penguncian, dan sinkronisasi. Demikian pula, banyak software masuk ke database untuk mendukung jenis koneksi, seperti menyediakanquery, update, dan transaksi.
5.4.3 Gaya Server Klien
Gaya lain yang sangat umum digunakan
untuk membangun sistem saat ini adalah gaya client-server. Server komputasi
client adalah salah satu paradigma dasar komputasi terdistribusi.
Dalam gaya ini, ada dua komponen, yaitu klien dan server. Kendala dari gaya ini adalah bahwa klien hanya dapat berkomunikasi dengan server, dan tidak dapat berkomunikasi dengan klien lainnya. Komunikasi antara komponen klien dan komponen server diprakarsai oleh klien ketika klien mengirimkan permintaan untuk beberapa layanan yang dimana server mendukung. server menerima permintaan,mendefinisikan, melakukan layanan, dan kemudian mengembalikan hasil perhitungan kepada klien yang meminta layanan.
Ada satu jenis konektor dalam gaya ini. Sebuah konektor menghubungkan klien ke server. Jenis konektor asimetris akhir klien (end clien) konektor hanya dapat membuat permintaan (dan menerima balasan), sedangkan akhir server (end server) hanya dapat mengirim balasan dalam menanggapi permintaan itumelalui konektor ini. komunikasi sering sinkron, klien menunggu servermembawa hasil sebelum melanjutkan. Artinya, klien diblokir atas permintaan, sampai mendapatkan jawabannya.
Dalam gaya ini, ada dua komponen, yaitu klien dan server. Kendala dari gaya ini adalah bahwa klien hanya dapat berkomunikasi dengan server, dan tidak dapat berkomunikasi dengan klien lainnya. Komunikasi antara komponen klien dan komponen server diprakarsai oleh klien ketika klien mengirimkan permintaan untuk beberapa layanan yang dimana server mendukung. server menerima permintaan,mendefinisikan, melakukan layanan, dan kemudian mengembalikan hasil perhitungan kepada klien yang meminta layanan.
Ada satu jenis konektor dalam gaya ini. Sebuah konektor menghubungkan klien ke server. Jenis konektor asimetris akhir klien (end clien) konektor hanya dapat membuat permintaan (dan menerima balasan), sedangkan akhir server (end server) hanya dapat mengirim balasan dalam menanggapi permintaan itumelalui konektor ini. komunikasi sering sinkron, klien menunggu servermembawa hasil sebelum melanjutkan. Artinya, klien diblokir atas permintaan, sampai mendapatkan jawabannya.
Sebuah
bentuk umum dari gaya ini adalah struktur N-Tier. Dalam gaya ini, klien mengirimkan permintaan ke server, tetapi server hanya untuk melayani permintaan
dan mengirim beberapa permintaan ke server lain.
Server juga bertindak sebagai klien untuk tingkat
berikutnya. Sebuah contoh umum ini adalah arsitektur 3-Tier. Dalam gaya ini, klien yang membuat permintaan dan
menerima hasil akhir berada di tingkat client. Tingkat menengah
yaitu tier bisnis, mengandung komponen yang memproses data yang diajukan
oleh klien dan menerapkan aturan bisnis yang diperlukan. Tingkat ketiga adalah tingkat
basis data di mana data berada.
Dalam arsitektur client-server, klien dan komponen server berada pada mesin yang berbeda.Oleh karena itu, konektor antara klien dan server diharapkan untuk mendukung jenis permintaan / hasil dari hubungan di mesin yang berbeda. Akibatnya, konektor ini secara internal cukup kompleks dan melibatkan cukup banyak jaringan untuk mendukung. Banyak sistem client server saat port digunakan TCP untuk konektornya. Web menggunakan HTTP untuk mendukung konektor ini.
Ada perbedaan antara arsitektur berlapis dan arsitektur berjenjang. Gaya berjenjang adalah komponen dan konektor tampilan arsitektur di mana setiap tier adalah komponen, dan komponen-komponen ini berkomunikasi dengan orang-orang yang berdekatan melalui protokol. Sebuah arsitektur berlapis adalah pandangan modul menyediakan bagaimana modul diatur dan digunakan.
Dalam arsitektur client-server, klien dan komponen server berada pada mesin yang berbeda.Oleh karena itu, konektor antara klien dan server diharapkan untuk mendukung jenis permintaan / hasil dari hubungan di mesin yang berbeda. Akibatnya, konektor ini secara internal cukup kompleks dan melibatkan cukup banyak jaringan untuk mendukung. Banyak sistem client server saat port digunakan TCP untuk konektornya. Web menggunakan HTTP untuk mendukung konektor ini.
Ada perbedaan antara arsitektur berlapis dan arsitektur berjenjang. Gaya berjenjang adalah komponen dan konektor tampilan arsitektur di mana setiap tier adalah komponen, dan komponen-komponen ini berkomunikasi dengan orang-orang yang berdekatan melalui protokol. Sebuah arsitektur berlapis adalah pandangan modul menyediakan bagaimana modul diatur dan digunakan.
5.4.4 Beberapa Gaya Lain
Publish Subscribe Style,dalam gaya ini ada dua jenis komponen.
Satu jenis komponen seperangkat
yang didefinisikan. Dan yang kedua compo-motivasional, menghasilkan atau mempublikasikan acara.Peer-to-peer
gaya, atau gaya berorientasi objek. Dalam gaya ini, komponen peer dan komponen komponen lain dapat meminta
layanan dari komponen lainnya. Model ini adalah salah satu yang didukung melalui konektor middleware
seperti CORBA atau NET.
5.5 Mendokumentasikan Desain Arsitektur
Sejauh ini kita telah berfokus pada pandangan melalui diagram. Ketika merancang berakhir, arsitektur
harus mengkomunikasikan
kepada seluruh stakeholder untuk negosiasidan kesepakatan. Arsitektur harus dengan tepat mendokumentasikaninformasi yang
cukup untuk melakukananalisis. Mendokumentasikan arsitektur itu sangat penting. Pada bagian
ini, kita akan
membahas
dokumen arsitektur.
Tanpa
penjelasan didokumentasikan dengan baik arsitektur, itu tidak mungkin untuk
memiliki pemahaman yang sama jelas. Oleh karena itu, benar mendokumentasikan
arsitektur adalah sama pentingnya dengan membuat satu diagram. Pada bagian ini,
kita membahas apa dokumen arsitektur harus berisi:
1. Sistem
dan konteks arsitektur
2. Melihat
deskripsi arsitektur
3. Across
views documentation
Sebuah
diagram konteks yang menetapkan ruang lingkup sistem, batas-batasnya, aktor
kunci yang berinteraksi dengan sistem, dan sumber dan tenggelam data juga bisa
sangat berguna. Sebuah diagram konteks sering diwakili dengan menunjukkan
sistem di tengah, dan menunjukkan hubungan dengan orang dan sistem, termasuk
sumber dan mengambil data. Dengan konteks didefinisikan, dokumen dapat
melanjutkan dengan menggambarkan struktur atau pandangan yg berbeda. Beberapa
tampilan dari jenis yg berbeda mungkin diperlukan, dan yang dilihat dipilih
tergantung pada kebutuhan proyek dan saham.
Dokumen
pendukung yang diperlukan untuk tampilan diagram. dokumen pendukung ini harus
memiliki beberapa atau semua hal berikut:
a. Elemen
Katalog. Memberikan informasi lebih lanjut tentang unsur-unsur yang ditampilkan
dalam representasi utama. Selain menjelaskan tujuan dari elemen, juga harus
menjelaskan antarmuka elemen '(ingat bahwa semua elemen memiliki antarmuka di
mana mereka berinteraksi dengan unsur-unsur lain). Semua antarmuka yang
disediakan oleh elemen harus dispesifikasikan. Interface harus memiliki
identitas yang unik, dan spesifikasi harus memberikan kedua informasi sintaksis
dan semantik. informasi sintaksis sering dalam hal tanda tangan, yang
menggambarkan semua item data yang terlibat dalam antarmuka dan jenis mereka.
informasi semantik harus menjelaskan apa antarmuka tidak. deskripsi juga harus
jelas menyatakan kondisi kesalahan bahwa antarmuka dapat kembali.
b. Arsitektur
Dasar pemikiran. Meskipun pandangan spesifik es elemen dan hubungan di antara
mereka, tidak memberikan wawasan ke dalam mengapa arsitek memilih struktur
tertentu. Arsitektur alasan memberikan alasan untuk memilih elemen erent di ff
dan menyusun mereka dengan cara itu dilakukan. Bagian ini juga dapat memberikan
beberapa diskusi tentang alternatif yang dipertimbangkan dan mengapa mereka
ditolak. Diskusi ini, selain menjelaskan pilihan, juga berguna kemudian ketika
seorang analis membuat perubahan bertanya-tanya mengapa arsitektur tidak harus
diubah dalam beberapa cara (yang mungkin bisa membuat perubahan mudah).
c. Tingkah
laku. Pandangan memberikan informasi struktural. Tidak mewakili perilaku aktual
atau eksekusi. Akibatnya, dalam struktur, semua interaksi yang mungkin selama
eksekusi akan ditampilkan. Kadang-kadang, perlu untuk mendapatkan beberapa
gagasan tentang perilaku aktual dari sistem dalam beberapa skenario. seperti
deskripsi berguna untuk berdebat tentang sifat seperti kebuntuan. deskripsi
perilaku dapat diberikan untuk membantu pemahaman bantuan eksekusi sistem.
Sering diagram seperti diagram kolaborasi atau urutan diagram (kita akan
membahas ini lebih lanjut dalam Bab 6 tentang desain OO) digunakan.
d. Informasi
lainnya. Ini mungkin termasuk keterangan tentang semua keputusan-keputusan yang
belum diambil selama pembuatan arsitektur tetapi telah sengaja untuk masa
depan, seperti, pilihan server atau protokol. Jika ini dilakukan, maka harus
dispesifikasikan sebagai fi xing ini akan memiliki dampak pada arsitektur.
Menggabungkan
pandangan, bagaimanapun, harus dilakukan hanya jika hubungan antara pandangan
kuat dan mudah. Jika tidak, menempatkan beberapa pandangan dalam satu diagram
akan mengacaukan pandangan dan membuatnya membingungkan. Tujuan mengungkapkan
beberapa pandangan dalam satu bukan hanya untuk mengurangi jumlah tampilan,
tetapi harus dilakukan terutama untuk membantu pemahaman dan menunjukkan
hubungan.
Good job.
BalasHapus