Tugas Rekayasa Perangkat Lunak 5

RINGKASAN BAB 7 CODING DAN PENGUJIAN UNIT

- Seperti membaca program adalah kegiatan jauh lebih umum daripada menulis program, tujuan dari kegiatan coding adalah untuk menghasilkan program yang, selain bebas dari cacat, mudah untuk memahami dan memodifikasi.

- Gunakan pemrograman terstruktur di mana program ini adalah urutan yang cocok tunggal single entry konstruksi exit membuat program yang mudah untuk memahami dan memverifikasi. praktek-praktek lainnya seperti menggunakan informasi bersembunyi, standar coding cocok, dan praktek pemrograman yang baik juga membantu meningkatkan pembacaan kode dan kualitas.

- Untuk pengembang, itu adalah yang paling efektif untuk mengembangkan kode secara bertahap. Hal ini dapat dilakukan dengan menulis kode sedikit demi sedikit, dan pengujian dan debugging setiap kenaikan sebelum menulis kode lebih. Atau, pengembangan uji-driven dapat diikuti di mana uji kasus yang ditulis pertama dan kemudian kode ditulis untuk lulus uji kasus ini. Meskipun coding dari modul umumnya dilakukan oleh programmer individu, alternatif adalah pasangan pemrograman, di mana coding dilakukan oleh sepasang programmer baik bersama-sama berkembang strategi, struktur data, algoritma dll

- Kode Berkembang perlu dikelola dengan baik. Hal ini dapat dilakukan melalui kontrol alat kode sumber yang tepat yang memungkinkan manajemen mudah dari versi yang berbeda yang bisa dibuat, serta mudah kehancuran perubahan yang perlu digulung kembali.

- Sebagai kode berubah dengan waktu, untuk memastikan bahwa kualitas kode tidak terus menurunkan karena evolusi, refactoring dapat dilakukan. Selama refactoring ada fungsi baru ditambahkan hanya perbaikan dilakukan agar desain kode membaik dengan penurunan kopling, peningkatan kohesi, dan lebih baik menggunakan hirarki.

- Unit testing adalah sangat populer dan paling sering digunakan praktek oleh programmer untuk memverifikasi kode yang mereka tulis. Dalam unit testing, programmer menguji / nya kode nya dalam isolasi. Untuk bahasa prosedural ini sering satu set kecil prosedur atau fungsi, dan untuk bahasa berorientasi objek ini umumnya kelas atau satu set kecil kelas. pengujian unit membutuhkan driver dan stub, dan dapat difasilitasi oleh penggunaan kerangka yang memungkinkan tes otomatis eksekusi script. kerangka yang baik seperti Cunit dan Junit ada untuk kedua bahasa prosedural dan bahasa berorientasi objek.

- Sejumlah metrik ada untuk mengukur kualitas yang berbeda dari kode. Yang paling umum digunakan adalah metrik ukuran, karena mereka digunakan untuk menilai produktivitas orang dan sering digunakan dalam estimasi biaya. The ukuran paling umum adalah baris kode (LOC), yang juga digunakan di sebagian besar model biaya. Tujuan dari metrik kompleksitas adalah untuk mengukur kompleksitas perangkat lunak, seperti com plexity merupakan faktor penting yang mempengaruhi produktivitas proyek dan merupakan faktor dalam estimasi biaya. Sejumlah metrik yang berbeda ada, yang paling umum adalah kompleksitas cyclomatic, yang didasarkan pada logika internal program dan mendefinisikan kompleksitas sebagai jumlah siklus independen dalam grafik aliran program.

Tugas Rekayasa Perangkat Lunak 4

SOFTWARE ARSITEKTUR

- Setiap sistem yang kompleks terdiri dari subsistem yang berinteraksi di bawah kendali desain sistem sehingga sistem menyediakan perilaku yang diharapkan. Sebagai sistem perangkat lunak yang semakin menjadi didistribusikan dan lebih kompleks, arsitektur menjadi langkah penting dalam membangun sistem. Arsitektur juga merupakan tempat awal ketika properti seperti keandalan dan kinerja dapat dievaluasi untuk sistem, sebuah kemampuan yang semakin menjadi penting.

