Chapter 9

Desain Arsitektur
Slide Set untuk menyertakan

Rekayasa Perangkat Lunak: Pendekatan Praktisi, 7 / e

oleh Roger S. Pressman
Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman

Untuk non-profit tujuan pendidikan Dapat diperbanyakkan HANYA untuk digunakan siswa di tingkat universitas bila digunakan dalam hubungannya dengan Rekayasa Perangkat Lunak:. Pendekatan Praktisi, 7 / e Setiap reproduksi atau penggunaan lainnya adalah dilarang tanpa izin tertulis dari penulis. Semua informasi hak cipta harus muncul jika slide ini diposting di sebuah situs web untuk digunakan siswa.
These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 1

Mengapa Arsitektur?
Arsitektur bukanlah software operasional. Sebaliknya, itu merupakan representasi yang memungkinkan seorang insinyur perangkat lunak untuk: (1) menganalisis efektivitas desain dalam memenuhi persyaratan yang dinyatakannya, (2) mempertimbangkan alternatif arsitektur pada tahap ketika membuat perubahan desain masih relatif mudah, dan (3) mengurangi risiko yang terkait dengan pembangunan perangkat lunak.

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

Mengapa Arsitektur Penting?

Representasi dari arsitektur perangkat lunak merupakan enabler untuk komunikasi antara semua pihak (stakeholders) yang tertarik dalam pengembangan sistem berbasis komputer. Arsitektur menyoroti keputusan desain awal yang akan memiliki dampak yang mendalam pada semua pekerjaan rekayasa perangkat lunak yang berikut dan, sama pentingnya, pada keberhasilan akhir dari sistem sebagai suatu entitas operasional. Arsitektur "merupakan, modus intelektual graspable relatif kecil bagaimana sistem yang terstruktur dan bagaimana komponennya bekerja sama" [BAS03].

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

Deskripsi Arsitektur

IEEE Computer Society telah mengusulkan IEEE-Std-1471-2000, Rekomendasi Praktek untuk Deskripsi Arsitektur Software-Intensif System, [IEE00] untuk membangun kerangka kerja konseptual dan kosakata untuk digunakan selama desain arsitektur perangkat lunak, untuk memberikan pedoman rinci untuk mewakili deskripsi arsitektur, dan untuk mendorong praktek desain arsitektur suara. The IEEE Standard mendefinisikan deskripsi arsitektur (AD) sebagai "kumpulan produk untuk mendokumentasikan arsitektur." Gambaran itu sendiri diwakili menggunakan beberapa pandangan, di mana setiap pandangan adalah "representasi dari seluruh sistem dari perspektif yang saling terkait [stakeholders] kekhawatiran."

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

Genre Arsitektur

Genre menyiratkan kategori tertentu dalam domain perangkat lunak secara keseluruhan. Dalam setiap kategori, Anda menemukan sejumlah subkategori. Sebagai contoh, dalam genre bangunan, Anda akan menemukan gaya umum berikut: rumah, kondominium, gedung-gedung apartemen, gedung perkantoran, bangunan industri, gudang, dan sebagainya. Dalam setiap gaya umum, gaya yang lebih spesifik mungkin berlaku. Setiap gaya akan memiliki struktur yang dapat digambarkan dengan menggunakan satu set pola diprediksi.

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

Ragam Gaya Arsitektur

Masing-masing 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
6

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

Data-Centered Architecture

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

Data Flow Architecture

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

Call and Return Architecture

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

Layered Architecture

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

10

Pola Arsitektural

Concurrencyaplikasi harus menangani banyak tugas dalam pola yang mensimulasikan paralelisasi operating system process management pattern task scheduler pattern PersistenceData 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.

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

11

Desain Arsitektur

Perangkat lunak ini harus ditempatkan dalam konteks desain harus menentukan entitas eksternal (sistem lain, perangkat, orang-orang) yang berinteraksi dengan perangkat lunak dan sifat interaksi Satu set arketipe arsitektur harus diidentifikasi Sebuah archetype adalah abstraksi (mirip dengan kelas) yang merupakan salah satu unsur perilaku sistem Perancang menentukan struktur sistem dengan mendefinisikan dan menyempurnakan komponen perangkat lunak yang melaksanakan setiap archetype

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

12

Architectural Context
Safehome Product Internet-based system

control panel

target system: Security Function uses

uses

surveillance function peers

homeowner

uses

sensors

sensors

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

13

Archetypes
Cont roller communicat es wit h

Node

