# 軟體工程(下)
> 沒有上，因為期中考前沒在做

## CH9 Architectural Design

架構設計決策
軟體架構設計 -> 軟體架構描述
系統規格以及系統架構設計基本上可以同時進行，因為系統規格與其架構進密相關

* Stakenholder communication
有明確的架構可以幫助與既得利益者的溝通
* System analysis
分析"非功能性的需求"
* Large-scale reuse
測試過後的架構具有可重複利用性，節省時間

**Architecture and system characteristics**:
* Performance: 系統重要運算、溝通可以減到最低，所以利用大元件來組成來增強效能
* Security: 外部對系統，不希望外界侵入到系統 -> layer architecture 一層層保護(把關)
* Safety: 系統對外，不希望系統造成對外的危險
* Availability: 具有容錯機制，其中一個壞掉可以用其他的元件
* Maintainability: 可以維護性

但是這些條件其實會有衝突，例如large-grain元件的要求可能會犧牲可維護性、具有容錯機制可能犧牲安全性等

**系統結構(system structuring)**
-> 可以畫block diagram來設計子系統的架構圖
* 抽象沒辦法表示太多資訊
* 可以用於溝通，易於理解，用來做專案規劃

**架構模型(Architectural models)**
* 靜態結構模型(static structural model): 元件的呈現
* 動態流程模型(dynamic process model): 流程結構
* 介面模型(interface model): 定義子系統之間的介面
* 關係模型(relationships model): 資料流模型，輸入輸出之間的關係
* 分散模型(distribution model): 每個子系統分布在哪個電腦

**系統組織(system organization)**
設計系統的結構，有以下三種
* shared data repository: 共享資料庫style
* shared services: 共享服務
* abstraact machine: 階層式的架構

* Repository model:
共享資料庫模型可以讓子系統在中央資料庫共享資料
* 優點: 有效率、子系統不需要理解資料如何產生、備份容易、保密容易
* 缺點: 子系統之間需要做協調，型式要統一、資料改變成本比較高、沒辦法特定管理模式，資料使用困難

* Client-server model:
分散不同功能在不同的伺服器，client and server透過網路來溝通
* 優點: 資料分散容易、個別伺服器易於升級以及維護
* 缺點: 沒有共用資料庫，資料交換沒有效率

* Abstract machine (layered) model
每層提供不同的服務，上層可以使用下層的東西，並且影響只有前後一層

## CH10 Architecutre Design Styles
分解的方法有哪些?
sub-system and modules的區別:
* sub system本身就是系統，可以提供服務
* modules只是元件，必須跟其他元件配合才能提供服務

**模組化的分解(modular decomposition)**:
* object model: 類似物件導向程式設計的物件
* 物件有已經定義好的介面
* 物件導向分解，control model
* 優點: 物件相對獨立，容易呈現架構
* 缺點: 物件介面改動會有副作用，需要詳細分析
* pipeline or data-flow model: 前一個輸出當作輸入
* function-oriented pipelining (UNIX shell)
* 互動式系統不適合使用此系統
* 根據功能分模組，每個模組可以以function概括
* 優點: 加新功能非常容易
* 缺點: 資料傳遞需要共同格式，很難做"事件導向"

**控制方式(Control styles)**:
* centralised control
* 有==主要系統==做反映，還有分以下兩種系統
* call return model: 由上而下呼叫，下面回傳到上面
* manager model: 系統控制權在manager手中 (集中式控制)
* event-based control
* 每個子系統都有辦法做反應，也分為以下兩種
* Broadcast models: 事件沒有特定對象，看哪個子系統要處理
* 適合整合分散式系統
* Interrupt-driven models: 有特定對象，利用中斷通知某元件該處理什麼事(很像OS說的中斷)

**參考架構(Reference architectures)**:
跟應用領域相關，可以分成兩種
* Generic models: 從真實系統架構中抓取某些共同特徵，變成比較一般的 (實作導向)
* buttom-up 從已經應用的東西去總結出相同的類別
* Reference models: 從理想model中構想出來，當成參考標準 (理論導向)
* top-down 先有理論然後生成實際物體

## CH11 Application Architectures
軟體應用架構的介紹，可以分為以下幾種:
1. Data processing
* 批次的方式，資料進來處理，完成輸出，不會受到使用者干擾
* input -> process -> output
* 例如: 薪水、帳單處理系統

**Data-flow diagrams**:
透過這種圖來表示資料在系統中的移動、處理方式，可以簡化為以下表示方式:
* round-edged: 資料處理的過程
* arrows: 資料流的方向
* rectangles: 檔案以及資料庫存
如下圖例:

2. Transaction processing
* 有使用者的request，也會更新資料庫。
* 例如: 銀行交易系統、電子商務系統、**定位系統**

**middleware(交易中介軟體)**: 將資料做序列化，最後才送到資料庫
可以大致分成以下四層:
* the user interface
* user communications -> 登入介面、form或是query管理
* information retrieval
* 分散式搜尋
* 文件擷取
* 帳單
* system DB

3. Event processing
* 類似即時系統或是嵌入式系統，根據事件類型給予相對應的處理
* 例如: 文字編輯器(使用者透過滑鼠鍵盤等事件，給予回饋)
4. Language processing
* 使用者透過**正規語言**來讓系統做指定的處理
* 例如: compiler、shell

## CH12 Contemporary Rapid Software Development
**Agile methods(靈活方法開發)**
快速軟體開發(Rapid software development)
Requirement: 系統需求時常改變，傳統瀑布式開發不適合現在這種環境(不切實際)