Catatan Kuliah Rekayasa Perangkat Lunak (Software Engineering) Bagian 2

(1)

Catatan Kuliah

Rekayasa Perangkat Lunak

(Software Engineering)

(2)

Software Engineering: A Practitioner’s Approach, 6/e

Bab 10

Desain Arsitektur

R.S. Pressman & Associates, Inc.

For University Use Only

May be reproduced ONLY for student use at the university level

when used in conjunction with Software Engineering: A Practitioner's Approach.

Any other reproduction or use is expressly prohibited.

(3)

Kenapa Arsitektur ?

Arsitektur bukanlah PL operasional, namun dia merupakan

representasi yang memungkinkan pengembang PL untuk :

(1)menganalisa efektivitas desain dalam memenuhi

kebutuhan,

(2) Mengetahui alternatif2x arsitektur pada keadaan dimana

membuat perubahan desain masih relatif lebih mudah, dan

(3) Mengurangi resiko terkait dengan konstruksi PL.

(4)

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

(5)

Desain Data



Pada level arsitektur …



Desain satu atau lebih database untuk mendukung arsitektur

aplikasi



Desain method untuk „

_mining

‟ isi dari berbagai database



Navigasi melalui database2x 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

(6)

Desain Data



Pada level komponen …



Mengambil objek2x data dan mengembangkan satu set

abstraksi data



_{Implementasi atribut2x objek data sebagai satu atau}

lebih struktur data



_{review struktur data untuk memastikan bahwa relasi}

yang tepat sudah dibuat

(7)

Desain Data—Level Komponen

1. Prinsip2x 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

(8)

Ragam Gaya Arsitektur



_{Data-centered architectures}



_{Data flow architectures}



Call and return architectures

Object-oriented architectures

Masing2x menggambarkan kategori sistem yang menunjukkan : (1) a

sekumpulan komponen

(mis database, modul komputasi) yang

menunjukkan fungsi yan dibutuhkan sistem, (2)

sekumpulan connectors

yang memungkinkan komunikasi, koordinasi dan kerjasama antar

komponen components, (3)

batasan

yang menentukan bagaimana

komponen dapat diintegrasikan untuk membentuk sistem, dan (4)

smodel semantik

yang memungkinkan desainer untk memahami properti

keseluruhan dari sistem dengan menganlisai properti dalam bagian2x di

dalamnya.

(9)

(10)

(11)

(12)

(13)

Pattern Arsitektural



Concurrency

—aplikasi harus menangani banyak tugas dalam

pola yang mensimulasikan paralelisasi



operating system process management pattern



task scheduler

pattern



Persistence

—Data ada jika dia bertahan setelah eksekusi proses

yang membuatnya. Ada dua pattern umum ::



database management system

pattern yang menerapkan

penyimpanan dan pengambilan dari DBMS kepada arsitektur aplikasi



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.

(14)

Desain Arsitektur



PL harus ditempatkan pada konteks



Desain harus menentukan entitas eksternal (sistem lain, piranti,

orang) dimana PL berinteraksi dengannya



Sekumpulan arsitektur archetypes harus diidentifikasi



_archetype

_{adalah abstraksi (mirip dengan class) yang}

menampilkan satu elemen dari perilaku sistem



Desainer menentukan struktur sistem dengan memilih

(15)

Architectural Context

target system:

Security Function

uses

peers

homeowner

Safehome

Pro duct

Internet-based

system

surveillance

function

sensors

control

panel

sensors

uses

(16)

Archetypes

Cont roller

Node

communicat es wit h

(17)

Component Structure

SafeHome Execut ive Ext ernal Communicat ion Management

GUI Int ernet Int erface

Funct ion select ion

Securit y Surveillance Home management Cont r ol panel pr ocessing det ect or management alar m pr ocessing

(18)

Refined Component

Structure

Ext er nal Communicat ion

Management

GUI Int ernet Int erf ace

Securit y Co n t ro l p an e l p ro ce ssin g d e t e ct o r m an ag e m e n t alarm p ro ce ssin g Ke y p ad p ro ce ssin g sch e d u le r p h o n e Saf eHome Execut ive

(19)

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

(20)

Metode Desain Arsitektur

"four bedrooms, three baths,

lots of glass ..."

(21)

Memperoleh Arsitektur Program

Program

(22)

Partisi Arsitektur



Partisi “horizontal” dan “vertical”

(23)

Partisi Horizontal



