Panduan Cepat

Arsitektur sistem menggambarkan komponen utamanya, hubungannya (struktur), dan bagaimana mereka berinteraksi satu sama lain. Arsitektur dan desain perangkat lunak mencakup beberapa faktor pendukung seperti strategi Bisnis, atribut kualitas, dinamika manusia, desain, dan lingkungan TI.

Kami dapat memisahkan Arsitektur dan Desain Perangkat Lunak menjadi dua fase berbeda: Arsitektur Perangkat Lunak dan Desain Perangkat Lunak. DiArchitecture, keputusan nonfungsional dibuat dan dipisahkan oleh persyaratan fungsional. Dalam Desain, persyaratan fungsional terpenuhi.

Arsitektur Perangkat Lunak

Arsitektur berfungsi sebagai a blueprint for a system. Ini memberikan abstraksi untuk mengelola kompleksitas sistem dan membangun mekanisme komunikasi dan koordinasi antar komponen.

  • Ini mendefinisikan a structured solution untuk memenuhi semua persyaratan teknis dan operasional, sekaligus mengoptimalkan atribut kualitas umum seperti kinerja dan keamanan.

  • Selanjutnya, ini melibatkan serangkaian keputusan penting tentang organisasi yang terkait dengan pengembangan perangkat lunak dan masing-masing keputusan ini dapat berdampak besar pada kualitas, pemeliharaan, kinerja, dan keberhasilan keseluruhan produk akhir. Keputusan ini terdiri dari -

    • Pemilihan elemen struktural dan antarmuka yang digunakan untuk menyusun sistem.

    • Perilaku seperti yang ditentukan dalam kolaborasi di antara elemen tersebut.

    • Komposisi elemen struktural dan perilaku tersebut menjadi subsistem yang besar.

    • Keputusan arsitektur selaras dengan tujuan bisnis.

    • Gaya arsitektur memandu organisasi.

Desain perangkat lunak

Desain perangkat lunak menyediakan a design planyang menjelaskan elemen-elemen sistem, bagaimana mereka cocok, dan bekerja sama untuk memenuhi kebutuhan sistem. Tujuan memiliki rencana desain adalah sebagai berikut -

  • Untuk menegosiasikan persyaratan sistem, dan untuk menetapkan harapan dengan pelanggan, pemasaran, dan personel manajemen.

  • Bertindak sebagai cetak biru selama proses pengembangan.

  • Pandu tugas implementasi, termasuk desain terperinci, pengkodean, integrasi, dan pengujian.

Itu datang sebelum desain rinci, pengkodean, integrasi, dan pengujian dan setelah analisis domain, analisis persyaratan, dan analisis risiko.

Tujuan Arsitektur

Tujuan utama dari arsitektur adalah untuk mengidentifikasi persyaratan yang mempengaruhi struktur aplikasi. Arsitektur yang tertata dengan baik mengurangi risiko bisnis yang terkait dengan pembangunan solusi teknis dan membangun jembatan antara persyaratan bisnis dan teknis.

Beberapa tujuan lainnya adalah sebagai berikut -

  • Ekspos struktur sistem, tetapi sembunyikan detail implementasinya.

  • Sadarilah semua kasus penggunaan dan skenario.

  • Cobalah untuk memenuhi kebutuhan berbagai pemangku kepentingan.

  • Tangani persyaratan fungsional dan kualitas.

  • Kurangi tujuan kepemilikan dan tingkatkan posisi pasar organisasi.

  • Meningkatkan kualitas dan fungsionalitas yang ditawarkan oleh sistem.

  • Meningkatkan kepercayaan eksternal baik dalam organisasi atau sistem.

Batasan

Arsitektur perangkat lunak masih merupakan disiplin ilmu yang muncul dalam rekayasa perangkat lunak. Ini memiliki batasan berikut -

  • Kurangnya alat dan cara standar untuk merepresentasikan arsitektur.

  • Kurangnya metode analisis untuk memprediksi apakah arsitektur akan menghasilkan implementasi yang memenuhi persyaratan.

  • Kurangnya kesadaran akan pentingnya desain arsitektur untuk pengembangan perangkat lunak.

  • Kurangnya pemahaman tentang peran arsitek perangkat lunak dan komunikasi yang buruk di antara para pemangku kepentingan.

  • Kurangnya pemahaman tentang proses desain, pengalaman desain dan evaluasi desain.

Peran Arsitek Perangkat Lunak

Arsitek Perangkat Lunak memberikan solusi yang dapat dibuat dan dirancang oleh tim teknis untuk seluruh aplikasi. Seorang arsitek perangkat lunak harus memiliki keahlian di bidang berikut -

Keahlian Desain

  • Ahli dalam desain perangkat lunak, termasuk beragam metode dan pendekatan seperti desain berorientasi objek, desain yang digerakkan oleh peristiwa, dll.

  • Pimpin tim pengembangan dan koordinasikan upaya pengembangan untuk integritas desain.

  • Harus dapat meninjau proposal desain dan tradeoff di antara mereka sendiri.

Keahlian Domain

  • Ahli dalam sistem yang sedang dikembangkan dan merencanakan evolusi perangkat lunak.

  • Membantu dalam proses investigasi kebutuhan, memastikan kelengkapan dan konsistensi.

  • Mengkoordinasikan definisi model domain untuk sistem yang dikembangkan.

Keahlian Teknologi

  • Ahli tentang teknologi yang tersedia yang membantu dalam implementasi sistem.

  • Mengkoordinasikan pemilihan bahasa pemrograman, framework, platform, database, dll.

Keahlian Metodologis

  • Ahli dalam metodologi pengembangan perangkat lunak yang dapat diadopsi selama SDLC (Software Development Life Cycle).

  • Pilih pendekatan yang tepat untuk pengembangan yang membantu seluruh tim.

Peran Tersembunyi Arsitek Perangkat Lunak

  • Memfasilitasi pekerjaan teknis di antara anggota tim dan memperkuat hubungan kepercayaan dalam tim.

  • Spesialis informasi yang berbagi pengetahuan dan memiliki pengalaman luas.

  • Lindungi anggota tim dari kekuatan eksternal yang akan mengganggu mereka dan mengurangi nilai proyek.

Kiriman Arsitek

  • Serangkaian tujuan fungsional yang jelas, lengkap, konsisten, dan dapat dicapai

  • Deskripsi fungsional sistem, dengan setidaknya dua lapisan dekomposisi

  • Konsep sistem

  • Desain dalam bentuk sistem, dengan setidaknya dua lapisan dekomposisi

  • Sebuah gagasan tentang waktu, atribut operator, dan rencana implementasi dan operasi

  • Dokumen atau proses yang memastikan dekomposisi fungsional diikuti, dan bentuk antarmuka dikontrol

Atribut Kualitas

Kualitas adalah ukuran keunggulan atau keadaan bebas dari kekurangan atau cacat. Atribut kualitas adalah properti sistem yang terpisah dari fungsionalitas sistem.

Menerapkan atribut kualitas memudahkan untuk membedakan sistem yang baik dari yang buruk. Atribut adalah faktor keseluruhan yang memengaruhi perilaku waktu proses, desain sistem, dan pengalaman pengguna.

Mereka dapat diklasifikasikan sebagai -

Atribut Kualitas Statis

Mencerminkan struktur sistem dan organisasi, yang terkait langsung dengan arsitektur, desain, dan kode sumber. Mereka tidak terlihat oleh pengguna akhir, tetapi mempengaruhi biaya pengembangan dan pemeliharaan, misalnya: modularitas, kemampuan pengujian, kemampuan pemeliharaan, dll.

Atribut Kualitas Dinamis

Merefleksikan perilaku sistem selama pelaksanaannya. Mereka secara langsung terkait dengan arsitektur sistem, desain, kode sumber, konfigurasi, parameter penerapan, lingkungan, dan platform.

Mereka terlihat oleh pengguna akhir dan ada saat runtime, misalnya throughput, ketahanan, skalabilitas, dll.

Skenario Kualitas

Skenario kualitas menentukan bagaimana mencegah kesalahan menjadi kegagalan. Mereka dapat dibagi menjadi enam bagian berdasarkan spesifikasi atributnya -

  • Source - Entitas internal atau eksternal seperti orang, perangkat keras, perangkat lunak, atau infrastruktur fisik yang menghasilkan stimulus.

  • Stimulus - Kondisi yang perlu diperhatikan saat masuk ke sistem.

  • Environment - Stimulus terjadi dalam kondisi tertentu.

  • Artifact - Seluruh sistem atau sebagian seperti prosesor, saluran komunikasi, penyimpanan persisten, proses, dll.

  • Response - Suatu aktivitas yang dilakukan setelah datangnya stimulus seperti mendeteksi kesalahan, memulihkan dari kesalahan, menonaktifkan sumber peristiwa, dll.

  • Response measure - Harus mengukur respon yang terjadi sehingga persyaratan dapat diuji.

Atribut Kualitas Umum

Tabel berikut mencantumkan atribut kualitas umum yang harus dimiliki arsitektur perangkat lunak -

Kategori Atribut Kualitas Deskripsi
Kualitas Desain Integritas Konseptual Mendefinisikan konsistensi dan koherensi dari keseluruhan desain. Ini termasuk cara komponen atau modul dirancang.
Pemeliharaan Kemampuan sistem untuk mengalami perubahan dengan tingkat kemudahan.
Dapat digunakan kembali Mendefinisikan kemampuan komponen dan subsistem agar sesuai untuk digunakan dalam aplikasi lain.
Kualitas Run-time Interoperabilitas Kemampuan suatu sistem atau sistem yang berbeda untuk beroperasi dengan sukses dengan mengkomunikasikan dan bertukar informasi dengan sistem eksternal lain yang ditulis dan dijalankan oleh pihak eksternal.
Pengelolaan Menentukan seberapa mudah bagi administrator sistem untuk mengelola aplikasi.
Keandalan Kemampuan sistem untuk tetap beroperasi dari waktu ke waktu.
Skalabilitas Kemampuan sistem untuk menangani peningkatan beban tanpa memengaruhi kinerja sistem atau kemampuan untuk segera diperbesar.
Keamanan Kemampuan sistem untuk mencegah tindakan berbahaya atau tidak disengaja di luar penggunaan yang dirancang.
Performa Indikasi daya tanggap sistem untuk menjalankan tindakan apa pun dalam interval waktu tertentu.
Ketersediaan Menentukan proporsi waktu sistem berfungsi dan berfungsi. Ini dapat diukur sebagai persentase dari total waktu henti sistem selama periode yang telah ditentukan.
Kualitas Sistem Dukungan Kemampuan sistem untuk memberikan informasi berguna untuk mengidentifikasi dan menyelesaikan masalah jika gagal bekerja dengan benar.
Testabilitas Mengukur seberapa mudahnya membuat kriteria pengujian untuk sistem dan komponennya.
Kualitas Pengguna Kegunaan Mendefinisikan seberapa baik aplikasi memenuhi persyaratan pengguna dan konsumen dengan menjadi intuitif.
Kualitas Arsitektur Ketepatan Akuntabilitas untuk memenuhi semua persyaratan sistem.
Kualitas Non-runtime Portabilitas Kemampuan sistem untuk berjalan di bawah lingkungan komputasi yang berbeda.
Keutuhan Kemampuan untuk membuat komponen sistem yang dikembangkan secara terpisah bekerja sama dengan benar.
Modifikasi Kemudahan setiap sistem perangkat lunak dapat mengakomodasi perubahan pada perangkat lunaknya.
Atribut kualitas bisnis Biaya dan jadwal Biaya sistem sehubungan dengan waktu ke pasar, masa pakai proyek yang diharapkan & pemanfaatan warisan.
Daya jual Penggunaan sistem sehubungan dengan persaingan pasar.

Arsitektur perangkat lunak dideskripsikan sebagai organisasi dari suatu sistem, di mana sistem tersebut mewakili sekumpulan komponen yang menyelesaikan fungsi yang ditentukan.

Gaya arsitektur

Itu architectural style, juga disebut sebagai architectural pattern, adalah sekumpulan prinsip yang membentuk sebuah aplikasi. Ini mendefinisikan kerangka abstrak untuk suatu keluarga sistem dalam hal pola organisasi struktural.

Gaya arsitektur bertanggung jawab untuk -

  • Berikan leksikon komponen dan konektor dengan aturan tentang bagaimana mereka dapat digabungkan.

  • Tingkatkan partisi dan izinkan penggunaan kembali desain dengan memberikan solusi untuk masalah yang sering terjadi.

  • Jelaskan cara tertentu untuk mengonfigurasi kumpulan komponen (modul dengan antarmuka yang terdefinisi dengan baik, dapat digunakan kembali, dan dapat diganti) dan konektor (hubungan komunikasi antar modul).

Perangkat lunak yang dibangun untuk sistem berbasis komputer menunjukkan salah satu dari banyak gaya arsitektur. Setiap gaya menjelaskan kategori sistem yang meliputi -

  • Seperangkat tipe komponen yang menjalankan fungsi yang dibutuhkan oleh sistem.

  • Seperangkat konektor (panggilan subrutin, panggilan prosedur jarak jauh, aliran data, dan soket) yang memungkinkan komunikasi, koordinasi, dan kerja sama di antara berbagai komponen.

  • Batasan semantik yang menentukan bagaimana komponen dapat diintegrasikan untuk membentuk sistem.

  • Tata letak topologi dari komponen yang menunjukkan keterkaitan waktu proses mereka.

Desain Arsitektur Umum

Tabel berikut mencantumkan gaya arsitektur yang dapat diatur menurut area fokus utamanya -

Kategori Desain arsitektur Deskripsi
Komunikasi Bus pesan Menjelaskan penggunaan sistem perangkat lunak yang dapat menerima dan mengirim pesan menggunakan satu atau lebih saluran komunikasi.
Arsitektur Berorientasi Layanan (SOA) Mendefinisikan aplikasi yang mengekspos dan menggunakan fungsionalitas sebagai layanan menggunakan kontrak dan pesan.
Penyebaran Server klien Pisahkan sistem menjadi dua aplikasi, di mana klien membuat permintaan ke server.
3-tier atau N-tier Memisahkan fungsionalitas menjadi segmen terpisah dengan setiap segmen menjadi tingkatan yang terletak di komputer terpisah secara fisik.
Domain Desain Berbasis Domain Berfokus pada pemodelan domain bisnis dan mendefinisikan objek bisnis berdasarkan entitas dalam domain bisnis.
Struktur Berbasis Komponen Uraikan desain aplikasi menjadi komponen fungsional atau logis yang dapat digunakan kembali yang mengekspos antarmuka komunikasi yang terdefinisi dengan baik.
Berlapis Bagilah masalah aplikasi ke dalam kelompok bertumpuk (lapisan).
Berorientasi pada objek Berdasarkan pembagian tanggung jawab suatu aplikasi atau sistem menjadi objek, masing-masing berisi data dan perilaku yang relevan dengan objek tersebut.

Jenis Arsitektur

