軟件構(gòu)架實踐

內(nèi)容概要

　　本書在第1版的基礎(chǔ)上，根據(jù)軟件生命期的特點，分預(yù)想構(gòu)架、創(chuàng)建構(gòu)架、分析構(gòu)架和從一個系統(tǒng)至多個系統(tǒng)進行闡述。本書對第1版某些內(nèi)容進行了深入介紹，并增添了一些新內(nèi)容：ATAM、質(zhì)量需求、構(gòu)架重構(gòu)、用UML對構(gòu)架編檔和CBAM等。此外，本書還對一些新案例進行了分析，以幫助理解軟件構(gòu)架如何適應(yīng)商業(yè)需求。本書是卡內(nèi)基·梅隆大學(xué)軟件工程研究所推薦教材，榮獲取美國權(quán)威的“軟件開發(fā)”雜志第九屆圖書效率大獎。本書可作為軟件學(xué)院及高校相關(guān)專業(yè)本科生和研究生的教材，也適合業(yè)界人士研究參考。

作者簡介

作者：（美國）林·巴斯（Len Bass） （美國）保羅·克萊門茨（Paut Clements） （美國）瑞克·凱茲曼（Rick Kazman）  林·巴斯（Len Bass），軟件工程研究所（SEl）的一名離級軟件工程師。他已經(jīng)編著了5本書籍，并發(fā)表了大量關(guān)于軟件工程、人機交互的論文。他曾經(jīng)領(lǐng)導(dǎo)一個小組為飛行控制模擬器開發(fā)軟件構(gòu)架。目前，該構(gòu)架已經(jīng)被用作美國空軍標(biāo)準。 保羅·克萊門茨（Paut Clements），軟件工程研究所（SEI）的一名高級技術(shù)人員，其工作職責(zé)是開發(fā)軟件構(gòu)架和設(shè)計產(chǎn)品線。他已經(jīng)發(fā)表了30多篇關(guān)于軟件設(shè)計和實時系統(tǒng)的論文。 瑞克·凱茲曼（Rick Kazman），軟件工程研究所（SEI）的一名高級軟件工程師，負責(zé)構(gòu)架權(quán)衡分析工作，是沃特魯大學(xué)和多倫多大學(xué)的副教授。他已經(jīng)發(fā)表了50多篇關(guān)于軟件工程、人機交互和信息檢索的論文。

書籍目錄

