Bab 9. Rekayasa Desain

(1)

Bab 9 Rekayasa Desain

Tujuan Pembelajaran Umum

Mendeskripsikan perangkat lunak praktis

Tujuan Pembelajaran Khusus

Mampu Mengidentifikasikan rekayasa desain

Gambar : Rekayasa Desain

Desain dan kualitas

 Desain harus mengimplementasikan semua kebutuhan eksplisit yang ada dalam model analisis, dan dia harus mengakomodasi semua kebutuhan implisit yang diinginkan oleh konsumen.

 Desain harus dapat berupa panduan yang dapat dibaca dan dipahami oleh orang-orang yang akan membuat kode, dan mereka yang menguji serta nantinya mendukung PL tersebut.

 Desain harus menyediakan gambaran utuh dari PL, menggambarkan domain data, fungsional, dan perilaku dari perspektif implementasi.

Analy sis Model

use-cases - text use-case diagrams activity diagrams swim lane diagrams

data flow diagrams control-flow diagrams processing narratives f l o w- o r i e n t e d e l e m e n t s b e h a v i o r a l e l e m e n t s c l a ss- b a se d e l e m e n t s sc e n a r i o - b a se d e l e m e n t s class diagrams analysis packages CRC models collaboration diagrams state diagrams sequence diagrams D a t a / Cl a ss D e si g n A r c h i t e c t u r a l D e si g n I n t e r f a c e D e si g n Co m p o n e n t - L e v e l D e si g n Design Model

(2)

Panduan kualitas

 Sebuah desain harus menampilkan arsitektur yang (1) dibuat menggunakan pola atau

style arsitektural yang sudah dikenal, (2) terdiri dari komponen-komponen yang menunjukkan karakteristik desain yang baik dan (3) dapat diimplementasi dalam bentul yang evolusioner.

 Untuk sistem yang lebih kecil, desain kadang dapat dikembangkan secara linear.

 Sebuah desain harus berbentuk modular; oleh karena itu PL harus secara logis

dipartisi menjadi beberapa elemen subsistem

 Sebuah desain harus berisi representasi yang berbeda dari data ,arsitektur, antarmuka,

dan komponen.

 Sebuah desain harus menuju struktur data yang tepat untuk class-class yang akan diimplementasi dan digambar dari pola data yang dikenal.

 Sebuah desain harus menuju komponen-komponen yang menunjukkan fungsional

karakteristik yang independen.

 Sebuah desain harus menuju antarmuka yang mengurangi kompleksitas koneksi

antara kompoenen-komponen dan dengan lingkungan eksternal.

 Sebuah desain harus diturunkan menggunakan method berulang yang diatur oleh

informasi yang disebut selama analisis kebutuhan PL.

 Desain harus direpresentasikan menggunakan notasi yang secara efektif

mengkomunikasikan maknanya.

Prinsip-prinsip desain

 Proses desain tidak boleh berjalan dengan “kacamata kuda”

 Proses desain harus bisa dirujuk dari model analisis.

 Proses desain tidak boleh mengulang penemuan-penemuan dasar.

 Desain harus dapat meminimalkan jarak intelektual antara PL dan permasalah yang

ada di dunia nyata.

 Desain harus menampakkan keseragaman dan integrasi.

 Desain harus terstruktur untuk mengakomodasi perubahan.

 Desain harus terstruktur untuk turun secara bertahap, walaupun ketika data, event,

atau kondisi operasi yang menyimpang ditemui.

 Desain bukan coding dan coding bukan desain.

 Desain harus dapat dipantau kualitasnya mulai dari dia dibuat, bukan setelah jadi.

(3)

Konsep Dasar

 abstraksi—data, prosedur, kontrol

 arsitektur—Struktur keseluruhan PL

 Patterns/pola—”memuat esensi” dari solusi desain yang sudah terbukti

 modularitas—Pembagian data dan fungsi

 menyembunyikan—interface terkendali

 Independensi fungsi—single-minded function dan low coupling

 refinement—elaborasi detail dari semua abstraksi

 Refactoring—sebuah teknik reorganisasi yang menyederhanakan desain

Abstraksi data

