BAB 10: PERANCANGAN ARSITEKTURAL SOFTWARE ENGINEERING (REKAYASA PERANGKAT LUNAK) PTIK/JPTE/FT/UNM
CHAPTER 10
1
Muhlis Tahir 092904033 PTIK A 2009
CHAPTER 10
2
TUJUAN : Memahami mengapa perancangan arsitektural perangkat lunak sangat penting. Memahami kemungkinan diperlukannya lebih dari satu model untuk mendokumentasikan arsitektur sistem Mengetahui sejumlah tipe arsitektur perangkat lunak yang , yang mencakup struktur sistem, dekomposisi modular dan kontrol. Memahami bagaimana model arsitektur spesifik domain dapat digunakan sebagai dasar untuk arsitektur jalur-produk dan untuk membandingkan implementasi arsitektur. CHAPTER 10
3
TOPIK YANG DIBAHAS Penstrukturan sistem Model kontrol Dekomposisi modular Arsitektur spesifik-domain
CHAPTER 10
4
ARSITEKTUR PERANGKAT LUNAK Sistem-sistem besar selalu diuraikan menjadi subsistem-subsistem yang memberikan sekumpulan layanan yang berhubungan Proses perancangan awal untuk mengidentifikasi subsistem ini dan menetapkan kerangka kerja untuk kontrol dan komunikasinya disebut perancangan arsitektural Output proses perancangan ini disebut arsitektur perangkat lunak CHAPTER 10
5
PERANCANGAN ARSITEKTUR Tahapan awal dari proses perancangan sistem Sarana untuk link antara spesifikasi dengan perancangan proses Dilakukan secara paralel dengan beberapa aktivitas spesifikasi Mengidentifikasi komponen utama sistem dan bagaimana komunikasi diantaranya
CHAPTER 10
6
KEUNTUNGAN PERANCANGAN Komunikasi Stakeholder • Arsitektur merupakan presentasi tingkat tinggi dari sistem yang dapat digunakan sebagai fokus pembahasan oleh berbagai stakeholder Analisis Sistem • Artinya apakah analisis dapat menggabungkan kebutuhan fungsi dan non fungsi Pemakaian Ulang Berskala Besar • Perancangan ini mendukung konsep “reusable”
CHAPTER 10
7
PROSES PERANCANGAN ARSITEKTURAL Penstrukturan Sistem • Sistem di dekomposisi ke dalam beberapa sub-sistem dan komunikasi diantara subsistem ini harus dapat diidentifikasi Pemodelan Kontrol • Model umum hubungan kontrol antara bagian -bagian sistem ditetapkan Dekomposisi Modular • Setiap sub-sistem yang teridentifikasi diuraikan menjadi modulmodul
CHAPTER 10
8
SUB-SISTEM DAN MODUL Sub-sistem adalah sistem yg berdiri sendiri yg operasinya tidak bertumpu pada layanan yg disediakan oleh subsistem-subsistem lain. Modul adalah komponen sistem yg menyediakan satu atau lebih layanan untuk modul lain. Modul biasanya tidak dianggap sebagai sistem yg independen. CHAPTER 10
9
MODEL ARSITEKTUR Berbagai macam model arsitektur dapat dihasilkan selama proses perancangan Tiap-tiap model mewakili sudut pandang yang berlainan
CHAPTER 10
10
MODEL ARSITEKTUR (LANJ …) Model struktur statis yg menunjukkan subsistemsubsistem atau komponen-komponen yang akan dikembangkan sebagai unit-unit yang terpisah Model dinamis menunjukkan struktur proses dari sistem Model interface mendefinisikan layanan yang disediakan oleh setiap subsistem melalui interface umum mereka Model hubungan yang menunjukkan hubungan seperti aliran data di antara subsistem-subsistem
CHAPTER 10
11
GAYA ARSITEKTUR Perancangan arsitektur bisa didasarkan pada model atau gaya arsitektur tertentu. Pengetahuan akan gaya arsitektur ini akan menyederhanakan masalah-masalah yang berkaitan dengan pendefinisian arsitektur sistem. Oleh karena itu sistem yang besar dan heterogen tentu tidak dapat diselesaikan dengan gaya arsitektur tunggal CHAPTER 10
12
ATRIBUT ARSITEKTUR Kinerja • Ar sitektur harus dirancang untuk melokalisasi operas-operasi kritis dalam sejumlah kecil subsistem dengan komunikasi sesedikit mungkin antara subsistem-subsistem. Keamanan • Gunakan struktur berlapis untuk arsitekturnya, dengan aset yang paling pentingterlindung pada bagian dalam.
Keselamatan • Operasi-operasi yang berhubungan dengan keselamatan sebaiknya berada dalam sejumlah kecil subsistem. Ketersediaan • Sediakan komponen redundan dalam perancangan arsitektur Kemampuan Dipelihara • Ar sitektur sistem harus dirancang dengan menggunakan komponen kecil dan berdiri sendiri, yang dapat diganti segera
CHAPTER 10
13
PENSTRUKTURAN SISTEM Berhubungan dengan Model yang lebih spesifik penguraian sistem menjadi menunjukkan bagaimana satu set subsistem yang subsistem membagi data , berinteraksi mendistribusikan dan interface dengan tiap-tiap Pada tingkat yang paling subsistem abstrak , desain arsitektural dapat digambarkan sebagai diagram blok di mana setiap blok pada diagram merepresentasikan subsistem
CHAPTER 10
14
DIAGRAM BLOK SISTEM KONTROL ROBOT PENGEPAK
CHAPTER 10
15
KETERANGAN GAMBAR DIAGRAM BLOK SISTEM KONTROL ROBOT PENGEPAK Merupakan model struktural arsitektur untuk sistem robot pengepak sistem robotik ini dapat mengepak berbagai benda. Sistem ini menggunakan subsistem menggunakan subsitem visi untuk memilih benda pada ban berjalan,mengidentifikasi jenis benda tersebut, dan memilih pengepak yang sesuai.
CHAPTER 10
16
MODEL REPOSITORI [MEDIA PENYIMPANAN] Subsistem harus mempertukarkan data . Hal ini bisa dilakukan dengan dua cara : • Semua data bersama disimpan pada database pusat sehingga dapat diakses oleh semua subsistem. Model ini disebut model repositori. • Setiap subsistem memelihara database sendiri. Data dipertukarkan dengan subsistem lain dengan mengirimkan message Bila jumlah data yang dipertukarkan itu sangat besar . Maka model repositori yang lebih sering digunakan
CHAPTER 10
17
ARSITEKTUR TOOLSET CASE
CHAPTER 10
18
KETERANGAN GAMBAR ARSITEKTUR TOOLSET CASE Merupakan contoh arsitektur toolset CASE yang berdasarkan diatas repositori yang dipakai bersama. Repositori bersama pertama untuk CASE tool mungkin dikembangkan diawal tahun 1970-an oleh perusahaan UK yang bernama ICL untuk mendukung pengembangan sistem operasi mereka (McGuffin et al., 1979). Model ini terkenal ketika Buxton(1980) membuat proposal untuk environment. Stoneman demi mendukung pengembangan sistem yang ditulis.
CHAPTER 10
19
KARAKTERISTIK MODEL REPOSITORI Keuntungan • Efisien untuk pemakaian data bersama. • Subsistem dapat menyetujui model data repositori yang merupakan kompromi antara berbagai kepentingan. • Model pemakaian bersama dapat dimasukkan dalam skema repositori Kerugian • Evolusi data menjadi sulit dan rumit • Kebijaksanaan data dipaksa menjadi seragam • Tidak mudah mendistribusikan repositori ke dalam sejumlah mesin
CHAPTER 10
20
ARSITEKTUR CLIENT-SERVER Model Arsitektur client-server merupakan model sistem terdistribusi yang menunjukkan bagaimana data dan pemrosesan didistribusikan pada serangkaian prosessor, komponen utamanya : • Satu set server stand-alone yang memberikan layanan ke subsistem lainnya seperti printing, data management, etc. • Satu set client yang minta layanan yang diberikan oleh server • Satu set jaringan yang memungkinkan pelanggan mengakses layanan-layanan ini
CHAPTER 10
21
ARSITEKTUR SISTEM PERPUSTAKAAN FILM DAN GAMBAR
CHAPTER 10
22
KETERANGAN GAMBAR ARSITEKTUR SISTEM PERPUSTAKAAN FILM DAN GAMBAR Ini merupakan sistem hiperteks multiuser untuk menyediakan perpustakaan film dan foto. Pada sistem ini ada beberapa server yang menangani dan menampilan jenis media yang berbeda. Kerangka video ini harus ditransmisikan dengan cepat dan sinkron tetapi dengan resolusi yang relatif rendah. Kerangka ini dapat dikompres dalam penyimpanannya. Namun demikian, gambar diam harus harus menyediakan link kesistem informasi hiperteks.
CHAPTER 10
23
KARAKTERISTIK CLIENT-SERVER Keuntungan • Distribusi dari data dapat dilaksanakan secara langsung. • Mudah untuk menambah server yang baru maupun update server yang ada Kerugian • No shared data model so sub -systems use dif ferent data organisation. data interchange may be inef ficient • Redundant management in each server • No central register of names and services - it may be hard to find out what servers and services are available
CHAPTER 10
24
MODEL MESIN ABSTRAK Digunakan untuk memodelkan interfacing sub-sistem. Model ini mengorganisasikan sistem menjadi serangkaian lapisan yang masing-masing menyediakan serangkaian layanan. Pendekatan mendukung pengembangan sistem inkremental. Sementara suatu lapisan dikembangkan, beberapa layanan yang diberikan oleh lapisan tersebut dapat disediakan bagi user. Kerugian pendekatan berlapis adalah bahwa penstrukturan sistem dengan cara ini mungkin sulit.
CHAPTER 10
25
MESIN ABSTRAK VERSI MANAJEMEN SISTEM
CHAPTER 10
26
KETERANGAN GAMBAR MESIN ABSTRAK VERSI MANAJEMEN SISTEM Gambar tersebut memiliki persamaan dengan model Programming Support Environment dan menunjukkan bagaimana sistem diintegrasikan dengan memakai pendekatan mesin abstrak ini.
CHAPTER 10
27
MODEL KONTROL Membahas bagaimana sistem diuraikan menjadi subsistem-subsistem . Ada dua pendekatan umum untuk model kontrol : • Kontrol tersentralisasi dimana satu subsistem memiliki tanggung jawab menyeluruh untuk kontrol. • Kontrol berbasis event setiap subsistem dapat menanggapi event yang dibangkitkan secara eksternal.
CHAPTER 10
28
KONTROL TERSENTRALISASI S atu subsistem ditujukan sebagai kontroler sistem dan memiliki tanggung jawab untuk mengatur eksekusi subsistemsubsistem lainnya. Model Call-Return • Model subrutin top-down biasa , dimana kontrol di mulai dari puncak hirarki subrutin dan melalui pemanggilan subrutin diteruskan ketingkat yang lebih bawah Model Manager • Satu komponen sistem ditunjuk sebagai manajer sistem dan mengendalikan awal, akhir, dan koordinasi proses-proses sistem lainnya Dapat Dilihat pada gambar dibawah ini. CHAPTER 10
29
MODEL KONTROL CALL-RETURN
CHAPTER 10
30
MODEL KONTROL REAL-TIME
CHAPTER 10
31
KETERANGAN GAMBAR MODEL KONTROL REAL-TIME Merupakan ilustrasi model manajemen tersentralisasi dari kontrol untuk sistem konkuren. Model ini sering digunakan pada sistem real time yang tidak memiliki batas waktu yang ketat. Kontroler pusat menangani eksekusi serangkaian proses yang berhubungan dengan sensor atau akuator
CHAPTER 10
32
SISTEM EVENT-DRIVEN Model kontrol event-drivent dikendalikan oleh event yang dibangkitkan secara eksternal Ada dua prinsip even-drivent : • Model Broadcast. Pada model ini suatu event, pada prinsipnya melakukan penyiaran (broadcast) event ke semua subsistem • Model Interrupt-driven. Model ini digunakan secara eksklusif pada siste real-time dimana interrupt eksternal dideteksi oleh sebuah interrupt handler Model event drivent yang lain termasuk spreadsheets dan sistem produksi
CHAPTER 10
33
MODEL BROADCAST Model ini efektif dalam mengintegrasikan subsistem yang terdistribusi melintasi komputer-komputer pada suatu jaringan. Subsistem memutuskan event mana yang mereka butuhkan dan event dan message handler menjamin bahwa event-event ini dikirimkan ke subsistem. Sebuah subsistem dapat secara eksplisit mengirimkan message ke subsistem lain. Setiap subsistem dapat mengaktifkan subsistem manapun tanpa mengetahui nama dan lokasinya. Biar lebih jelas anda dapat melihat gambar dibawah ini CHAPTER 10
34
BROADCAST SELEKTIF
CHAPTER 10
35
SISTEM INTERRUPT-DRIVEN Digunakan untuk sistem real-time dengan response mendadak Ada sejumlah tipe interrupt yang diketahui,yang didefinisikan handler untuk setiap tipenya. Tiap–tiap tipe interrupt dihubungkan dengan lokasi memori di mana alamat handler di simpan. Kerugiannya ialah bahwa pemrograman menjadi kompleks dan validasi menjadi sulit.
CHAPTER 10
36
KONTROL INTERRUPT-DRIVEN
CHAPTER 10
37
DEKOMPOSISI MODULAR Bentuk lain dari level struktur dimana subsistem didekomposisi ke dalam modul-modul Ada dua model yg dapat digunakan untuk menguraikan subsistem menjadi modul : • Model berorientasi objek. Sistem diuraikan menjadi serangkaian objek yang berkomunikasi • Model aliran data. Sistem diuraikan menjadi Moduls fungsional yang menerima data input dan mentransformasikannya Jika memungkinkan , keputusan tentang konkurensi ditunda sampai modul dapat diimplementasikan.
CHAPTER 10
38
MODEL OBJEK Struktur sistem dimana serangkaian objek yang terhubung longgar dengan interface yang terdefinisi dengan baik Dekomposisi berorientasi objek membahas kelas objek, atribut, dan operasinya . Ketika diimplementasikan,objek dibuat dari kelaskelas ini dan suatu model kontrol digunakan untuk mengkordinasikan operasi objek, contoh kelas INVOICE pada gambar di bawah.
CHAPTER 10
39
MODEL OBJEK SISTEM PEMROSESAN INVOICEMODEL OBJEK SISTEM PEMROSESAN INVOICE
CHAPTER 10
40
KETERANGAN GAMBAR MODEL OBJEK SISTEM PEMROSESAN INVOICEMODEL OBJEK SISTEM PEMROSESAN INVOICE Merupakan contoh model arsitektural berorientasi objek untuk sistem pemrosesan faktur. Sistem ini dapat mengeluarkan faktur untuk pelanggan,menerima pembayaran mengeluarkan resi untuk pembayaran ini dan bisa berfungsi sebagai sebagai pengingat faktur-faktur yang tidak dibayar.
CHAPTER 10
41
MODEL ALIRAN DATA Pada model aliran data , transformasi fungsional memproses input dan menghasilkan output Model ini kadangkala disebut model pipa (pipe) dan filter mengikuti istilah pada sistem UNIX Varian model aliran data ini telah dipakai sejak komputer pertama kali digunakan untuk pemrosesan otomatis Tidak berapa cocok untuk sistem interaktif
CHAPTER 10
42
MODEL ALIRAN DATA PROSES INVOICE
CHAPTER 10
43
KETERANGAN GAMBAR MODEL OBJEK SISTEM PEMROSESAN INVOICEMODEL OBJEK SISTEM PEMROSESAN INVOICE Sebuah organisasi telah mengeluarkan faktur kepada pelanggan . Sekali seminggu pembayaran yang telah dilakukan dipasangkan dengan fakturnya. Untuk faktur yang telah dibayar, diberikan satu resi. Untuk faktur yang belum dibayar dalam waktu yang telah ditentukan, dikeluarkan dan peringatan.
CHAPTER 10
44
ARSITEKTUR SPESIFIK DOMAIN Model arsitektur yang spesifik bagi suatu domain aplikasi yang dapat digunakan Ada dua tipe model arsitektur spesifik : • Model Generik. Merupakan abstraksi dari sejumlah sistem riil. • Model referensi . Lebih abstrak dan mendeskripsikan kelas sistem yang lebih besar. Model generik adalah pendekatan bottom-up models; Model referensi adalah pendekatan top-down models
CHAPTER 10
45
MODEL GENERIK Kompiler adalah model generik yang baik, kompiler mencakup : • Lexical analyser • Symbol table • Syntax analyser • Syntax tree • Semantic analyser • Code generator Model generik kompiler dapat diorganisasikan dengan berbagai model arsitektur.
CHAPTER 10
46
MODEL COMPILER
CHAPTER 10
47
KETERANGAN GAMBAR MODEL COMPILER Komponen-komponen yang membentuk compiler dapat diorganisasikan menurut model arsitektural yang berbeda. Sebagaimana ditunjukan oleh garlan dan shaw (1993), compiler dapat diimplementasi dengan memakai model komposit. Arsitektur aliran data dapat digunakan , dengan tabel simbol berfungsi sebagai repositori untuk data yang dipakai bersama. Fase analisis leksikal, sintatik, dan semantik diatur secara sekuensial.
CHAPTER 10
48
SISTEM PEMROSESAN BAHASA
CHAPTER 10
49
KETERANGAN GAMBAR SISTEM PEMROSESAN BAHASA Model ini masih digunakan secara luas. Model ini efektif dalam lingkungan batch dimana program dikomplikasi dan dieksekusi tanpa interaksi user. Namun demikian, model ini kurang efektif jika compiler akan diintegrasi denagn alat bantu pemrosesan bahasa lain seperti sistem edit terstruktur, debugger interaktif, program pretty printer, dll. Komponen-komponen sistem generik dengan demikian dapat di organisasikan pada model berbasiskan repositor.
CHAPTER 10
50
ARSITEKTUR REFERENSI
Model referensi biasanya diturunkan dari studi domain aplikasi Model ini merepresentasikan arsitektur yang ideal, yang mencakup semua fitur yang dapat dimiliki sistem Contoh arsitektur referensi adalah model OSI layer OSI model merupakan model untuk sistem komunikasi
CHAPTER 10
51
OSI REFERENCE MODEL
CHAPTER 10
52
KETERANGAN GAMBAR OSI REFERENCE MODEL Model referensi OSI merupakan model kerangka kerja yang diterima secara global bagi pengembangan standar yang lengkap dan terbuka. Model OSI membantu menciptakan standar terbuka antar system untuk saling berhubungan dan saling berkomunikasi terutama dalam bidang teknologi informasi. Model referensi OSI secara konseptual terbagi ke dalam 7 lapisan dimana masing-masing lapisan memiliki fungsi jaringan yang spesifik. Model ini diciptakan berdasarkan sebuah proposal yang dibuat oleh The International Standards Organization (ISO) sebagai langkah awal menuju standarisasi protokol Internasional yang digunakan pada berbagai Layer .
CHAPTER 10
53
KETERANGAN GAMBAR OSI REFERENCE MODEL (1) Tujuan OSI Koordinasi berbagai kegiatan. Penyimpanan data. Manajemen sumber dan proses. Keandalan dan keamanan sistem pendukung perangkat lunak . Membuat kerangka agar sistem / jaringan yang mengikutinya dapat saling berkomunikasi/ saling bertukar informasi, sehingga tidak tergantung merk dan model peralatan. 3 layer pertama adalah interface antara terminal dan jaringan yang dipakai bersama, 4 layer selanjutnya adalah hubungan antara software. Antar layer berlainan terdapat interface, layer yang sama terdapat protokol.
CHAPTER 10
54
HAL-HAL PENTING Arsitektur PL merupakan kerangka kerja fundamental bagi penstrukturan sistem. Sistem yang besar jarang mengikuti satu model arsitektur, biasanya gabungan dari beberapa model Model dekomposisi sistem mencakup model repositori, model client-server, model mesin abstrak. Model kontrol mencakup kontrol tersentralisasi dan model event Model dekomposisi modular mencakup model aliran data dan model objekModel arsitektur spesifik domain merupakan abstraksi terhadap domain aplikasi CHAPTER 10
55
SEKIAN DAN TERIMA KASIH
CHAPTER 10
56
