Sabtu, 05 November 2016

Software Arsitektur



BAB V  SOFTWARE ARSITEKTUR

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

5.1 Peran Software Arsitektur
        Secara umum, arsitektur sistem memberikan pandangan tingkat yang sangat tinggi dari bagian-bagian dari sistem dan bagaimana mereka berhubungan untuk membentuk seluruh sistem. Setiap sistem yang kompleks dapat dipartisi dalam banyak cara berbeda. Hal yang sama berlaku untuk sistem-tidak ada struktur yang unik dari sistem.
        Karena kemungkinan ini memiliki beberapa struktur, salah satu definisi yang paling banyak diterima dari arsitektur perangkat lunak adalah bahwa arsitektur perangkat lunak sistem adalah struktur dari sistem, yang terdiri software el-ements, sifat eksternal terlihat dari hubungan mereka.
        Deskripsi arsitektur sistem karena itu akan menggambarkan di perubahan struktur dari sistem. Pertanyaan alami berikutnya adalah mengapa harus tim membangun sistem perangkat lunak untuk beberapa pelanggan tertarik dalam menciptakan dan mendokumentasikan struktur dari sistem yang diusulkan.beberapa penting kegunaan software arsitektur:

1.    Memahami dan komunikasi. Deskripsi arsitektur adalah utamanya untuk berkomunikasi arsitektur untuk berbagai pemangku kepentingan, yang di-clude pengguna yang akan menggunakan sistem, klien yang ditugaskan sistem, pembangun yang akan membangun sistem, dan, tentu saja. Melalui penjelasan ini para pemangku kepentingan memperoleh pemahaman tentang beberapa sifat makro dari sistem dan bagaimana sistem bermaksud untuk mengisi persyaratan fungsional dan kualitas.
2.    Reuse. Jika seseorang ingin membangun sebuah produk perangkat lunak di mana komponen yang ada dapat digunakan kembali, maka arsitektur menjadi titik kunci. arsitektur harus mepilih sedemikian rupa bahwa komponen yang harus digunakan kembali dapat cocok dengan baik dan bersama-sama dengan komponen lain yang dapat dikembangkan. Arsitektur juga facili-tates menggunakan kembali antara produk-produk yang keluarga produk serupa dan bangunan sehingga bagian-bagian umum ini di berbeda tetapi produk serupa dapat digunakan kembali
3.    Konstruksi dan Evolution. Arsitektur partisi sistem menjadi bagian-bagian, beberapa partisi arsitektur yang disediakan dapat digunakan secara alami untuk membangun sistem, yang juga mensyaratkan bahwa sistem akan dipecah menjadi bagian-bagian sehingga tim secara terpisah dapat bekerja pada bagian berbeda. bagian-bagian yang ditentukan dalam arsitektur relatif indepen-dent (ketergantungan antara bagian-bagian yang datang melalui hubungan mereka), mereka dapat dibangun secara mandiri.
4.    Analisis. Hal ini sangat diinginkan jika dapat ditentukan beberapa sifat penting tentang tingkahlaku dari sistem sebelum sistem ini benar-benar dibangun. Hal ini akan memungkinkan para desainer untuk mempertimbangkan alternatif dan memilih salah satu yang terbaik akan sesuai dengan kebutuhan.  Dalam beberapa proyek komunikasi mungkin sangat penting, tapi analisis kinerja rinci mungkin tidak diperlukan (karena sistem yang terlalu kecil atau dimaksudkan untuk hanya beberapa pengguna). Dalam beberapa sistem lain, analisis kinerja mungkin penggunaan utama arsitektur.


5.2  Arsitektur Views
        Dalam pandangan modul, sistem ini dipandang sebagai kumpulan unit kode, masing-masing menerapkan beberapa bagian dari fungsi sistem. Artinya, unsur-unsur utama dalam pandangan ini adalah modul. pandangan-pandangan ini adalah kode-based dan tidak secara eksplisit rep-membenci setiap struktur runtime dari sistem. Contoh modul paket, kelas, prosedur, metode, koleksi fungsi, dan koleksi kelas. Hubungan antara modul ini juga berbasis kode dan tentang bagaimana kode modul berinteraksi dengan modul lain. Contoh hubungan dalam pandangan ini (yaitu, modul B adalah bagian dari modul A) atau tergantung pada modul A menggunakan jasa dari modul B untuk melakukan fungsi dan kebenaran modul sendiri sebuah tergantung pada kebenaran modul B dan generalisasi atau spesialisasi (modul B adalah generalisasi dari modul A).
        Dalam komponen dan konektor  sistem ini dipandang sebagai pembacaan entitas runtime Artinya, komponen adalah unit yang memiliki identitas dalam sistem mengeksekusi. Objects adalah sebuah kolektifitas benda, dan proses adalah contoh dari komponen. Sementara pelaksana adalah komponen