Gambar 9.1. : Abstraksi Data

Abstraksi prosedur

Gambar 9.2.: Abstraksi prosedur door

implemented as a data structure manufacturer model number type swing direction inserts lights type number weight opening mechanism

open

implemented with a "knowledge" of the object that is associated with enter

details of enter algorithm

(4)

Arsitektur

“Struktur keseluruhan dari PL dan cara dimana struktur menyediakan integritas konseptual bagi sebuah sistem” [SHA95a]

Properti Struktural.

Aspek representasi desain arsitektur ini menentukan komponen-komponen sebuah sistem(mis : modul, objek, filter), dan pola komponen-komponen tersebut dipaket dan berinteraksi satu dengan yang lain. Sebagai contoh : objek dipaket untuk enkapsulasi baik data dan proses yang memanipulasi data dan berinteraksi dengan metode invokasi.

Properti extra-fungsional. Deskripsi desain arsitektur harus menggambarkan bagaimana arsitektur mencapai kebutuhan kinerja, kapasitas, reliabilitas, keamanan, adaptabilitas, dan karakteristik sistem yang lain.

Keluarga atau sistem-sistem yang berhubungan. Desain arsitektur harus dapat menggambar pola-pola yang diulang, yang secara umum ditemukan dalam keluarga desain atau sistem yang mirip. Esensinya, desain harus mempunyai kemampuan untuk menggunakan kembali blok-blok arsitektur bangunan

Patern/Pola

Design Pattern Template

 Nama Pattern—menggambarkan esensi pattern dalam nama yang singkat tapi

ekspresif

 Intent/Tujuan—menjelaskan pattern dan apa yang dilakukan

 Juga dikenal sebagai/Also-known-as—Daftar sinonim untuk pattern terkait

 Motivation/Motivasi—menyediakan contoh masalah

 Aplikabilitas—menjelaskan situasi desain spesifik dimana pattern dapat diterapkan

 Struktur—menggambarkan class yang dibutuhkan untuk implementasi pattern

 Participants—menggambarkan tanggungjawab class-class yang diperlukan untuk

mengimplementasikan pattern

 Collaborations—menggambarkan bagaimana participan berkolaborasi untuk

memikul tanggung jwabanya.

 Konsekuensi—menggambarkan pengaruh desain terhadap pattern dan potensi

masalah yang harus diperhatikan ketika pattern diimplementasi.

 Related patterns—relasi referensi silang design patterns

(5)

Gambar :9.3. : Desain Modular

Memodularitas permasalahan

Gambar 9.4. : Modularitas permasalhan Penyembunyian informasi

Gambar 9.5. : Penyembunyian informasi

easier to build, easier to change, easier to fix ...

Berapakah jumlah modul yang pas Untuk desain PL tertentu ?

optimal number of modules cost of software number of modules module integration cost module development cost

module controlled interface "secret" • algorithm • data structure

• details of external interface • resource allocation policy clients

(6)

Mengapa informasi disembunyikan  Mengurangi “efek samping”

 Membatasi pengaruh global dari keputusan desain lokal  Menekankan komunikasi melalui interface yang terkendali  Mengurangi penggunaan data global

 Merujuk pada enkapsulasi—sebuah atribut dari desain kualitas tinggi  Menghasilkan PL dengan kualitas tinggi

(7)

Langkah-langkah refinement

Gambar 9.6. : Langkah-langkah refinement

Independensi fungsi

Gambar 9.7. : Independensi Fungi pada Sistem

Mengukur modul dari dua sudut pandang

Gambar 9.8. : Pengukuran Modul dari dua sudut pandang

open

walk to door; reach for knob; open door; walk through; close door.

repeat until door opens turn knob clockwise; if knob doesn't turn, then

take key out; find correct key; insert in lock; endif

pull/push door move out of way; end repeat

COHESION - the degree to which a module performs one and only one function.

COUPLING - the degree to which a module is "connected" to other

modules in the system.

MODULE What's

(8)

