SOFTWARE ENGINEERING

(REKAYASA PERANGKAT LUNAK)

PTIK/JPTE/FT/UNM

BAB 10: PERANCANGAN ARSITEKTURAL

CHAPTER 10 1

Muhlis Tahir

092904033

PTIK A 2009

CHAPTER 10 2

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.

TUJUAN :

CHAPTER 10 3

Penstrukturan sistem

Model kontrol

Dekomposisi modular

Arsitektur spesifik-domain

TOPIK YANG DIBAHAS

CHAPTER 10 4

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

ARSITEKTUR PERANGKAT LUNAK

CHAPTER 10 5

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

PERANCANGAN ARSITEKTUR

CHAPTER 10 6

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”

KEUNTUNGAN PERANCANGAN

CHAPTER 10 7

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

PROSES PERANCANGAN

ARSITEKTURAL

CHAPTER 10 8

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.

SUB-SISTEM DAN MODUL

CHAPTER 10 9

Berbagai macam model arsitektur dapat

dihasilkan selama proses perancangan

Tiap-tiap model mewakili sudut pandang yang

berlainan

MODEL ARSITEKTUR

CHAPTER 10 10

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

MODEL ARSITEKTUR (LANJ …)

CHAPTER 10 11

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

GAYA ARSITEKTUR

CHAPTER 10 12

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

ATRIBUT ARSITEKTUR

CHAPTER 10 13

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

PENSTRUKTURAN SISTEM

CHAPTER 10 14

DIAGRAM BLOK SISTEM KONTROL ROBOT

PENGEPAK

CHAPTER 10 15

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.

KETERANGAN GAMBAR DIAGRAM BLOK

SISTEM KONTROL ROBOT PENGEPAK

CHAPTER 10 16

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

MODEL REPOSITORI [MEDIA PENYIMPANAN]

CHAPTER 10 17

ARSITEKTUR TOOLSET CASE

CHAPTER 10 18

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.

KETERANGAN GAMBAR ARSITEKTUR

TOOLSET CASE

CHAPTER 10 19

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

KARAKTERISTIK MODEL REPOSITORI

CHAPTER 10 20

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

ARSITEKTUR CLIENT-SERVER

CHAPTER 10 21

ARSITEKTUR SISTEM PERPUSTAKAAN

FILM DAN GAMBAR

CHAPTER 10 22

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.

KETERANGAN GAMBAR ARSITEKTUR

SISTEM PERPUSTAKAAN FILM DAN

GAMBAR

CHAPTER 10 23

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 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

KARAKTERISTIK CLIENT-SERVER

CHAPTER 10 24

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.

MODEL MESIN ABSTRAK

CHAPTER 10 25

MESIN ABSTRAK VERSI MANAJEMEN

SISTEM

CHAPTER 10 26

Gambar tersebut memiliki persamaan dengan

model Programming Support Environment dan

menunjukkan bagaimana sistem diintegrasikan

dengan memakai pendekatan mesin abstrak ini.

KETERANGAN GAMBAR MESIN ABSTRAK

VERSI MANAJEMEN SISTEM

CHAPTER 10 27

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.

MODEL KONTROL

CHAPTER 10 28

Satu subsistem ditujukan sebagai kontroler sistem dan

memiliki tanggung jawab untuk mengatur eksekusi subsistem-

subsistem 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.

KONTROL TERSENTRALISASI

CHAPTER 10 29

MODEL KONTROL CALL-RETURN

CHAPTER 10 30

MODEL KONTROL REAL-TIME

CHAPTER 10 31

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

KETERANGAN GAMBAR MODEL KONTROL

REAL-TIME

CHAPTER 10 32

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

SISTEM EVENT-DRIVEN

CHAPTER 10 33

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

MODEL BROADCAST

CHAPTER 10 34

BROADCAST SELEKTIF

CHAPTER 10 35

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.

SISTEM INTERRUPT-DRIVEN

CHAPTER 10 36

KONTROL INTERRUPT-DRIVEN

CHAPTER 10 37

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.

DEKOMPOSISI MODULAR

CHAPTER 10 38

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 kelas-

kelas ini dan suatu model kontrol digunakan untuk

mengkordinasikan operasi objek, contoh kelas

INVOICE pada gambar di bawah.

MODEL OBJEK

CHAPTER 10 39

MODEL OBJEK SISTEM PEMROSESAN

INVOICEMODEL OBJEK SISTEM PEMROSESAN

INVOICE

CHAPTER 10 40

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.

KETERANGAN GAMBAR MODEL OBJEK SISTEM

PEMROSESAN INVOICEMODEL OBJEK SISTEM

PEMROSESAN INVOICE

CHAPTER 10 41

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

MODEL ALIRAN DATA

CHAPTER 10 42

MODEL ALIRAN DATA PROSES INVOICE

CHAPTER 10 43

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.

KETERANGAN GAMBAR MODEL OBJEK SISTEM

PEMROSESAN INVOICEMODEL OBJEK SISTEM

PEMROSESAN INVOICE

CHAPTER 10 44

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

ARSITEKTUR SPESIFIK DOMAIN

CHAPTER 10 45

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.

MODEL GENERIK

CHAPTER 10 46

MODEL COMPILER

CHAPTER 10 47

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.

KETERANGAN GAMBAR MODEL

COMPILER

CHAPTER 10 48

SISTEM PEMROSESAN BAHASA

CHAPTER 10 49

Model ini masih digunakan secara luas. Model ini efektif dalam

l ingkungan batch dimana program dikomplikasi dan dieksekusi

tanpa interaksi user. Namun demikian, model ini kurang efektif

j ika 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.

KETERANGAN GAMBAR SISTEM

PEMROSESAN BAHASA

CHAPTER 10 50

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

ARSITEKTUR REFERENSI

CHAPTER 10 51

OSI REFERENCE MODEL

CHAPTER 10 52

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 .

KETERANGAN GAMBAR OSI

REFERENCE MODEL

CHAPTER 10 53

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.

KETERANGAN GAMBAR OSI

REFERENCE MODEL (1)

CHAPTER 10 54

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

HAL-HAL PENTING

CHAPTER 10 55

SEKIAN DAN TERIMA KASIH

CHAPTER 10 56