yang harus berinteraksi dengan orang lain untuk mendukung layanan sistem. Konektor menyediakan sarana untuk interaksi ini. Contoh konektor pipa dan soket. Data juga dapat bertindak sebagai konektor. Jika komponen menggunakan beberapa middleware untuk berkomunikasi dan berkoordinasi, maka middleware adalah konektor. Oleh karena itu, unsur-unsur utama dari pandangan ini adalah komponen dan konektor.
        Pandangan alokasi berfokus pada bagaimana unit software erent dialokasikan ke sumber daya seperti perangkat keras, sistem file, dan orang-orang. Artinya, pandangan alokasi menentukan hubungan antara unsur-unsur perangkat lunak dan elemen lingkungan di mana sistem perangkat lunak dijalankan. Mereka mengekspos sifat struktural seperti dimana proses berjalan pada prosesor mana, dan bagaimana file sistem diatur pada sistem file.
        Deskripsi arsitektur terdiri dari pandangan jenis dengan setiap tampilan mengekspos beberapa struktur dari sistem. views modul menunjukkan bagaimana peranti lunak ini disusun sebagai satu set unit implementasi, C & C views menunjukkan bagaimana perangkat lunak ini disusun sebagai berinteraksi elemen runtime, dan pandangan alokasi menunjukkan bagaimana perangkat lunak berhubungan dengan struktur nonsoftware. Ketiga jenis pandang sistem yang sama membentuk arsitektur sistem.
        Perhatikan bahwa pandangan tersebut tidak berhubungan. Mereka semua merupakan sistem yang sama. Oleh karena itu, ada hubungan antara unsur-unsur dalam satu tampilan dan dalam pandangan lain. Hubungan ini mungkin sederhana atau mungkin rumit.
Misalnya, hubungan antara modul dan komponen mungkin menjadi satu dalam satu modul mengimplementasikan
dalam salah satu komponen. Di sisi lain, mungkin cukup kompleks dengan modul yang digunakan oleh beberapa komponen, dan komponen menggunakan beberapa modul. Sekaligus menciptakan tampilan dan para desainer harus menyadari hubungan ini.
        Pertanyaan berikutnya adalah apakah pandangan standar yang harus diungkapkan untuk menggambarkan arsitektur sistem? Untuk menjawab pertanyaan ini, analogi dengan bangunan dapat lagi membantu. Jika seseorang membangun sebuah rumah kecil yang sederhana, maka mungkin tidak ada kebutuhan untuk memiliki pandangan yang terpisah menjelaskan darurat dan sistem kebakaran. Demikian pula, jika tidak ada AC di gedung, ada perlu tidak pandangan untuk itu. Di sisi lain, sebuah bangunan  mungkin akan membutuhkan kedua pandangan ini, selain tampilan lain menggambarkan pipa, ruang, kabel, dll
        Namun, meskipun fakta bahwa ada beberapa gambar yang menunjukkan tampila bangunan, ada satu pandangan yang mendominasi dalam konstruksi-yang struktur fisik. Pandangan ini membentuk dasar dari tampilan lain dalam bahwa pandangan lain dapat benar-benar diselesaikan kecuali pandangan ini bisa dilakukan. pandangan lain mungkin atau mungkin tidak diperlukan untuk membangun sebuah bangunan, tergantung pada sifat proyek. Oleh karena itu, dalam arti, pandangan memberikan struktur bangunan dapat dianggap sebagai pandangan utama dalam hal itu hampir selalu digunakan, dan tampilan lain bergantung pada pandangan ini secara substansial. Pandangan juga menangkap mungkin properti yang paling penting untuk dianalisis pada tahap awal, yaitu bahwa organisasi ruang.
        Situasi dengan arsitektur perangkat lunak juga agak mirip
. Namun, pandangan ini telah menjadi pandangan de facto utama dan salah satu yang hampir selalu siap ketika arsitektur dirancang.
        Catatan tentang hubungan antara arsitektur dan desain adalah dalam rangka. Sebagai partisi sistem menjadi bagian-bagian yang lebih kecil dan menyusun sistem dari bagian-bagian ini juga merupakan tujuan dari desain.
Ini bertujuan untuk mencapai tujuan yang sama dan tampaknya fundamental mengandalkan membagi dan menaklukkan aturan. Pertama, harus jelas bahwa arsitektur adalah desain dalam hal itu adalah dalam domain solusi dan berbicara tentang struktur dari sistem yang diusulkan. Selanjutnya, pandangan arsitektur memberikan tampilan tingkat tinggi dari sistem.

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