第i部分 預(yù)想構(gòu)架
第1章 構(gòu)架商業(yè)周期
1．1 構(gòu)架的產(chǎn)生
1．2 軟件過程和構(gòu)架商業(yè)周期
1．3 什么樣的構(gòu)架才算好
1. 4 小結(jié)
1．5 討論題
第2章 什么是軟件構(gòu)架
2．1 軟件構(gòu)架概念的澄清
2．2 其他觀點
2．3 構(gòu)架模式、參考模型和參考構(gòu)架
2．4 為什么說軟件構(gòu)架非常重要
2．5 構(gòu)架結(jié)構(gòu)和視圖
2．6 小結(jié)
2．7 可進一步參閱的文獻
2．8 討論題
第3章 a-7e航空電子系統(tǒng)：使用構(gòu)架結(jié)構(gòu)的案例分析
3．1 與構(gòu)架商業(yè)周期的關(guān)系
3．2 需求與質(zhì)量
3．3 a-7e航空電子系統(tǒng)的構(gòu)架
3．4 小結(jié)
3．5 可進一步參閱的文獻
3．6 討論題
第ii部分 創(chuàng)建構(gòu)架
第4章 理解質(zhì)量屬性
4．1 功能和構(gòu)架
4．2 構(gòu)架和質(zhì)量屬性
4．3 系統(tǒng)質(zhì)量屬性
4．4 實踐中的質(zhì)量屬性場景
4．5 其他系統(tǒng)質(zhì)量屬性
4．6 商業(yè)質(zhì)量
4．7 構(gòu)架質(zhì)量
4．8 小結(jié)
4．9 可進一步參閱的文獻
4．10 討論題
第5章 實現(xiàn)質(zhì)量屬性
5．1 策略介紹
5．2 可用的策略
5．3 可更改性策略
5．4 性能策略
5．5 安全性策略
5．6 可測試性策略
5．7 可使用性策略
5．8 策略與構(gòu)架模式的關(guān)系
5．9 構(gòu)架模式和樣式
5．10 小結(jié)
5．11 討論題
5．12 可進一步參閱的文獻
第6章 空中交遁管制系統(tǒng)：高可用性設(shè)計案例分析
6．1 與構(gòu)架商業(yè)周期的關(guān)系
6．2 需求與質(zhì)量
6．3 構(gòu)架解決方案
6．4 小結(jié)
6．5 可進一步參閱的文獻
6．6 討論題
第7章 設(shè)計構(gòu)架
7．1 生命期中的構(gòu)架
7．2 設(shè)計構(gòu)架
7．3 形成團隊結(jié)構(gòu)
7．4 創(chuàng)建骨架系統(tǒng)
7．5 小結(jié)
7．6 可進一步參閱的文獻
7．7 討論題
第8章 飛行模擬：構(gòu)架可集成性案例分析
8．1 與構(gòu)架商業(yè)周期的關(guān)系
8．2 需求與質(zhì)量
8．3 構(gòu)架解決方案
8．4 小結(jié)
8．5 可進一步參閱的文獻
8．6 討論題
第9章 軟件構(gòu)架編檔
9．1 構(gòu)架文檔的使用
9．2 視圖
9．3 選擇相關(guān)視圖
9．4 視圖編檔
9．5 跨視圖文檔
9．6 統(tǒng)一建模語言
9．7 小結(jié)
9．8 可進一步參閱的文獻
9．9 討論題
第10章 軟件構(gòu)架重構(gòu)
10．1 介紹
10．2 信息提取
10．3 數(shù)據(jù)庫構(gòu)造
10．4 視圖融合
10．5 重構(gòu)
10．6 示例
10．7 小結(jié)
10．8 可進一步參閱的文獻
10．9 討論題
第iii部分分析構(gòu)架
第11章 atam：構(gòu)架評估的綜合方法
11．1 atam中的參與者
11．2 atam的結(jié)果
11．3 atam的階段
11．4 完美的系統(tǒng)：應(yīng)用atam的案例分析
11．5 小結(jié)
11．6 可進一步參閱的文獻
11．7 討論題
第12章 cbam：制定構(gòu)架設(shè)計決策的定量方法
12．1 制定決策的環(huán)境
12．2 cbam的基礎(chǔ)
12．3 實現(xiàn)cbam
12．4 案例分析：nasaecs項目
12．5 使用cbam方法的結(jié)果
12．6 小結(jié)
12．7 可進一步參閱的文獻
12．8 討論題
第13章 萬維網(wǎng)；可互操作性案例分析
13．1 與構(gòu)架商業(yè)周期的關(guān)系
13．2 需求與質(zhì)量
13．3 構(gòu)架解決方案
13．4 通過abc的另一個周期：基于web的電子商務(wù)構(gòu)架的演變
13．5 實現(xiàn)質(zhì)量目標(biāo)
13．6 目前的構(gòu)架商業(yè)周期
13．7 小結(jié)
13．8 可進一步參閱的文獻
13．9 討論題
第iv部分 從-個系統(tǒng)到多個系統(tǒng)
第14章 軟件產(chǎn)品線：重用構(gòu)架資產(chǎn)
14．1 概述
14．2 軟件產(chǎn)品線行之有效的原因
14．3 范圍
14．4 產(chǎn)品線的構(gòu)架
14．5 使用軟件產(chǎn)品線的困難之處
14．6 小結(jié)
14．7 可進一步參閱的文獻
14．8 討論題
第15章 celslusteeh：產(chǎn)品線開發(fā)案例分析
15．1 與構(gòu)架商業(yè)周期的關(guān)系
15．2 需求與質(zhì)量
15．3 構(gòu)架解決方案
15．4 小結(jié)
15．5 可進一步參閱的文獻
15．6 討論題
第16章 j2ee/ejb：工業(yè)標(biāo)準計算基礎(chǔ)結(jié)構(gòu)的案例分析
16．1 與構(gòu)架商業(yè)周期的關(guān)系
16．2 需求與質(zhì)量
16．3 構(gòu)架解決方案
16．4 系統(tǒng)部署決策
16．5 小結(jié)
16．6 可進一步參閱的文獻
16．7 討論題
第17章 luther構(gòu)架：使用j2ee的移動應(yīng)用案例分析
17．1 與構(gòu)架商業(yè)周期的關(guān)系
17．2 需求與質(zhì)量
17．3 構(gòu)架解決方案
17．4 luther構(gòu)架如何實現(xiàn)其質(zhì)量目標(biāo)
17．5 小結(jié)
17．6 可進一步參閱的文獻
17．7 討論題
第18章 用商業(yè)組件構(gòu)建系統(tǒng)
18．1 組件對構(gòu)架的影響
18．2 構(gòu)架失配
18．3 基于組件設(shè)計的搜尋
18．4 aseilm示例
18．5 小結(jié)
18．6 可進一步參閱的文獻
第19章 未來的軟件構(gòu)架
19．1 重新認識構(gòu)架商業(yè)周期
19．2 創(chuàng)建構(gòu)架
19．3 生命期中的構(gòu)架
19．4 商業(yè)組件的影響
19．5 小結(jié)
縮略語表
參考文獻
索引