Det ect or

Indicat or

10.7 UML relat ionships f or Saf eHome securit y f unct ion archet ypes These slides are designed toFigure accompany Software Engineering: A Practitioners Approach, 7/e (adapt ed f rom [ BOS00] ) (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

14

Component Structure
SafeHome Execut ive Funct ion select ion

Ext ernal Communicat ion Management

Securit y

Surveillance

Home management

GUI

Int ernet Int erface

Cont rol panel processing det ect or management alarm processing

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

15

Refined Component Structure

SafeHome Executive

Ext ernal Communicat ion Management

Security GUI Internet Interface

Cont rol panel pro cessing det ect or m anagem ent alarm processing

Key pad processing

scheduler

phone com m u nicat ion

CP display funct ions

alarm sensor sensor sensor sensor sensor sensor sensor sensor sensor

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

16

Analisis Desain Arsitektur

1. Kumpulkan semua skenario. 2. Dapatkan kebutuhan-kebutahnya, batas-batasannya, dan gambaran lingkungan. 3. Gambarkan pola/gaya arsitektur yang telah dipilih untuk menangani skenario-skenarionya dan kebutuhan-kebutuhannya :: module view process view data flow view 4. Evaluasi kualitas atribut-atributnya 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 arsitektur-arsitektur kandidat (yg dikembangkan pada langkah 3) menggunakan analisis pada langkah 5.
These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 17

Kompleksitas arsitektur

kompleksitas keseluruhan arsitektur yang diusulkan dinilai dengan mempertimbangkan dependensi antara komponen dalam arsitektur [Zha98]

Berbagi dependensi mewakili hubungan ketergantungan antara konsumen yang menggunakan sumber daya yang sama atau produsen yang memproduksi untuk konsumen yang sama. Arus dependensi mewakili hubungan ketergantungan antara produsen dan konsumen sumber daya. Dependensi Dibatasi merupakan kendala pada aliran relatif kontrol di antara serangkaian kegiatan.

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

18

Arsitektur Bahasa Deskripsi (ADL)

Arsitektur bahasa deskripsi (ADL) menyediakan semantik dan sintaks untuk menggambarkan arsitektur perangkat lunak Menyediakan desainer dengan kemampuan untuk:

Dekomposi komponen arsitektur menyusun komponen individu menjadi blok-blok arsitektur yang lebih besar dan merupakan interface (mekanisme koneksi) antar komponen.

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

19

Metode Desain Arsitektur

Kebutuhan kostumer
"Empat kamar tidur, tiga kamar mandi, banyak kaca ...

architectural design
These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

20

Memperoleh Arsitektur Program

Program Architecture

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

21

Partisi Arsitektur

Partisi horizontal dan vertical dibutuhkan.

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

22

Partisi Horizontal

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

function 2
These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 23

Partisi Vertikal : Factoring

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

workers

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

24

Mengapa Arsitektur Terpartisi?

Hasilnya adalah Perangkat Lunak yang mudah diuji Membawa kepada Perangkat Lunak yang lebih mudah dikelola Hasilnya efek samping yang semakin sedikit Hasilnya adalah Perangkat Lunak yang lebih mudah dikembangkan

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

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

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

26

Flow Characteristics

Transform flow
This edition of SEPA does not cover transaction mapping. For a detailed discussion see the SEPA website

Transaction flow
These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

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 Memperbaiki struktur program yang dihasilkan Menggunakan konsep modularitas efektif
These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 28

Pendekatan Pemetaan Umum

Mengisolasi transformasi pusat dengan menetapkan batas-batas aliran masuk dan keluar Lakukan "tingkat pertama anjak piutang." Arsitektur program diturunkan menggunakan hasil pemetaan ini dalam distribusi top-down kontrol. Anjak mengarah ke struktur program di mana komponen tingkat atas melakukan pengambilan keputusan dan komponen tingkat rendah melakukan sebagian input, perhitungan, dan bekerja output. Komponen tingkat menengah melakukan beberapa kontrol dan melakukan jumlah moderat kerja. Lakukan "second-level factoring."

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

29

Pemetaan Transformasi
a b d c data flow model x1 x2 b a c d x3 e f g h x4 i j e f g i h

"Transform" mapping

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

30

Factoring
direction of increasing decision making typical "decision making" modules

typical "worker" modules

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

31

First Level Factoring

main program controller

input controller

processing controller

output controller

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

32

Second Level Mapping

D C
control main

A A B C

mapping from the flow boundary outward

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

33