Software Engineering Chapter 10 Kelompok 3Rekayasa Perangkat Lunak Chapter 101 Pendidikan Teknik Informatika dan Komputer

Kelompok 3Rekayasa Perangkat Lunak Chapter Syaputri Artami S Ayu Anggriani H Rudy Dian Syah Zulfadli Sulthan Jumiati Husnaeni Nurhalimah

Penstrukturan sistem Model kontrol Dekomposisi modular Arsitektur spesifik-domain Kelompok 3Rekayasa Perangkat Lunak Chapter 103

Proses perancangan untuk mengidentifikasi sub- sistem yang membangun sebuah sistem dan merupakan kerangka kerja bagi kontrol dan komunikasi sub-sistem adalah perancangan arsitektural Hasil dari perancangan ini dideskripsikan sebagai arsitektur perangkat lunak Kelompok 3Rekayasa Perangkat Lunak Chapter 104

Merupakan tahap awal dari proses perancangan sistem Merupakan hubungan antara spesifikasi dan proses desain Sering dilakukan secara paralel dengan beberapa aktifitas spesifikasi Hal ini melibatkan identifikasi komponen utama sistem dan proses komunikasinya Kelompok 3Rekayasa Perangkat Lunak Chapter 105

Komunikasi stakeholder Arsitektur dapat dijadikan sebagai fokus diskusi bagi para pemegang kepentingan (stakeholder) Analisis sistem Menganalis apakah sistem dapat memenuhi persyaratan kritis seperti kinerja, keandalan dan keampuan pemeliharaan Pemakaian ulang berskala besar Arsitektur mungkin dapat digunakan kembali pada berbagai sistem Kelompok 3Rekayasa Perangkat Lunak Chapter 106

Penstrukturan sistem Sistem distruktur menjadi sejumlah sub-sistem utama dan pengidentifikasian komunikasi antar sub-sistem Pemodelan kontrol Model umum hubungan kontrol antara bagian-bagian sistem ditetapkan Dekomposisi modular Susb-sistem diidentifikasi dan didekomposisi menjadi modul-modul Kelompok 3Rekayasa Perangkat Lunak Chapter 107

Sub-sistem adalah sistem yang berkerja secara independen berdasarkan layanan yang diberikan oleh sub-sistem lainnya Modul adalah komponen sistem satu atau lebih layanan untuk modul lain tapi umumnya tidak dianggap sebagai sistem yang terpisah Kelompok 3Rekayasa Perangkat Lunak Chapter 108

Model arsitektur yang berbeda dapat saja dihasilkan selama proses perancangan Setiap model meyajikan perspektif yang berbeda berdasarkan pada arsitekturnya Kelompok 3Rekayasa Perangkat Lunak Chapter 109

Model struktural statis menggambarkan komponen sistem utama Model proses dinamis menggambarkan struktur proses dari sistem Model interface yang menunjukkan interface sub- sistem Model hubungan menunjukkan hubungan seperti aliran data antar sub-sistem Kelompok 3Rekayasa Perangkat Lunak Chapter 1010

Model arsitektur sistem mungkin sesuai dengan model atau gaya arsitektural generik Kesadaran gaya ini dapat menyederhanakan masalah sistem dalam mendefinisikan arsitekturnya Namun, banyak sistem besar yang sangat heterogen dan tidak mengikuti perancangan arsitektural tunggal Kelompok 3Rekayasa Perangkat Lunak Chapter 1011

Kinerja Melokalisasi operasi-operasi kritis untuk meminimalkan komunikasi antar sub-sistem Keamanan Menggunakan arsitektur berlapis, dan menempatkan aset terpenting pada lapisan terdalam Keselamatan Mengisolasi keselamatan tethadap komponen-komponen kritis Ketersediaan Menyertakan redudan komponen tanpa menghentikan sistem Kemampuan pemeliharaan Menggunakan komponen kecil dan berdiri sendiri dan dapt diganti sesegera mungkin Kelompok 3Rekayasa Perangkat Lunak Chapter 1012

Behubungan dengan dekomposisi sistem ke interaksi sub-sistem Perancangan arsitektural biasanya dinyatakan dalam blok diagram yang menyajikan gambaran dari struktur sistem Beberapa model-spesifik menunjukkan cara sub- sistem berbagi data, distribusi dan antarmuka satu sama lain yang dapat dibangun Kelompok 3Rekayasa Perangkat Lunak Chapter 1013

Kelompok 3Rekayasa Perangkat Lunak Chapter 1014

Sub-sistem melakukan pertukaran data. Hal ini dimungkinkan dengan 2 cara: Data disimpan pada sebuah pusat database atau repository yang dapat diakses oelh semua sub-sistem Setiap sub-sistem memelihara database sendiri dan dapat dipertukarkan dengan sub-sistem lain dengan mengirimkan message kepadanya Dalam hal berbagi data dalam jumlah yang sangat besar, model repository yang paling fleksible untuk digunakan Kelompok 3Rekayasa Perangkat Lunak Chapter 1015