Ada empat jenis arsitektur dari sudut pandang suatu perusahaan dan secara kolektif, arsitektur ini disebut sebagai enterprise architecture.

  • Business architecture - Mendefinisikan strategi bisnis, tata kelola, organisasi, dan proses bisnis utama dalam suatu perusahaan dan berfokus pada analisis dan desain proses bisnis.

  • Application (software) architecture - Berfungsi sebagai cetak biru untuk sistem aplikasi individu, interaksi mereka, dan hubungannya dengan proses bisnis organisasi.

  • Information architecture - Mendefinisikan aset data logis dan fisik serta sumber daya manajemen data.

  • Information technology (IT) architecture - Mendefinisikan blok bangunan perangkat keras dan perangkat lunak yang membentuk sistem informasi keseluruhan organisasi.

Proses Desain Arsitektur

Proses desain arsitektur berfokus pada dekomposisi sistem menjadi komponen yang berbeda dan interaksinya untuk memenuhi persyaratan fungsional dan nonfungsional. Input utama untuk desain arsitektur perangkat lunak adalah -

  • Persyaratan yang dihasilkan oleh tugas analisis.

  • Arsitektur perangkat keras (arsitek perangkat lunak pada gilirannya memberikan persyaratan kepada arsitek sistem, yang mengkonfigurasi arsitektur perangkat keras).

Hasil atau keluaran dari proses desain arsitektur adalah sebuah architectural description. Proses desain arsitektur dasar terdiri dari langkah-langkah berikut -

Pahami Masalahnya

  • Ini adalah langkah paling krusial karena mempengaruhi kualitas desain yang mengikutinya.

  • Tanpa pemahaman yang jelas tentang masalah, tidak mungkin dapat menciptakan solusi yang efektif.

  • Banyak proyek dan produk perangkat lunak dianggap gagal karena tidak benar-benar menyelesaikan masalah bisnis yang valid atau memiliki laba atas investasi (ROI) yang dapat dikenali.

Identifikasi Elemen Desain dan Hubungannya

  • Dalam fase ini, buat baseline untuk mendefinisikan batasan dan konteks sistem.

  • Penguraian sistem menjadi komponen utamanya berdasarkan persyaratan fungsional. Dekomposisi dapat dimodelkan menggunakan matriks struktur desain (DSM), yang menunjukkan ketergantungan antara elemen desain tanpa menentukan perincian elemen.

  • Pada langkah ini, validasi arsitektur pertama dilakukan dengan mendeskripsikan sejumlah instance sistem dan langkah ini disebut sebagai desain arsitektur berbasis fungsionalitas.

Evaluasi Desain Arsitektur

  • Setiap atribut kualitas diberi perkiraan sehingga untuk mengumpulkan ukuran kualitatif atau data kuantitatif, desain dievaluasi.

  • Ini melibatkan evaluasi arsitektur untuk kesesuaian dengan persyaratan atribut kualitas arsitektur.

  • Jika semua atribut kualitas yang diperkirakan sesuai dengan standar yang dipersyaratkan, proses desain arsitektur selesai.

  • Jika tidak, tahap ketiga dari desain arsitektur perangkat lunak dimasukkan: transformasi arsitektur. Jika atribut kualitas yang diamati tidak memenuhi persyaratannya, maka desain baru harus dibuat.

Ubah Desain Arsitektur

  • Langkah ini dilakukan setelah dilakukan evaluasi terhadap desain arsitektur. Desain arsitektur harus diubah hingga memenuhi persyaratan atribut kualitas secara sempurna.

  • Ini berkaitan dengan pemilihan solusi desain untuk meningkatkan atribut kualitas sambil mempertahankan fungsionalitas domain.

  • Sebuah desain diubah dengan menerapkan operator desain, gaya, atau pola. Untuk transformasi, ambil desain yang ada dan terapkan operator desain seperti dekomposisi, replikasi, kompresi, abstraksi, dan berbagi sumber daya.

  • Desain dievaluasi lagi dan proses yang sama diulangi beberapa kali jika perlu dan bahkan dilakukan secara rekursif.

  • Transformasi (yaitu solusi pengoptimalan atribut kualitas) umumnya meningkatkan satu atau beberapa atribut kualitas sementara mereka mempengaruhi yang lain secara negatif

Prinsip Arsitektur Utama

Berikut adalah prinsip-prinsip utama yang harus dipertimbangkan saat merancang arsitektur -

Bangun untuk Berubah Daripada Membangun untuk Tahan Lama

Pertimbangkan bagaimana aplikasi mungkin perlu berubah dari waktu ke waktu untuk mengatasi persyaratan dan tantangan baru, dan membangun fleksibilitas untuk mendukungnya.

Kurangi Risiko dan Model untuk Menganalisis

Gunakan alat desain, visualisasi, sistem pemodelan seperti UML untuk menangkap persyaratan dan keputusan desain. Dampaknya juga dapat dianalisis. Jangan memformalkan model sedemikian rupa sehingga menekan kemampuan untuk mengulang dan menyesuaikan desain dengan mudah.

Gunakan Model dan Visualisasi sebagai Alat Komunikasi dan Kolaborasi

Komunikasi yang efisien dari desain, keputusan, dan perubahan berkelanjutan pada desain sangat penting untuk arsitektur yang baik. Gunakan model, tampilan, dan visualisasi arsitektur lainnya untuk berkomunikasi dan berbagi desain secara efisien dengan semua pemangku kepentingan. Hal ini memungkinkan komunikasi yang cepat dari perubahan desain.

Identifikasi dan pahami keputusan teknik utama dan area di mana kesalahan paling sering dibuat. Berinvestasilah untuk mengambil keputusan penting dengan benar pada kali pertama untuk membuat desain lebih fleksibel dan kecil kemungkinannya rusak oleh perubahan.

Gunakan Pendekatan Inkremental dan Iteratif

Mulailah dengan arsitektur dasar dan kemudian kembangkan arsitektur kandidat dengan pengujian berulang untuk meningkatkan arsitektur. Tambahkan detail secara berulang ke desain melalui beberapa gerakan printhead untuk mendapatkan gambar besar atau benar, lalu fokus pada detailnya.

Prinsip Desain Utama

Berikut adalah prinsip desain yang harus dipertimbangkan untuk meminimalkan biaya, persyaratan pemeliharaan, dan memaksimalkan daya tahan, kegunaan arsitektur -

Pemisahan Masalah

Bagilah komponen sistem menjadi fitur khusus sehingga tidak ada tumpang tindih di antara fungsionalitas komponen. Ini akan memberikan kohesi tinggi dan kopling rendah. Pendekatan ini menghindari saling ketergantungan antar komponen sistem yang membantu dalam memelihara sistem dengan mudah.

Prinsip Tanggung Jawab Tunggal

Setiap modul dari suatu sistem harus memiliki satu tanggung jawab khusus, yang membantu pengguna untuk memahami sistem dengan jelas. Ini juga akan membantu dengan integrasi komponen dengan komponen lain.

Prinsip Pengetahuan Sedikit

Setiap komponen atau objek tidak boleh memiliki pengetahuan tentang detail internal komponen lain. Pendekatan ini menghindari saling ketergantungan dan membantu pemeliharaan.

Minimalkan Desain Besar di Muka

Minimalkan desain besar di awal jika persyaratan aplikasi tidak jelas. Jika ada kemungkinan memodifikasi persyaratan, hindari membuat desain besar untuk keseluruhan sistem.

Jangan Ulangi Fungsi tersebut

Jangan mengulang fungsionalitas menentukan bahwa fungsionalitas komponen tidak boleh diulang dan karenanya sepotong kode harus diimplementasikan dalam satu komponen saja. Duplikasi fungsionalitas dalam aplikasi dapat menyulitkan penerapan perubahan, mengurangi kejelasan, dan menimbulkan potensi inkonsistensi.

Lebih memilih Komposisi daripada Warisan sambil Menggunakan Kembali Fungsionalitas

Inheritance menciptakan ketergantungan antara kelas anak dan induk dan karenanya memblokir penggunaan kelas anak secara gratis. Sebaliknya, komposisi memberikan tingkat kebebasan yang tinggi dan mengurangi hierarki warisan.

Identifikasi Komponen dan Kelompokkan dalam Lapisan Logis

Identitas komponen dan area perhatian yang dibutuhkan dalam sistem untuk memenuhi persyaratan. Kemudian kelompokkan komponen terkait ini dalam lapisan logis, yang akan membantu pengguna untuk memahami struktur sistem pada tingkat tinggi. Hindari mencampur komponen dari jenis masalah yang berbeda di lapisan yang sama.

Tentukan Protokol Komunikasi antar Lapisan

Memahami bagaimana komponen akan berkomunikasi satu sama lain yang membutuhkan pengetahuan lengkap tentang skenario penerapan dan lingkungan produksi.

Tentukan Format Data untuk Layer

Berbagai komponen akan saling berinteraksi melalui format data. Jangan mencampur format data sehingga aplikasi mudah diimplementasikan, diperluas, dan dipelihara. Usahakan untuk menjaga format data tetap sama untuk sebuah lapisan, sehingga berbagai komponen tidak perlu mengkodekan / mendekode data saat berkomunikasi satu sama lain. Ini mengurangi overhead pemrosesan.

Komponen Layanan Sistem harus Abstrak

Kode yang terkait dengan keamanan, komunikasi, atau layanan sistem seperti logging, profil, dan konfigurasi harus diabstraksikan dalam komponen terpisah. Jangan gabungkan kode ini dengan logika bisnis, karena mudah untuk memperluas desain dan memeliharanya.

Pengecualian Desain dan Mekanisme Penanganan Pengecualian

Menentukan pengecualian sebelumnya, membantu komponen untuk mengelola kesalahan atau situasi yang tidak diinginkan dengan cara yang elegan. Manajemen pengecualian akan sama di seluruh sistem.

Konvensi Penamaan

Konvensi penamaan harus didefinisikan sebelumnya. Mereka menyediakan model yang konsisten yang membantu pengguna untuk memahami sistem dengan mudah. Lebih mudah bagi anggota tim untuk memvalidasi kode yang ditulis oleh orang lain, dan karenanya akan meningkatkan kemudahan pemeliharaan.

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 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 tersebut 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 struktural merepresentasikan aspek statis dari suatu sistem. Aspek statis ini mewakili bagian-bagian dari 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 urutan, 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 keseluruhan 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 menggambarkan 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 menjelaskan 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 lain 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 dari sistem dan menjelaskan 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 pandangan dan evaluator mereka
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 menyediakan kemampuan untuk mendekomposisi komponen, menggabungkan komponen, dan menentukan antarmuka komponen.

Bahasa deskripsi arsitektur adalah bahasa spesifikasi formal, yang menggambarkan 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 suatu bahasa yang diklasifikasikan sebagai ADL -

  • Ini harus sesuai untuk mengkomunikasikan arsitektur kepada semua pihak terkait.

  • Ini harus sesuai untuk tugas pembuatan, perbaikan, dan validasi arsitektur.

  • 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.

Paradigma berorientasi objek (OO) mengambil bentuknya dari konsep awal pendekatan pemrograman baru, sementara minat dalam desain dan metode analisis muncul jauh kemudian. Analisis OO dan paradigma desain adalah hasil logis dari adopsi bahasa pemrograman OO secara luas.

  • Bahasa berorientasi objek pertama adalah Simula (Simulasi sistem nyata) yang dikembangkan pada tahun 1960 oleh para peneliti di Pusat Komputasi Norwegia.

  • Pada tahun 1970, Alan Kay dan kelompok penelitiannya di Xerox PARC membuat komputer pribadi bernama Dynabook dan bahasa pemrograman berorientasi objek murni pertama (OOPL) - Smalltalk, untuk pemrograman Dynabook.

  • Pada 1980-an, Grady Boochmenerbitkan sebuah makalah berjudul Desain Berorientasi Objek yang terutama menyajikan desain untuk bahasa pemrograman, Ada. Dalam edisi berikutnya, ia memperluas ide-idenya ke metode desain berorientasi objek lengkap.

  • Pada 1990-an, Coad menggabungkan gagasan perilaku ke metode berorientasi objek.

Inovasi penting lainnya adalah Object Modeling Techniques (OMT) oleh James Rum Baugh dan Rekayasa Perangkat Lunak Berorientasi Objek (OOSE) oleh Ivar Jacobson.

Pengantar Paradigma OO

Paradigma OO adalah metodologi penting untuk pengembangan perangkat lunak apa pun. Sebagian besar gaya atau pola arsitektur seperti pipa dan filter, penyimpanan data, dan berbasis komponen dapat diimplementasikan dengan menggunakan paradigma ini.

Konsep dasar dan terminologi dari sistem berorientasi objek -

Obyek

Objek adalah elemen dunia nyata dalam lingkungan berorientasi objek yang mungkin memiliki keberadaan fisik atau konseptual. Setiap objek memiliki -

  • Identitas yang membedakannya dari objek lain di sistem.

  • Status yang menentukan properti karakteristik dari suatu objek serta nilai properti yang dimiliki objek tersebut.

  • Perilaku yang merepresentasikan aktivitas yang terlihat secara eksternal yang dilakukan oleh suatu objek dalam hal perubahan statusnya.

Objek dapat dimodelkan sesuai dengan kebutuhan aplikasi. Sebuah objek mungkin memiliki keberadaan fisik, seperti pelanggan, mobil, dll .; atau keberadaan konseptual yang tidak berwujud, seperti proyek, proses, dll.

Kelas

Kelas mewakili sekumpulan objek yang memiliki sifat karakteristik yang sama yang menunjukkan perilaku umum. Ini memberikan cetak biru atau deskripsi dari objek yang dapat dibuat darinya. Penciptaan objek sebagai anggota kelas disebut instantiation. Jadi, benda adalahinstance dari sebuah kelas.

Konstituen kelas adalah -

  • Sekumpulan atribut untuk objek yang akan dibuat instance-nya dari kelas. Secara umum, objek yang berbeda dari suatu kelas memiliki beberapa perbedaan dalam nilai atributnya. Atribut sering disebut sebagai data kelas.

  • Satu set operasi yang menggambarkan perilaku objek kelas. Operasi juga disebut sebagai fungsi atau metode.

Example

Mari kita pertimbangkan sebuah kelas sederhana, Circle, yang merepresentasikan lingkaran figur geometris dalam ruang dua dimensi. Atribut kelas ini dapat diidentifikasi sebagai berikut -

  • x – coord, untuk menunjukkan koordinat x dari pusat
  • y – coord, untuk menunjukkan koordinat y dari pusat
  • a, untuk menunjukkan jari-jari lingkaran

Beberapa operasinya dapat didefinisikan sebagai berikut -

  • findArea (), metode untuk menghitung luas
  • findCircumference (), metode untuk menghitung keliling
  • scale (), metode untuk menambah atau mengurangi radius

Enkapsulasi

Enkapsulasi adalah proses mengikat atribut dan metode bersama-sama di dalam kelas. Melalui enkapsulasi, detail internal suatu kelas dapat disembunyikan dari luar. Ini memungkinkan elemen kelas untuk diakses dari luar hanya melalui antarmuka yang disediakan oleh kelas.

Polimorfisme

Polimorfisme aslinya adalah kata Yunani yang berarti kemampuan untuk mengambil berbagai bentuk. Dalam paradigma berorientasi objek, polimorfisme menyiratkan penggunaan operasi dengan cara yang berbeda, bergantung pada contoh tempat mereka beroperasi. Polimorfisme memungkinkan objek dengan struktur internal yang berbeda memiliki antarmuka eksternal yang sama. Polimorfisme sangat efektif saat menerapkan pewarisan.

Example