5.1 Peran Software Arsitektur

- Secara umum, arsitektur sistem memberikan pandangan tingkat yang sangat tinggi dari bagian-bagian dari sistem dan bagaimana mereka berhubungan untuk membentuk seluruh sistem. Setiap sistem yang kompleks dapat dipartisi dalam banyak cara berbeda. Hal yang sama berlaku untuk sistem-tidak ada struktur yang unik dari sistem.

- Deskripsi arsitektur sistem karena itu akan menggambarkan di perubahan struktur dari sistem. Pertanyaan alami berikutnya adalah mengapa harus tim membangun sistem perangkat lunak untuk beberapa pelanggan tertarik dalam menciptakan dan mendokumentasikan struktur dari sistem yang diusulkan.beberapa penting kegunaan software arsitektur:

1. Memahami dan komunikasi. Deskripsi arsitektur adalah utamanya untuk berkomunikasi arsitektur untuk berbagai pemangku kepentingan, yang di-clude pengguna yang akan menggunakan sistem, klien yang ditugaskan sistem, pembangun yang akan membangun sistem, dan, tentu saja. Melalui penjelasan ini para pemangku kepentingan memperoleh pemahaman tentang beberapa sifat makro dari sistem dan bagaimana sistem bermaksud untuk mengisi persyaratan fungsional dan kualitas.

2. Reuse. Jika seseorang ingin membangun sebuah produk perangkat lunak di mana komponen yang ada dapat digunakan kembali, maka arsitektur menjadi titik kunci. arsitektur harus mepilih sedemikian rupa bahwa komponen yang harus digunakan kembali dapat cocok dengan baik dan bersama-sama dengan komponen lain yang dapat dikembangkan. Arsitektur juga facili-tates menggunakan kembali antara produk-produk yang keluarga produk serupa dan bangunan sehingga bagian-bagian umum ini di berbeda tetapi produk serupa dapat digunakan kembali

3. Konstruksi dan Evolution. Arsitektur partisi sistem menjadi bagian-bagian, beberapa partisi arsitektur yang disediakan dapat digunakan secara alami untuk membangun sistem, yang juga mensyaratkan bahwa sistem akan dipecah menjadi bagian-bagian sehingga tim secara terpisah dapat bekerja pada bagian berbeda. bagian-bagian yang ditentukan dalam arsitektur relatif indepen-dent (ketergantungan antara bagian-bagian yang datang melalui hubungan mereka), mereka dapat dibangun secara mandiri.

4. Analisis. Hal ini sangat diinginkan jika dapat ditentukan beberapa sifat penting tentang tingkah laku dari sistem sebelum sistem ini benar-benar dibangun. Hal ini akan memungkinkan para desainer untuk mempertimbangkan alternatif dan memilih salah satu yang terbaik akan sesuai dengan kebutuhan.  Dalam beberapa proyek komunikasi mungkin sangat penting, tapi analisis kinerja rinci mungkin tidak diperlukan (karena sistem yang terlalu kecil atau dimaksudkan untuk hanya beberapa pengguna). Dalam beberapa sistem lain, analisis kinerja mungkin penggunaan utama arsitektur.

5.2 Arsitektur Views

- Dalam pandangan modul, sistem ini dipandang sebagai kumpulan unit kode, masing-masing menerapkan beberapa bagian dari fungsi sistem. Artinya, unsur-unsur utama dalam pandangan ini adalah modul. pandangan-pandangan ini adalah kode-based dan tidak secara eksplisit rep-membenci setiap struktur runtime dari sistem.

- Dalam komponen dan konektor sistem ini dipandang sebagai pembacaan entitas runtime Artinya, komponen adalah unit yang memiliki identitas dalam sistem mengeksekusi. Objects adalah sebuah kolektifitas benda, dan proses adalah contoh dari komponen. Sementara pelaksana adalah komponen yang harus berinteraksi dengan orang lain untuk mendukung layanan sistem. Konektor menyediakan sarana untuk interaksi ini.