5.1 Contoh komponen

        Komponen adalah dari jenis komponen, di mana jenis merupakan komponen generik, mendefinisikan komputasi umum dan interface komponen dari jenis yang harus memiliki. Perhatikan bahwa meskipun komponen memiliki tipe, di C & C tampilan arsitektur, kita memiliki komponen (yaitu, contoh aktual) dan tidak jenis. Contoh jenis ini adalah klien, server, filter, dll Di ff domain erent mungkin memiliki jenis generik lainnya seperti kontroler, aktuator, dan sensor (untuk domain sistem kontrol).
       Dalam diagram mewakili C & C lihat arsitektur sistem, itu sangat diinginkan untuk memiliki di ff erent representasi untuk jenis komponen di ff erent, sehingga jenis erent di ff dapat diidentifikasi secara visual. Dalam diagram kotak-dan-line, sering semua komponen yang direpresentasikan sebagai kotak persegi panjang. Pendekatan seperti ini akan mengharuskan jenis komponen dijelaskan secara terpisah dan pembaca harus membaca deskripsi untuk mengetahui jenis-jenis komponen. Hal ini jauh lebih baik untuk menggunakan di ff erent simbol / notasi untuk setiap di ff jenis komponen erent. Beberapa simbol yang umum digunakan untuk mewakili jenis komponen umum ditemukan ditunjukkan pada Gambar 5.1.

5.3.2 Konektor










5.2 Contoh konektor

        Komponen erent di ff dari sistem cenderung berinteraksi sementara sistem dalam operasi untuk menyediakan layanan yang diharapkan dari sistem. Interaksi antar komponen dapat melalui cara sederhana yang didukung oleh infrastruktur pelaksanaan proses yang mendasari sistem operasi. Misalnya, komponen dapat berinteraksi dengan yang lain menggunakan mekanisme panggilan prosedur (konektor), yang disediakan oleh lingkungan runtime untuk bahasa pemrograman. Namun, interaksi mungkin melibatkan mekanisme yang lebih kompleks juga. Contoh mekanisme seperti panggilan prosedur jauh, port TCP / IP, dan protokol seperti HTTP. Beberapa simbol yang umum digunakan untuk mewakili jenis konektor yang biasa ditemukan ditunjukkan pada Gambar 5.2.
        Sebuah konektor juga memiliki nama yang harus menggambarkan sifat interaksi konektor mendukung. Perlu menunjukkan bahwa pelaksanaan konektor mungkin cukup kompleks. Jika konektor disediakan oleh sistem yang mendasari, maka komponen hanya perlu memastikan bahwa mereka menggunakan konektor sesuai spesifikasi mereka. Namun, jika sistem yang mendasarinya tidak menyediakan konektor yang digunakan dalam arsitektur, maka seperti disebutkan di atas, konektor harus dilaksanakan sebagai bagian dari proyek untuk membangun sistem. Artinya, selama pengembangan, tidak hanya akan komponen perlu dikembangkan, tetapi sumber daya harus ditugaskan untuk juga mengembangkan konektor. (Situasi ini mungkin timbul karena sistem khusus yang membutuhkan konektor yang khusus untuk masalah domain.) Secara umum, sekaligus menciptakan arsitektur, adalah bijaksana untuk arsitek untuk menggunakan konektor yang tersedia pada sistem di mana perangkat lunak akan dikerahkan.





5.4 Gaya Arsitektur untuk C & C View
5.4.1 Pipa dan Filter
        Pipa-dan-filter bergaya arsitektur cocok untuk sistem yang terutama melakukan transformasi data dan tujuan dari sistem ini adalah untuk menghasilkan beberapa data output dengan sesuai mengubah input data. Sebuah filter mungkin memiliki lebih dari satu input dan lebih dari satu output. Filter tidak perlu tahu identitas dari filter yang mengirim input data atau identitas filter yang akan mengkonsumsi data yang mereka hasilkan .