Mari kita pertimbangkan dua kelas, Circle dan Square, masing-masing dengan metode findArea (). Meskipun nama dan tujuan metode di kelas sama, implementasi internal, yaitu prosedur penghitungan luas berbeda untuk setiap kelas. Ketika sebuah objek kelas Circle memanggil metode findArea (), operasi menemukan area lingkaran tanpa konflik apa pun dengan metode findArea () dari kelas Square.

Relationships

Untuk mendeskripsikan sistem, spesifikasi dinamis (perilaku) dan statis (logis) dari suatu sistem harus disediakan. Spesifikasi dinamis mendeskripsikan hubungan antar objek misalnya penyampaian pesan. Dan spesifikasi statis menggambarkan hubungan antar kelas, misalnya agregasi, asosiasi, dan pewarisan.

Message Passing

Aplikasi apa pun membutuhkan sejumlah objek yang berinteraksi secara harmonis. Objek dalam sistem dapat berkomunikasi satu sama lain dengan menggunakan message passing. Misalkan sebuah sistem memiliki dua objek - obj1 dan obj2. Objek obj1 mengirim pesan ke objek obj2, jika obj1 ingin obj2 mengeksekusi salah satu metodenya.

Komposisi atau Agregasi

Agregasi atau komposisi adalah hubungan antar kelas dimana kelas dapat dibuat dari kombinasi objek kelas lain. Ini memungkinkan objek untuk ditempatkan langsung di dalam tubuh kelas lain. Agregasi disebut sebagai hubungan "bagian-dari" atau "memiliki-a", dengan kemampuan untuk menavigasi dari keseluruhan ke bagian-bagiannya. Objek agregat adalah objek yang terdiri dari satu atau lebih objek lainnya.

Asosiasi

Asosiasi adalah sekelompok tautan yang memiliki struktur dan perilaku yang sama. Asosiasi menggambarkan hubungan antara objek dari satu atau lebih kelas. Tautan dapat didefinisikan sebagai turunan dari suatu asosiasi. Derajat asosiasi menunjukkan jumlah kelas yang terlibat dalam koneksi. Derajatnya mungkin unary, binary, atau ternary.

  • Hubungan unary menghubungkan objek dari kelas yang sama.
  • Hubungan biner menghubungkan objek dari dua kelas.
  • Hubungan terner menghubungkan objek dari tiga kelas atau lebih.

Warisan

Ini adalah mekanisme yang memungkinkan kelas baru dibuat dari kelas yang ada dengan memperluas dan menyempurnakan kemampuannya. Kelas-kelas yang ada disebut kelas dasar / kelas induk / kelas super, dan kelas-kelas baru disebut kelas turunan / kelas anak / subkelas.

Subclass dapat mewarisi atau memperoleh atribut dan metode dari super-class asalkan super-class mengizinkannya. Selain itu, subclass dapat menambahkan atribut dan metodenya sendiri dan dapat memodifikasi salah satu metode kelas-super. Pewarisan mendefinisikan hubungan "adalah - a".

Example

Dari satu kelas Mamalia, sejumlah kelas dapat diturunkan seperti Manusia, Kucing, Anjing, Sapi, dll. Manusia, kucing, anjing, dan sapi semuanya memiliki ciri khas mamalia. Selain itu, masing-masing memiliki ciri khas tersendiri. Dapat dikatakan bahwa sapi “adalah - seekor” mamalia.

Analisis OO

Dalam tahap analisis berorientasi objek pengembangan perangkat lunak, persyaratan sistem ditentukan, kelas diidentifikasi, dan hubungan antar kelas diakui. Tujuan dari analisis OO adalah untuk memahami domain aplikasi dan persyaratan khusus sistem. Hasil dari tahap ini adalah spesifikasi kebutuhan dan analisis awal struktur logis dan kelayakan suatu sistem.

Tiga teknik analisis yang digunakan bersama-sama untuk analisis berorientasi objek adalah pemodelan objek, pemodelan dinamis, dan pemodelan fungsional.

Pemodelan Objek

Pemodelan objek mengembangkan struktur statis dari sistem perangkat lunak dalam kaitannya dengan objek. Ini mengidentifikasi objek, kelas di mana objek dapat dikelompokkan dan hubungan antara objek. Ini juga mengidentifikasi atribut utama dan operasi yang menjadi ciri setiap kelas.

Proses pemodelan objek dapat divisualisasikan dalam langkah-langkah berikut -

  • Identifikasi objek dan kelompokkan ke dalam kelas
  • Identifikasi hubungan antar kelas
  • Buat diagram model objek pengguna
  • Tentukan atribut objek pengguna
  • Tentukan operasi yang harus dilakukan di kelas

Pemodelan Dinamis

Setelah perilaku statis dari sistem dianalisis, perilakunya berkaitan dengan waktu dan perubahan eksternal perlu diperiksa. Inilah tujuan dari pemodelan dinamis.

Pemodelan Dinamis dapat didefinisikan sebagai "cara menggambarkan bagaimana suatu objek merespons peristiwa, baik peristiwa internal yang dipicu oleh objek lain, atau peristiwa eksternal yang dipicu oleh dunia luar".

Proses pemodelan dinamis dapat divisualisasikan dalam langkah-langkah berikut -

  • Identifikasi status setiap objek
  • Identifikasi peristiwa dan analisis penerapan tindakan
  • Buat diagram model dinamis, yang terdiri dari diagram transisi keadaan
  • Ekspresikan setiap status dalam hal atribut objek
  • Validasi diagram transisi keadaan yang digambar

Pemodelan Fungsional

Pemodelan Fungsional adalah komponen terakhir dari analisis berorientasi objek. Model fungsional menunjukkan proses yang dilakukan dalam suatu objek dan bagaimana data berubah, saat berpindah antar metode. Ini menentukan arti operasi pemodelan objek dan tindakan pemodelan dinamis. Model fungsional sesuai dengan diagram aliran data dari analisis terstruktur tradisional.

Proses pemodelan fungsional dapat divisualisasikan dalam langkah-langkah berikut -

  • Identifikasi semua masukan dan keluaran
  • Buat diagram aliran data yang menunjukkan dependensi fungsional
  • Sebutkan tujuan setiap fungsi
  • Identifikasi kendala
  • Tentukan kriteria pengoptimalan

Desain Berorientasi Objek

Setelah tahap analisis, model konseptual dikembangkan lebih lanjut menjadi model berorientasi objek dengan menggunakan desain berorientasi objek (OOD). Dalam OOD, konsep yang tidak bergantung pada teknologi dalam model analisis dipetakan ke kelas implementasi, batasan diidentifikasi, dan antarmuka dirancang, menghasilkan model untuk domain solusi. Tujuan utama dari desain OO adalah untuk mengembangkan arsitektur struktural suatu sistem.

Tahapan untuk desain berorientasi objek dapat diidentifikasi sebagai -

  • Mendefinisikan konteks sistem
  • Merancang arsitektur sistem
  • Identifikasi objek dalam sistem
  • Konstruksi model desain
  • Spesifikasi antarmuka objek

Desain OO dapat dibagi menjadi dua tahap - Desain konseptual dan Desain detail.

Conceptual design

Dalam tahap ini, semua kelas diidentifikasi yang diperlukan untuk membangun sistem. Selanjutnya, tanggung jawab khusus ditugaskan untuk setiap kelas. Diagram kelas digunakan untuk memperjelas hubungan antar kelas, dan diagram interaksi digunakan untuk menunjukkan aliran peristiwa. Itu juga dikenal sebagaihigh-level design.

Detailed design

Dalam tahap ini, atribut dan operasi ditetapkan ke setiap kelas berdasarkan diagram interaksinya. Diagram mesin status dikembangkan untuk menggambarkan detail lebih lanjut dari desain. Itu juga dikenal sebagailow-level design.

Prinsip desain

Berikut adalah prinsip desain utama -

Principle of Decoupling

Sulit untuk mempertahankan sistem dengan sekumpulan kelas yang sangat saling bergantung, karena modifikasi dalam satu kelas dapat mengakibatkan pembaruan berjenjang dari kelas lain. Dalam desain OO, kopling ketat dapat dihilangkan dengan memperkenalkan kelas atau warisan baru.

Ensuring Cohesion

Kelas yang kohesif melakukan satu set fungsi yang terkait erat. Kurangnya sarana kohesi - kelas melakukan fungsi yang tidak terkait, meskipun tidak mempengaruhi operasi seluruh sistem. Itu membuat seluruh struktur perangkat lunak sulit untuk dikelola, diperluas, dipelihara, dan diubah.

Open-closed Principle

Menurut prinsip ini, suatu sistem harus dapat diperluas untuk memenuhi persyaratan baru. Implementasi yang ada dan kode sistem tidak boleh dimodifikasi sebagai hasil dari perluasan sistem. Selain itu, pedoman berikut harus diikuti dalam prinsip terbuka-tertutup -

  • Untuk setiap kelas beton, antarmuka dan implementasi terpisah harus dipertahankan.

  • Dalam lingkungan multithread, pertahankan atribut tetap pribadi.

  • Minimalkan penggunaan variabel global dan variabel kelas.

Dalam arsitektur aliran data, keseluruhan sistem perangkat lunak dilihat sebagai serangkaian transformasi pada bagian atau kumpulan data masukan yang berurutan, di mana data dan operasi tidak bergantung satu sama lain. Dalam pendekatan ini, data masuk ke dalam sistem dan kemudian mengalir melalui modul satu per satu sampai mereka ditugaskan ke beberapa tujuan akhir (keluaran atau penyimpanan data).

Koneksi antara komponen atau modul dapat diimplementasikan sebagai aliran I / O, buffer I / O, pipa, atau tipe koneksi lainnya. Data dapat dialirkan dalam topologi grafik dengan siklus, dalam struktur linier tanpa siklus, atau dalam struktur tipe pohon.

Tujuan utama dari pendekatan ini adalah untuk mencapai kualitas penggunaan kembali dan modifiabilitas. Ini cocok untuk aplikasi yang melibatkan serangkaian transformasi data independen atau komputasi yang terdefinisi dengan baik pada input dan output yang ditentukan secara teratur seperti kompiler dan aplikasi pemrosesan data bisnis. Ada tiga jenis urutan eksekusi antara modul-

  • Batch berurutan
  • Pipa dan filter atau mode pipa tidak berurutan
  • Pengendalian proses

Batch Sequential

Sekuensial batch adalah model pemrosesan data klasik, di mana subsistem transformasi data dapat memulai prosesnya hanya setelah subsistem sebelumnya selesai sepenuhnya -

  • Aliran data membawa sekumpulan data secara keseluruhan dari satu subsistem ke subsistem lainnya.

  • Komunikasi antar modul dilakukan melalui file perantara sementara yang dapat dihapus oleh subsistem yang berurutan.

  • Ini berlaku untuk aplikasi di mana data dikumpulkan, dan setiap subsistem membaca file input terkait dan menulis file output.

  • Aplikasi khas dari arsitektur ini mencakup pemrosesan data bisnis seperti perbankan dan penagihan utilitas.

Keuntungan

  • Menyediakan divisi yang lebih sederhana pada subsistem.

  • Setiap subsistem dapat menjadi program independen yang mengerjakan input data dan menghasilkan data output.

Kekurangan

  • Memberikan latensi tinggi dan throughput rendah.

  • Tidak menyediakan konkurensi dan antarmuka interaktif.

  • Kontrol eksternal diperlukan untuk implementasi.

Arsitektur Pipa dan Filter

Pendekatan ini menekankan pada transformasi data secara bertahap oleh komponen yang berurutan. Dalam pendekatan ini, aliran data digerakkan oleh data dan seluruh sistem diuraikan menjadi komponen sumber data, filter, pipa, dan penyerap data.

Koneksi antar modul adalah aliran data yang merupakan buffer pertama masuk / keluar pertama yang dapat berupa aliran byte, karakter, atau jenis lain semacam itu. Fitur utama dari arsitektur ini adalah eksekusi bersamaan dan bertahap.

Saring

Filter adalah trafo aliran data independen atau transduser aliran. Ini mengubah data aliran data masukan, memprosesnya, dan menulis aliran data yang ditransformasikan melalui pipa untuk diproses oleh filter berikutnya. Ia bekerja dalam mode inkremental, di mana ia mulai bekerja segera setelah data masuk melalui pipa yang terhubung. Ada dua jenis filter -active filter dan passive filter.

Active filter

Filter aktif memungkinkan pipa yang terhubung untuk menarik data masuk dan mendorong keluar data yang diubah. Ini beroperasi dengan pipa pasif, yang menyediakan mekanisme baca / tulis untuk menarik dan mendorong. Mode ini digunakan dalam pipa UNIX dan mekanisme filter.

Passive filter

Filter pasif memungkinkan pipa yang terhubung untuk mendorong data masuk dan mengeluarkan data. Ini beroperasi dengan pipa aktif, yang menarik data dari filter dan mendorong data ke filter berikutnya. Ini harus menyediakan mekanisme baca / tulis.

Keuntungan

  • Memberikan konkurensi dan throughput tinggi untuk pemrosesan data yang berlebihan.

  • Menyediakan dapat digunakan kembali dan menyederhanakan pemeliharaan sistem.

  • Memberikan modifiabilitas dan kopling rendah antar filter.

  • Memberikan kesederhanaan dengan menawarkan pembagian yang jelas antara dua filter yang dihubungkan dengan pipa.

  • Memberikan fleksibilitas dengan mendukung eksekusi sekuensial dan paralel.

Kekurangan

  • Tidak cocok untuk interaksi dinamis.

  • Penyebut umum yang rendah diperlukan untuk transmisi data dalam format ASCII.

  • Overhead transformasi data antar filter.

  • Tidak menyediakan cara bagi filter untuk berinteraksi secara kooperatif untuk memecahkan masalah.

  • Sulit untuk mengkonfigurasi arsitektur ini secara dinamis.

Pipa

Pipa tidak memiliki kewarganegaraan dan membawa aliran biner atau karakter yang ada di antara dua filter. Itu dapat memindahkan aliran data dari satu filter ke filter lainnya. Pipa menggunakan sedikit informasi kontekstual dan tidak menyimpan informasi status antar-instansiasi.

Arsitektur Kontrol Proses

Ini adalah jenis arsitektur aliran data di mana datanya tidak bertumpuk sekuensial atau aliran pipelined. Aliran data berasal dari sekumpulan variabel, yang mengontrol pelaksanaan proses. Ini menguraikan seluruh sistem menjadi subsistem atau modul dan menghubungkannya.

Jenis Subsistem

Arsitektur kontrol proses akan memiliki file processing unit untuk mengubah variabel kontrol proses dan a controller unit untuk menghitung jumlah perubahan.

Unit pengontrol harus memiliki elemen berikut -

  • Controlled Variable- Variabel Terkendali memberikan nilai untuk sistem yang mendasarinya dan harus diukur dengan sensor. Misalnya, kecepatan dalam sistem kendali jelajah.

  • Input Variable- Mengukur masukan untuk proses. Misalnya temperatur udara balik dalam sistem kendali temperatur

  • Manipulated Variable - Nilai Variabel yang Dimanipulasi disesuaikan atau diubah oleh pengontrol.

  • Process Definition - Ini mencakup mekanisme untuk memanipulasi beberapa variabel proses.

  • Sensor - Memperoleh nilai variabel proses yang berkaitan dengan kontrol dan dapat digunakan sebagai referensi umpan balik untuk menghitung ulang variabel yang dimanipulasi.

  • Set Point - Ini adalah nilai yang diinginkan untuk variabel terkontrol.

  • Control Algorithm - Ini digunakan untuk memutuskan bagaimana memanipulasi variabel proses.