- Pandangan alokasi berfokus pada bagaimana unit software erent dialokasikan ke sumber daya seperti perangkat keras, sistem file, dan orang-orang. Artinya, pandangan alokasi menentukan hubungan antara unsur-unsur perangkat lunak dan elemen lingkungan di mana sistem perangkat lunak dijalankan. Mereka mengekspos sifat struktural seperti dimana proses berjalan pada prosesor mana, dan bagaimana file sistem diatur pada sistem file.

- Deskripsi arsitektur terdiri dari pandangan jenis dengan setiap tampilan mengekspos beberapa struktur dari sistem. views modul menunjukkan bagaimana peranti lunak ini disusun sebagai satu set unit implementasi, C & C views menunjukkan bagaimana perangkat lunak ini disusun sebagai berinteraksi elemen runtime, dan pandangan alokasi menunjukkan bagaimana perangkat lunak berhubungan dengan struktur nonsoftware. Ketiga jenis pandang sistem yang sama membentuk arsitektur sistem.

- Perhatikan bahwa pandangan tersebut tidak berhubungan. Mereka semua merupakan sistem yang sama.

- Catatan tentang hubungan antara arsitektur dan desain adalah dalam rangka. Sebagai partisi sistem menjadi bagian-bagian yang lebih kecil dan menyusun sistem dari bagian-bagian ini juga merupakan tujuan dari desain. Ini bertujuan untuk mencapai tujuan yang sama dan tampaknya fundamental mengandalkan membagi dan menaklukkan aturan. Pertama, harus jelas bahwa arsitektur adalah desain dalam hal itu adalah dalam domain solusi dan berbicara tentang struktur dari sistem yang diusulkan. Selanjutnya, pandangan arsitektur memberikan tampilan tingkat tinggi dari sistem.

5.3 Komponen dan Konektor view

- Batas-batas antara arsitektur dan desain tingkat tinggi tidak sepenuhnya jelas. Pada tingkat arsitektur, salah satu kebutuhan untuk hanya menampilkan bagian-bagian yang diperlukan untuk melakukan evaluasi yang diinginkan. Struktur internal bagian-bagian ini tidak penting. Di sisi lain selama desain merancang struktur bagian-bagian. Namun, bagian mana dari struktur harus diperiksa terlebih dahulu. Dan arsitektur,desain adalah masalah pilihan. Secara umum, detail yang tidak diperlukan untuk melakukan jenis analisis yang ingin kita lakukan pada saat arsitektur yang tidak perlu dan harus dibiarkan untuk desain.

- Arsitektur sistem memiliki dua elemen utama yaitu,komponen dan konektor. Komponen biasanya elemen komputasi atau toko data yang memiliki beberapa kehadiran selama pelaksanaan sistem. Konektor menentukan sarana interaksi antara komponen-komponen ini. pandangan sistem dan komponen yang terhubung ke mana dan melalui konektor apa. Struktur pada dasarnya adalah sebuah grafik, dengan motivasional sebagai node dan konektor sebagai tepi.

5.3.1 Komponen

- Komponen adalah dari jenis komponen di mana jenis merupakan komponen generik, mendefinisikan komputasi umum dan interface komponen dari jenis yang harus memiliki. Perhatikan bahwa meskipun komponen memiliki tipe, di C & C tampilan arsitektur, kita memiliki komponen (yaitu, contoh aktual) dan tidak jenis. Contoh jenis ini adalah klien, server, filter, dll. Perbedaan domain mungkin memiliki jenis generik lainnya seperti kontroler, aktuator, dan sensor (untuk domain sistem kontrol).