Refaktoring

 Fowler [FOW99] mendefinisikan refactoring sbb :

 "Refactoring adalah proses mengubah sistem PL dimana dia tidak mengubah perilaku eksternal dari kode (desain) sehingga menigkatkan struktur internal.”  Ketika PL refactored, desain akan diperiksa terhadap :

 redundancy

 Elemen desain yang tidak berguna

 Algoritma yang tidak efisien atau tidak perlu

 Struktur data dengan konstruksi yang buruk atau tidak tepat

 Atau kesalahan desain lain yang dapat diperiksa untuk menghasilkan desain yang lebih baik.

Konsep Desain OO  Desain Class

 Entity classes  Boundary classes  Controller classes

 Inheritance—semua tanggung jawab superclass akan diwarisi oleh semua subclassnya

 Messages—stimulasi beberapa perilaku yang dapat terjadi pada objek penerima pesan

 Polymorphism—sebuah karakteristik yang mengurangi usaha yang dibutuhkan untuk memperluas desain

Desain Class

 Analisis class disempurnakan dalam desain untuk menjadi class-class entitas  Class-class boundary dikembangkan selama desain untuk membuat interface(mis.

Layar interaktif atau laporan cetak) yang dilihat pengguna dan berinteraksi.

 Class-class boundary didesain dengan tanggungjawab untuk mengelola cara objek entitas ditampilkan kepada user.

 Class-class control didesain untuk mengelola :  Pembuatan atau perubahan objek entitas;

 Instansiasi object boundary dengan mengambil informasi dari objek entitas;  Komunikasi kompleks antara sekelompok objek;

 Validasi data yang dikomunikasikan antar objek atau antar pengguna dan aplikasi.

(9)

Inheretance

 Pilihan-pilihan desain :

 Class dapat didesain dan dibangun dari nol. Jika demikian, inheritance tidak digunakan.

 Hierarki class dapat dicari untuk mencari kemungkinan jika sebuah class yang lebih tinggi pada hierarki (superclass) memiliki atribut-atribut dan operasi-operasi yang paling banyak dibutuhkan. Class baru ini diturunkan dari superclass dan beberapa tambahan dapat diberikan jika dibutuhkan.  Hierarki class dapat di restrukturisasi sehingga atribut-atribut dan

operasi-operasi yang dibutuhkan dan diturunkan oleh class baru tersebut.

 Karakteristik dari class yang sudah ada dapat di override dan atribut-atribut dan operasi-operasi dengan versi berbeda dapat diimplementasikan untuk class baru tersebut

Message Gambar 9.9. : Message Polymorphis :SenderObject :ReceiverObject message (<parameters>)

(10)

Pendekatan konvensional case of graphtype:

if graphtype = linegraph then DrawLineGraph (data); if graphtype = piechart then DrawPieChart (data); if graphtype = histogram then DrawHisto (data); if graphtype = kiviat then DrawKiviat (data); end case;

Semua graphs menjadi subclass dari class umum yang disebut graph. Menggunakan konsep overloading, setiap subclass mendefinisikan operasi yang disebut draw. Sebuah object dapat mengirim pesan draw pada salah satu instansiasi objek dari salah satu subclassnya. Objek yang menerima message akan menjalankan operasi draw nya sendri untuk membuat graph yang sesuai.. graphtype draw

(11)

Gambar : 9.10 Dimensi proses desain Elemen-elemen model desain

 Elemen-elemen Data

o Data model --> struktur data o Data model --> arsitektur database  Elemen-elemen arsitektur

o Domain aplikasi

o Class-class analisis, relasinya, kolaborasi dan perilaku diubah menjadi realisasi desain

o Patterns dam “styles” (Chapter 10)  Elemen-elemen interface

o user interface (UI)

o Interface external pada sistem lain, piranti-piranti, jaringan-jaringan atau produsen maupun konsumen informasi lainnya

 Interface internal antara komponen-komponen desain. o Elemen-elemen komponen

o Elemen-elemen deploy

process dimension archit ect ure

element s int erface element s component -level element s deployment -level element s low high

class diagr ams analysis packages CRC models

collabor at ion diagr ams

use- cases - t ext use- case diagr ams act ivit y diagr ams sw im lane diagr ams

collabor at ion diagr ams dat a f low diagr ams cont r ol- f low diagr ams pr ocessing nar r at ives dat a f low diagr ams