Area Aplikasi

Arsitektur kontrol proses cocok di domain berikut -

  • Desain perangkat lunak sistem tertanam, di mana sistem dimanipulasi oleh data variabel kontrol proses.

  • Aplikasi, yang bertujuan untuk mempertahankan properti tertentu dari keluaran proses pada nilai referensi yang diberikan.

  • Berlaku untuk kontrol jelajah mobil dan sistem kontrol suhu gedung.

  • Perangkat lunak sistem waktu nyata untuk mengontrol rem anti-lock mobil, pembangkit listrik tenaga nuklir, dll.

Dalam arsitektur data-centered, data dipusatkan dan sering diakses oleh komponen lain, yang memodifikasi data. Tujuan utama dari gaya ini adalah untuk mencapai keutuhan data. Arsitektur data-centered terdiri dari berbagai komponen yang berkomunikasi melalui repositori data bersama. Komponen mengakses struktur data bersama dan relatif independen, dalam hal itu, mereka hanya berinteraksi melalui penyimpanan data.

Contoh paling terkenal dari arsitektur data-centered adalah arsitektur database, di mana skema database umum dibuat dengan protokol definisi data - misalnya, satu set tabel terkait dengan bidang dan tipe data dalam RDBMS.

Contoh lain dari arsitektur data-centered adalah arsitektur web yang memiliki skema data yang umum (yaitu meta-struktur Web) dan mengikuti model data hypermedia dan proses berkomunikasi melalui penggunaan layanan data berbasis web bersama.

Jenis Komponen

Ada dua jenis komponen -

  • SEBUAH central datastruktur atau penyimpanan data atau tempat penyimpanan data, yang bertanggung jawab untuk menyediakan penyimpanan data permanen. Ini mewakili keadaan saat ini.

  • SEBUAH data accessor atau kumpulan komponen independen yang beroperasi di penyimpanan data pusat, melakukan penghitungan, dan mungkin mengembalikan hasil.

Interaksi atau komunikasi antar pengakses data hanya melalui penyimpanan data. Data adalah satu-satunya alat komunikasi antar klien. Aliran kontrol membedakan arsitektur menjadi dua kategori -

  • Gaya Arsitektur Repositori
  • Gaya Arsitektur Papan Tulis

Gaya Arsitektur Repositori

Dalam Gaya Arsitektur Repositori, penyimpanan data bersifat pasif dan klien (komponen perangkat lunak atau agen) penyimpanan data aktif, yang mengontrol aliran logika. Komponen yang berpartisipasi memeriksa penyimpanan data untuk perubahan.

  • Klien mengirimkan permintaan ke sistem untuk melakukan tindakan (misalnya memasukkan data).

  • Proses komputasi bersifat independen dan dipicu oleh permintaan yang masuk.

  • Jika jenis transaksi dalam aliran input transaksi memicu pemilihan proses untuk dieksekusi, maka itu adalah database tradisional atau arsitektur repositori, atau repositori pasif.

  • Pendekatan ini banyak digunakan di DBMS, sistem informasi perpustakaan, repositori antarmuka di CORBA, kompiler dan lingkungan CASE (rekayasa perangkat lunak berbantuan komputer).

Keuntungan

  • Menyediakan integritas data, fitur backup dan restore.

  • Memberikan skalabilitas dan penggunaan kembali agen karena mereka tidak memiliki komunikasi langsung satu sama lain.

  • Mengurangi overhead data transien antar komponen perangkat lunak.

Kekurangan

  • Ini lebih rentan terhadap kegagalan dan replikasi atau duplikasi data dimungkinkan.

  • Ketergantungan tinggi antara struktur data penyimpanan data dan agennya.

  • Perubahan struktur data sangat mempengaruhi klien.

  • Evolusi data itu sulit dan mahal.

  • Biaya pemindahan data di jaringan untuk data terdistribusi.

Gaya Arsitektur Papan Tulis

Dalam Gaya Arsitektur Blackboard, penyimpanan data aktif dan kliennya pasif. Oleh karena itu aliran logis ditentukan oleh status data saat ini di penyimpanan data. Ini memiliki komponen papan tulis, yang bertindak sebagai tempat penyimpanan data pusat, dan representasi internal dibangun dan ditindaklanjuti oleh elemen komputasi yang berbeda.

  • Sejumlah komponen yang bertindak secara independen pada struktur data umum disimpan di papan tulis.

  • Dalam gaya ini, komponen hanya berinteraksi melalui papan tulis. Penyimpanan data memberi tahu klien setiap kali ada perubahan penyimpanan data.

  • Status solusi saat ini disimpan di papan tulis dan pemrosesan dipicu oleh status papan tulis.

  • Sistem mengirimkan pemberitahuan yang disebut trigger dan data ke klien saat terjadi perubahan pada data.

  • Pendekatan ini ditemukan dalam aplikasi AI tertentu dan aplikasi kompleks, seperti pengenalan ucapan, pengenalan gambar, sistem keamanan, dan sistem manajemen sumber daya bisnis, dll.

  • Jika status saat ini dari struktur data pusat adalah pemicu utama pemilihan proses yang akan dijalankan, repositori dapat menjadi papan tulis dan sumber data bersama ini adalah agen aktif.

  • Perbedaan utama dengan sistem database tradisional adalah bahwa pemanggilan elemen komputasi dalam arsitektur papan tulis dipicu oleh status papan tulis saat ini, dan bukan oleh input eksternal.

Bagian dari Model Papan Tulis

Model papan tulis biasanya disajikan dengan tiga bagian utama -

Knowledge Sources (KS)

Sumber Pengetahuan, juga dikenal sebagai Listeners atau Subscribersadalah unit yang berbeda dan independen. Mereka memecahkan sebagian masalah dan mengumpulkan hasil parsial. Interaksi antar sumber pengetahuan berlangsung secara unik melalui papan tulis.

Blackboard Data Structure

Data status pemecahan masalah diatur ke dalam hierarki yang bergantung pada aplikasi. Sumber pengetahuan membuat perubahan pada papan tulis yang secara bertahap mengarah pada solusi masalah.

Control

Kontrol mengelola tugas dan memeriksa status kerja.

Keuntungan

  • Memberikan skalabilitas yang memudahkan untuk menambah atau memperbarui sumber pengetahuan.

  • Menyediakan konkurensi yang memungkinkan semua sumber pengetahuan untuk bekerja secara paralel karena tidak bergantung satu sama lain.

  • Mendukung eksperimen untuk hipotesis.

  • Mendukung penggunaan kembali agen sumber pengetahuan.

Kekurangan

  • Perubahan struktur papan tulis mungkin berdampak signifikan pada semua agennya karena ketergantungan yang erat antara papan tulis dan sumber pengetahuan.

  • Sulit untuk memutuskan kapan harus menghentikan penalaran karena hanya solusi perkiraan yang diharapkan.

  • Masalah dalam sinkronisasi beberapa agen.

  • Tantangan utama dalam merancang dan menguji sistem.

Arsitektur hierarki memandang keseluruhan sistem sebagai struktur hierarki, di mana sistem perangkat lunak diuraikan menjadi modul atau subsistem logis pada tingkat yang berbeda dalam hierarki. Pendekatan ini biasanya digunakan dalam merancang perangkat lunak sistem seperti protokol jaringan dan sistem operasi.

Dalam desain hierarki perangkat lunak sistem, subsistem tingkat rendah memberikan layanan kepada subsistem tingkat atas yang berdekatan, yang memanggil metode di tingkat bawah. Lapisan bawah menyediakan fungsionalitas yang lebih spesifik seperti layanan I / O, transaksi, penjadwalan, layanan keamanan, dll. Lapisan tengah menyediakan lebih banyak fungsi yang bergantung pada domain seperti logika bisnis dan layanan pemrosesan inti. Dan, lapisan atas menyediakan fungsionalitas yang lebih abstrak dalam bentuk antarmuka pengguna seperti GUI, fasilitas pemrograman shell, dll.

Ini juga digunakan dalam organisasi perpustakaan kelas seperti perpustakaan kelas .NET dalam hierarki namespace. Semua jenis desain dapat mengimplementasikan arsitektur hierarki ini dan sering kali digabungkan dengan gaya arsitektur lain.

Gaya arsitektur hierarkis dibagi menjadi -

  • Main-subroutine
  • Master-slave
  • Mesin virtual

Utama-subrutin

Tujuan dari gaya ini adalah untuk menggunakan kembali modul dan secara bebas mengembangkan modul atau subrutin individu. Dalam gaya ini, sistem perangkat lunak dibagi menjadi beberapa subrutin dengan menggunakan perbaikan dari atas ke bawah sesuai dengan fungsionalitas yang diinginkan dari sistem.

Perbaikan ini mengarah secara vertikal hingga modul yang diuraikan cukup sederhana untuk memiliki tanggung jawab independen yang eksklusif. Fungsionalitas dapat digunakan kembali dan digunakan bersama oleh banyak penelepon di lapisan atas.

Ada dua cara untuk mengirimkan data sebagai parameter ke subrutin, yaitu -

  • Pass by Value - Subrutin hanya menggunakan data masa lalu, tetapi tidak dapat memodifikasinya.

  • Pass by Reference - Subrutin menggunakan serta mengubah nilai data yang direferensikan oleh parameter.

Keuntungan

  • Mudah untuk menguraikan sistem berdasarkan penyempurnaan hierarki.

  • Dapat digunakan dalam subsistem desain berorientasi objek.

Kekurangan

  • Rentan karena berisi data yang dibagikan secara global.

  • Kopling yang ketat dapat menyebabkan lebih banyak efek riak perubahan.

Tuan-Budak

Pendekatan ini menerapkan prinsip 'divide and conquer' dan mendukung komputasi kesalahan dan akurasi komputasi. Ini adalah modifikasi dari arsitektur subrutin utama yang memberikan keandalan sistem dan toleransi kesalahan.

Dalam arsitektur ini, budak memberikan layanan duplikat kepada master, dan master memilih hasil tertentu di antara budak dengan strategi pemilihan tertentu. Para budak dapat melakukan tugas fungsional yang sama dengan algoritma dan metode yang berbeda atau fungsi yang sama sekali berbeda. Ini termasuk komputasi paralel di mana semua budak dapat dieksekusi secara paralel.

Implementasi pola Master-Slave mengikuti lima langkah -

  • Tentukan bagaimana komputasi tugas dapat dibagi menjadi satu set sub-tugas yang sama dan mengidentifikasi sub-layanan yang diperlukan untuk memproses sub-tugas.

  • Tentukan bagaimana hasil akhir dari seluruh layanan dapat dihitung dengan bantuan hasil yang diperoleh dari pemrosesan sub-tugas individu.

  • Tentukan antarmuka untuk sub-layanan yang diidentifikasi di langkah 1. Ini akan diterapkan oleh budak dan digunakan oleh master untuk mendelegasikan pemrosesan sub-tugas individu.

  • Menerapkan komponen pendukung sesuai dengan spesifikasi yang dikembangkan pada langkah sebelumnya.

  • Terapkan master sesuai dengan spesifikasi yang dikembangkan pada langkah 1 hingga 3.

Aplikasi

  • Cocok untuk aplikasi di mana keandalan perangkat lunak merupakan masalah kritis.

  • Diterapkan secara luas di bidang komputasi paralel dan terdistribusi.

Keuntungan

  • Komputasi lebih cepat dan skalabilitas mudah.

  • Memberikan ketahanan karena budak dapat diduplikasi.

  • Slave dapat diimplementasikan secara berbeda untuk meminimalkan kesalahan semantik.

Kekurangan

  • Overhead komunikasi.

  • Tidak semua masalah bisa dibagi.

  • Sulit diimplementasikan dan masalah portabilitas.

Arsitektur Mesin Virtual

Arsitektur Mesin Virtual menganggap beberapa fungsionalitas, yang tidak asli dari perangkat keras dan / atau perangkat lunak yang diimplementasikan. Mesin virtual dibangun di atas sistem yang ada dan menyediakan abstraksi virtual, sekumpulan atribut, dan operasi.

Dalam arsitektur mesin virtual, master menggunakan 'subservice' yang 'sama' dari slave dan menjalankan fungsi seperti pekerjaan terpisah, memanggil budak, dan menggabungkan hasil. Ini memungkinkan pengembang untuk mensimulasikan dan menguji platform, yang belum dibangun, dan mensimulasikan mode "bencana '' yang akan terlalu rumit, mahal, atau berbahaya untuk diuji dengan sistem sebenarnya.

Dalam kebanyakan kasus, mesin virtual memisahkan bahasa pemrograman atau lingkungan aplikasi dari platform eksekusi. Tujuan utamanya adalah menyediakanportability. Interpretasi modul tertentu melalui Mesin Virtual dapat dianggap sebagai -

  • Mesin interpretasi memilih instruksi dari modul yang sedang diinterpretasikan.

  • Berdasarkan instruksi, mesin memperbarui status internal mesin virtual dan proses di atas diulangi.

Gambar berikut menunjukkan arsitektur infrastruktur VM standar pada satu mesin fisik.

Itu hypervisor, juga disebut virtual machine monitor, berjalan pada OS host dan mengalokasikan sumber daya yang cocok untuk setiap OS tamu. Ketika tamu melakukan panggilan sistem, hypervisor memotong dan menerjemahkannya ke panggilan sistem terkait yang didukung oleh OS host. Hypervisor mengontrol setiap akses mesin virtual ke CPU, memori, penyimpanan persisten, perangkat I / O, dan jaringan.

Aplikasi

Arsitektur mesin virtual cocok di domain berikut -

  • Cocok untuk menyelesaikan masalah dengan simulasi atau terjemahan jika tidak ada solusi langsung.

  • Contoh aplikasi termasuk penerjemah mikroprogram, pemrosesan XML, eksekusi bahasa perintah skrip, eksekusi sistem berbasis aturan, Smalltalk dan bahasa pemrograman yang diketik juru bahasa Java.

  • Contoh umum mesin virtual adalah interpreter, sistem berbasis aturan, shell sintaksis, dan pemroses bahasa perintah.

Keuntungan

  • Portabilitas dan independensi platform mesin.

  • Kesederhanaan pengembangan perangkat lunak.

  • Memberikan fleksibilitas melalui kemampuan untuk menginterupsi dan menanyakan program.

  • Simulasi model kerja bencana.

  • Memperkenalkan modifikasi pada waktu proses.

Kekurangan

  • Eksekusi penerjemah lambat karena sifat penerjemah.

  • Ada biaya kinerja karena penghitungan tambahan yang terlibat dalam eksekusi.

Gaya Berlapis

