BAB 10: PERANCANGAN ARSITEKTURAL

Transkripsi

1 BAB 10: PERANCANGAN ARSITEKTURAL SOFTWARE ENGINEERING (REKAYASA PERANGKAT LUNAK) PTIK/JPTE/FT/UNM CHAPTER 10 1

2 Muhlis Tahir PTIK A 2009 CHAPTER 10 2

3 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

4 TOPIK YANG DIBAHAS Penstrukturan sistem Model kontrol Dekomposisi modular Arsitektur spesifik-domain CHAPTER 10 4

5 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

6 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

7 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

8 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

9 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

10 MODEL ARSITEKTUR Berbagai macam model arsitektur dapat dihasilkan selama proses perancangan Tiap-tiap model mewakili sudut pandang yang berlainan CHAPTER 10 10

11 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

12 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

13 ATRIBUT ARSITEKTUR Kinerja Arsitektur 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 Arsitektur sistem harus dirancang dengan menggunakan komponen kecil dan berdiri sendiri, yang dapat diganti segera CHAPTER 10 13

14 PENSTRUKTURAN SISTEM Berhubungan dengan penguraian sistem menjadi satu set subsistem yang berinteraksi Pada tingkat yang paling abstrak, desain arsitektural dapat digambarkan sebagai diagram blok di mana setiap blok pada diagram merepresentasikan subsistem Model yang lebih spesifik menunjukkan bagaimana subsistem membagi data, mendistribusikan dan interface dengan tiap-tiap subsistem CHAPTER 10 14

15 DIAGRAM BLOK SISTEM KONTROL ROBOT PENGEPAK CHAPTER 10 15

16 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

17 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

18 ARSITEKTUR TOOLSET CASE CHAPTER 10 18

19 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

20 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

21 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

22 ARSITEKTUR SISTEM PERPUSTAKAAN FILM DAN GAMBAR CHAPTER 10 22

23 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

24 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 different data organisation. data interchange may be inefficient 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

25 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

26 MESIN ABSTRAK VERSI MANAJEMEN SISTEM CHAPTER 10 26

27 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

28 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

29 KONTROL TERSENTRALISASI Satu 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

30 MODEL KONTROL CALL-RETURN CHAPTER 10 30

31 MODEL KONTROL REAL-TIME CHAPTER 10 31

32 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

33 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

34 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

35 BROADCAST SELEKTIF CHAPTER 10 35

36 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

37 KONTROL INTERRUPT-DRIVEN CHAPTER 10 37

38 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

39 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

40 MODEL OBJEK SISTEM PEMROSESAN INVOICEMODEL OBJEK SISTEM PEMROSESAN INVOICE CHAPTER 10 40

41 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

42 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

43 MODEL ALIRAN DATA PROSES INVOICE CHAPTER 10 43

44 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

45 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

46 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

47 MODEL COMPILER CHAPTER 10 47

48 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

49 SISTEM PEMROSESAN BAHASA CHAPTER 10 49

50 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

51 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

52 OSI REFERENCE MODEL CHAPTER 10 52

53 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

54 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

55 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

56 SEKIAN DAN TERIMA KASIH CHAPTER 10 56