Kelompok 3Rekayasa Perangkat Lunak Chapter 1016

Kelebihan Cara yang efisien berbagi data dalam jumlah besar Sub-sistem tidak perlu tahu bagaimana data yang diproduksi oleh manajemen terpusat. Misalanya backup, keamanan dll. Model berbagi data berbentuk skema repository Kekurangan Sub-sistem harus setuju pada model data repository. Hal ini merupakan komporomi antara kebutuhan-kebutuhan khusus dari setiap alat bantu Evolusi data sulit dan mahal Model repository memaksakan kebijakan yang sama untuk semua sub-sistem Mungkin sulit untuk mendistribusikannya secara efektif ke sejumlah mesin. Kelompok 3Rekayasa Perangkat Lunak Chapter 1017

Model sistem terdistribusi menunjukkan bagaimana data dan pengolahannya didistribusikan ke berbagai komponen Stand-alone server menyediakan layan khusus seperti pencetakan, manajemen data, dll. Client yang mengakses layanan tersebut Dengan teknologi jaringan, client di mungkinkan untuk dapat mengakses server Kelompok 3Rekayasa Perangkat Lunak Chapter 1018

Kelompok 3Rekayasa Perangkat Lunak Chapter 1019

Kelebihan Distribusi data langsung Efektif dengan menggunkan sistem jaringan. Mudah untuk menambah server baru atau meng-upgrade server yang ada. Kekurangan Tidak ada model berbagi data yang sama sehingga sub- sistem menggunakan organisasi data yang berbeda. Pertukaran data menjadi tidak efisien dalam kasus ini. Diperlukan manajemen redudansi data disetiap server. Tidak ada pusat registrasi nama server dan servisnya. Hal ini menyebabkan kesulitan mengetahui apakah server dan layan tersedia atau tidak Kelompok 3Rekayasa Perangkat Lunak Chapter 1020

Digunakan untuk model interfacing sub-sistem Model ini mengorganisir sistem menjadi serangkaian lapisan yang masing-masing menyediakan serangkaian layanan Mendukung pengembangan sub-sistem secara incremental pada lapisan yang berbeda. Ketika antar muka lapisan dirubah, hanya lapisan terdekat yang dipengaruhinya Namun, sangat sulit untuk struktur sistem seperti ini Kelompok 3Rekayasa Perangkat Lunak Chapter 1021

Kelompok 3Rekayasa Perangkat Lunak Chapter 1022

Model struktural tidak seharusnya mencakup informasi kontrol. Hal ini berkenaan dengan kontrol aliran data antar sub-sistem Kontrol tersentralisasi Satu sub sistem memiliki tanggung jawab menyeluruh untuk mengontrol dan memulai dan menghentikan sub- sistem lainnya Kontrol berbasis-event Setiap sub-sistem menanggapi event yang dibangkitkan secara eksternal dari sub-sistem lain atau dari lingkungan sistem itu sendiri Kelompok 3Rekayasa Perangkat Lunak Chapter 1023

Merupakan sub-sistem yang ditujukan sebagai pengendali dan memiliki tanggungjawab untuk mengatur eksekusi sub-sistem lainnya Model call-return Model subrutin top-down yang biasa, dimana kontrol kontrol dimulai dari puncak hirarki subrutin dan diteruskan ktingkat yang lebih bawah. Model ini diterapkan pad sistem sekuensial Model manajer Model ini diterapkan pada sistem konkuren. Sebuah komponen sistem mengontrol proses penghentian, memulai dan koordinasi proses-proses sistem lainnya. Model ini diimplementasikan sebagai statement case Kelompok 3Rekayasa Perangkat Lunak Chapter 1024

Kelompok 3Rekayasa Perangkat Lunak Chapter 1025

Kelompok 3Rekayasa Perangkat Lunak Chapter 1026

Model kontrol event-driven dikendalikan oleh event yang dibangkitkan secara eksternal dimana timing event berada diluar kontrol proses yang menangani event tersebut Model kontrol event-driven Model Broadcast. Sebuah event dibroadcast ke semua sub-sistem. Setiap sub-sistem yang dapat menangani event ini akan menanggapinya. Model interrupt-driven. Digunakan pada sistem real-time dimana interupt eksternal dideteksi oleh sebuah intterupt handler dan kemudian diteruskan ke komponen lain untuk diolah Kelompok 3Rekayasa Perangkat Lunak Chapter 1027

Efektif dalam mengintegrasikan sub-sistem pada komputer yang berbeda dalam jaringan Sub-sitem didaftarkan untuk event-event tertentu, Ketika hal ini terjadi makan kontrol akan ke sub-sistem yang dapat meangani event tersebut Kebijakan kontrol tidak tertanam dalam pesan dan event handler. Sub-sistem mengerjakan event yang sesuai dengan fungsinya Namun, sub-sistem tidak tahu apa dan kapan event itu harus ditangani Kelompok 3Rekayasa Perangkat Lunak Chapter 1028