Dalam pendekatan ini, sistem diuraikan menjadi sejumlah lapisan yang lebih tinggi dan lebih rendah dalam suatu hierarki, dan setiap lapisan memiliki tanggung jawabnya sendiri dalam sistem.

  • Setiap lapisan terdiri dari sekelompok kelas terkait yang dienkapsulasi dalam sebuah paket, dalam komponen yang diterapkan, atau sebagai kelompok subrutin dalam format pustaka metode atau file header.

  • Setiap lapisan menyediakan layanan ke lapisan di atasnya dan berfungsi sebagai klien untuk lapisan di bawahnya yaitu permintaan ke lapisan i +1 memanggil layanan yang disediakan oleh lapisan i melalui antarmuka lapisan i. Tanggapan dapat kembali ke lapisan i +1 jika tugas selesai; jika tidak, lapisan i akan terus memanggil layanan dari lapisan i -1 di bawah.

Aplikasi

Gaya berlapis cocok di bidang berikut -

  • Aplikasi yang melibatkan kelas layanan berbeda yang dapat diatur secara hierarki.

  • Aplikasi apa pun yang dapat diuraikan menjadi bagian khusus aplikasi dan khusus platform.

  • Aplikasi yang memiliki divisi yang jelas antara layanan inti, layanan kritis, dan layanan antarmuka pengguna, dll.

Keuntungan

  • Desain berdasarkan tingkat abstraksi tambahan.

  • Memberikan kemandirian peningkatan karena perubahan pada fungsi satu lapisan memengaruhi paling banyak dua lapisan lainnya.

  • Pemisahan antarmuka standar dan implementasinya.

  • Diimplementasikan dengan menggunakan teknologi berbasis komponen yang membuat sistem lebih mudah untuk memungkinkan plug-and-play komponen baru.

  • Setiap lapisan dapat menjadi mesin abstrak yang digunakan secara independen yang mendukung portabilitas.

  • Mudah untuk menguraikan sistem berdasarkan definisi tugas dengan cara penyempurnaan top-down

  • Implementasi yang berbeda (dengan antarmuka yang identik) dari lapisan yang sama dapat digunakan secara bergantian

Kekurangan

  • Banyak aplikasi atau sistem yang tidak mudah terstruktur secara berlapis.

  • Performa runtime yang lebih rendah karena permintaan klien atau respons terhadap klien harus melalui beberapa lapisan yang berpotensi.

  • Ada juga masalah performa pada overhead pada marsaling data dan buffering oleh setiap lapisan.

  • Pembukaan komunikasi antar lapisan dapat menyebabkan kebuntuan dan "penghubung" dapat menyebabkan sambungan yang erat.

  • Pengecualian dan penanganan kesalahan adalah masalah dalam arsitektur berlapis, karena kesalahan dalam satu lapisan harus menyebar ke semua lapisan pemanggil

Tujuan utama dari arsitektur berorientasi interaksi adalah untuk memisahkan interaksi pengguna dari abstraksi data dan pemrosesan data bisnis. Arsitektur perangkat lunak yang berorientasi interaksi menguraikan sistem menjadi tiga partisi utama -

  • Data module - Modul data menyediakan abstraksi data dan semua logika bisnis.

  • Control module - Modul kontrol mengidentifikasi aliran tindakan kontrol dan konfigurasi sistem.

  • View presentation module - Modul tampilan presentasi bertanggung jawab atas presentasi visual atau audio dari keluaran data dan juga menyediakan antarmuka untuk masukan pengguna.

Arsitektur berorientasi interaksi memiliki dua gaya utama - Model-View-Controller (MVC) dan Presentation-Abstraction-Control(PAC). Baik MVC dan PAC mengusulkan tiga dekomposisi komponen dan digunakan untuk aplikasi interaktif seperti aplikasi web dengan banyak pembicaraan dan interaksi pengguna. Mereka berbeda dalam aliran kontrol dan organisasi mereka. PAC adalah arsitektur hierarki berbasis agen tetapi MVC tidak memiliki struktur hierarki yang jelas.

Model-View-Controller (MVC)

MVC menguraikan aplikasi perangkat lunak tertentu menjadi tiga bagian yang saling berhubungan yang membantu memisahkan representasi internal informasi dari informasi yang disajikan atau diterima dari pengguna.

Modul Fungsi
Model Enkapsulasi data yang mendasari dan logika bisnis
Kontroler Tanggapi tindakan pengguna dan arahkan aliran aplikasi
Melihat Memformat dan menyajikan data dari model ke pengguna.

Model

Model adalah komponen utama MVC yang secara langsung mengelola data, logika, dan batasan aplikasi. Ini terdiri dari komponen data, yang memelihara data aplikasi mentah dan logika aplikasi untuk antarmuka.

  • Ini adalah antarmuka pengguna independen dan menangkap perilaku domain masalah aplikasi.

  • Ini adalah simulasi perangkat lunak khusus domain atau implementasi dari struktur pusat aplikasi.

  • Ketika telah ada perubahan dalam statusnya, itu memberi pemberitahuan ke tampilan terkait untuk menghasilkan keluaran yang diperbarui dan pengontrol untuk mengubah set perintah yang tersedia.

Melihat

View dapat digunakan untuk merepresentasikan keluaran informasi dalam bentuk grafik seperti diagram atau grafik. Ini terdiri dari komponen presentasi yang memberikan representasi visual dari data

  • Views meminta informasi dari model mereka dan menghasilkan representasi keluaran kepada pengguna.

  • Beberapa tampilan dari informasi yang sama dimungkinkan, seperti diagram batang untuk manajemen dan tampilan tabel untuk akuntan.

Kontroler

Pengontrol menerima masukan dan mengubahnya menjadi perintah untuk model atau tampilan. Ini terdiri dari komponen pemrosesan input yang menangani input dari pengguna dengan memodifikasi model.

  • Ini bertindak sebagai antarmuka antara model dan tampilan terkait dan perangkat input.

  • Itu dapat mengirim perintah ke model untuk memperbarui status model dan ke tampilan terkait untuk mengubah presentasi tampilan model.

MVC - I

Ini adalah versi sederhana dari arsitektur MVC di mana sistem dibagi menjadi dua sub-sistem -

  • The Controller-View - Tampilan pengontrol bertindak sebagai antarmuka input / output dan pemrosesan selesai.

  • The Model - Model ini menyediakan semua layanan data dan domain.

MVC-I Architecture

Modul model memberi tahu modul tampilan pengontrol jika ada perubahan data sehingga tampilan data grafik apa pun akan diubah. Pengontrol juga mengambil tindakan yang tepat atas perubahan tersebut.

Hubungan antara controller-view dan model dapat dirancang dalam pola (seperti yang ditunjukkan pada gambar di atas) dari subscribe-notify dimana controller-view berlangganan model dan model memberi tahu controller-view jika ada perubahan.

MVC - II

MVC – II merupakan peningkatan dari arsitektur MVC-I yang memisahkan modul tampilan dan modul pengontrol. Modul model berperan aktif seperti pada MVC-I dengan menyediakan semua fungsionalitas inti dan data yang didukung oleh database.

Modul tampilan menyajikan data sementara modul pengontrol menerima permintaan masukan, memvalidasi data masukan, memulai model, tampilan, koneksinya, dan juga mengirimkan tugas.

MVC-II Architecture

Aplikasi MVC

Aplikasi MVC efektif untuk aplikasi interaktif di mana beberapa tampilan diperlukan untuk satu model data dan mudah untuk memasang tampilan antarmuka baru atau mengubah.

Aplikasi MVC cocok untuk aplikasi di mana terdapat divisi yang jelas antara modul sehingga profesional yang berbeda dapat ditugaskan untuk mengerjakan aspek yang berbeda dari aplikasi tersebut secara bersamaan.

Advantages

  • Ada banyak toolkit kerangka kerja vendor MVC yang tersedia.

  • Beberapa tampilan disinkronkan dengan model data yang sama.

  • Mudah untuk memasang plugin baru atau mengganti tampilan antarmuka.

  • Digunakan untuk pengembangan aplikasi di mana profesional keahlian grafis, profesional pemrograman, dan profesional pengembangan basis data bekerja dalam tim proyek yang dirancang.

Disadvantages

  • Tidak cocok untuk aplikasi berorientasi agen seperti aplikasi seluler dan robotika interaktif.

  • Beberapa pasang pengontrol dan tampilan berdasarkan model data yang sama membuat perubahan model data menjadi mahal.

  • Pembagian antara View dan Controller tidak jelas dalam beberapa kasus.

Presentation-Abstraction-Control (PAC)

Dalam PAC, sistem diatur menjadi hierarki dari banyak agen yang bekerja sama (triad). Ini dikembangkan dari MVC untuk mendukung persyaratan aplikasi beberapa agen selain persyaratan interaktif.

Setiap agen memiliki tiga komponen -

  • The presentation component - Memformat presentasi data visual dan audio.

  • The abstraction component - Mengambil dan memproses data.

  • The control component - Menangani tugas seperti aliran kendali dan komunikasi antara dua komponen lainnya.

Arsitektur PAC mirip dengan MVC, dalam arti modul presentasi seperti modul tampilan MVC. Modul abstraksi terlihat seperti modul model MVC dan modul kontrol seperti modul pengontrol MVC, tetapi mereka berbeda dalam aliran kontrol dan organisasinya.

Tidak ada hubungan langsung antara komponen abstraksi dan komponen presentasi di setiap agen. Komponen kontrol di setiap agen bertanggung jawab atas komunikasi dengan agen lain.

Gambar berikut menunjukkan diagram blok untuk agen tunggal dalam desain PAC.

PAC dengan Banyak Agen

Dalam PAC yang terdiri dari beberapa agen, agen tingkat atas menyediakan data inti dan logika bisnis. Agen tingkat bawah menentukan data dan presentasi spesifik yang terperinci. Agen level menengah atau menengah bertindak sebagai koordinator agen level rendah.

  • Setiap agen memiliki tugas khusus masing-masing.

  • Untuk beberapa agen tingkat menengah, presentasi interaktif tidak diperlukan, sehingga mereka tidak memiliki komponen presentasi.

  • Komponen kontrol diperlukan untuk semua agen yang melaluinya semua agen berkomunikasi satu sama lain.

Gambar berikut menunjukkan Beberapa Agen yang mengambil bagian dalam PAC.

Applications

  • Efektif untuk sistem interaktif di mana sistem tersebut dapat diuraikan menjadi banyak agen yang bekerja sama secara hierarkis.

  • Efektif bila kopling antar agen diharapkan lepas sehingga perubahan pada agen tidak mempengaruhi yang lain.

  • Efektif untuk sistem terdistribusi di mana semua agen terdistribusi jauh dan masing-masing memiliki fungsi sendiri dengan data dan antarmuka interaktif.

  • Cocok untuk aplikasi dengan komponen GUI yang kaya di mana masing-masing menyimpan datanya sendiri saat ini dan antarmuka interaktif dan perlu berkomunikasi dengan komponen lain.

Keuntungan

  • Dukungan untuk multi-tasking dan multi-viewing

  • Dukungan untuk penggunaan kembali dan perpanjangan agen

  • Mudah untuk memasukkan agen baru atau mengubah yang sudah ada

  • Dukungan untuk konkurensi di mana beberapa agen berjalan secara paralel di utas berbeda atau perangkat atau komputer berbeda

Kekurangan

  • Overhead karena jembatan kontrol antara presentasi dan abstraksi dan komunikasi kontrol di antara agen.

  • Sulit untuk menentukan jumlah agen yang tepat karena kopling longgar dan kemandirian yang tinggi antar agen.

  • Pemisahan lengkap presentasi dan abstraksi dengan kontrol di setiap agen menghasilkan kompleksitas pengembangan karena komunikasi antar agen hanya terjadi di antara kontrol agen

Dalam arsitektur terdistribusi, komponen disajikan pada platform yang berbeda dan beberapa komponen dapat bekerja sama satu sama lain melalui jaringan komunikasi untuk mencapai tujuan atau sasaran tertentu.

  • Dalam arsitektur ini, pemrosesan informasi tidak terbatas pada satu mesin melainkan didistribusikan melalui beberapa komputer independen.

  • Sistem terdistribusi dapat ditunjukkan oleh arsitektur klien-server yang membentuk basis untuk arsitektur multi-tier; alternatif adalah arsitektur broker seperti CORBA, dan Service-Oriented Architecture (SOA).

  • Ada beberapa kerangka kerja teknologi untuk mendukung arsitektur terdistribusi, termasuk .NET, J2EE, CORBA, layanan Web .NET, layanan Web Java AXIS, dan layanan Globus Grid.

  • Middleware adalah infrastruktur yang mendukung pengembangan dan pelaksanaan aplikasi terdistribusi dengan tepat. Ini menyediakan penyangga antara aplikasi dan jaringan.

  • Itu berada di tengah sistem dan mengelola atau mendukung berbagai komponen sistem terdistribusi. Contohnya adalah monitor pemrosesan transaksi, konverter data dan pengontrol komunikasi, dll.

Middleware sebagai infrastruktur untuk sistem terdistribusi

Basis arsitektur terdistribusi adalah transparansi, keandalan, dan ketersediaannya.

Tabel berikut mencantumkan berbagai bentuk transparansi dalam sistem terdistribusi -

Sr.No. Transparansi & Deskripsi
1

Access

Menyembunyikan cara sumber daya diakses dan perbedaan platform data.
2

Location

Menyembunyikan di mana sumber daya berada.
3

Technology

Menyembunyikan berbagai teknologi seperti bahasa pemrograman dan OS dari pengguna.
4

Migration / Relocation

Sembunyikan sumber daya yang mungkin dipindahkan ke lokasi lain yang sedang digunakan.
5

Replication

Sembunyikan sumber daya yang mungkin disalin di beberapa lokasi.
6

Concurrency

Sembunyikan sumber daya yang mungkin dibagikan dengan pengguna lain.
7

Failure

Menyembunyikan kegagalan dan pemulihan sumber daya dari pengguna.
8

Persistence

Menyembunyikan apakah sumber daya (perangkat lunak) ada dalam memori atau disk.

Keuntungan

  • Resource sharing - Berbagi sumber daya perangkat keras dan perangkat lunak.

  • Openness - Fleksibilitas penggunaan perangkat keras dan perangkat lunak dari vendor yang berbeda.

  • Concurrency - Pemrosesan bersamaan untuk meningkatkan kinerja.

  • Scalability - Meningkatkan throughput dengan menambahkan sumber daya baru.

  • Fault tolerance - Kemampuan untuk melanjutkan pengoperasian setelah terjadi kesalahan.

Kekurangan

  • Complexity - Mereka lebih kompleks daripada sistem terpusat.

  • Security - Lebih rentan terhadap serangan eksternal.

  • Manageability - Dibutuhkan lebih banyak usaha untuk manajemen sistem.

  • Unpredictability - Tanggapan tak terduga tergantung pada organisasi sistem dan beban jaringan.

Sistem Terpusat vs. Sistem Terdistribusi

Kriteria Sistem terpusat Sistem Terdistribusi
Ekonomi Rendah Tinggi
Ketersediaan Rendah Tinggi
Kompleksitas Rendah Tinggi
Konsistensi Sederhana Tinggi
Skalabilitas Miskin Baik
Teknologi Homogen Heterogen
Keamanan Tinggi Rendah

Arsitektur Client-Server

Arsitektur klien-server adalah arsitektur sistem terdistribusi paling umum yang menguraikan sistem menjadi dua subsistem utama atau proses logis -

  • Client - Ini adalah proses pertama yang mengeluarkan permintaan ke proses kedua yaitu server.

  • Server - Ini adalah proses kedua yang menerima permintaan, menjalankannya, dan mengirimkan balasan ke klien.