Tentukan cabang yang terpisah pada hierarki

modul untuk setiap fungsi utama



Gunakan modul kontrol untuk koodinasi

komunikasi antar fungsi2x

(24)

Partisi Vertikal : Factoring



Didesain sehingga pengambilan keputusan dan

pekerjaan distratifikasi



Modul pengambilan keputusan tetap ada di

puncak arsitektur

(25)

Mengapa Arsitektur Terpartisi?



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

(26)

Desain Terstruktur



Tujuan : untuk mendapatkan arsitektur

program yang terpartisi



pendekatan:



DFD dipetakan ke arsitektur program



PSPEC dan STD digunakan untuk

mengindikasikan setiap modul

(27)

Karakteristik Aliran

Aliran Transformasi

(28)

Pendekatan Pemetaan Umum

Isolasi aliran ke dalam dan ke luar

batasan; untuk aliran transaksi, isolasi

Pusat transaksi

Bekerja dari batasan luar, petakan

Transformasi DFD ke modul terkait

Tambahkan modul kontrol jika dibutuhkan

Sempurnakan struktur program

(29)

Pemetaan Transformasi

data flow model

"Transform" mapping

a

b

c

d

e

f

g

h

i

j

x1

x2

x3

x4

b

c

d

e

f

g

i

(30)

Factoring

typical "decision

making" modules

direction of increasing

decision making

(31)

First Level Factoring

main

program

controller

input

controller

processing

controller

output

controller

(32)

Second Level Mapping

D

C

B

A

C

B

D

mapping from the

flow boundary outward

main

(33)

Transaction Flow

T

incoming flow

(34)

Transaction Example

operator

commands

process

operator

commands

fixture setting

report

robot control

fixture

servos

display

screen

robot

control

software

assembly

(35)

Refining the Analysis Model

write an English language processing narrative

for the level 01 flow model

apply noun/verb parse to isolate processes, data

items, store and entities

develop level 02 and 03 flow models

create corresponding data dictionary entries

refine flow models as appropriate

... now, we're ready to begin design!

1.

2.

3.

4.

5.

(36)

Deriving Level 1

Processing narrative for " process operator commands"

Process operator command software reads operator commands from

the cell operator. An error message is displayed for invalid commands.

The command type is determined for valid commands and appropriate

action is taken. When fixture commands are encountered, fixture

status is analyzed and a fixture setting is output to the fixture servos.

When a report is selected, the assembly record file is read and a

report is generated and displayed on the operator display screen.

When robot control switches are selected, control values are sent to

the robot control system.

Processing narrative for " process operator commands"

Process operator command software

reads

operator commands from

the cell operator . An error message is

displayed

for invalid commands .

The command type is

determined

for valid commands and appropriate

action is

taken

. When fixture commands are

encountered

, fixture

noun-verb

parse

(37)

Level 1 Data Flow Diagram

operator _commands read operator commands determine command type analyze f ix ture status generate report send control value f ix ture servos display sc reen robot control sy stem as sembly record valid command Error msg f ix ture setting report f ix ture select report control robot status

(38)

Level 2 Data Flow Diagram

read co mmand prod uce error msg va li da te co mmand de te rmi ne type read fixtu re sta tus de te rmi ne setti ng format setti ng read reco rd ca lcul ate ou tp ut va lu es format repo rt repo rt va lu es reco rd co mmand

co mmand _{i nva li d co mmand}

sta tus error msg robo t co ntro l send co ntro l va lu e co mbi ned sta tus raw se tti ng fixtu re setti ng

(39)

Transaction Mapping Principles

isolate the incoming flow path

define each of the action paths by looking for

the "spokes of the wheel"

assess the flow on each action path

define the dispatch and control structure

map each action path flow individually

(40)

Transaction Mapping

data flow model

a

b

t

d

e

f

g

h

i

j

k

l

m

n

_Mapping

b

a

x1

t

x2

x3

x4

(41)

Isolate Flow Paths

read co mmand prod uce error msg va li da te co mmand de te rmi ne type read fixtu re sta tus de te rmi ne setti ng format setti ng read reco rd ca lcul ate ou tp ut va lu es format repo rt repo rt va lu es reco rd asse mbl y reco rd co mmand co mmand i nva li d co mmand sta tus error msg robo t co ntro l send co ntro l va lu e sta rt /sto p co mbi ned sta tus raw se tti ng fixtu re settin g