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 8. Summary
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 Ini memberi Anda gambaran besar
Apa langkah-langkahnya? 1) Desain Data 2) Representasi struktur arsitektur sistem Apakah produk kerja? Arsitektur Data Struktur Program Properti Komponen Dan Hubungannya
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 Hubungan antara komponen-komponen
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 Untuk cenderung untuk mengatasi masalah perilaku tertentu
Sebuah Taksonomi/Klasifikasi Singkat Styles Arsitektur arsitektur data-berpusat Sebuah menyimpan data (misalnya, file atau database) berada di pusat arsitektur ini Client software Client software Client software Data store (repository) 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 Main Program/subprogram architecture
Object-oriented architecture Komponen sistem merangkum data dan operasi Komunikasi antara komponen dicapai melalui lewat pesan Layered architecture User Interface Layer Components Application Layer Utility Layer Core Core Layer Layer Core 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 interface processing Bar code reader Conveyor line Bar code Line speed indicator Request Sorting station operator Conveyor Line Sorting System Queries Shunt commands Diagnostic data Sorting mechanism Mainframe Input processing maintenance and self-test Sorting station operator output processing
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 Actors Use Superordinate systems Target system Used by Depend on Use Peers - 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-topeer - Actors: Entitas (orang, perangkat) yang berinter aksi dengan sistem target Subordinate systems
Example of ACD, Fungsi keamanan rumah dari produk SafeHome Superordinate systems Safehome product Internet-based system Control panel Home owner Use Target system : Security function Use Surveillance function Peers Actors Uses Sensor Sensors 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 Mekanisme yang memungkinkan mempersenjatai atau melucuti dari node
Defining Archetypes Example of the SafeHome home security function Controller Communication with Node Detector Indicator UML relationship for SafeHome security function archtypes
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 Dan kemudian menentukan seberapa sensitif atribut kualitas
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 Transaction... Transaction center T Action paths............ 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, langkahlangkah desain berikut Step 1. Ulasan model sistem yang mendasar Mewakili produsen eksternal dan konsumen data Control panel User command and data SoftHome software Display information Alarm type Control Panel display Alarm Sensor Sensor status Telephone Number tones Telephone line Context level DFD for the SafeHome security function
Step 2. eview dan memperbaiki diagram aliran data untuk perangkat lunak Model analisis disempurnakan untuk menghasilkan lebih detail Control panel Sensors User command and data Interact With user Password Process password Sensor status Start stop Configure request Configure system Configure system Valid ID msg. Configuration data Monitor sensors Configuration data Configuration information A/D msg. Display Message And status Sensor information Configuration data Telephone Number tones Level 1 DFD for the SafeHome security function Display information Alarm type Control Panel display Alarm Telephone line
Configuration information Configuration data Interact With user Configure system Sensor ID, type Process password Sensor status Sensor ID, type, location Sensor information Configure system Alarm data Telephone number Alarm type Dial phone Telephone number tones Level 2 DFD that refines the monitor sensors transform
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 Read sensors Configuration information Generate display Sensor status Acquire response info Establish Alarm conditions Level 3 DFD for monitor sensors with flow boundary Select Phone number Format display Setup Connection To phone net Generate Alarm signal Generate Pulse to line
Step 4. mengisolasi transformasi pusat dengan menetapkan batasbatas 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 Incoming Information Processing controller Transform Flow controller Monitor Sensors executive Outgoing Information Processing controller Sensor Input controller Alarm Conditions controller Alarm Output 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 Incoming path Monitor Sensors executive Transform center Generate display Format display Generate Alarm Signal Setup ConnectionGenerate To phone Pulses to net line Outgoing path Sensor Input controller Acquire Response info Acquire Response info Establish Alarm codition Alarm conditions controller Select Phone number Format display Generate display Alarm output controller Generate alarm signal Setup connection To phone net Generate Pulse to line
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 Establish Alarm conditions Alarm output controller Read sensors Establish Alarm conditions Establish Alarm conditions Establish Alarm conditions Refined program structure for monitor sensors 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 Design steps for transaction mapping
Step 1. Review the fundamental system model Level 1 data flow for this mapping Control panel Sensors User command and data Interact With user Password Process password Sensor status Start stop Configure request Configure system Configure system Valid ID msg. Configuration data Monitor sensors Configuration data Configuration information A/D msg. Display Message And status Sensor information Configuration data Telephone Number tones Level 1 DFD for the SafeHome security function Display information Alarm type Control Panel display Alarm Telephone line
Step 2. Review and refine data flow diagram for the software Level 2 data flow diagram for user interaction subsystem User commands Read User command - 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 Password Command type Password System parameters Invoke Command processing Read password and data Read System data Configure Start stop Four digits Level 2 DFD for user interaction subsystem Activate/ Deactivate system Compare Password With file Raw Configuration Build data Configuration file Formatted Configuration data Configuration information A/D message Configuration data Invalid password Valid password Produce Invalid message Configuration data Display Messages And status Try again message Display information
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 The incoming path and all action path must also be isolated
User commands Read User command - Transaction center Password - Transform characteristic - Incoming, transform, and outgoing flow are bounded Command type Password System parameters Invoke Command processing Read password and data Read System data Configure Start stop Four digits Activate/ Deactivate system Compare Password With file - Transform characteristic - Incoming, transform, and outgoing flow are bounded Raw Configuration Build data Configuration file Formatted Configuration data Configuration information A/D message Configuration data Invalid password Valid password Produce Invalid message Configuration data Display Messages And status Try again message Display information
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 Transaction control Incoming branch Dispatch branch b d p Incoming flow b a Reception path c 1 d Dispatcher q Transform center q r s r q s Outgoing flow
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 Display Message & status Produce Invalid message
Step 7. Refine the first-iteration architecture using design heuristics for improved software quality To consider module independence, practicality, and maintainability
Arsitektur perangkat lunak memberikan Sebuah melihat secara keseluruhan atas sistem yang akan dibangun