Dalam arsitektur ini, aplikasi dimodelkan sebagai sekumpulan layanan yang disediakan oleh server dan sekumpulan klien yang menggunakan layanan ini. Server tidak perlu tahu tentang klien, tetapi klien harus mengetahui identitas server, dan pemetaan prosesor ke proses belum tentu 1: 1

Arsitektur klien-server dapat diklasifikasikan menjadi dua model berdasarkan fungsionalitas klien -

Model klien tipis

Dalam model klien tipis, semua pemrosesan aplikasi dan manajemen data dilakukan oleh server. Klien hanya bertanggung jawab untuk menjalankan perangkat lunak presentasi.

  • Digunakan saat sistem lawas dimigrasi ke arsitektur server klien di mana sistem lawas bertindak sebagai server dalam dirinya sendiri dengan antarmuka grafis yang diterapkan pada klien

  • Kerugian utama adalah bahwa ia menempatkan beban pemrosesan yang berat pada server dan jaringan.

Model tebal / klien gemuk

Dalam model thick-client, server hanya bertanggung jawab atas pengelolaan data. Perangkat lunak pada klien mengimplementasikan logika aplikasi dan interaksi dengan pengguna sistem.

  • Paling sesuai untuk sistem C / S baru yang kapabilitas sistem klien telah diketahui sebelumnya

  • Lebih kompleks daripada model klien tipis terutama untuk manajemen. Versi baru aplikasi harus diinstal di semua klien.

Keuntungan

  • Pemisahan tanggung jawab seperti presentasi antarmuka pengguna dan pemrosesan logika bisnis.

  • Dapat digunakan kembali komponen server dan potensi konkurensi

  • Menyederhanakan desain dan pengembangan aplikasi terdistribusi

  • Itu membuatnya mudah untuk memigrasi atau mengintegrasikan aplikasi yang ada ke dalam lingkungan terdistribusi.

  • Itu juga membuat penggunaan sumber daya secara efektif ketika sejumlah besar klien mengakses server berkinerja tinggi.

Kekurangan

  • Kurangnya infrastruktur heterogen untuk menghadapi perubahan kebutuhan.

  • Komplikasi keamanan.

  • Ketersediaan dan keandalan server terbatas.

  • Testabilitas dan skalabilitas terbatas.

  • Klien gemuk dengan presentasi dan logika bisnis bersama.

Arsitektur Multi-Tier (Arsitektur n-tier)

Arsitektur multi-tier adalah arsitektur client-server di mana fungsi-fungsi seperti presentasi, pemrosesan aplikasi, dan manajemen data dipisahkan secara fisik. Dengan memisahkan aplikasi menjadi beberapa tingkatan, pengembang mendapatkan opsi untuk mengubah atau menambahkan lapisan tertentu, daripada mengerjakan ulang seluruh aplikasi. Ini memberikan model dimana pengembang dapat membuat aplikasi yang fleksibel dan dapat digunakan kembali.

Penggunaan arsitektur multi-tier yang paling umum adalah arsitektur three-tier. Arsitektur tiga tingkat biasanya terdiri dari tingkat presentasi, tingkat aplikasi, dan tingkat penyimpanan data dan dapat dijalankan pada prosesor terpisah.

Tingkat Presentasi

Lapisan presentasi adalah level aplikasi teratas yang dapat diakses pengguna secara langsung seperti halaman web atau Sistem Operasi GUI (Antarmuka Pengguna Grafis). Fungsi utama lapisan ini adalah menerjemahkan tugas dan hasil menjadi sesuatu yang dapat dipahami pengguna. Ini berkomunikasi dengan tingkatan lain sehingga menempatkan hasil ke tingkat browser / klien dan semua tingkatan lainnya di jaringan.

Tingkat Aplikasi (Logika Bisnis, Tingkat Logika, atau Tingkat Tengah)

Tingkatan aplikasi mengoordinasikan aplikasi, memproses perintah, membuat keputusan logis, mengevaluasi, dan melakukan perhitungan. Ini mengontrol fungsionalitas aplikasi dengan melakukan pemrosesan terperinci. Itu juga memindahkan dan memproses data antara dua lapisan sekitarnya.

Tingkat Data

Dalam lapisan ini, informasi disimpan dan diambil dari database atau sistem file. Informasi tersebut kemudian diteruskan kembali untuk diproses dan kemudian kembali ke pengguna. Ini mencakup mekanisme persistensi data (server basis data, berbagi file, dll.) Dan menyediakan API (Antarmuka Pemrograman Aplikasi) ke tingkat aplikasi yang menyediakan metode pengelolaan data yang disimpan.

Advantages

  • Kinerja yang lebih baik daripada pendekatan klien-tipis dan lebih sederhana untuk dikelola daripada pendekatan klien-tebal.

  • Meningkatkan penggunaan kembali dan skalabilitas - seiring meningkatnya permintaan, server tambahan dapat ditambahkan.

  • Memberikan dukungan multi-threading dan juga mengurangi lalu lintas jaringan.

  • Memberikan pemeliharaan dan fleksibilitas

Disadvantages

  • Testability yang Tidak Memuaskan karena kurangnya alat pengujian.

  • Keandalan dan ketersediaan server yang lebih penting.

Gaya Arsitektur Broker

Gaya Arsitektur Broker adalah arsitektur middleware yang digunakan dalam komputasi terdistribusi untuk mengoordinasikan dan mengaktifkan komunikasi antara server terdaftar dan klien. Di sini, komunikasi objek terjadi melalui sistem middleware yang disebut broker permintaan objek (bus perangkat lunak).

  • Klien dan server tidak berinteraksi satu sama lain secara langsung. Klien dan server memiliki koneksi langsung ke proxy-nya yang berkomunikasi dengan broker-mediator.

  • Sebuah server menyediakan layanan dengan mendaftarkan dan mempublikasikan antarmuka mereka dengan broker dan klien dapat meminta layanan dari broker secara statis atau dinamis dengan pencarian.

  • CORBA (Common Object Request Broker Architecture) adalah contoh implementasi yang baik dari arsitektur broker.

Komponen Gaya Arsitektur Broker

Komponen gaya arsitektur broker dibahas melalui kepala berikut -

Broker

Broker bertanggung jawab untuk mengkoordinasikan komunikasi, seperti meneruskan dan mengirimkan hasil dan pengecualian. Ini bisa berupa layanan yang berorientasi pada permintaan, dokumen atau broker berorientasi pesan dimana klien mengirim pesan.

  • Ini bertanggung jawab untuk memperantarai permintaan layanan, menemukan server yang tepat, mengirimkan permintaan, dan mengirim tanggapan kembali ke klien.

  • Ini menyimpan informasi pendaftaran server termasuk fungsionalitas dan layanannya serta informasi lokasi.

  • Ini menyediakan API untuk diminta klien, server untuk merespons, mendaftarkan atau membatalkan registrasi komponen server, mentransfer pesan, dan menemukan server.

Stub

Stub dibuat pada waktu kompilasi statis dan kemudian disebarkan ke sisi klien yang digunakan sebagai proxy untuk klien. Proksi sisi klien bertindak sebagai mediator antara klien dan broker dan memberikan transparansi tambahan antara mereka dan klien; objek jarak jauh tampak seperti objek lokal.

Proksi menyembunyikan IPC (komunikasi antar-proses) pada tingkat protokol dan melakukan pengaturan nilai parameter dan un-marshaling hasil dari server.

Skeleton

Kerangka dibuat oleh kompilasi antarmuka layanan dan kemudian disebarkan ke sisi server, yang digunakan sebagai proxy untuk server. Proksi sisi server merangkum fungsi jaringan khusus sistem tingkat rendah dan menyediakan API tingkat tinggi untuk menengahi antara server dan pialang.

Ia menerima permintaan, membongkar permintaan, mengurai argumen metode, memanggil layanan yang sesuai, dan juga menyusun hasil sebelum mengirimnya kembali ke klien.

Bridge

Sebuah jembatan dapat menghubungkan dua jaringan yang berbeda berdasarkan pada protokol komunikasi yang berbeda. Ini menengahi berbagai broker termasuk DCOM, .NET remote, dan broker Java CORBA.

Bridges adalah komponen opsional, yang menyembunyikan detail implementasi ketika dua broker saling beroperasi dan mengambil permintaan dan parameter dalam satu format dan menerjemahkannya ke format lain.

Broker implementation in CORBA

CORBA adalah standar internasional untuk Broker Permintaan Objek - middleware untuk mengelola komunikasi di antara objek terdistribusi yang ditentukan oleh OMG (grup manajemen objek).

Arsitektur Berorientasi Layanan (SOA)

Layanan adalah komponen fungsionalitas bisnis yang terdefinisi dengan baik, mandiri, independen, diterbitkan, dan tersedia untuk digunakan melalui antarmuka pemrograman standar. Sambungan antara layanan dilakukan oleh protokol umum dan universal berorientasi pesan seperti protokol layanan Web SOAP, yang dapat mengirimkan permintaan dan tanggapan antara layanan secara longgar.

Arsitektur berorientasi layanan adalah desain klien / server yang mendukung pendekatan TI berbasis bisnis di mana aplikasi terdiri dari layanan perangkat lunak dan konsumen layanan perangkat lunak (juga dikenal sebagai klien atau peminta layanan).

Fitur SOA

Arsitektur berorientasi layanan menyediakan fitur-fitur berikut -

  • Distributed Deployment - Mengekspos data perusahaan dan logika bisnis sebagai unit fungsionalitas tanpa status, digabungkan, dapat ditemukan, terstruktur, berbasis standar, berbutir kasar, dan tanpa kewarganegaraan yang disebut layanan.

  • Composability - Kumpulkan proses baru dari layanan yang ada yang diekspos pada perincian yang diinginkan melalui antarmuka pengaduan yang terdefinisi dengan baik, dipublikasikan, dan standar.

  • Interoperability - Berbagi kemampuan dan menggunakan kembali layanan bersama di seluruh jaringan terlepas dari protokol atau teknologi implementasi yang mendasarinya.

  • Reusability - Pilih penyedia layanan dan akses ke sumber daya yang ada yang diekspos sebagai layanan.

Operasi SOA

Gambar berikut mengilustrasikan bagaimana SOA beroperasi -

Advantages

  • Kopling longgar dari orientasi layanan memberikan fleksibilitas besar bagi perusahaan untuk memanfaatkan semua sumber layanan yang tersedia terlepas dari batasan platform dan teknologi.

  • Setiap komponen layanan independen dari layanan lain karena fitur layanan stateless.

  • Implementasi layanan tidak akan memengaruhi penerapan layanan selama antarmuka yang diekspos tidak diubah.

  • Klien atau layanan apa pun dapat mengakses layanan lain apa pun platform, teknologi, vendor, atau implementasi bahasanya.

  • Dapat digunakan kembali aset dan layanan karena klien suatu layanan hanya perlu mengetahui antarmuka publiknya, komposisi layanannya.

  • Pengembangan aplikasi bisnis berbasis SOA jauh lebih efisien dari segi waktu dan biaya.

  • Meningkatkan skalabilitas dan menyediakan koneksi standar antar sistem.

  • Penggunaan 'Layanan Bisnis' yang efisien dan efektif.

  • Integrasi menjadi lebih mudah dan meningkatkan interoperabilitas intrinsik.

  • Kompleksitas abstrak untuk pengembang dan mendorong proses bisnis lebih dekat ke pengguna akhir.

Arsitektur berbasis komponen berfokus pada penguraian desain menjadi komponen fungsional atau logis individu yang mewakili antarmuka komunikasi terdefinisi dengan baik yang berisi metode, peristiwa, dan properti. Ini memberikan tingkat abstraksi yang lebih tinggi dan membagi masalah menjadi sub-masalah, masing-masing terkait dengan partisi komponen.

Tujuan utama dari arsitektur berbasis komponen adalah untuk memastikan component reusability. Komponen merangkum fungsionalitas dan perilaku elemen perangkat lunak menjadi unit biner yang dapat digunakan kembali dan dapat diterapkan sendiri. Ada banyak kerangka kerja komponen standar seperti COM / DCOM, JavaBean, EJB, CORBA, .NET, layanan web, dan layanan grid. Teknologi ini banyak digunakan dalam desain aplikasi GUI desktop lokal seperti komponen grafis JavaBean, komponen MS ActiveX, dan komponen COM yang dapat digunakan kembali hanya dengan operasi seret dan lepas.

Desain perangkat lunak berorientasi komponen memiliki banyak keunggulan dibandingkan pendekatan berorientasi objek tradisional seperti -

  • Mengurangi waktu di pasar dan biaya pengembangan dengan menggunakan kembali komponen yang ada.

  • Peningkatan keandalan dengan penggunaan kembali komponen yang ada.

Apa itu Komponen?

Komponen adalah sekumpulan fungsionalitas yang terdefinisi dengan baik yang modular, portabel, dapat diganti, dan dapat digunakan kembali yang merangkum implementasinya dan mengekspornya sebagai antarmuka tingkat yang lebih tinggi.

Komponen adalah objek perangkat lunak, dimaksudkan untuk berinteraksi dengan komponen lain, merangkum fungsionalitas tertentu atau sekumpulan fungsi. Ini memiliki antarmuka yang jelas dan sesuai dengan perilaku yang direkomendasikan umum untuk semua komponen dalam arsitektur.

Komponen perangkat lunak dapat didefinisikan sebagai unit komposisi dengan antarmuka yang ditentukan secara kontrak dan hanya ketergantungan konteks eksplisit. Artinya, komponen perangkat lunak dapat diterapkan secara independen dan diatur oleh pihak ketiga.

Tampilan sebuah Komponen

Sebuah komponen dapat memiliki tiga tampilan berbeda - tampilan berorientasi objek, tampilan konvensional, dan tampilan terkait proses.

Object-oriented view

Sebuah komponen dipandang sebagai satu set dari satu atau lebih kelas yang bekerja sama. Setiap kelas domain masalah (analisis) dan kelas infrastruktur (desain) dijelaskan untuk mengidentifikasi semua atribut dan operasi yang berlaku untuk implementasinya. Ini juga melibatkan pendefinisian antarmuka yang memungkinkan kelas untuk berkomunikasi dan bekerja sama.

Conventional view

Ini dipandang sebagai elemen fungsional atau modul program yang mengintegrasikan logika pemrosesan, struktur data internal yang diperlukan untuk mengimplementasikan logika pemrosesan dan antarmuka yang memungkinkan komponen dipanggil dan data untuk diteruskan ke sana.

Process-related view

Dalam tampilan ini, alih-alih membuat setiap komponen dari awal, sistem membangun dari komponen yang ada yang dikelola di pustaka. Saat arsitektur perangkat lunak dirumuskan, komponen dipilih dari perpustakaan dan digunakan untuk mengisi arsitektur.

  • Komponen antarmuka pengguna (UI) mencakup kisi, tombol yang disebut kontrol, dan komponen utilitas memperlihatkan subset fungsi tertentu yang digunakan dalam komponen lain.

  • Jenis komponen umum lainnya adalah yang intensif sumber daya, tidak sering diakses, dan harus diaktifkan menggunakan pendekatan just-in-time (JIT).

  • Banyak komponen tidak terlihat yang didistribusikan dalam aplikasi bisnis perusahaan dan aplikasi web internet seperti Enterprise JavaBean (EJB), komponen .NET, dan komponen CORBA.