- Dalam diagram mewakili C & C lihat arsitektur sistem, itu sangat diinginkan untuk memiliki perbedaan representasi untuk jenis komponen yang berbeda, sehingga jenis yg berbeda dapat diidentifikasi secara visual. Dalam diagram kotak-dan-line, sering semua komponen yang direpresentasikan sebagai kotak persegi panjang. Pendekatan seperti ini akan mengharuskan jenis komponen dijelaskan secara terpisah dan pembaca harus membaca deskripsi untuk mengetahui jenis-jenis komponen. Hal ini jauh lebih baik untuk menggunakan simbol yang berbeda/ notasi untuk setiap jenis komponen yg berbeda.

5.3.2 Konektor

- Komponen yang berbeda dari sistem cenderung berinteraksi sementara sistem dalam operasi untuk menyediakan layanan yang diharapkan dari sistem. Interaksi antar komponen dapat melalui cara sederhana yang didukung oleh infrastruktur pelaksanaan proses yang mendasari sistem operasi. Misalnya, komponen dapat berinteraksi dengan yang lain menggunakan mekanisme panggilan prosedur (konektor), yang disediakan oleh lingkungan runtime untuk bahasa pemrograman. Namun, interaksi mungkin melibatkan mekanisme yang lebih kompleks juga. Contoh mekanisme seperti panggilan prosedur jauh, port TCP / IP, dan protokol seperti HTTP. Beberapa simbol yang umum digunakan untuk mewakili jenis konektor yang biasa ditemukan ditunjukkan pada Gambar 5.2.

- Sebuah konektor juga memiliki nama yang harus menggambarkan sifat interaksi konektor mendukung. Perlu menunjukkan bahwa pelaksanaan konektor mungkin cukup kompleks. Jika konektor disediakan oleh sistem yang mendasari, maka komponen hanya perlu memastikan bahwa mereka menggunakan konektor sesuai spesifikasi mereka. Namun, jika sistem yang mendasarinya tidak menyediakan konektor yang digunakan dalam arsitektur, maka seperti disebutkan di atas, konektor harus dilaksanakan sebagai bagian dari proyek untuk membangun sistem. Artinya, selama pengembangan, tidak hanya akan komponen perlu dikembangkan, tetapi sumber daya harus ditugaskan untuk juga mengembangkan konektor. (Situasi ini mungkin timbul karena sistem khusus yang membutuhkan konektor yang khusus untuk masalah domain.) Secara umum, sekaligus menciptakan arsitektur, adalah bijaksana untuk arsitek untuk menggunakan konektor yang tersedia pada sistem di mana perangkat lunak akan dikerahkan.

5.4 Gaya Arsitektur untuk C & C View

a. Pipa dan Filter
Pipa-dan-filter bergaya arsitektur cocok untuk sistem yang terutama melakukan transformasi data dan tujuan dari sistem ini adalah untuk menghasilkan beberapa data output dengan sesuai mengubah input data. Sebuah filter mungkin memiliki lebih dari satu input dan lebih dari satu output. Filter tidak perlu tahu identitas dari filter yang mengirim input data atau identitas filter yang akan mengkonsumsi data yang mereka hasilkan.

b. Data Bersama Style
- Ada dua variasi dari gaya ini. Dalam gaya papan, jika beberapa data yang diposting di repositori data, semua komponen accessor yang perlu tahu tentang hal itu diinformasikan. Dalam database, bentuk gaya sering didukung melalui pemicu. Yang lain adalah gaya repositori, dimana penyimpanan data hanya repositori pasif yang menyediakan penyimpanan permanen dan kontrol terkait untuk mengakses data.

- Banyak aplikasi database menggunakan gaya arsitektur ini. Banyak sistem Web sering mengikuti gaya ini di back end-dalam menanggapi permintaan pengguna, script erent di ff (accesor data) akses dan memperbarui beberapa data bersama.

- Komponen perhitungan yang berbeda tidak perlu berkomunikasi dengan satu sama lain dan bahkan tidak perlu tahu tentang keberadaan masing-masing.

- Misalnya, jika kemudian diputuskan bahwa penjadwalan kursus bisa otomatis berdasarkan data pada pendaftaran (dan informasi lain tentang ruang kelas dll), maka komponen lain yang disebut Penjadwalan hanya dapat menambahkan.