cont r ol- f low diagr ams pr ocessing nar r at ives

st at e diagr ams sequence diagr ams st at e diagr ams

sequence diagr ams

design class r ealizat ions subsyst ems

r ef inement s t o:

deployment diagr ams class diagr ams

analysis packages CRC models

component diagr ams design classes act ivit y diagr ams sequence diagr ams

r ef inement s t o:

component diagr ams design classes act ivit y diagr ams sequence diagr ams

collabor at ion diagr ams component diagr ams design classes act ivit y diagr ams sequence diagr ams

a na ly sis m ode l de sign m ode l Requirement s: const raint s int eroperabilit y t arget s and conf igurat ion

t echnical int er f ace design

Navigat ion design GUI design

(12)

Elemen-elemen komponen

Gambar : 9.11. UML Component Diagram for SafeHome Elemen-elemen deployment

Gambar 9.12. : UML Deployment Diagram for SafeHome

Design Patern

 Desainer terbaik di segala bidang tetap mempunyai keterbatasan untuk melihat pola yang mencirikan sebuah masalah dan menghubungkannya dengan pola yang dapat dikombinasikan untuk membuat solusi

 Sebuah deskripsi dari design pattern dapat juga dilihat sebagai sekumpulan design forces.

 Design forces menjelaskan kebutuhan non fungsional (misalkan : kemudahan perawatan, portabilitas) yang dihubungkan dengan PL dimana pattern akan diaplikasikan.

SensorManagement

Sensor

Figure 9 . 8 UML deploy m ent diagram f or Saf eHom e

Per sonal comput er

Security

homeManagement Surveillance

communication

Cont rol Panel CPI serv er Security homeownerAccess

(13)

 Karakteristik pattern (class, tanggungjawab, dan kolaborasi) mengindikasikan atribut-atrobit desain yang harus diatur untuk memungkinkan pattern mengakomodasi permasalahan yang bervariasi.

Frameworks

 Sebuah framework bukan merupakan pattern arsitektur, namun lebih merupakan kerangka dengan sekumpulan “plug points” (yang juga disebut hooks dan slots) yang memungkinkannya untuk beradaptasi dengan domain permasalahan tertentu.

 Gamma et al mencatat bahwa:

 Design patterns lebih abstrak dari frameworks.

 Design patterns adalah elemen-elemen arsitektural yang lebih kecil daripada frameworks

(14)

Bab 10 Desain Arsitektur

Tujuan Pembelajaran Umum

Mendeskripsikan Perangkat Lunak Praktis

Tujuan Pembelajaran Khusus

Mampu Mengidentifikasikan desain arsitektur

Arsitektur Software (Software Architecture)

Arsitektur perangkat lunak dari sebuah program atau sistem komputasi adalah struktur atau struktur dari sistem, yang terdiri dari komponen-komponen perangkat lunak, sifat eksternal terlihat dari komponen-komponen, dan hubungan di antara mereka.

Mengapa arsitektur penting

 Representasi dari arsitektur PL adalah enabler bagi komunikasi antar pihak (stakeholder) yang tertarik dengan pengembangan sistem berbasis komputer.

 Arsitketur menyoroti keputusan desain awal yang akan mempunyai pengaruh yang sangat besar pada pekerjaan RPL yang mengikutinya, dan keberhasilan pada entitas sistem operasional.

 Arsitektur membangun model yang relatif kecil dan mudah digenggam secara intelektual tentang bagaimana sistem distrukturkan dan bagaimana komponen2x bekerja sama [BAS03].

Desain data terbagi 2 antara lain :

 Tingkat Arsitektur (Architectural level)  desain database

o data mining o data warehousing

 Tingkat Komponen (Component level)  desain struktur data

Pada level arsitektur …

 Desain satu atau lebih database untuk mendukung arsitektur aplikasi  Desain method untuk „mining‟ isi dari berbagai database

(15)

 Navigasi melalui database-database yang ada dalam usaha untuk mengambil informasi level bisnis yang sesuai

 Desain sebuah data warehouse—sebuah database besar, independen yang mempunyai akses pada data yang disipan dalam database yang melayani sekelompok aplikasi yang dibutuhkan bisnis