Karakteristik Komponen

  • Reusability- Komponen biasanya dirancang untuk digunakan kembali dalam situasi yang berbeda dalam aplikasi yang berbeda. Namun, beberapa komponen mungkin dirancang untuk tugas tertentu.

  • Replaceable - Komponen dapat diganti secara bebas dengan komponen serupa lainnya.

  • Not context specific - Komponen dirancang untuk beroperasi di lingkungan dan konteks yang berbeda.

  • Extensible - Sebuah komponen dapat diperpanjang dari komponen yang ada untuk memberikan perilaku baru.

  • Encapsulated - Komponen AA menggambarkan antarmuka, yang memungkinkan pemanggil untuk menggunakan fungsinya, dan tidak mengungkapkan detail proses internal atau variabel atau status internal apa pun.

  • Independent - Komponen dirancang untuk memiliki ketergantungan minimal pada komponen lain.

Prinsip Desain Berbasis Komponen

Sebuah desain level komponen dapat direpresentasikan dengan menggunakan beberapa representasi perantara (misalnya grafis, tabel, atau berbasis teks) yang dapat diterjemahkan ke dalam kode sumber. Desain struktur data, antarmuka, dan algoritme harus sesuai dengan pedoman yang mapan untuk membantu kami menghindari kesalahan.

  • Sistem perangkat lunak diuraikan menjadi unit komponen yang dapat digunakan kembali, kohesif, dan dikemas.

  • Setiap komponen memiliki antarmuka sendiri yang menentukan port yang diperlukan dan port yang disediakan; setiap komponen menyembunyikan implementasinya yang terperinci.

  • Sebuah komponen harus diperpanjang tanpa perlu membuat kode internal atau modifikasi desain pada bagian komponen yang ada.

  • Bergantung pada abstraksi komponen tidak tergantung pada komponen konkret lainnya, yang menambah kesulitan dalam pengeluaran.

  • Konektor menghubungkan komponen, menentukan dan mengatur interaksi antar komponen. Jenis interaksi ditentukan oleh antarmuka komponen.

  • Interaksi komponen dapat berupa pemanggilan metode, pemanggilan asinkron, penyiaran, interaksi berbasis pesan, komunikasi aliran data, dan interaksi khusus protokol lainnya.

  • Untuk kelas server, antarmuka khusus harus dibuat untuk melayani kategori utama klien. Hanya operasi yang relevan dengan kategori klien tertentu yang harus ditentukan di antarmuka.

  • Sebuah komponen dapat diperluas ke komponen lain dan masih menawarkan titik ekstensi sendiri. Ini adalah konsep arsitektur berbasis plug-in. Ini memungkinkan sebuah plugin menawarkan API plugin lain.

Panduan Desain Tingkat Komponen

Membuat konvensi penamaan untuk komponen yang ditetapkan sebagai bagian dari model arsitektur dan kemudian menyempurnakan atau menguraikan sebagai bagian dari model tingkat komponen.

  • Mendapatkan nama komponen arsitektur dari domain masalah dan memastikan bahwa nama tersebut memiliki arti bagi semua pemangku kepentingan yang melihat model arsitektur.

  • Mengekstrak entitas proses bisnis yang dapat ada secara independen tanpa ketergantungan terkait pada entitas lain.

  • Mengenali dan menemukan entitas independen ini sebagai komponen baru.

  • Menggunakan nama komponen infrastruktur yang mencerminkan arti spesifik implementasinya.

  • Memodelkan dependensi apa pun dari kiri ke kanan dan warisan dari atas (kelas dasar) ke bawah (kelas turunan).

  • Buat model dependensi komponen apa pun sebagai antarmuka daripada merepresentasikannya sebagai dependensi komponen-ke-komponen langsung.

Melakukan Desain Tingkat Komponen

Mengenali semua kelas desain yang sesuai dengan domain masalah seperti yang didefinisikan dalam model analisis dan model arsitektur.

  • Mengenali semua kelas desain yang sesuai dengan domain infrastruktur.

  • Menjelaskan semua kelas desain yang tidak diperoleh sebagai komponen yang dapat digunakan kembali, dan menentukan detail pesan.

  • Mengidentifikasi antarmuka yang sesuai untuk setiap komponen dan menguraikan atribut serta menentukan tipe data dan struktur data yang diperlukan untuk mengimplementasikannya.

  • Menjelaskan aliran pemrosesan dalam setiap operasi secara rinci dengan menggunakan kode pseudo atau diagram aktivitas UML.

  • Menjelaskan sumber data persisten (database dan file) dan mengidentifikasi kelas yang diperlukan untuk mengelolanya.

  • Kembangkan dan uraikan representasi perilaku untuk kelas atau komponen. Ini dapat dilakukan dengan menguraikan diagram status UML yang dibuat untuk model analisis dan dengan memeriksa semua kasus penggunaan yang relevan dengan kelas desain.

  • Menguraikan diagram penerapan untuk memberikan detail implementasi tambahan.

  • Mendemonstrasikan lokasi paket kunci atau kelas komponen dalam sistem dengan menggunakan instance kelas dan menentukan perangkat keras dan lingkungan sistem operasi tertentu.

  • Keputusan akhir dapat dibuat dengan menggunakan prinsip dan pedoman desain yang telah ditetapkan. Desainer berpengalaman mempertimbangkan semua (atau sebagian besar) solusi desain alternatif sebelum menetapkan model desain akhir.

Keuntungan

  • Ease of deployment - Saat versi baru yang kompatibel tersedia, lebih mudah untuk mengganti versi yang sudah ada tanpa berdampak pada komponen lain atau sistem secara keseluruhan.

  • Reduced cost - Penggunaan komponen pihak ketiga memungkinkan Anda menyebarkan biaya pengembangan dan pemeliharaan.

  • Ease of development - Komponen mengimplementasikan antarmuka terkenal untuk menyediakan fungsionalitas yang ditentukan, memungkinkan pengembangan tanpa memengaruhi bagian lain dari sistem.

  • Reusable - Penggunaan komponen yang dapat digunakan kembali berarti bahwa mereka dapat digunakan untuk menyebarkan biaya pengembangan dan pemeliharaan ke beberapa aplikasi atau sistem.

  • Modification of technical complexity - Komponen memodifikasi kompleksitas melalui penggunaan wadah komponen dan layanannya.

  • Reliability - Keandalan sistem secara keseluruhan meningkat karena keandalan masing-masing komponen meningkatkan keandalan seluruh sistem melalui penggunaan kembali.

  • System maintenance and evolution - Mudah untuk mengubah dan memperbarui implementasi tanpa mempengaruhi sistem lainnya.

  • Independent- Independensi dan konektivitas komponen yang fleksibel. Pengembangan independen komponen oleh kelompok yang berbeda secara paralel. Produktivitas untuk pengembangan perangkat lunak dan pengembangan perangkat lunak di masa depan.

Antarmuka pengguna adalah kesan pertama dari sistem perangkat lunak dari sudut pandang pengguna. Oleh karena itu, setiap sistem perangkat lunak harus memenuhi kebutuhan pengguna. UI terutama melakukan dua fungsi -

  • Menerima masukan pengguna

  • Menampilkan keluaran

Antarmuka pengguna memainkan peran penting dalam sistem perangkat lunak apa pun. Ini mungkin satu-satunya aspek yang terlihat dari sistem perangkat lunak sebagai -

  • Pengguna awalnya akan melihat arsitektur antarmuka pengguna eksternal sistem perangkat lunak tanpa mempertimbangkan arsitektur internalnya.

  • Antarmuka pengguna yang baik harus menarik pengguna untuk menggunakan sistem perangkat lunak tanpa kesalahan. Ini harus membantu pengguna untuk memahami sistem perangkat lunak dengan mudah tanpa informasi yang menyesatkan. UI yang buruk dapat menyebabkan kegagalan pasar terhadap persaingan sistem perangkat lunak.

  • UI memiliki sintaks dan semantik. Sintaksnya terdiri dari jenis komponen seperti tekstual, ikon, tombol, dll. Dan kegunaan merangkum semantik UI. Kualitas UI dicirikan oleh tampilan dan nuansanya (sintaksis) dan kegunaannya (semantik).

  • Pada dasarnya ada dua jenis antarmuka pengguna - a) Tekstual b) Grafis.

  • Perangkat lunak dalam domain yang berbeda mungkin memerlukan gaya antarmuka penggunanya yang berbeda, misalnya kalkulator hanya memerlukan area kecil untuk menampilkan angka numerik, tetapi area yang luas untuk perintah, Halaman web memerlukan formulir, tautan, tab, dll.

Antarmuka Pengguna Grafis

Antarmuka pengguna grafis adalah jenis antarmuka pengguna yang paling umum tersedia saat ini. Ini sangat ramah pengguna karena menggunakan gambar, grafik, dan ikon - karena itulah disebut 'grafis'.

Ini juga dikenal sebagai WIMP interface karena itu memanfaatkan -

  • Windows - Area persegi panjang di layar tempat menjalankan aplikasi yang umum digunakan.

  • Icons - Gambar atau simbol yang digunakan untuk mewakili aplikasi perangkat lunak atau perangkat keras.

  • Menus - Daftar opsi di mana pengguna dapat memilih apa yang mereka butuhkan.

  • Pointers- Simbol seperti panah yang bergerak di sekitar layar saat pengguna menggerakkan mouse. Ini membantu pengguna untuk memilih objek.

Desain Antarmuka Pengguna

