學習目標 　　聽<軟體架構相關音訊>軟體開發架構一節      待解決問題 　　構件的概念 ? 　　　　構件是面向軟體體系架構的可複用軟體模組。構件（component）是可複用的軟體組成成份，可被用來構造其他軟體。它可以是被封裝的物件類、類樹、一些功能. 　　如何表達一個專案的架構,用什麼圖表? 　　架構設計作為一個系統開發的中間產品,交付的是什麼內容? 　　各種架構風格的適用場景? 　　網際網路應用  BS架構的應用  ria 富網際網路是什麼意思?　      學習內容 特定領域軟體架構 領域分析 這個階段的主要目標是獲得領域模型(Domain Model).領域模型描述領域中系統之間共同的需求.領域模型所描述的需求陳曾為領域需求 準備性活動:  定義領域邊界-->從而明確分析的物件 識別資訊源    -->即領域分析和整個領域工程中資訊的來源.可能的資訊源包括現存系統,技術文獻,問題域和系統開發的專家 使用者需求和市場分析,領域演化的歷史記錄等. 分析領域中系統的需求,確定哪些需求是被領域中的系統廣泛共享的,從而建立領域模型. 領域設計
目標:獲得DSSA(特定領域軟體架構) 這個階段通過獲得DSSA,也就同時形成了重用基礎設施的規約. 領域實現   目標:依據領域模型和DSSA開發和組織可重新資訊.這些可重新資訊可能是從現有系統中提取出來的,也可能是需要通過新的開發得到 參與的人員:領域實現人員 領域設計人員 領域分析人員 領域專家    　　　　 以上的過程是一個反覆的,逐漸求精的過程.     建立過程（5個階段及其目標）

• 定義領域範圍->確定什麼在感興趣的領域中及本過程導何時結束.
• 定義領域特定的元素->編譯領域字典和領域術語的同義詞詞典.
• 定義領域特定的設計和實現需求約束->描述解空間中有差別的特性.
• 定義領域模型和架構->產生一般的架構,並說明構成他們的模組或構件的語義和語法.
• 產生 蒐集可重用的產品單元->為DSSA增加構件使得它可以被用來產生問題域中的新應用.

建立的過程是併發的,遞迴的和反覆進行的.  三層次系統模型         基於架構的軟體開發方法（ABSD）   1、架構需求 技術環境,設計師的經驗影響  建立分析原型（類圖 打包 構件） 標識構件 需求評審（需求庫--重用的系統）？？已完成這麼多專案，需求庫在哪裡------是否可以從文件劃分需求庫？？ 2、架構設計     提出架構模型（選擇符合風格）     影射構件 影射到架構當中          三層架構為例             表示層 資料層 業務層分別於有哪些構件      分析構件之間的相互作用；     設計     評審 3、架構文件化     從使用的角度進行編寫     各個系統之間通訊的檔案 4、架構複審     外部人員參加的評審-標識潛在風險 5、架構實現     用實體顯示出架構 分過程構建     架構說明書 系統構件及實現（構件庫） 6、架構演化     使用過程中，進行軟體演化（修改軟體架構）     需求變化--標記構件--建立新構件/修改構件          更新構件     更新構件的相關關係     新的構件 迭代思想   基於架構的軟體開發方法--比如：視覺化建模方法（UML類圖） 架構的選擇是一個系統的保障   軟體架構評估 物件：質量屬性(27個屬性) 可用性:是指系統能夠正常執行的時間比例. 常見的策略:錯誤檢測技術(命令/響應 心跳 異常) 錯誤恢復(表絕 冗餘) 錯誤預防(定期充值 程序監視器)   可修改性:是指能夠快速的以較高的效能價格比對系統進行變更的能力. 常見的策略:區域性化修改(維持語義的一致性,預期期望的變更 泛化該模組)   防止連鎖反映(資訊隱藏 維持現有的介面 限制通訊路徑)   效能:是系統的相應能力,既要經過多長時間才能對某個時間作出響應,或者再某段時間內系統所能處理時間的個數. 常見的策略:資源需求(提高計算效率 減少計算開銷 管理時間率 限制執行時間) 資源管理方面(引入併發 維持資料或計算的多個副本 增加可用資源) 資源仲裁方面(先進顯出 固定優先順序排程 動態優先順序排程)   安全性:是指系統向合法使用者提供服務的同時能夠阻止非授權使用者使用的企圖或拒絕服務的能力. 策略:抵抗攻擊(對使用者進行身份驗證呢個 對使用者進行授權 維護資料的機密性 限制暴露的資訊 限制訪問)  檢測攻擊  從攻擊中恢復   可測試性:是指軟體發現故障並隔離,定位其故障的能力特性,以及在一定的時間和成本前提下,進行測試設計,測試執行的能力. 策略:將介面與實現分離  特化訪問介面   易用性:是衡量使用者使用一個軟體產品完成制定任務的難以程度.   軟體架構評估 　　　　方法： 基於場景的評估方法(主要使用的方法 \) 1、分析方面[三種分析法] ATAM(架構權衡分析法 Architecture Tradeoff Analysis Method) 1、評估參與者（3種人員）

• 評估小組
• 專案決策者
• 其他專案干係人

2、評估活動（9個步驟）   CBAM(成本效率分析法 Cost Benefit Analysis Method) 概念:用來對架構設計決策的成本和收益進行建模,其基本思想是架構策略影響系統的質量屬性,反過來這些質量屬性又會為系統的專案干係人帶來一些效益. CRAM協助專案干係人根據其投資收益率選擇架構策略. 評估步驟:

• 整理場景
• 對場景進行細化
• 確定場景的優先順序
• 分配效用
• 確定期望的質量屬性響應級別的效用
• 計算各種架構策略的總收益
• 根據受成本限制影響的投資收益率來選擇架構策略.

  SAAM(軟體架構分析法 Software Architecture Analysis Method) 步驟:(6個步驟)   　　 評估結果 1 把代表了未來肯呢個做的更改的場景與架構對應起來,顯現出架構中未來可能表現出較高複雜性的地方,並對每個這樣的更改的預期工作量作出評估. 2 理解系統的功能 對多個架構所支援的功能和數量作出評估   軟體產品線(Software Product LIne)   類似於 硬體製造 汽車生產 概念:  　　　　　　是一個產品集合,這些產品共享一個公共的,可管理的特徵集,這個特徵集能滿足特定領域的特定需求. 優勢  提高軟體生產率和質量 縮短開發時間 降低總開發成本 組成 核心資源 產品集合    雙生命週期模型 領域工程階段 應用工程階段   SEI模型 基本活動:核心資源開發(領域工程)  產品開發(應用工程)  管理   三生命週期模型 主要針對發行軟體企業的軟體產品線開發   產品線的建立方式(4種方式)  

	演化方式	革命方式
基於現有產品	基於現有產品架構設計產品線的架構,經演化現有構件,開發產品線構件	核心資源的開發基於現有產品集的需求和可與測的,將來需求的超集
全新產品線	產品線核心資源歲產品新成員的需求而演化	開發滿足所有預期產品線成員的需求的核心資源

 　　　　   發展過程有3個階段

• 開發階段
• 配置分發階段
• 演化階段

成功實施產品線的因素

對要實施產品線的領域具備長期和身後的經驗

一個用於構建產品的好的核心資源庫

好的產品線架構

好的管理(軟體資源 人員組織和過程等)支援