1.
Quick Look of this chapter
2.
Software Architecture
3.
Data Design
4.
Architectural Styles and Patterns
5.
Architectural Design
6.
Assessing Alternative Architecture Designs
7.
Mapping Data Flow into a Software Architecture
What is it ?
◦ Desain arsitektur merupakan
Untuk mewakili struktur data & komponen Program
Mempertimbangkan
Struktur dan sifat dari komponen sistem
Hubungan timbal balik antara komponen sistem
Siapa yang melakukannya?
◦ Software engineer
◦ Specialists
Ketika sistem yang besar dan kompleks
Mengapa penting ?
◦ Misalnya, ketika membangun rumah
Ada perlu memiliki blueprint untuk membangun
Apa langkah-langkahnya ?
◦ 1) Desain Data
◦ 2) Representasi struktur arsitektur sistem
Apakah produk kerja ?
◦ Arsitektur Data
◦ Struktur Program
Apa arsitektur?
◦ Ketika kita membahas arsitektur bangunan,
Cara di mana berbagai komponen bangunan yang terintegrasi untuk membentuk suatu kesatuan yang utuh
Untuk memenuhi kebutuhan
◦ Ketika kita membahas perangkat lunak,
Struktur komponen software
Mengapa Arsitektur Penting?
◦ Untuk mengaktifkan untuk komunikasi antara para stakeholder
◦ Untuk menyoroti keputusan desain yang akan memiliki dampak pada sukses rekayasa perangkat lunak
Apa desain data ?
◦ Untuk menerjemahkan objek data yang didefinisikan sebagai bagian dari model analisis ke dalam struktur data pada komponen perangkat lunak
Desain Data di Tingkat Arsitektur
◦ Salah satu desain contoh di tingkat arsitektur, data warehouse
Desain Data di Tingkat Komponen
◦ Wasserman telah mengusulkan seperangkat prinsip
1) Prinsip analisis sistematis diterapkan untuk fungsi juga harus diterapkan pada data
2) Semua struktur data dan operasi harus diidentifikasi
Struktur data yang efisien harus mempertimbangkan operasi
3) Sebuah mekanisme untuk mendefinisikan isi dari setiap objek data harus ditetapkan dan digunakan
4) Keputusan desain tingkat rendah data harus ditunda sampai akhir dalam proses desain
Karena skema top-down
Untuk Tentukan secara rinci selama desain komponen-tingkat
5) Representasi struktur data harus hanya diketahui modul yang langsung menggunakan
6) Sebuah perpustakaan data yang berguna dan operasi harus dikembangkan
What is architecture style ?
◦
Transformasi pada desain tingkat sistem keseluruhan
◦
Tujuannya adalah untuk membangun struktur untuk semua
komponen dari sistem
What is architecture pattern ?
◦
Transformasi pada desain tingkat arsitektur
◦
Berbeda dari gaya dalam sejumlah cara yang mendasar
Ruang lingkup pola kurang luas
Berfokus pada satu aspek dari arsitektur
Untuk memberlakukan aturan pada arsitektur
Menggambarkan bagaimana perangkat lunak akan menangani beberapa aspek fungsionalitas
Sebuah Taksonomi/Klasifikasi Singkat Styles Arsitektur
◦
arsitektur data-berpusat
Sebuah menyimpan data (misalnya, file atau database) berada di pusat arsitektur ini
Data store (repository) Client
software
Client software
Client software
Client software
Client software
Data-flow architecture
◦
A pipe and filter structure
Filter: Sebuah set komponen
Pipe: Untuk menghubungkan antar komponen
Untuk mengirimkan data dari satu komponen ke yang berikutnya
Filter
Filter Filter Filter Filter
Filter
Filter Filter
Call and return architecture
◦
Relatif mudah untuk memodifikasi dan skala
◦
Dua substyles ada
Main program/subprogram architecture
Struktur program klasik
"Program Utama" memanggil sejumlah komponen program
Remote procedure call architecture
Komponen arsitektur program utama / sub pada jaringan
Main Program
Controller subprogram
Controller subprogram
Controller subprogram
Application subprogram
Application subprogram
Application subprogram
Application subprogram
Core Layer Core Layer Object-oriented architecture
◦ Komponen sistem merangkum data dan operasi
◦ Komunikasi antara komponen dicapai melalui lewat pesan
Layered architecture
Core Layer
Utility Layer
Application Layer
User Interface Layer
Representing the System in Context
◦ In chapter 6, the system context diagram
Mewakili arus informasi ke dalam dan keluar dari sistem, user interface, dan pengolahan dukungan yang relevan
user maintenance
and
Bar code reader
Bar code
Request Queries
Line speed indicator
Representing the System in Context
◦ In this chapter,
To use an architectural context diagram (ACD)
Untuk model cara di mana perangkat lunak berinteraksi dengan entitas eksternal untuk batas-batasnya
Target system Superordinate systems
Used by
Use
Peers Use
Actors
Depend on
Subordinate systems
- Superordinate systems: Untuk menggunakan
sistem target sebagai bagian dari beberapa tingkat yang lebih tinggi
- Subordiate systems: Untuk digunakan oleh
sistem target dan memberikan data atau pengolahan
- Peer-level: Untuk berinteraksi secara
peer-to-peer
- Actors: Entitas (orang, perangkat) yang berinter
Example of ACD, Fungsi keamanan rumah dari produk SafeHome
Target system : Security function Safehome
product
Home owner Control
panel
Surveillance function
Sensors Sensor
Internet-based system
Use
Peers Use
Actors
Uses
Subordinate systems
Defining Archetypes
◦ An archetype is a class or pattern
Untuk mewakili abstraksi inti untuk desain arsitektur
◦ Example of the SafeHome home security function
Node
Input dan output unsur fungsi keamanan rumah (ex, berbagai sensor, indikator alarm)
Detector
Semua peralatan penginderaan yang feed informasi ke dalam sistem target
Indicator
Semua mekanisme untuk menunjukkan bahwa kondisi alarm yang terjadi pengawas
Controller
Defining Archetypes
◦ Example of the SafeHome home security function
Controller
Node
Detector Indicator
Communication with
An Architecture Trade-Off Analysis Method
◦ The Software Engineering Institute (SEI) has developed an architecture trade-off analysis method (ATAM)
Evaluation process for software architecture
1) Collect scenarios
Satu set penggunaan-kasus dikembangkan untuk menyajikan sistem dari sudut pandang pengguna
2) Menampilkan Persyarata, kendala, dan deskripsi lingkungan
3) Describe the architectural styles/pattern
4) Evaluasi atribut kualitas dengan mempertimbangkan setiap atribut
Penilaian meliputi kehandalan, kinerja, keamanan, pemeliharaan, fleksibilitas, testability, portabilitas, usabilitas, dan interoperabilitas
5) Mengidentifikasi sensitivitas atribut kualitas untuk berbagai atribut arsitektur Membuat perubahan kecil dalam arsitektur
6) Critique candidate architectures using the sensitivity analysis (in step 5)
Sekarang, kita perlu beberapa transisi dari model analisis untuk berbagai
gaya arsitektur
Dua Jenis Metode Pemetaan
1)Transform Flow
Informasi harus masuk dan software keluar dalam bentuk di "dunia luar”
Sebagai contoh, data diketik pada keyboard, nada pada saluran telepon, dan gambar video dalam aplikasi multimedia adalah segala bentuk informasi dunia luar
Data dieksternalisasi tersebut harus diubah menjadi bentuk internal untuk diproses
Definisi Kata
Aliran Masuk
Jalur yang mengubah data eksternal menjadi data internal
Aliran Keluar
2) Aliran Transaksi
Transaction
Sebuah item data tunggal memicu arus informasi
Item data tunggal disebut transaksi
Transaction center
Pusat arus informasi
T
Transaction center
… Action paths
... ... ...
... ...
Transaction
Two kinds of mapping method
1)Transform Mapping
Satu set langkah-langkah desain yang memungkinkan DFD (data flow diagram) dalam gaya arsitektur tertentu
Untuk menggambarkan pendekatan ini, contoh fungsi keamanan SafeHome
Untuk memetakan data flow diagram ke dalam arsitektur, langkah-langkah desain berikut
Step 1. Ulasan model sistem yang mendasar
Mewakili produsen eksternal dan konsumen data
SoftHome User command
and data
Sensor Number tones
Step 2. eview dan memperbaiki diagram aliran data untuk perangkat lunak
Model analisis disempurnakan untuk menghasilkan lebih detail
Configuration information
Control And status
Monitor User command
and data
Configure Number tones Sensor
Valid ID msg.
Configuration data
Sensor information
Configuration information number tones Alarm Sensor ID,
type
Level 2 DFD that refines the monitor sensors transform
Alarm type Sensor
information
Sensor ID, type, location Configuration
Step 3. Tentukan apakah DFD memiliki transformasi atau karakteristik aliran transaksi
Evaluating Level 3 DFD,
No distinct transaction center is implied
So, transform characteristic will be assumed
Configuration information
Read
conditions Select
Phone
number Setup Connection
To phone net
Generate Pulse to
line
Step 4. mengisolasi transformasi pusat dengan menetapkan batas-batas aliran masuk dan keluar
Step 5. Perform “first-level factoring”
Hasil pemfaktoran ini dalam top-down mendistribusikan kontrol
Top-level: Melakukan Pengambilan keputusan
Middle-level: melakukan kontrol dan melakukan dalam jumlah sedang kerja
Low-level: melakukan sebagian input, perhitungan, dan hasil outputnya
Step 5. Perform “first-level factoring”
Monitor Sensors executive
Sensor Input controller
Alarm Output controller Alarm
Conditions controller Incoming
Information Processing controller
Outgoing Information Processing controller Transform
Step 6. Melakukan “second-level factoring”
Pemetaan transformasi individual dari DFD ke dalam modul yang tepat dalam arsitektur
1) Dimulai pada transformasi Batas Pusat
2) Pindah keluar sepanjang jalan masuk dan keluar
Step 6. Perform “second-level factoring”
Generate display
Setup Connection
To phone net
Generate Pulses to
line Format
display Generate Alarm Signal
Monitor Sensors executive
Sensor Input
controller Alarm output
controller Alarm conditions
controller Incoming path
Outgoing path Transform
center
Generate alarm signal Format
display
Setup connection To phone net
Generate display
Step 7. Perbaiki arsitektur pertama-iterasi menggunakan desain heuristic untuk meningkatkan kualitas perangkat lunak
Untuk menyaring untuk kohesi yang baik, kopling minimal, tanpa kesulitan, dan dipelihara tanpa kesulitan
Monitor Sensors
◦
Transaction Mapping
A single data item triggers one of a number of information flows
The single data item is called transaction
This Mapping will be illustrated by considering the SafeHome user interaction system
Step 1. Review the fundamental system model
Level 1 data flow for this mapping
Control And status
Monitor
Configuration information
User command and data
Configure Number tones Sensor
Valid ID msg.
Configuration data
Sensor information
Step 2. Review and refine data flow diagram for the software
Level 2 data flow diagram for user interaction subsystem
Configuration information Read And status Read
password
Compare Password With file
Produce
type Configure System parameters
and data
Raw
A/D message
Configuration data
Valid password
Level 2 DFD for user interaction subsystem
- The data object (User command) flows into the system
- A single data item (Command type) triggers the data flow to fan outward from hub
Step 3. Determine whether the DFD has transform or transaction flow characteristic
Transaction flow characteristic
Step 4. Identify the transaction center and the flow characteristic along each of the action paths
The transaction center lies at the origin of a number of actions paths
Read And status Read
password
Compare Password With file
Produce Invalid message
Configuration information User
commands
Command
type Configure System parameters
and data
Raw
A/D message
Configuration data
Valid password
- Transform characteristic - Incoming, transform, and outgoing flow are bounded
- Transform characteristic - Incoming, transform, and outgoing flow are bounded
Step 5. Map the DFD in a program structure amenable to transaction processing
Mapped into incoming branch and dispatch branch
Incoming branch: Along incoming path
Dispatch branch: Start transaction center
Step 6. Factor and refine the transaction structure and the structure of each action path
User With file
Password
Step 7. Refine the first-iteration architecture using design heuristics for improved software quality
Arsitektur perangkat lunak memberikan