Ini dimulai dengan analisis tugas yang memahami tugas utama pengguna dan domain masalah. Ini harus dirancang dalam istilah terminologi Pengguna dan permulaan pekerjaan pengguna daripada programmer.

  • Untuk melakukan analisis antarmuka pengguna, praktisi perlu mempelajari dan memahami empat elemen -

    • Itu users yang akan berinteraksi dengan sistem melalui antarmuka

    • Itu tasks yang harus dilakukan oleh pengguna akhir untuk melakukan pekerjaan mereka

    • Itu content yang disajikan sebagai bagian dari antarmuka

    • Itu work environment di mana tugas-tugas ini akan dilakukan

  • Desain UI yang tepat atau baik bekerja dari kemampuan dan keterbatasan pengguna, bukan dari mesin. Saat merancang UI, pengetahuan tentang sifat pekerjaan dan lingkungan pengguna juga penting.

  • Tugas yang akan dilakukan kemudian dapat dibagi-bagi yang diberikan kepada pengguna atau mesin, berdasarkan pengetahuan tentang kapabilitas dan keterbatasan masing-masing. Desain antarmuka pengguna sering kali dibagi menjadi empat level berbeda -

    • The conceptual level - Ini menjelaskan entitas dasar yang mempertimbangkan pandangan pengguna tentang sistem dan tindakan yang mungkin dilakukan padanya.

    • The semantic level - Ini menjelaskan fungsi yang dilakukan oleh sistem, yaitu deskripsi persyaratan fungsional sistem, tetapi tidak membahas bagaimana pengguna akan memanggil fungsi tersebut.

    • The syntactic level - Ini menjelaskan urutan input dan output yang diperlukan untuk menjalankan fungsi yang dijelaskan.

    • The lexical level - Ini menentukan bagaimana input dan output sebenarnya dibentuk dari operasi perangkat keras primitif.

  • Desain antarmuka pengguna adalah proses berulang, di mana semua iterasi menjelaskan dan menyempurnakan informasi yang dikembangkan di langkah sebelumnya. Langkah-langkah umum untuk desain antarmuka pengguna

    • Mendefinisikan objek antarmuka pengguna dan tindakan (operasi).

    • Mendefinisikan peristiwa (tindakan pengguna) yang akan menyebabkan keadaan antarmuka pengguna berubah.

    • Menunjukkan bagaimana pengguna menafsirkan keadaan sistem dari informasi yang disediakan melalui antarmuka.

    • Jelaskan setiap status antarmuka seperti yang akan dilihat oleh pengguna akhir.

    Proses Pengembangan Antarmuka Pengguna

    Ini mengikuti proses spiral seperti yang ditunjukkan pada diagram berikut -

    Interface analysis

    Ini berkonsentrasi atau berfokus pada pengguna, tugas, konten, dan lingkungan kerja yang akan berinteraksi dengan sistem. Mendefinisikan tugas berorientasi manusia dan komputer yang diperlukan untuk mencapai fungsi sistem.

    Interface design

    Ini mendefinisikan satu set objek antarmuka, tindakan, dan representasi layar mereka yang memungkinkan pengguna untuk melakukan semua tugas yang ditentukan dengan cara yang memenuhi setiap tujuan kegunaan yang ditentukan untuk sistem.

    Interface construction

    Ini dimulai dengan prototipe yang memungkinkan skenario penggunaan dievaluasi dan dilanjutkan dengan alat pengembangan untuk menyelesaikan konstruksi.

    Interface validation

    Ini berfokus pada kemampuan antarmuka untuk mengimplementasikan setiap tugas pengguna dengan benar, mengakomodasi semua variasi tugas, untuk mencapai semua persyaratan pengguna umum, dan sejauh mana antarmuka mudah digunakan dan mudah dipelajari.

    User Interface Models

    Ketika antarmuka pengguna dianalisis dan dirancang, empat model berikut digunakan -

    User profile model

    • Dibuat oleh pengguna atau insinyur perangkat lunak, yang menetapkan profil pengguna akhir sistem berdasarkan usia, jenis kelamin, kemampuan fisik, pendidikan, motivasi, tujuan, dan kepribadian.

    • Mempertimbangkan pengetahuan sintaksis dan semantik pengguna dan mengklasifikasikan pengguna sebagai pemula, berpengetahuan intermiten, dan pengguna sering yang berpengetahuan luas.

    Design model

    • Dibuat oleh seorang insinyur perangkat lunak yang menggabungkan representasi data, arsitektur, antarmuka, dan prosedural dari perangkat lunak.

    • Berasal dari model analisis kebutuhan dan dikendalikan oleh informasi dalam spesifikasi kebutuhan yang membantu dalam mendefinisikan pengguna sistem.

    Implementation model

    • Dibuat oleh pelaksana perangkat lunak yang mengerjakan tampilan dan nuansa antarmuka yang dikombinasikan dengan semua informasi pendukung (buku, video, file bantuan) yang menjelaskan sintaks dan semantik sistem.

    • Berfungsi sebagai terjemahan dari model desain dan upaya untuk menyetujui model mental pengguna sehingga pengguna kemudian merasa nyaman dengan perangkat lunak dan menggunakannya secara efektif.

    User's mental model

    • Dibuat oleh pengguna saat berinteraksi dengan aplikasi. Ini berisi gambar sistem yang dibawa pengguna di kepala mereka.

    • Seringkali disebut persepsi sistem pengguna dan kebenaran deskripsi tergantung pada profil pengguna dan keakraban secara keseluruhan dengan perangkat lunak dalam domain aplikasi.

    Pertimbangan Desain Antarmuka Pengguna

    Berpusat pada pengguna

    Antarmuka pengguna harus merupakan produk yang berpusat pada pengguna yang melibatkan pengguna di sepanjang siklus pengembangan produk. Prototipe antarmuka pengguna harus tersedia untuk pengguna dan umpan balik dari pengguna, harus dimasukkan ke dalam produk akhir.

    Sederhana dan Intuitif

    UI memberikan kesederhanaan dan intuisi sehingga dapat digunakan dengan cepat dan efektif tanpa instruksi. GUI lebih baik daripada UI tekstual, karena GUI terdiri dari menu, jendela, dan tombol dan dioperasikan hanya dengan menggunakan mouse.

    Tempatkan Pengguna dalam Kontrol

    Jangan paksa pengguna untuk menyelesaikan urutan yang telah ditentukan sebelumnya. Beri mereka pilihan — untuk membatalkan atau menyimpan dan kembali ke tempat mereka tinggalkan. Gunakan istilah di seluruh antarmuka yang dapat dipahami pengguna, daripada istilah sistem atau pengembang.

    Memberi pengguna beberapa indikasi bahwa suatu tindakan telah dilakukan, baik dengan menunjukkan hasil tindakan kepada mereka, atau mengakui bahwa tindakan tersebut telah berhasil dilakukan.

    Transparansi

    UI harus transparan yang membantu pengguna merasa seperti sedang menjangkau langsung melalui komputer dan secara langsung memanipulasi objek yang sedang mereka kerjakan. Antarmuka dapat dibuat transparan dengan memberikan objek kerja kepada pengguna daripada objek sistem. Misalnya, pengguna harus memahami bahwa kata sandi sistem mereka setidaknya harus terdiri dari 6 karakter, bukan berapa byte penyimpanan yang harus dimiliki kata sandi.

    Gunakan pengungkapan progresif

    Selalu berikan akses mudah ke fitur umum dan tindakan yang sering digunakan. Sembunyikan fitur dan tindakan yang kurang umum dan izinkan pengguna untuk menavigasinya. Jangan mencoba memasukkan setiap informasi ke dalam satu jendela utama. Gunakan jendela sekunder untuk informasi yang bukan informasi kunci.

    Konsistensi

    UI menjaga konsistensi di dalam dan di seluruh produk, menjaga hasil interaksi tetap sama, perintah dan menu UI harus memiliki format yang sama, tanda baca perintah harus serupa dan parameter harus diteruskan ke semua perintah dengan cara yang sama. UI tidak boleh memiliki perilaku yang dapat mengejutkan pengguna dan harus menyertakan mekanisme yang memungkinkan pengguna untuk pulih dari kesalahan mereka.

    Integrasi

    Sistem perangkat lunak harus berintegrasi dengan lancar dengan aplikasi lain seperti MS notepad dan MS-Office. Itu dapat menggunakan perintah Clipboard secara langsung untuk melakukan pertukaran data.

    Berorientasi Komponen

    Desain UI harus modular dan menggabungkan arsitektur berorientasi komponen sehingga desain UI akan memiliki persyaratan yang sama seperti desain bodi utama sistem perangkat lunak. Modul dapat dengan mudah dimodifikasi dan diganti tanpa mempengaruhi bagian lain dari sistem.

    Dapat disesuaikan

    Arsitektur sistem perangkat lunak secara keseluruhan menggabungkan modul plug-in, yang memungkinkan banyak orang yang berbeda secara mandiri memperluas perangkat lunak. Ini memungkinkan pengguna individu untuk memilih dari berbagai bentuk yang tersedia untuk menyesuaikan preferensi dan kebutuhan pribadi.

    Kurangi Beban Memori Pengguna

    Jangan memaksa pengguna untuk mengingat dan mengulangi apa yang seharusnya dilakukan komputer untuk mereka. Misalnya, saat mengisi formulir online, nama pelanggan, alamat, dan nomor telepon harus diingat oleh sistem setelah pengguna memasukkannya, atau setelah catatan pelanggan dibuka.

    Antarmuka pengguna mendukung pengambilan memori jangka panjang dengan menyediakan item kepada pengguna untuk dikenali daripada harus mengingat informasi.

    Pemisahan

    UI harus dipisahkan dari logika sistem melalui penerapannya untuk meningkatkan penggunaan kembali dan pemeliharaan.

    Pendekatan Iteratif dan Incremental

    Ini adalah pendekatan iteratif dan inkremental yang terdiri dari lima langkah utama yang membantu menghasilkan solusi kandidat. Solusi kandidat ini selanjutnya dapat disempurnakan dengan mengulangi langkah-langkah ini dan akhirnya membuat desain arsitektur yang paling sesuai dengan aplikasi kita. Di akhir proses, kami dapat meninjau dan mengkomunikasikan arsitektur kami kepada semua pihak yang berkepentingan.

    Ini hanyalah satu pendekatan yang mungkin. Ada banyak pendekatan lain yang lebih formal yang mendefinisikan, meninjau, dan mengkomunikasikan arsitektur Anda.

    Identifikasi Tujuan Arsitektur

    Identifikasi tujuan arsitektur yang membentuk proses arsitektur dan desain. Tujuan yang sempurna dan terdefinisi menekankan pada arsitektur, menyelesaikan masalah yang tepat dalam desain dan membantu menentukan kapan fase saat ini telah selesai, dan siap untuk pindah ke fase berikutnya.

    Langkah ini mencakup kegiatan berikut -

    • Identifikasi tujuan arsitektur Anda di awal.
    • Identifikasi konsumen arsitektur kami.
    • Identifikasi kendala.

    Contoh aktivitas arsitektur termasuk membangun prototipe untuk mendapatkan umpan balik tentang UI pemrosesan pesanan untuk aplikasi Web, membangun aplikasi pelacakan pesanan pelanggan, dan merancang otentikasi, dan arsitektur otorisasi untuk aplikasi untuk melakukan tinjauan keamanan.

    Skenario Kunci

    Langkah ini menekankan pada desain yang paling penting. Skenario adalah deskripsi ekstensif dan mencakup interaksi pengguna dengan sistem.

    Skenario kunci adalah skenario yang dianggap paling penting untuk keberhasilan aplikasi Anda. Ini membantu untuk membuat keputusan tentang arsitektur. Tujuannya adalah untuk mencapai keseimbangan antara tujuan pengguna, bisnis, dan sistem. Misalnya, autentikasi pengguna adalah skenario kunci karena merupakan perpotongan dari atribut kualitas (keamanan) dengan fungsionalitas penting (cara pengguna masuk ke sistem Anda).

    Ikhtisar Aplikasi

    Buat ikhtisar aplikasi, yang membuat arsitektur lebih mudah disentuh, menghubungkannya dengan batasan dan keputusan dunia nyata. Ini terdiri dari kegiatan berikut -

    Identifikasi Jenis Aplikasi

    Identifikasi jenis aplikasi apakah itu aplikasi seluler, klien kaya, aplikasi internet kaya, layanan, aplikasi web, atau kombinasi dari jenis-jenis ini.

    Identifikasi Kendala Penerapan

    Pilih topologi penyebaran yang sesuai dan selesaikan konflik antara aplikasi dan infrastruktur target.

    Identifikasi Gaya Desain Arsitektur Penting

    Identifikasi gaya desain arsitektur penting seperti klien / server, layered, message-bus, desain domain-driven, dll. Untuk meningkatkan pemartisian dan mempromosikan penggunaan kembali desain dengan memberikan solusi untuk masalah yang sering berulang. Aplikasi sering kali menggunakan kombinasi gaya.

    Identifikasi Teknologi yang Relevan

    Identifikasi teknologi yang relevan dengan mempertimbangkan jenis aplikasi yang kami kembangkan, opsi pilihan kami untuk topologi penerapan aplikasi, dan gaya arsitektur. Pilihan teknologi juga akan diarahkan oleh kebijakan organisasi, keterbatasan infrastruktur, keterampilan sumber daya, dan lain sebagainya.

    Masalah Utama atau Hotspot Utama

    Saat mendesain aplikasi, hot spot adalah zona di mana kesalahan paling sering dibuat. Identifikasi masalah utama berdasarkan atribut kualitas dan masalah lintas sektoral. Masalah potensial termasuk munculnya teknologi baru dan persyaratan bisnis yang kritis.

    Atribut kualitas adalah keseluruhan fitur arsitektur Anda yang memengaruhi perilaku waktu proses, desain sistem, dan pengalaman pengguna. Masalah lintas sektor adalah fitur desain kami yang dapat diterapkan di semua lapisan, komponen, dan tingkatan.

    Ini juga area di mana kesalahan desain berdampak tinggi paling sering dibuat. Contoh masalah lintas sektoral adalah otentikasi dan otorisasi, komunikasi, manajemen konfigurasi, manajemen pengecualian dan validasi, dll.

    Solusi Kandidat

    Setelah menentukan hotspot kunci, buat arsitektur baseline awal atau desain tingkat tinggi pertama, lalu mulai mengisi detail untuk menghasilkan arsitektur kandidat.

    Arsitektur kandidat mencakup jenis aplikasi, arsitektur penerapan, gaya arsitektur, pilihan teknologi, atribut kualitas, dan masalah lintas sektor. Jika arsitektur kandidat merupakan perbaikan, itu bisa menjadi dasar dari mana arsitektur kandidat baru dapat dibuat dan diuji.

    Validasi desain solusi kandidat terhadap skenario dan persyaratan utama yang telah ditentukan, sebelum mengikuti siklus secara berulang dan menyempurnakan desain.

    Kami dapat menggunakan paku arsitektur untuk menemukan area spesifik dari desain atau untuk memvalidasi konsep baru. Paku arsitektur adalah prototipe desain, yang menentukan kelayakan jalur desain tertentu, mengurangi risiko, dan dengan cepat menentukan kelayakan berbagai pendekatan. Uji lonjakan arsitektur terhadap skenario dan hotspot utama.

    Review Arsitektur

    Tinjauan arsitektur adalah tugas terpenting untuk mengurangi biaya kesalahan dan untuk menemukan serta memperbaiki masalah arsitektur sedini mungkin. Ini adalah cara yang mapan dan hemat biaya untuk mengurangi biaya proyek dan kemungkinan kegagalan proyek.

    • Tinjau arsitektur sesering mungkin pada pencapaian proyek besar, dan sebagai tanggapan terhadap perubahan arsitektur signifikan lainnya.

    • Tujuan utama tinjauan arsitektur adalah untuk menentukan kelayakan arsitektur baseline dan kandidat, yang memverifikasi arsitektur dengan benar.

    • Hubungkan persyaratan fungsional dan atribut kualitas dengan solusi teknis yang diusulkan. Ini juga membantu mengidentifikasi masalah dan mengenali area untuk perbaikan

    Evaluasi berbasis skenario adalah metode dominan untuk meninjau desain arsitektur yang berfokus pada skenario yang paling penting dari perspektif bisnis, dan yang memiliki dampak terbesar pada arsitektur. Berikut adalah metodologi tinjauan umum -

    Metode Analisis Arsitektur Perangkat Lunak (SAAM)

    Ini pada awalnya dirancang untuk menilai modifiabilitas, tetapi kemudian diperluas untuk meninjau arsitektur sehubungan dengan atribut kualitas.

    Arsitektur Metode Analisis Tradeoff (ATAM)

    Ini adalah versi SAAM yang dipoles dan ditingkatkan, yang meninjau keputusan arsitektural sehubungan dengan persyaratan atribut kualitas, dan seberapa baik mereka memenuhi tujuan kualitas tertentu.

    Review Desain Aktif (ADR)

    Ini paling cocok untuk arsitektur yang tidak lengkap atau dalam proses, yang lebih fokus pada sekumpulan masalah atau bagian individual dari arsitektur pada satu waktu, daripada melakukan tinjauan umum.

    Review Aktif Desain Intermediate (ARID)

    Ini menggabungkan aspek ADR dari meninjau arsitektur yang sedang berjalan dengan fokus pada serangkaian masalah, dan pendekatan ATAM dan SAAM dari tinjauan berbasis skenario yang berfokus pada atribut kualitas.

    Metode Analisis Manfaat Biaya (CBAM)

    Ini berfokus pada analisis biaya, manfaat, dan implikasi jadwal dari keputusan arsitektur.

    Analisis Tingkat Modifikasi Arsitektur (ALMA)

    Ini memperkirakan modifiabilitas arsitektur untuk sistem informasi bisnis (BIS).

    Metode Penilaian Arsitektur Keluarga (FAAM)

    Ini memperkirakan arsitektur keluarga sistem informasi untuk interoperabilitas dan ekstensibilitas.

    Mengkomunikasikan Desain Arsitektur

    Setelah menyelesaikan desain arsitektur, kita harus mengkomunikasikan desain tersebut kepada pemangku kepentingan lainnya, yang meliputi tim pengembangan, administrator sistem, operator, pemilik bisnis, dan pihak lain yang berkepentingan.

    Ada beberapa metode terkenal berikut untuk menjelaskan arsitektur kepada orang lain: -

    Model 4 + 1

    Pendekatan ini menggunakan lima tampilan arsitektur yang lengkap. Diantaranya, empat pandangan (filelogical view, itu process view, itu physical view, dan development view) menggambarkan arsitektur dari pendekatan yang berbeda. Tampilan kelima menunjukkan skenario dan kasus penggunaan untuk perangkat lunak. Ini memungkinkan para pemangku kepentingan untuk melihat fitur-fitur arsitektur yang secara khusus menarik minat mereka.

    Arsitektur Deskripsi Bahasa (ADL)

    Pendekatan ini digunakan untuk menggambarkan arsitektur perangkat lunak sebelum implementasi sistem. Ini membahas masalah berikut - perilaku, protokol, dan konektor.

    Keuntungan utama ADL adalah kita dapat menganalisis arsitektur untuk kelengkapan, konsistensi, ambiguitas, dan kinerja sebelum secara resmi mulai menggunakan desain.

    Pemodelan Tangkas

    Pendekatan ini mengikuti konsep bahwa "konten lebih penting daripada representasi". Ini memastikan bahwa model yang dibuat sederhana dan mudah dipahami, cukup akurat, terperinci, dan konsisten.

    Dokumen model tangkas menargetkan pelanggan tertentu dan memenuhi upaya kerja pelanggan itu. Kesederhanaan dokumen memastikan bahwa ada partisipasi aktif dari para pemangku kepentingan dalam pemodelan artefak.

    IEEE 1471

    IEEE 1471 adalah nama pendek untuk standar yang secara resmi dikenal sebagai ANSI / IEEE 1471-2000, “Praktik yang Direkomendasikan untuk Deskripsi Arsitektur Sistem Intensif Perangkat Lunak”. IEEE 1471 meningkatkan isi deskripsi arsitektural, khususnya, memberikan arti khusus pada konteks, pandangan, dan sudut pandang.

    Unified Modeling Language (UML)

    Pendekatan ini mewakili tiga pandangan dari model sistem. Itufunctional requirements view (persyaratan fungsional sistem dari sudut pandang pengguna, termasuk kasus penggunaan); the static structural view(objek, atribut, hubungan, dan operasi termasuk diagram kelas); dandynamic behavior view (kolaborasi antar objek dan perubahan keadaan internal objek, termasuk urutan, aktivitas, dan diagram status).

ja/tutorial
es/tutorial
de/tutorial
fr/tutorial
th/tutorial
pt/tutorial
ru/tutorial
vi/tutorial
it/tutorial
ko/tutorial
tr/tutorial
id/tutorial
pl/tutorial
hi/tutorial
japost
espost
depost
frpost
thpost
ptpost
rupost
vipost
itpost
kopost
trpost
idpost
plpost
hipost

© Copyright 2021 - 2024 | All Rights Reserved