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
◦ Untuk membentuk suatu model intelektual banding relatif kecil dari bagaimana sistem terstruktur dan bagaimana komponen bekerja sama
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
Representasi dari aliran data dan konten juga harus dikembangkan dan Ulasan organisasi data alternatif harus dipertimbangkan
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
7) Desain sebuah perangkat lunak dan bahasa pemrograman harus mendukung spesifikasi
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 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 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 Components
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 interface processing Input processing output processing maintenance and self-test Conveyor Line Sorting System Sorting station operator Bar code reader Conveyor line Sorting mechanism Mainframe Sorting station operator Bar code Request Queries Line speed indicator Diagnostic data Shunt commands
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 Superordinate 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
Mekanisme yang memungkinkan mempersenjatai atau melucuti dari node
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)
Berdasarkan hasil langkah 5 dan 6, beberapa arsitektur dapat dimodifikasi dan diwakili secara lebih rinci
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
Jalur bahwa data yang masuk melewati transformasi pusat dan bergerak "keluar" dari perangkat lunak
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 Transaction flow
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 software Control panel Sensor Control Panel display Alarm Telephone line User command and data Sensor status Display information Alarm type Telephone Number tones
Step 2. eview dan memperbaiki diagram aliran data untuk perangkat lunak
Model analisis disempurnakan untuk menghasilkan lebih detail
Configuration information Control panel Sensors Interact With user Configure system Configure system Process password Display Message And status Monitor sensors Control Panel display Alarm Telephone line User command and data Configure request Configuration data Configuration data Display information Alarm type Telephone Number tones Sensor status Password Start stop A/D msg. Valid ID msg. Configuration data Sensor information
Configuration information Interact With user Configure system Configure system Process password Dial phone Telephone number tones Alarm data Sensor status Telephone number Sensor ID, type
Level 2 DFD that refines the monitor sensors transform
Alarm type Sensor information Sensor ID, type, location Configuration data
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 sensors Acquire response info Sensor status Establish Alarm conditions Select Phone number Setup Connection To phone net Generate Pulse to line Format display Generate display Generate Alarm signal
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
DFD dipetakan ke panggilan dan kembali (Main / sub Program arsitektur) arsitektur
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 Flow controller
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
3) Mentransformasi dipetakan ke tingkat subordinary dari arsitektur perangkat lunak
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 Generate Pulse to line Establish Alarm codition Select Phone number Acquire Response info Acquire Response info
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 executive Acquire Response info Read sensors Establish Alarm conditions Alarm output controller Establish Alarm conditions Establish Alarm conditions Establish Alarm conditions Establish Alarm conditions
◦
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 panel Sensors Interact With user Configure system Configure system Process password Display Message And status Monitor sensors Control Panel display Alarm Telephone line Configuration information User command and data Configure request Configuration data Configuration data Display information Alarm type Telephone Number tones Sensor status Password Start stop A/D msg. 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 User command Read System data Invoke Command processing Build Configuration file Activate/ Deactivate system Display Messages And status Read password Compare Password With file Produce Invalid message User commands Command type Configure System parameters and data Raw Configuration data Formatted Configuration data Configuration data Display information “Try again” message Invalid password Four digits Password Password Start stop 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
- So, Transaction oriented data flow
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 User command Read System data Invoke Command processing Build Configuration file Activate/ Deactivate system Display Messages And status Read password Compare Password With file Produce Invalid message Configuration information User commands Command type Configure System parameters and data Raw Configuration data Formatted Configuration data Configuration data Display information “Try again” message Invalid password Four digits Password Password Start stop 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
a b d p b d c1 q r s a q r s q Incoming flow Transform center Outgoing flow Reception path Transaction control Dispatcher Incoming branch Dispatch branch
Step 6. Factor and refine the transaction structure and the structure of each action path
User Interaction path Read User command Invoke Command Processing System Configuration Controller Activate/ Deactivate system Password Processing Controller Read System data Build Configuration file Read password Compare Password With file Password Output controller Produce Invalid message Display Message & status
Step 7. Refine the first-iteration architecture using design heuristics for improved software quality
Arsitektur perangkat lunak memberikan