- Ada satu jenis konektor dalam gaya ini, baca / tulis. Perhatikan bagaimana gaya konektor umum  dapat mengambil bentuk yang lebih tepat dalam arsitektur tertentu. Misalnya,database dapat dilihat sebagai pendukung membaca dan update untuk program berinteraksi. Namun, sistem database dapat pula memberikan transaksi layanan.

c. Gaya Server Klien
- Gaya lain yang sangat umum digunakan untuk membangun sistem saat ini adalah gaya client-server. Server komputasi client adalah salah satu paradigma dasar komputasi terdistribusi.

- Dalam gaya ini, ada dua komponen, yaitu klien dan server. Kendala dari gaya ini adalah bahwa klien hanya dapat berkomunikasi dengan server, dan tidak dapat berkomunikasi dengan klien lainnya. Komunikasi antara komponen klien dan komponen server diprakarsai oleh klien ketika klien mengirimkan permintaan untuk beberapa layanan yang dimana server mendukung. server menerima permintaan,mendefinisikan, melakukan layanan, dan kemudian mengembalikan hasil perhitungan kepada klien yang meminta layanan.

- Ada satu jenis konektor dalam gaya ini. Sebuah konektor menghubungkan klien ke server. Jenis konektor asimetris akhir klien (end clien) konektor hanya dapat membuat permintaan (dan menerima balasan), sedangkan akhir server (end server) hanya dapat mengirim balasan dalam menanggapi permintaan itumelalui konektor ini. komunikasi sering sinkron, klien menunggu servermembawa hasil sebelum melanjutkan. Artinya, klien diblokir atas permintaan, sampai mendapatkan jawabannya.

- Sebuah bentuk umum dari gaya ini adalah struktur N-Tier. Dalam gaya ini, klien mengirimkan permintaan ke server, tetapi server hanya untuk melayani permintaan dan mengirim beberapa permintaan ke server lain. Server juga bertindak sebagai klien untuk tingkat berikutnya. Sebuah contoh umum ini adalah arsitektur 3-Tier. Dalam gaya ini, klien yang membuat permintaan dan menerima hasil akhir berada di tingkat client. Tingkat menengah yaitu tier bisnis, mengandung komponen yang memproses data yang diajukan oleh klien dan menerapkan aturan bisnis yang diperlukan. Tingkat ketiga adalah tingkat basis data di mana data berada.

- Dalam arsitektur client-server, klien dan komponen server berada pada mesin yang berbeda.Oleh karena itu, konektor antara klien dan server diharapkan untuk mendukung jenis permintaan / hasil dari hubungan di mesin yang berbeda. Akibatnya, konektor ini secara internal cukup kompleks dan melibatkan cukup banyak jaringan untuk mendukung. Banyak sistem client server saat port digunakan TCP untuk konektornya. Web menggunakan HTTP untuk mendukung konektor ini.

- Ada perbedaan antara arsitektur berlapis dan arsitektur berjenjang. Gaya berjenjang adalah komponen dan konektor tampilan arsitektur di mana setiap tier adalah komponen, dan komponen-komponen ini berkomunikasi dengan orang-orang yang berdekatan melalui protokol. Sebuah arsitektur berlapis adalah pandangan modul menyediakan bagaimana modul diatur dan digunakan.

d. Beberapa Gaya Lain
- Publish Subscribe Style,dalam gaya ini ada dua jenis komponen. Satu jenis komponen seperangkat yang didefinisikan. Dan yang kedua compo-motivasional, menghasilkan atau mempublikasikan acara.Peer-to-peer gaya, atau gaya berorientasi objek. Dalam gaya ini, komponen peer dan komponen komponen lain dapat meminta layanan dari komponen lainnya. Model ini adalah salah satu yang didukung melalui konektor middleware seperti CORBA atau NET.

5.5 Mendokumentasikan Desain Arsitektur