Kelompok 3Rekayasa Perangkat Lunak Chapter 1029

Digunakan pada sistem real-time dimana respon cepat terhadap event penting Ada jenis interrupt yang dikenali, yang didefiniskan handler untuk setiap tipenya Setiap tipe intterupt dihubungkan dengan lokasi memori dimana alamt handler disimpan Memungkinkan respon yang cepat tapi kompleks untuk program dan validasi yang sulit Kelompok 3Rekayasa Perangkat Lunak Chapter 1030

Kelompok 3Rekayasa Perangkat Lunak Chapter 1031

Another structural level where sub-systems are decomposed into modules Two modular decomposition models covered An object model where the system is decomposed into interacting objects A data-flow model where the system is decomposed into functional modules which transform inputs to outputs. Also known as the pipeline model If possible, decisions about concurrency should be delayed until modules are implemented Kelompok 3Rekayasa Perangkat Lunak Chapter 1032

Level struktrural lain diman sub-sistem di dekomposisi menjadi sebuah modul Model Dekomposisi modular : Model berorientasi objek. Sistem diuraikan menjadi serangkaian objek yang berkomunikasi Model Aliran data. Sistem diuraikan menjadi modul-modul fungsional yang mengubah input menjadi ouput. Biasa disebut pipilining Jika mungkin, keputusan tentang konkuransi harus ditunda sampai modul diimplementasikan Kelompok 3Rekayasa Perangkat Lunak Chapter 1033

Struktur sistem menjadi serangkaian objek yang terhubung longgar dengan interface yang terdefinisi dengan baik Dekomposisi berorientasi-objek berkaitan dengan identifikasi kelas objek, atribut dan operasinya Ketika diimplementasikan, objek dibuat dari kelas-kelas ini dan beberapa model kontrol digunakan untuk mengkoordinasikan operasi suatu objek Kelompok 3Rekayasa Perangkat Lunak Chapter 1034

Kelompok 3Rekayasa Perangkat Lunak Chapter 1035

Funngsi utamanya adalah mentransformasikan input menjadi output Kadangkala disebut pipeline dan filter, mengikuti istilah yang dipakai pada sistem Unix Varian model ini umum digunakan. Ketika transformasi bersifar sekuensial dengan data yang diproses dalam batch, model arsitektural ini merupakan model sekuensial batch Tidak cocok untuk sistem yang interaktif Kelompok 3Rekayasa Perangkat Lunak Chapter 1036

Kelompok 3Rekayasa Perangkat Lunak Chapter 1037

Model arsitektural yang yang spesifik bagi suatu domain aplikasi Tipe model arsitektural spesifik-domain Model Generik yang merupakan abstraksi dari sejumlah sisem riil. Model ini meng-enkapsulasi karakteristik utama dari sistem. Model referensi, yang lebih abstrak dan mendeskripsikan kelas sistem yang lebih besar dan membandingkan arsitektur yang berbeda Model generik biasanya diturunkan secara ‘bottom-up’ dari sistem yang sudah ada; sedangkan model referensi diturunkan secara ‘top-down’. Kelompok 3Rekayasa Perangkat Lunak Chapter 1038

Model compiler merupakan contoh yang paling terkenal dari model arsitektural generik Penganalisa leksikal Tabel simbol Penganalisa sintaks Pohon sintaks Penganalisa semantik Generator kode Model Compiler generik dapat diatur berdasarkan model arsitektural yang berbeda Kelompok 3Rekayasa Perangkat Lunak Chapter 1039

Kelompok 3Rekayasa Perangkat Lunak Chapter 1040

Kelompok 3Rekayasa Perangkat Lunak Chapter 1041

Model referensi berasal dari studi domain aplikasi bukan dari sistem yang ada Dapat digunakan sebagai dasar untuk implementasi sistem atau untuk membandingkan sistem yang berbeda. Karena berfungsi sebagai standar terhadap sistem yang dapat dievaluasi Model OSI adalah model berlapis untuk sistem komunikasi. Kelompok 3Rekayasa Perangkat Lunak Chapter 1042

Application Kelompok 3Rekayasa Perangkat Lunak Chapter 1043

Arsitektur perangkat lunak merupakan kerangka kerja fundamental bagi penstrukturan sistem seperti model struktural, model kontrol dan model dekomposisi Sistem yang besar jarang mengikuti satu model arsitektural Model dekomposisi sistem meliputi model repository, model client-server, dan model mesin abstrak (virtual machine) Model Kontrol meliputi kontrol tersentralisasi dan model event-driven. Kelompok 3Rekayasa Perangkat Lunak Chapter 1044

Model dekomposisi modular meliputi Model aliran data dan Model objek Model arsitektural spesifik-domain merupakan abstraksi terhadap domain aplikasi. Model ini dibangun dari sistem yang sudah ada, atau model referensi yang merupakan model ideal dan abstrak dari domain Kelompok 3Rekayasa Perangkat Lunak Chapter 1045

Kelompok 3Rekayasa Perangkat Lunak Chapter 1046