5.4.2 Data Bersama Style
        Ada dua variasi dari gaya ini. Dalam gaya papan, jika beberapa data yang diposting di repositori data, semua komponen accessor yang perlu tahu tentang hal itu diinformasikan. Dalam database, bentuk gaya sering didukung melalui pemicu. Yang lain adalah gaya repositori, dimana penyimpanan data hanya repositori pasif yang menyediakan penyimpanan permanen dan kontrol terkait untuk mengakses data.
        Banyak aplikasi database menggunakan gaya arsitektur ini. Banyak sistem Web sering mengikuti gaya ini di back end-dalam menanggapi permintaan pengguna, script erent di ff (accesor data) akses dan memperbarui beberapa data bersama.
       Sebagai contoh sistem yang menggunakan gaya arsitektur, mari kita perhatikan sistem pendaftaran mahasiswa di sebuah universitas. Sistem ini jelas memiliki repositori pusat yang berisi informasi tentang kursus, siswa, prasyarat, dll memiliki komponen Administrator yang menentukan repositori, hak untuk di ff erent orang, dll Komponen Pendaftaran memungkinkan siswa untuk reg-ister dan memperbarui informasi bagi siswa dan kursus. Komponen Persetujuan adalah untuk memberikan persetujuan bagi mereka program yang membutuhkan persetujuan instruktur. Komponen Laporan menghasilkan laporan mengenai siswa yang terdaftar di program erent di ff pada akhir pendaftaran. Komponen Course Feedback digunakan untuk mengambil umpan balik dari siswa pada akhir kursus. Arsitektur ini ditunjukkan pada Gambar 5.7.








                                                                                                                                       






        Perhatikan diagram diatas, bahwa komponen perhitungan yang berbeda tidak perlu berkomunikasi dengan satu sama lain dan bahkan tidak perlu tahu tentang keberadaan masing-masing.
        Misalnya, jika kemudian diputuskan bahwa penjadwalan kursus bisa otomatis berdasarkan data pada pendaftaran (dan informasi lain tentang ruang kelas dll), maka komponen lain yang disebut Penjadwalan hanya dapat menambahkan.
        Ada satu jenis konektor dalam gaya ini
, baca / tulis. Perhatikan bagaimana gaya konektor umum  dapat mengambil bentuk yang lebih tepat dalam arsitektur tertentu. Misalnya,database dapat dilihat sebagai pendukung membaca dan update untuk program berinteraksi. Namun, sistem database dapat pula memberikan transaksi layanan. .
        Perhatikan juga bahwa dalam banyak kasus lainnya, konektor melibatkan pertimbangan jumlah infrastruktur yang mendasarinya. Misalnya, membaca dan menulis ke sistem file melibatkan cukup banyak perangkat lunak sistem file yang melibatkan seperti direktori, buffering,penguncian, dan sinkronisasi. Demikian pula, banyak software masuk ke database untuk mendukung jenis koneksi, seperti menyediakanquery, update, dan transaksi.
5.4.3 Gaya Server Klien
       Gaya lain yang sangat umum digunakan untuk membangun sistem saat ini adalah gaya client-server. Server komputasi client adalah salah satu paradigma dasar komputasi terdistribusi.
Dalam gaya ini, ada dua komponen
, yaitu klien dan server. Kendala dari gaya ini adalah bahwa klien hanya dapat berkomunikasi dengan server, dan tidak dapat berkomunikasi dengan klien lainnya. Komunikasi antara komponen klien dan komponen server diprakarsai oleh klien ketika klien mengirimkan permintaan untuk beberapa layanan yang dimana server mendukung. server menerima permintaan,mendefinisikan, melakukan layanan, dan kemudian mengembalikan hasil perhitungan kepada klien yang meminta layanan.
        Ada satu jenis konektor dalam gaya ini. Sebuah konektor menghubungkan klien ke server. Jenis konektor asimetris akhir klien
(end clien) konektor hanya dapat membuat permintaan (dan menerima balasan), sedangkan akhir server (end server) hanya dapat mengirim balasan dalam menanggapi permintaan itumelalui konektor ini. komunikasi sering sinkron, klien menunggu servermembawa hasil sebelum melanjutkan. Artinya, klien diblokir atas permintaan, sampai mendapatkan jawabannya.
        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.
5.4.4 Beberapa Gaya Lain
       Publish Subscribe Style,dalam gaya ini ada dua jenis komponen. Satu jenis komponen seperangkat yang didefinisikan. Dan yang kedua compo-motivasional, menghasilkan atau mempublikasikan acara.Peer-to-peer gaya, atau gaya berorientasi objek. Dalam gaya ini, komponen peer dan komponen komponen lain dapat meminta layanan dari komponen lainnya. Model ini adalah salah satu yang didukung melalui konektor middleware seperti CORBA atau NET.
5.5  Mendokumentasikan Desain Arsitektur
        Sejauh ini kita telah berfokus pada pandangan melalui diagram. Ketika merancang berakhir, arsitektur harus mengkomunikasikan kepada seluruh stakeholder untuk negosiasidan kesepakatan. Arsitektur harus dengan tepat mendokumentasikaninformasi yang cukup untuk melakukananalisis. Mendokumentasikan arsitektur itu sangat penting. Pada bagian ini, kita akan membahas dokumen arsitektur.