- Sejauh ini kita telah berfokus pada pandangan melalui diagram. Ketika merancang berakhir, arsitektur harus mengkomunikasikan kepada seluruh stakeholder untuk negosiasidan kesepakatan. Arsitektur harus dengan tepat mendokumentasikaninformasi yang cukup untuk melakukananalisis. Mendokumentasikan arsitektur itu sangat penting. Pada bagian ini, kita akan membahas dokumen arsitektur.

- Tanpa penjelasan didokumentasikan dengan baik arsitektur, itu tidak mungkin untuk memiliki pemahaman yang sama jelas. Oleh karena itu, benar mendokumentasikan arsitektur adalah sama pentingnya dengan membuat satu diagram. Pada bagian ini, kita membahas apa dokumen arsitektur harus berisi:
Sistem dan konteks arsitektur
Melihat deskripsi arsitektur
Across views documentation

- Sebuah diagram konteks yang menetapkan ruang lingkup sistem, batas-batasnya, aktor kunci yang berinteraksi dengan sistem, dan sumber dan tenggelam data juga bisa sangat berguna. Sebuah diagram konteks sering diwakili dengan menunjukkan sistem di tengah, dan menunjukkan hubungan dengan orang dan sistem, termasuk sumber dan mengambil data. Dengan konteks didefinisikan, dokumen dapat melanjutkan dengan menggambarkan struktur atau pandangan yg berbeda. Beberapa tampilan dari jenis yg berbeda mungkin diperlukan, dan yang dilihat dipilih tergantung pada kebutuhan proyek dan saham.

- Dokumen pendukung yang diperlukan untuk tampilan diagram. dokumen pendukung ini harus memiliki beberapa atau semua hal berikut:

a.) Elemen Katalog. Memberikan informasi lebih lanjut tentang unsur-unsur yang ditampilkan dalam representasi utama. Selain menjelaskan tujuan dari elemen, juga harus menjelaskan antarmuka elemen '(ingat bahwa semua elemen memiliki antarmuka di mana mereka berinteraksi dengan unsur-unsur lain). Semua antarmuka yang disediakan oleh elemen harus dispesifikasikan. Interface harus memiliki identitas yang unik, dan spesifikasi harus memberikan kedua informasi sintaksis dan semantik. informasi sintaksis sering dalam hal tanda tangan, yang menggambarkan semua item data yang terlibat dalam antarmuka dan jenis mereka. informasi semantik harus menjelaskan apa antarmuka tidak. deskripsi juga harus jelas menyatakan kondisi kesalahan bahwa antarmuka dapat kembali.

b.) Arsitektur Dasar pemikiran. Meskipun pandangan spesifik elemen es dan hubungan di antara mereka, tidak memberikan wawasan ke dalam mengapa arsitek memilih struktur tertentu. Arsitektur alasan memberikan alasan untuk memilih elemen erent di ff dan menyusun mereka dengan cara itu dilakukan. Bagian ini juga dapat memberikan beberapa diskusi tentang alternatif yang dipertimbangkan dan mengapa mereka ditolak. Diskusi ini, selain menjelaskan pilihan, juga berguna kemudian ketika seorang analis membuat perubahan bertanya-tanya mengapa arsitektur tidak harus diubah dalam beberapa cara (yang mungkin bisa membuat perubahan mudah).

c.) Tingkah Laku. Pandangan memberikan informasi struktural. Tidak mewakili perilaku aktual atau eksekusi. Akibatnya, dalam struktur, semua interaksi yang mungkin selama eksekusi akan ditampilkan. Kadang-kadang, perlu untuk mendapatkan beberapa gagasan tentang perilaku aktual dari sistem dalam beberapa skenario. seperti deskripsi berguna untuk berdebat tentang sifat seperti kebuntuan. deskripsi perilaku dapat diberikan untuk membantu pemahaman bantuan eksekusi sistem. Sering diagram seperti diagram kolaborasi atau urutan diagram (kita akan membahas ini lebih lanjut dalam Bab 6 tentang desain OO) digunakan.