Data-data levcl komponen

1. Prinsip-prinsip analisis semantik yang diterapkan pada fungsi dan perilaku harus juga dapat berjalan pada data.

2. Seluruh struktur data dan operasi yang akan dilakukan harus dapat diidentifikasi. 3. Sebuah data dictionary harus dibuat dan digunakan untuk menentukan desain

program dan data.

4. Keputusan desain data level rendah harus ditunda hingga akhir proses desain.

5. Representasi struktur dara harus diketahui oleh modul yang menggunakannya langsung dalam struktur tersebut (enkapsulasi).

6. Sebuah pustaka struktur data dan operasi yang memungkinkan untuk diterapkan harus dikembangkan.

7. Desain PL dan bahasa pemrograman harus mendukung spesifikasi dan realisasi dari tipe data abstrak.

Tingkat Arsitektur

Setiap gaya menggambarkan kategori sistem yang meliputi:

1. Satu set komponen (misalnya, database, modul komputasi) yang melakukan fungsi yang dibutuhkan oleh sistem,

2. Satu set konektor yang memungkinkan "komunikasi, koordinasi, dan kerjasama" antara komponen-komponen,

3. Kendala yang menentukan bagaimana komponen dapat diintegrasikan untuk membentuk sistem, dan

4. Model semantik yang memungkinkan seorang desainer untuk memahami sifat-sifat keseluruhan sistem.

Gaya-gaya spesifik pada arsitektur, yaitu :

1. Arsitektur data-terpusat (data-centered architecture) 2. Arsitektur aliran data (data flow architecture)

3. Panggilan dan kembali arsitektur (call and return architecture) 4. Arsitektur berorientasi objek (object oriented architecture) 5. arsitektur berlapis

(16)

Gambar 10.1. : Arsitektur data terpusat

Gambar : Arsitektur aliran data

(17)

Gambar 10.3. : Arsitektur Orientasi Objek

Gambar 10.4. : Arsitektur Layer

Arsitektur Pola (Patern Architecture)

 Concurrency—aplikasi harus menangani banyak tugas dalam pola yang mensimulasikan paralelisasi

o operating system process management pattern o task scheduler pattern

 Persistence—Data ada jika dia bertahan setelah eksekusi proses yang membuatnya. Ada dua pattern umum ::

o database management system pattern yang menerapkan penyimpanan dan pengambilan dari DBMS kepada arsitektur aplikasi

(18)

o application level persistence pattern yang membangun fitur persistence pada aristektur aplikasi

 Distribution— pola dimana sistem atau komponen2x di antaranya berkomunkasi dalam lingkungan terdistribusi

 Broker bertindak sebagai orang di tengah antara komponen klient dan komponen server. Desain Arsitektur (design architecture)

 Arsitektur diagram konteks adalah model bagaimana perangkat lunak berinteraksi

dengan entitas eksternal

 Arketipe (archetype) adalah kelas atau pola yang mewakili abstraksi penting untuk

system

 Komponen arsitektur yang berasal dari domain aplikasi, infrastruktur, dan antarmuka.

Diagam Konteks Arketipe (Arch. Context Diagram)

Gambar 10.5. : Diagram Konteks Arketipe Contoh : Safe Home ACD

(19)

(20)

Safe Home Archtype

Gambar 10.7. : Safe Home ACD Archetype Struktur Komponen

(21)

Komponen Elaboration

Gambar 10.9. : Komponen Elaboration

Analisis Desain Arsitektur

1. Kumpulkan semua skenario.

2. Dapatkan kebutuhan2x, batasan2x, dan gambaran lingkungan. 3. Gambarkan pola/gaya arsitektur yang telah dipilih untuk menangani

skenario2x dan kebutuhan2x :: • module view

• process view • data flow view

4. Evaluasi kualitas atribut2x dengan melihat setiap atribut dalam isolasi. 5. Kenali kualitas atribut untuk setiap atribut arsitektural untuk masing-masik

gaya arsitektur yang spesifik.

6. Lakukkan kritik pada arsitektur2x kandidat (yg dikembangkan pada langkah 3) menggunakan analisis pada langkah 5.