Tanpa penjelasan didokumentasikan dengan baik arsitektur, itu tidak mungkin untuk memiliki pemahaman yang sama jelas. Oleh karena itu, benar mendokumentasikan arsitektur adalah sama pentingnya dengan membuat satu diagram. Pada bagian ini, kita membahas apa dokumen arsitektur harus berisi:
1.    Sistem dan konteks arsitektur
2.    Melihat deskripsi arsitektur
3.    Across views documentation
Sebuah diagram konteks yang menetapkan ruang lingkup sistem, batas-batasnya, aktor kunci yang berinteraksi dengan sistem, dan sumber dan tenggelam data juga bisa sangat berguna. Sebuah diagram konteks sering diwakili dengan menunjukkan sistem di tengah, dan menunjukkan hubungan dengan orang dan sistem, termasuk sumber dan mengambil data. Dengan konteks didefinisikan, dokumen dapat melanjutkan dengan menggambarkan struktur atau pandangan yg berbeda. Beberapa tampilan dari jenis yg berbeda mungkin diperlukan, dan yang dilihat dipilih tergantung pada kebutuhan proyek dan saham.
Dokumen pendukung yang diperlukan untuk tampilan diagram. dokumen pendukung ini harus memiliki beberapa atau semua hal berikut:
a.     Elemen Katalog. Memberikan informasi lebih lanjut tentang unsur-unsur yang ditampilkan dalam representasi utama. Selain menjelaskan tujuan dari elemen, juga harus menjelaskan antarmuka elemen '(ingat bahwa semua elemen memiliki antarmuka di mana mereka berinteraksi dengan unsur-unsur lain). Semua antarmuka yang disediakan oleh elemen harus dispesifikasikan. Interface harus memiliki identitas yang unik, dan spesifikasi harus memberikan kedua informasi sintaksis dan semantik. informasi sintaksis sering dalam hal tanda tangan, yang menggambarkan semua item data yang terlibat dalam antarmuka dan jenis mereka. informasi semantik harus menjelaskan apa antarmuka tidak. deskripsi juga harus jelas menyatakan kondisi kesalahan bahwa antarmuka dapat kembali.
b.    Arsitektur Dasar pemikiran. Meskipun pandangan spesifik es elemen dan hubungan di antara mereka, tidak memberikan wawasan ke dalam mengapa arsitek memilih struktur tertentu. Arsitektur alasan memberikan alasan untuk memilih elemen erent di ff dan menyusun mereka dengan cara itu dilakukan. Bagian ini juga dapat memberikan beberapa diskusi tentang alternatif yang dipertimbangkan dan mengapa mereka ditolak. Diskusi ini, selain menjelaskan pilihan, juga berguna kemudian ketika seorang analis membuat perubahan bertanya-tanya mengapa arsitektur tidak harus diubah dalam beberapa cara (yang mungkin bisa membuat perubahan mudah).
c.     Tingkah laku. Pandangan memberikan informasi struktural. Tidak mewakili perilaku aktual atau eksekusi. Akibatnya, dalam struktur, semua interaksi yang mungkin selama eksekusi akan ditampilkan. Kadang-kadang, perlu untuk mendapatkan beberapa gagasan tentang perilaku aktual dari sistem dalam beberapa skenario. seperti deskripsi berguna untuk berdebat tentang sifat seperti kebuntuan. deskripsi perilaku dapat diberikan untuk membantu pemahaman bantuan eksekusi sistem. Sering diagram seperti diagram kolaborasi atau urutan diagram (kita akan membahas ini lebih lanjut dalam Bab 6 tentang desain OO) digunakan.
d.    Informasi lainnya. Ini mungkin termasuk keterangan tentang semua keputusan-keputusan yang belum diambil selama pembuatan arsitektur tetapi telah sengaja untuk masa depan, seperti, pilihan server atau protokol. Jika ini dilakukan, maka harus dispesifikasikan sebagai fi xing ini akan memiliki dampak pada arsitektur.
        Menggabungkan pandangan, bagaimanapun, harus dilakukan hanya jika hubungan antara pandangan kuat dan mudah. Jika tidak, menempatkan beberapa pandangan dalam satu diagram akan mengacaukan pandangan dan membuatnya membingungkan. Tujuan mengungkapkan beberapa pandangan dalam satu bukan hanya untuk mengurangi jumlah tampilan, tetapi harus dilakukan terutama untuk membantu pemahaman dan menunjukkan hubungan.


Tidak ada komentar:

Poskan Komentar