章節(jié)摘錄

版權(quán)頁：   插圖：   The Architecture Enables More Accurate Cost and Schedule Estimates.Cost and schedule estimates are an important management tool to enable themanager to acquire the necessary resources and to understand whether a projectis in trouble.Cost estimations based on an understanding of the system piecesare,inherently,more accurate than those based on overall system knowledge.Aswe have said,the organizational structure of a project is based on its architecture. Each team will be able to make more accurate estimates for its piece than aproject manager will and will feel more ownership in making the estimates cometrue.Second,the initial definition of an architecture means that the requirementsfor a system have been reviewed and,in some sense,validated.The more knowledge about the scope of a system,the more accurate the estimates. ARCHITECTURE AS A TRANSFERABLE,RE-USABLE MODEL The earlier in the life cycle re-use is applied,the greater the benefit that can beachieved.While code re-use is beneficial,re-use at the architectural level provides tremendous leverage for systems with similar requirements.Not only codecan be re-used but so can the requirements that led to the architecture in the firstplace,as well as the experience of building the re-used architecture.When architectural decisions can be re-used across multiple systems,all of the early decisionconsequences we just described are also transferred. Software Product Lines Share a Common Architecture.A software product line or family is a set of software-intensive systems sharing a common,managed set of features that satisfy the specific needs of a particular market segmentor mission and that are developed from a common set of core assets in a prescribed way.Chief among these core assets is the architecture that was designedto handle the needs of the entire family.Product line architects choose an architecture (or a family of closely related architectures) that will serve all envisionedmembers of the product line by making design decisions that apply across thefamily early and by making other decisions that apply only to individual members late.The architecture defines what is fixed for all members of the productline and what is variable.Software product lines represent a powerful approach tomulti-system development that shows order-of-magnitude payoffs in time to market,cost,productivity,and product quality.The power of architecture lies at theheart of the paradigm.

圖書封面

圖書標(biāo)簽Tags

無

評論、評分、閱讀與下載

---

    軟件構(gòu)架實踐 PDF格式下載

---