Rekayasa Perangkat Lunak (Software Engineering) · spesifikasi dan realisasi dari tipe data abstrak. ... dan komponen server. ... selec t ion Sec urit y Surv eillanc e Hom e

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1

Catatan Kuliah

Rekayasa Perangkat Lunak

(Software Engineering) Bagian 2


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

Bab 10

Desain Arsitektur copyright © 1996, 2001, 2005

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.


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.


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

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

bisnis


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

Sederhanakan struktur data sesuai dengan kebutuhan


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

spesifikasi dan realisasi dari tipe data abstrak.


Ragam Gaya Arsitektur

Data-centered architectures

Data flow architectures

Call and return architectures

Object-oriented architectures

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


Data-Centered Architecture


Data Flow Architecture


Call and Return Architecture


Layered Architecture


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.


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

komponen PL yang mengimplmentasi masing2x

archetype


Architectural Context

target system:

Security Functionuses

uses peershomeowner

Safehome

ProductInternet-based

system

surveillance

function

sensors

control

panel

sensors

uses


Archetypes

Figure 10.7 UML relat ionships for SafeHome securit y funct ion archetypes

(adapted f rom [BOS00] )

Cont roller

Node

communicates with

Detector Indicator


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 rol

panel

processing

det ect or

management

alarm

processing


Refined Component

Structure

sensorsensor

sensorsensor

sensorsensorsensor

sensor

Ext ernal

Communicat ion

Management

GUI Internet

Interface

Security

Cont ro l

panel

processing

det ect or

m anagem ent

alarm

processing

Key pad

processing

CP disp lay

funct ions

scheduler

sensorsensorsensorsensor

phone

com m unicat ion

alarm

SafeHome

Execut ive


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.


Metode Desain Arsitektur

"four bedrooms, three baths, lots of glass ..."

customer requirements

architectural design


Memperoleh Arsitektur Program

Program Architecture


Partisi Arsitektur

Partisi “horizontal” dan “vertical”

dibutuhkan


Partisi Horizontal

Tentukan cabang yang terpisah pada hierarki

modul untuk setiap fungsi utama

Gunakan modul kontrol untuk koodinasi

komunikasi antar fungsi2x

function 1 function 3

function 2


Partisi Vertikal : Factoring

Didesain sehingga pengambilan keputusan dan

pekerjaan distratifikasi

Modul pengambilan keputusan tetap ada di

puncak arsitektur

workers

decision-makers


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

dikembangkan


Desain Terstruktur

Tujuan : untuk mendapatkan arsitektur

program yang terpartisi

pendekatan:

DFD dipetakan ke arsitektur program

PSPEC dan STD digunakan untuk

mengindikasikan setiap modul

notasi: diagram struktur


Karakteristik Aliran

Aliran Transformasi

Aliran Transaksi


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

Menggunakan konsep modularitas efektif


Pemetaan Transformasi

data flow model

"Transform" mapping

ab

c

d e fg h

ij

x1

x2 x3 x4

b c

a

d e f g i

h j


Factoring

typical "worker" modules

typical "decision making" modules

direction of increasing decision making


First Level Factoring

main program controller

input controller

processing controller

output

controller


Second Level Mapping

D

C

BA

A

C

B

Dmapping from the flow boundary outward

main

control


Transaction Flow

T

incoming flow

action path


Transaction Example

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 record


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.


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 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 value s are sent to the robot control system.

noun-verb

parse


Level 1 Data Flow Diagram

operator commands

read

operator

commands

determine

command

type

analyze

f ixture

status

generate

report

send

control

value

f ixture

servos

display

screen

robot

control

system

assembly

record

valid command

Error msg

f ixture setting

report

robot control

f ixture

select report

control

robot

status


Level 2 Data Flow Diagram

read

command

produce

error

msg

validate

command

determine

type

read

fixture

status

determine

setting

format

setting

read

record

calculate

output

valuesformat

report

report

values

record

assembly

record

command

commandinvalid command

status

error msg

robot contro l

send

contro l

value

start /stop

combined

status

raw setting

fixture setting


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


Transaction Mapping

data flow model

ab

t

de f

gh

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


Isolate Flow Paths

read

command

produce

error

msg

validate

command

determine

type

read

fixture

status

determine

setting

format

setting

read

record

calculate

output

va luesformat

report

report

va lues

record

assembly

record

command

commandinvalid command

status

error msg

robot contro l

send

contro l

va lue

start /stop

combined

status

raw setting

fixture setting


Map the Flow Model

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


Refining the Structure Chart 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

Documents

Rekayasa Perangkat Lunak (Software Engineering) · spesifikasi dan realisasi dari tipe data abstrak. ... dan komponen server. ... selec t ion Sec urit y Surv eillanc e Hom e