(22)

Memperoleh arsitektur program

Gambar 10.10 : Memperoleh arsitektur program

Partisi Arsitektur

Partisi arsitektur secara vertical dan horizontal dibutuhkan dalam pengembangan perangkat lunak

Gambar 10.11. : Partisi Arsitektur

Partisi Horisontal

 Tentukan cabang yang terpisah pada hierarki modul untuk setiap fungsi utama  Gunakan modul kontrol untuk koodinasi komunikasi antar fungsi2x

Program

Architecture

(23)

Gambar 10.12 : Partisi Horisontal

Partisi vertical melalui proses refactoring

 Didesain sehingga pengambilan keputusan dan pekerjaan distratifikasi  Modul pengambilan keputusan tetap ada di puncak arsitektur

Gambar 10.13. : Partisi Vertikal : Refactoring Mengapa di dalam desain arsitektur diperlukan proses refactoring

 Hasilnya adalah PL yang mudah diuji

 Membawa kepada PL yang lebih mudah dikelola  Hasilnya efek samping yang semakin sedikit

 Hasilnya adalah PL yang lebih mudah dikembangkan Desain terstruktur adalah :

 Tujuan : untuk mendapatkan arsitektur program yang terpartisi  pendekatan:

o DFD dipetakan ke arsitektur program

o PSPEC dan STD digunakan untuk mengindikasikan setiap modul  notasi: diagram struktur

Karakteristik aliran

function 1 function 3

function 2

workers decision-makers

(24)

Gambar 10.14. : Karakteristik Aliran

Aliran Transformasi

(25)

Pendekatan Pemetaan Umum

 Isolisasi aliran ke dalam dan keluar batasan : untuk aliran transaksi, isolasi pusat transaksi

 Bekerja dari batasan luar, petakan transformasi DFD ke modul terkait

 Tambahkan modul control jika dibutuhkan

 Sempurnakan struktur program menggunakan konsep modularitas efektif

Pemetaan tranformasi

Gambar 10.15. : Pemetaan tranformasi

Factoring

Gambar 10.16 : Factoring First Level Factoring

data flow model

"Transform" mapping

a b c d e f g h i j x1 x2 x3 x4 b c a d e f g i h j

typical "worker" modules typical "decision making" modules

direction of increasing decision making

(26)

Gambar 10.17 : First Level Factoring Second level mapping

Gambar 10.18 : Second level mapping Transaction Flow

typical "worker" modules typical "decision making" modules direction of increasing decision making D C B A A C B D mapping from the

flow boundary outward

main

(27)

Gambar 10.19 : Transaction Flow Contoh Transaction

Gambar 10.20 : Contoh Transaksi

Menyempurnakan analisis model

1. Tuliskan narasi proses bahasa inggris atau model flow level 0

2. Mengaplikasikan kata kerja/benda untuk mengisolasi proses, item data, penyimpan dan entitas

3. Membangun model floe level 02 dan 03 4. Membuat data entri kamus yang sesuai

T incoming flow action path operator commands process operator commands fixture setting report robot control fixture servos display screen robot control software in reality, other commands

would also be shown assembly

(28)

5. Memperbaiki model aliran yang sesuai Transaction Mapping

Gambar 10.21 Maping Transaksi Isolate Flow Paths

Gambar : 10.22. Isolasi Arah Jalur

data flow model

a b t d e f g h i j k l m n _Mapping b a x1 t x2 d e f x3 g h x3.1 i j k x4 l m n read command produce error msg v alidate command determine ty pe read f ixture status determine setting f ormat setting read record calculate output v alues f ormat report report v alues record assembly record command command

inv alid command status error msg robot control send control v alue start /stop combined status raw setting f ixture setting

(29)

Map the flow model

Gambar 10.23 : Peta pada model flow

Refining Strcutre Chart

Gambar 10.24 : Refining Structure Chart

process operator commands command input controller read command validate command produce error message determine type fixture status controller report generation controller send control value

each of the action paths must be expanded further

process operator commands command input controller read command validate command produce error message determine type send control value read fixture status determine setting format setting read record calculate output values format report fixture status controller report generation controller