Catatan Kuliah Rekayasa Perangkat Lunak (Software Engineering) Bagian 2

Catatan Kuliah

Rekayasa Perangkat Lunak (Software Engineering) Bagian 2

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

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.


2

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.


3

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


4

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


5

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


6

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.


7

Ragam Gaya Arsitektur 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 architectures Data flow architectures Call and return architectures Object-oriented architectures Layered architectures


8

Data-Centered Architecture


9

Data Flow Architecture


10

Call and Return Architecture


11

Layered Architecture


12

Pattern Arsitektural 

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



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





operating system process management pattern task scheduler pattern

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.


13

Desain Arsitektur 

PL harus ditempatkan pada konteks 



Sekumpulan arsitektur archetypes harus diidentifikasi 



Desain harus menentukan entitas eksternal (sistem lain, piranti, orang) dimana PL berinteraksi dengannya 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


14

Architectural Context Safehome Pro duct

control panel

homeowner

Internet-based system

target system: Security Function

uses

surveillance function peers

uses

uses

sensors

sensors


15

Archetypes Cont roller

communicat es wit h

Node

Det ect or

Indicat or

Figure 10.7 UML relat ionships f or Saf eHome securit y f unct ion archet ypes These courseware materials are to(adapt be used conjunction ed f in rom [ BOS00] ) with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

16

Component Structure SafeHome Execut ive Funct ion select ion

Ext ernal Communicat ion Management

Securit y

GUI

Surveillance

Home management

Int ernet Int erface Cont rol panel processing

det ect or management

alarm processing


17

Refined Component Structure SafeHome Executive

Ext ernal Communicat ion Management

Security GUI

Internet Interface Co n t ro l p an e l p ro ce ssin g

Ke y p ad p ro ce ssin g

d e t e ct o r m an ag e m e n t

sch e d u le r

CP d isp lay fu n ct io n s

alarm p ro ce ssin g

phone co m m u n icat io n

alarm sennnso sorrr se se se soso se nnso so rr se se nnso rr se n so r se n so r


18

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.


19

Metode Desain Arsitektur customer requirements "four bedrooms, three baths, lots of glass ..."

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

20

Memperoleh Arsitektur Program

Program Architecture


21

Partisi Arsitektur 

Partisi “horizontal” dan “vertical” dibutuhkan


22

Partisi Horizontal 



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

function 1

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

23

Partisi Vertikal : Factoring 



Didesain sehingga pengambilan keputusan dan pekerjaan distratifikasi Modul pengambilan keputusan tetap ada di puncak arsitektur decision-makers

workers


24

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


25

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


26

Karakteristik Aliran

Aliran Transformasi

Aliran Transaksi


27

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


28

Pemetaan Transformasi a

b d

e

h

g

f

i

c

j

data flow model x1 x2 b

x4

x3 c

a

"Transform" mapping

d

e

f

g

i

h

j


29

Factoring direction of increasing decision making

typical "decision making" modules

typical "worker" modules 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

30

First Level Factoring main program controller

input controller

processing controller

output controller


31

Second Level Mapping main

D C control

B

A A B C

mapping from the flow boundary outward

D


32

Transaction Flow incoming flow

action path T


33

Transaction Example fixture servos

fixture setting commands

operator

process operator commands

report

display screen

robot control robot control software assembly record

in reality, other commands would also be shown


34

Refining the Analysis Model 1.

write an English language processing narrative for the level 01 flow model

2.

apply noun/verb parse to isolate processes, data items, store and entities

3.

develop level 02 and 03 flow models

4.

create corresponding data dictionary entries

5.

refine flow models as appropriate ... now, we're ready to begin design!


35

Deriving Level 1 Processing narrative for " process operator commands"

noun-verb parse

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


36

Level 1 Data Flow Diagram operator

commands

Error msg

f ixture servos

status

read operator commands valid command f ixture determine command type

control robot

send control value

analyze f ixture status

f ixture setting

select report

generate report

assembly record

report display sc reen

robot control sy stem

robot control


37

Level 2 Data Flow Diagram co mmand

error msg prod uce error msg

read co mmand i nva li d co mmand co mmand

de te rmi ne setti ng read fixtu re sta tus

va li da te co mmand de te rmi ne type

robo t co ntro l

format setti ng

sta tus

read reco rd

raw se tti ng

co mbi ned sta tus

reco rd ca lcul ate ou tp ut va lu es va lu es

send co ntro l va lu e

fixtu re setti ng

format repo rt

repo rt

asse mbl y reco rd sta rt /sto p


38

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


39

Transaction Mapping e

a

f

d

b

i

t g

h

k

l

data flow model

j m n

x1

Mapping

t

b a

x3

x2 d

e

f

g

x4

h

x3.1 i

l

m

n

j k


40

Isolate Flow Paths co mmand

error msg prod uce error msg

read co mmand i nva li d co mmand co mmand

de te rmi ne setti ng read fixtu re sta tus

va li da te co mmand de te rmi ne type

robo t co ntro l

format setti ng

sta tus

read reco rd

raw se tti ng

co mbi ned sta tus

reco rd ca lcul ate ou tp ut va lu es va lu es

send co ntro l va lu e

fixtu re settin g

format repo rt

repo rt

asse mbl y reco rd sta rt /sto p


41

Map the Flow Model process operator commands

command input controller read command

validate command

determine type

produce error message

fixture status controller

report generation controller

send control value

each of the action paths must be expanded further


42

Refining the Structure Chart process operator commands

command input controller read command

validate command

read fixture status

determine type

produce error message

determine setting

fixture status controller

format setting

report generation controller

read record

send control value

calculate output values

format report


43

Catatan Kuliah Rekayasa Perangkat Lunak (Software Engineering) Bagian 2

Recommend Documents