d.) Informasi Lainnya. Ini mungkin termasuk keterangan tentang semua keputusan-keputusan yang belum diambil selama pembuatan arsitektur tetapi telah sengaja untuk masa depan, seperti, pilihan server atau protokol. Jika ini dilakukan, maka harus dispesifikasikan sebagai fi xing ini akan memiliki dampak pada arsitektur.

- Menggabungkan pandangan, bagaimanapun, harus dilakukan hanya jika hubungan antara pandangan kuat dan mudah. Jika tidak, menempatkan beberapa pandangan dalam satu diagram akan mengacaukan pandangan dan membuatnya membingungkan. Tujuan mengungkapkan beberapa pandangan dalam satu bukan hanya untuk mengurangi jumlah tampilan, tetapi harus dilakukan terutama untuk membantu pemahaman dan menunjukkan hubungan.

Ringkasan

- Arsitektur dari sistem perangkat lunak menyediakan tampilan tingkat tinggi yang sangat dari sistem dalam hal bagian dari sistem dan bagaimana mereka berhubungan untuk membentuk seluruh sistem.

- Tergantung pada bagaimana sistem dipartisi, kita mendapatkan pandangan berbeda pada arsitektur sistem. Akibatnya, arsitektur sistem perangkat lunak didefinisikan sebagai struktur dari sistem yang terdiri dari unsur perangkat lunak, sifat eksternal terlihat mereka,dan hubungan di antara mereka.

- Arsitektur memfasilitasi pengembangan sistem berkualitas tinggi. Hal ini juga memungkinkan analisis dari banyak sifat sistem seperti kinerja yang tergantung sebagian besar pada arsitektur harus dilakukan di awal siklus hidup perangkat lunak.

- Ada tiga pandangan arsitektur utama dari sistem-modul, komponen dan konektor, dan alokasi. Dalam pandangan modul, sistem ini dipandang sebagai struktur modul pemrograman seperti paket, kelas, fungsi, dll dalam komponen dan konektor (C & C) lihat, sistem adalah kumpulan dari entitas runtime disebut komponen, yang saling berinteraksi melalui konektor. Pandangan alokasi menggambarkan bagaimana unit software berbeda dialokasikan ke sumber daya perangkat keras dalam sistem.

- C & C lihat adalah yang paling umum, dan sering pusat dari deskripsi arsitektur. Pandangan ini sering digambarkan oleh diagram blok menentukan komponen berbeda dan konektor berbeda antara komponen.

- Ada beberapa gaya umum untuk C & C tampilan yang telah ditemukan berguna untuk membuat arsitektur ini tampilan untuk sistem. Ini termasuk pipa dan filter, data bersama, client-server, mempublikasikan-berlangganan, peer to peer, dan proses gaya berkomunikasi. Masing-masing gaya ini menggambarkan jenis komponen dan konektor yang ada dan kendala pada bagaimana mereka digunakan.

- Pipa dan filter memiliki satu jenis komponen (filter) dan satu jenis konektor (pipa) dan komponen dapat dihubungkan melalui pipa.

- Gaya client-server memiliki dua jenis komponen (client dan server) dan ada satu konektor (permintaan / reply). Seorang klien hanya dapat berkomunikasi dengan server, dan interaksi yang diprakarsai oleh klien.

- Dalam gaya data bersama dua jenis komponen yang repositori dan data accesor. accesor Data membaca / menulis repositori dan berbagi informasi di antara mereka sendiri melalui repositori.

- Arsitektur membentuk dasar untuk sistem dan sisanya dari kegiatan desain dan pengembangan, dan perlu didokumentasikan dengan baik.

- Dokumen arsitektur harus menjelaskan konteks di mana arsitektur dirancang, pandangan arsitektur berbeda yang diciptakan, dan bagaimana pandangan berbeda berhubungan satu sama lain. Deskripsi arsitektur harus menentukan jenis elemen berbeda dan perilaku eksternal mereka, dan alasan arsitektur.

- Arsitektur harus dievaluasi untuk melihat bahwa itu memenuhi persyaratan. Pendekatan yang umum adalah untuk melakukan evaluasi subjektif sehubungan dengan sifat yang diinginkan.