具體描述
編輯推薦
在整本書中，Lahman都為理論問題進行瞭例證，解釋為什麼事情應該這樣完成，但對讀者沒有很高的數學要求。他關注於創建實現無關的模型，該模型可以完全地、精確地、無二義性地解決功能性需求。無論你是開發人員、團隊的領導、架構師或者設計師，書中介紹的技術都將幫助你構建更加健壯、易於維護、支持大規模重用的軟件。
內容簡介
當今世界，軟件變得越來越復雜，軟件的用戶對軟件性能、可靠性、功能性以及交付市場的速度等方麵的期望也在呈指數增長。本書通過將經過證實有用的麵嚮對象技術與一種強大的新方法學相結閤，為我們展示瞭應對這些挑戰的方法。
《基於模型的軟件開發》詳細介紹瞭基於模型的軟件開發的核心原則，展示如何分離每一個項目的關注點，使得參與者能夠為每個域特有的需要和特徵進行優化，通過實例展示如何實施更有效的麵嚮對象的分析、強調抽象、嚴格的分區、不變量建模、有限狀態機和程序單元之間的高效通信。通過閱讀本書，你將學到：
迴顧麵嚮對象方法誕生的曆史背景及麵嚮對象開發的基礎。
講解用於反映設計中用戶和計算機環境之間重要區彆的問題域和計算域。
為什麼應用分區很重要以及如何很好地進行應用分區。
構建描述基本應用結構的靜態模型。
為類、類的職責、關聯、引用完整性和知識完整性建模。
創建動態模型，用於通過有限狀態機描述行為。
成功地使用抽象動作語言（Abstract Action Language，AAL）和動作數據流圖（Action Data Flow Diagram，ADFD）。
《基於模型的軟件開發》共分三部分，共有18章。第一部分（第1～6章）重點介紹麵嚮對象方法誕生的曆史背景，闡述麵嚮對象的方法旨在解決的問題。第二部分（第7～13章）討論麵嚮對象開發的基本原則如何應用於MDB方法學中，如何定義穩定的應用結構或框架。第三部分（第14～18章）講述如何利用動態模型描述動態計算需要。
??
作者簡介
H.S. Lahman，1957年在插件闆上寫瞭他的第一個軟件程序。在接下來的十年，他作為勘探地球物理學傢在很多重要的沼澤、沙漠和苔原的叢林中使用尖端技術，這些磨練瞭他的意誌。然後，他迴到學校學習經濟學、運籌學和計算學。在接下來的30年中，他為MIS係統、科學和R-T/ E環境開發軟件。1982年，他成為一名麵嚮對象開發的倡導者。20世紀90年代，他成為一名軟件質量和開發過程改進的倡導者。
廖彬山，先後就讀於南京大學數學係和北京航空航天大學計算機科學與技術係。現在是美國CMU／SEI認證CMMI主任評估師（CMU／SEI-certified SCAMPI Lead Appraiser），北京國信普道科技有限公司CMMI首席顧問，北京航空航天大學軟件學院客座教授。目前主要從事CMMI的培訓、谘詢和評估工作及軟件工程理論與方法的研究工作。迄今為止，已經成功地為幾十傢不同類型、不同規模、不同應用領域的企業進行瞭基於CMM和CMMI的谘詢與評估工作，積纍瞭豐富的實踐經驗，有效地解決瞭企業實際存在的問題。已經成功地為國內近百傢企業提供瞭軟件估算、軟件度量與量化管理、功能點、統計過程控製、高成熟度組織的過程改進、個體軟件過程（PSP）、團隊軟件過程（TSP）、需求工程、缺陷管理、軟件測試、同行評審、持續風險管理、統一軟件開發過程等專題培訓，有效地提高瞭國內企業的項目管理和工程開發能力。
王慧，畢業於北京航空航天大學計算機學院，工學博士，研究方嚮為軟件工程和過程工程。她曾從事大型軟件過程建模與模擬係統的需求開發、軟件設計與實現、係統測試等工作。目前是一名谘詢師，成功地為多傢不同類型、不同規模、不同應用領域的企事業單位進行瞭敏捷開發方法、軟件項目管理、CMMI、TSP和PSP等谘詢工作，有效地解決瞭企業實際存在的問題。
馬蘇宏，畢業於北京航空航天大學計算機學院，工學碩士，研究方嚮為過程工程的建模、模擬與正嚮工程。曾就職於IBM公司，擔任軟件工程師，有豐富的軟件設計與開發經驗。目前是一名業餘的翻譯愛好者。
目錄
譯者序
前言
引言
第一部分 麵嚮對象開發的根本
第1章 曆史的視角 2
1.1 曆史 2
1.2 結構化開發 3
1.3 寶貴教訓 8
1.3.1 全局數據 9
1.3.2 巨程序單元 9
1.3.3 軟件結構 10
1.3.4 缺乏內聚性 10
1.3.5 耦閤 10
1.4 技術革新 12
1.4.1 圖靈機 13
1.4.2 語言和方法學 13
1.4.3 集閤和圖 16
1.4.4 範式 16
1.4.5 數據流 18
1.4.6 狀態機 20
第2章 對象技術 22
2.1 基本理念 22
2.1.1 可維護性 22
2.1.2 問題域抽象 23
2.1.3 OOA、OOD和OOP 24
2.1.4 主題 25
2.1.5 關注點分離 26
2.1.6 抽象層次 26
2.1.7 問題域抽象 28
2.1.8 封裝 29
2.1.9 內聚性 29
2.1.10 邏輯不可分性 30
2.1.11 通信模型 31
2.2 廣度優先處理（又稱對等協作） 32
2.2.1 細化與轉化 33
2.2.2 消息範式 35
2.2.3 對象特徵 36
第3章 泛化、繼承、泛型和多態 39
3.1 泛化 39
3.2 繼承 42
3.3 多態 42
3.4 泛型 45
第4章 MBD路綫圖 46
4.1 問題域和計算域 46
4.1.1 問題域 48
4.1.2 計算域 49
4.1.3 轉換 50
4.2 可維護性 50
4.2.1 領域分析 50
4.2.2 不變量建模 51
4.2.3 應用分區 52
4.2.4 靜態視圖 52
4.2.5 動態視圖 52
第5章 不變量建模 55
5.1 什麼是不變量建模 55
5.1.1 不變量 56
5.1.2 數據 57
5.2 好處 58
5.3 例子 60
5.3.1 銀行ATM軟件 60
5.3.2 硬件接口 64
5.3.3 摺舊 67
5.3.4 遠程POS輸入示例 72
第6章 應用分區 76
6.1 為什麼我們要關注 76
6.2 應用分區的基本概念 77
6.2.1 主題 79
6.2.2 客戶端/服務關係 82
6.2.3 抽象層次 84
6.2.4 接口 85
6.3 識彆子係統 86
6.3.1 將相同的實體抽象為其他子係統時，當前子係統是否存在不同的視角 86
6.3.2 是否存在客戶端/服務的關係 86
6.3.3 服務是否比客戶端更加詳細 87
6.3.4 是否與其他子係統知識共享 87
6.3.5 是否與其他子係統行為共享 87
6.3.6 主題是否內聚 87
6.3.7 邊界定義是否清晰 88
6.3.8 能否重用 88
6.3.9 是否被分布式網絡環境綁定 88
6.3.10 是否針對不同的問題域 88
6.4 橋 89
6.4.1 消息範式，又是消息範式 89
6.4.2 橋模型 91
6.5 描述子係統 92
6.5.1 子係統描述 93
6.5.2 關係描述 94
6.5.3 需求分配 94
6.6 一個例子：寵物保健中心 94
6.7 過程 106
第二部分 靜?態?模?型
第7章 第二部分路綫圖 112
7.1 什麼是靜態模型 113
7.2 知識和行為 114
7.3 實用的注釋 115
第8章 類 117
8.1 抽象錶示 117
8.1.1 為真實的東西建模 118
8.1.2 局限於子係統或組件中 119
8.1.3 邏輯不可分性 119
8.1.4 委托 120
8.2 類錶示法 121
8.3 識彆類及其職責 122
8.3.1 對象“突擊” 123
8.3.2 用例變異 124
8.4 例子 125
8.4.1 傳奇的銀行ATM控製器 125
8.4.2 寵物保健中心：處置 131
8.5 使用序列圖和協作圖 134
第9章 類的職責 137
9.1 屬性：一個類對象應該知道什麼 137
9.1.1 定義和錶示法 137
9.1.2 與數據存儲不同 138
9.1.3 狀態 139
9.1.4 抽象數據類型 140
9.2 操作和方法：對象必須做什麼 142
9.2.1 定義和錶示法 142
9.2.2 識彆行為 144
9.2.3 擬人化 148
9.3 過程 149
9.4 例子 150
9.4.1 ATM 150
9.4.2 寵物保健中心：處置 158
第10章 關聯 165
10.1 定義與基礎 165
10.2 錶示法 170
10.3 邏輯連接的性質 172
10.3.1 導航到知識與導航到行為 173
10.3.2 關聯角色 174
10.3.3 關聯路徑 175
10.4 條件性 178
10.5 多重性 182
10.5.1 使用“一個”模型替換問題域的“一個或更多個”模型 183
10.5.2 為問題域關聯提供二次關聯 184
10.5.3 選擇和參與 185
10.6 約束 187
10.7 關聯類 189
10.8 識彆關聯 192
10.9 例子 195
10.9.1 ATM控製器 195
10.9.2 寵物保健中心：處置 198
第11章 引用完整性和知識完整性 200
11.1 知識完整性 200
11.1.1 及時性 201
11.1.2 一緻性 201
11.1.3 快照和實時訪問 202
11.1.4 依賴屬性 202
11.1.5 屬性標準化 204
11.2 引用完整性 207
11.2.1 標識與引用屬性 207
11.2.2 關聯循環 209
11.2.3 關係和麵嚮對象範式：完全不同 211
第12章 泛化歸來 213
12.1 子類化 213
12.1.1 錶示法和規則 215
12.1.2 泛化和特定化 216
12.1.3 分類 219
12.1.4 包含多態 223
12.1.5 為什麼是{相交，完整}的子集 225
12.2 多方嚮子類、多重繼承與組閤 227
12.3 泛化的備選 235
12.3.1 委托 236
12.3.2 參數多態 238
12.3.3 基本抽象 238
第13章 識彆知識 239
13.1 麵嚮對象知識的性質是什麼 239
13.2 抽象聚閤 241
13.3 挑選適閤的抽象 245
13.3.1 抽象人們做什麼 246
13.3.2 潛在實體知道哪些 247
13.3.3 對象抽象應當知道哪些實體知識的子集 248
13.3.4 主題是什麼 248
13.3.5 抽象層次是什麼 251
13.4 抽象是否需要結閤實體知識 252
第三部分 動?態?模?型
第14章 第三部分路綫圖 258
14.1 第三部分路綫圖 258
14.1.1 一切都關乎行為 259
14.1.2 對象生命周期 261
14.1.3 異步解決方案 262
14.1.4 同步服務 266
14.2 動作語言 269
14.3 Mealy機、Moore機和Harel機 270
14.4 學習麯綫 272
第15章 有限狀態機 273
15.1 基本的有限狀態自動機 273
15.1.1 錶示法 277
15.1.2 契約設計的作用 280
15.2 尋找狀態機 283
15.2.1 知識和行為 283
15.2.2 管理序列 286
15.3 一些例子 295
15.3.1 車庫門遙控器 295
15.3.2 自動傢庭廚房 297
15.3.3 空中交通管製係統 297
15.3.4 岩石 298
第16章 狀態、轉換、事件和動作 300
16.1 狀態 300
16.2 轉換 305
16.3 事件 306
16.4 動作 309
16.5 執行模型 311
16.6 命名約定 313
第17章 開發狀態模型 316
17.1 設計狀態機 316
17.2 例子 325
17.2.1 ATM控製器：字符顯示 326
17.2.2 ATM控製器：調度器 331
17.2.3 ATM控製器：存款 340
第18章 抽象動作語言 344
18.1 AAL和ADFD 345
18.2 AAL語法 346
18.3 例子 348
18.3.1 車庫門遙控器 348
18.3.2 ATM：字符顯示 351
術語錶 354
前言/序言
軟件開發是一項極其復雜的智力活動，它是一門朝氣蓬勃並且仍在迅速發展的學科。軟件開發還不夠完善，因此迄今人們仍然在試圖找齣開發軟件的好方法。 盡管如此，多年來軟件開發方法仍然獲得瞭大幅提升。許多設計方法學不斷發展以促進軟件設計的各個方麵。其中之一是結構化設計方法，該方法提供瞭一種非常直觀的方式，用以很好地匹配圖靈和馮·諾依曼的硬件計算模型。 問題盡管結構化設計明顯優於它之前的特定方法，但它存在著一個緻命的弱點：當用戶需求隨著時間的推移改變時，軟件往往很難隨之修改，大型的應用尤其如此。與此同時，應用的規模和復雜性迅速膨脹。另外，新的語言、技術、操作係統、數據存儲範式、用戶界麵範式、硬件等以驚人的速度齣現在計算領域中。然而，商業條件一直在要求軟件産品更快、成本更低地投入市場。 希望因此，一些新的設計方法齣現瞭，這些方法從實踐中吸取瞭來之不易的經驗和教訓。同時，計算領域提齣瞭一些革命性的新觀點。其中之一就是麵嚮對象的範式，其主要目標為：在軟件産品的生命周期中，隨著需求齣現不可避免的變更，保證大型應用的可維護性。 本書介紹一種特定軟件設計方法的實踐，該方法稱為基於模型的開發方法，其主要基礎是Shlaer-Mellor方法。通常情況下應用OO範式，特定情況下應用MBD方法能夠使大型應用獲得更強的健壯性和可維護性。 本書主要內容盡管本書使用UML（Unified Modeling Language，統一建模語言）作為錶示法，但其應用是很淺顯的。有很多非常優秀的書籍描述瞭如何使用UML進行軟件設計，因此本書沒有過多地描述UML的語法。同樣，本書遵循瞭MBD的設計方法，但是該設計方法主要為下列真正目的提供背景支持： 本書的主要目標在於描述，為什麼在一般情況下使用OO方法和在特殊情況下使用MBD方法是在宣傳一種做事情的特殊方法。 不存在一種唯一正確的方法可以設計和開發所有軟件。設計更多地依賴於特定的開發環境，包括從業務目標到工具再到團隊文化等所有內容。最終，企業將決定在它的環境中哪一組工具是最高效的。為瞭做到這一點，決策者應當瞭解為什麼MBD的方法工具集得以應用在許多常見的環境中。更重要的是，相關人員需要充分理解基本原理，從而能夠根據特定的環境加以調整進而應用。 實現麵嚮對象的設計需要一種獨特的思維，該思維在硬件計算模型中很不直觀。本書真正關心的是設計軟件時如何思考，特定的錶示法和方法學不是本書的側重點。因此，本書以大量的篇幅探索好的軟件設計的思考過程，甚至故意提供瞭一些不好的初步設計，用以證明該方法的自我糾正能力。 為瞭獲得這樣的理解，有必要描述軟件開發的傳統方法（麵嚮對象方法之前）在某些方麵如何失敗，以及麵嚮對象範式如何改正這些缺點。盡管結構化方法為1970年之前軟件開發的混亂帶來瞭切實的秩序，但它不是萬能的。到20世紀80年代，軟件明確顯示，嚴重的可維護性問題仍然存在，這些問題正是麵嚮對象範式要解決的。 同樣，如果不討論一種方法學的某些基礎理論，那麼就沒有辦法描述該方法學是否能夠很好地工作。然而，這是一本軟件開發人員寫給軟件開發人員的書，因此本書有意識地使用瞭不具有數學嚴謹性的實踐術語來描述理論問題。 因為本書的主要內容是抽象OOA（Object Oriented Analysis，麵嚮對象分析）模型的建立，因此書中沒有很多OOPL（Object Oriented Programming Language，麵嚮對象編程語言）代碼。從方法學的名稱顧名思義，其重點在於抽象建模而不是編寫傳統的源語言代碼。實際上，當一個具有“轉化質量”的OOA模型開發完成後，模型就是代碼。換句話說，OOA建模使用的錶示法是一種擴展的UML符號，其中增加瞭符閤MDA的抽象動作語言（Abstract Action Language，AAL）的內容。錶示法是4GL（Fourth Generation Language，第四代語言）而不是3GL（Third Generation Language，第三代語言），但是模型像任何一個3GL程序一樣可執行。模型是獨立實現的，它是一個針對功能需求解決方案的完整、準確而清晰的規格說明。 我們需要指齣的最後一點是，作者的實踐開發經驗是以幾十年而不是幾年來衡量的。盡管本書的重點在於解釋為什麼這樣做事情，但它絕對不是一本理論書。本書的基礎是在現實世界中行之有效的方法。 路綫圖本書的主題限定於OOA層的應用開發，主要分為三部分。第一部分迴顧瞭曆史並介紹瞭基本的麵嚮對象的原則。引言部分包括對結構化開發問題的討論，這些問題正是OO範式想要解決的。第二部分關乎為問題的解決方案構造一個靜態的結構。這一部分描述瞭OO範式與其他方法的最大不同，主要錶現瞭OO範式在問題域抽象方麵的獨特視角。第三部分描述瞭解決方案的動態方麵，尤其是積極地使用有限狀態機進行行為描述。 讀者對象本書的主要受眾人群為具有較少OO經驗的人。本書假定讀者具有一些粗略的UML知識。本書還假定讀者具有一些軟件開發經驗，接觸過類似C語言的課程項目等。這裏假設的經驗層次包括：基本具備有關計算機和編程的一些知識，基本熟悉一些常見的縮略語，例如KISS等。 第二類讀者是從傳統的程序開發環境嚮OO範式轉變的大量人群。他們中的許多開發者直接躍進到使用麵嚮對象的編程語言寫程序，因為他們已經具有瞭豐富的編程經驗（即，相信如果一個人已經瞭解瞭一種編程語言，就能瞭解全部的編程語言）。可悲的是，這樣的開發者往往會開發齣大量不好的OO代碼，因為沒有人告訴他們為什麼麵嚮對象的分析和設計與結構化的分析和設計之間存在著巨大的差異。如果你是其中之一，那麼你需要忘掉之前所學過的所有關於設計軟件的內容，從零開始。 轉化的作用MBD的一個主要特點是，它是基於轉化（translation）的一係列方法之一。也就是說，MBD是一種這樣的方法，在該方法中，一個解決方案使用某種錶示法（例如UML）抽象為模型，然後使用一個完整的代碼發生器將模型自動轉化為一種實現。轉化具有一些明顯的優勢，因為它代錶瞭計算領域的一種自動化的邏輯擴展，能夠提高生産力、實現規模經濟並增加可靠性。缺點在於這並不容易做到。模型編譯器麵臨的優化問題比3GL編譯器麵臨的優化問題更加復雜。無論如何，當前已經存在一些商業代碼生成器能夠為基於轉化的方法提供100％的代碼生成。 盡管大部分轉化方法齣現於對象管理組織（Object Management Group，OMG）成立之前，由OMG所規範的模型驅動架構（Model-Driven Architecture，MDA）還是極大地推動瞭這些方法。MDA為即插即用工具提供急需的標準，為生成完整的代碼提供概念框架。從一個抽象的、獨立於實現的模型獲得第三代語言代碼或者程序集是一項重要的工作，特彆是對當前復雜的IDE（Integrated Development Environment，集成開發環境）來說。這項工作大大受益於MDA的概念及其形式化。 然而，MBD並不依賴於轉化。MBD中産生的模型與傳統開發中OOA産生的模型本質是相同的，可以通過手工的方式生産OOD模型和3GL代碼。MBD模型的構建隻是比典型的OOA模型更加嚴格，因為代碼生成器是沒有想象力的，它們處理命令中的內容，而不是暗示的內容。開發者必須手工實現轉化。 緻謝非常感謝Steve Mellor和Sally Shlaer的工作，他們的方法是MBD的基礎。他們是軟件開發轉化方法的開創者，並為OOA模型提供瞭急需的設計嚴謹性。除此之外，Steve Mellor是我見過的最好的OO建模者，他提供的例子讓人受益匪淺。 同樣感謝Rebecca Wirfs-Brock對手稿一絲不苟和悉心的審校。 Pathfinder Solutions為本書的方法提供瞭優秀的試驗場，Greg Eakman、Carolyn Duby和Peter Fontana提供瞭特彆的支持。 還要感謝Addison-Wesley齣版社的Chris Guzikowski和Raina Chrobak的耐心與信心。謝謝Elizabeth Ryan、Diane Freed和Chris Zahn的編輯工作。 盡管這本書於我退休之後開始撰寫，我還是要感謝Teradyne/ATB公司，他們提供瞭世界一流的軟件開發工廠，其中充滿瞭明星開發人員，他們為本書中的許多想法提供瞭原型。 最後，我要感謝30多年以來因特網上的大量用戶為本書中概念的解釋提供的共鳴版。讀者讀到的清晰描述大部分精煉自公共論壇上的描述。 引 言曆史是一場噩夢，我試圖從中清醒。 ——喬伊斯40年前，百萬行的程序被認為是巨型程序，僅供美國國防部（Department of Defense，DoD）內部巨大的主機係統使用。按常規估計，開發這樣的程序需要1000名工程師工作10年。今天，大多數PC上的應用都超過百萬行，並且有許多在韆萬行範圍之內。而且，人們期望它們能在幾年甚至更短的時間之內開發完成。因此，在程序規模不斷增長的同時，客戶期望開發費用能越來越少。 在高科技日新月異的當今社會，軟件快速老化已經成為常態。在公司的經濟發展模式中，增長的要求比以往任何時代都更受重視。諸多因素促使公司在短時間內創造齣更多、更好、更與眾不同的産品。由於這些新産品的研發製造都需要依賴日漸龐大的各式軟件，因此軟件開發人員完成工作、縮短上市時間的壓力不斷增大。 軟件開發人員同時奮戰在軟件開發的另外一條戰綫上。40年以前，對於發布的代碼，全美的平均缺陷率為150個/KLOC。但是該數據沒有人關注，因為大好形勢之時，沒有人去研究如何寫“好的”軟件。GOTO語句和全局數據占主流地位，設計在黑闆上或者雞尾酒餐巾上完成，DEL鍵永遠是程序員們的最愛。軟件開發如同一些電氣專業一樣晦澀難懂，因此，坦率地說，那時沒有人在意這些。 但是，這樣一個烏托邦式的情況不可能永久持續。在20世紀70、80年代發生瞭兩次變革。第一，一場由日本方麵開始的質量革新齣現，亞洲其他國傢紛紛效仿，隨後緩慢波及到西方工業國傢。此次變革使得用戶進入瞭一個新時代，他們不用再把每周六分之一的時間花在修理車子或者電視上，這纔是用戶真正喜歡的。第二，在此次質量革新之後，軟件的影響逐漸滲透到生活的方方麵麵，突然間軟件就成為經常齣錯的典型。現在用戶逐漸意識到瞭還有更好的質量革新方式，於是對於這些經常齣錯的軟件，他們不再喜歡瞭。 因此，要求軟件開發人員在更短的時間之內開發規模更大的程序，同時還要求將缺陷率控製在5西格瑪的範圍之內。更大的挑戰是，20世紀80年代市場流行的口號是“質量是免費的”。雖然每一位軟件開發人員都知道這是一派鬍言，因為軟件質量與開發時間是此消彼長的一種平衡。但是，市場壓力的影響遠遠大於軟件開發人員的影響，沒有人聽到軟件開發人員的呐喊。因此20世紀80年代對於“軟件危機”一詞更新更深層的含義是以軟件開發人員的健康為代價的。 第二個重大事件是關於計算的技術大爆炸。以前技術進步的主要特徵是新的語言或者操作係統的齣現。但是PC軟件數量的不斷增長，程序互操作性的需求和萬維網的齣現，促使計算技術創新不斷。從以架構策略為基礎的計劃工作到測試過程，現在的軟件開發人員在方方麵麵都有多種選擇。更誇張的是，當開發人員還在熟悉舊技術的時候，新的技術已經齣現瞭，速度之快令人咂舌。 最終，軟件開發人員麵臨著不斷産生的需求變更。計算域不是唯一麵對創新和變革的領域。美國聯邦會計標準局（Federal Accounting Standards Bureau，FASB）的核心管理信息係統IRS以及各式各樣的其他美國政府機關不定期在頒布變更指令。産品的激烈競爭迫使市場支持者不斷推陳齣新，以保持與競爭對手步伐一緻。同樣，在學術界，標準、技能和工程學科的技術方麵也日新月異，逐漸擺脫混亂形成統一。“需求萬年不變”和項目瀑布模型的日子一去不復返瞭。 總之，現代的軟件開發人員都麵臨著一個古老的問題，即：如何把5磅的東西盡快放到一個容量僅3磅的袋子裏，並保證沒有任何遺漏。今天，和半個世紀前相比，我們有著更好的工具、方法、過程和技術，但問題也是成比例增長的。基本匯編語言（Basic Assembly Language，BAL）要解決的軟件危機問題仍然如影隨形，這也是本書的第一條忠告。 軟件開發是一個不可能完成的任務，開發人員唯一要做的就是不斷應對並保持微笑。 1.?研究現狀1995年的某次會議上，主講人要求當時的與會人員中使用微軟Windows操作係統的人員舉手示意，數百人舉起瞭手。然後，他要求過去一周內係統崩潰過的人再次舉手，大半以上的人仍然舉手。接下來，他讓那些認為微軟在將來會被市場淘汰的人繼續舉手，結果所剩寥寥無幾。該主講人用此次實例來說明和驗證自己的說法，那就是，軟件質量不是一個事關公司生存的必要條件。 這一結論在今天很難保證是對的，尤其是在微軟與Linux的市場大戰中可見一斑。決定一個軟件公司在市場中生存的關鍵因素，其實是他們是否能夠提供用戶想要的東西。從廣義上講，這一點可大緻從産品的可靠性、功能性、易用性和可用性（即市場時效性）四個方麵評估，當然開發人員花費在這四個方麵的成本是不同的，如圖I-1所示。用戶總是希望各方麵都得到滿足，但是畢竟預算有限，因此供應商決定綜閤的總成本，然後由市場來檢驗用戶的滿意度。 圖I-1 權衡衝突的開發優先級如何滿足這四個方麵基本上是一項市場決策。在一個既定市場給定價格下，市場支持者總是期望通過一個最佳營銷戰略來賺取他們的第一桶金。而成本最小化的關鍵在於軟件開發人員。這種開發成本的降低會直接影響産品市場競爭優勢的確立。這種優勢的價值將取決於特定的市場地位。因此，衡量軟件開發現狀的問題是：運用什麼樣的工具纔能有效降低成本且滿足這四個方麵的要求。 我們有各種各樣的軟件工具來幫助我們，如版本控製係統。我們也有大量的過程，從XP到正式方法。我們還有很多種軟件設計方式方法。我們有像RUP和CMM這樣的過程框架，還有匯編語言、集成開發環境（IDE）、度量係統、估計模型和其他各種各樣的工具。 我們有各種珍貴的數據，可以整理齣可用的方法、技術和實踐經驗，形成最佳的組閤。 一幫黑客宅在他們的臥室裏，經過數月消耗掉無數可樂和披薩後黑掉某一應用的日子一去不復返瞭。如果工作麵試時，你告訴招聘經理去年你總共寫瞭100KLOC，那你可以跟這份工作“拜拜”瞭。因為招聘經理都明白效率如此低下的原因是編寫的代碼最後都不可靠，並且是一堆無法維護的爛攤子。有效降低滿足這四個方麵的成本，需要的是有組織、有係統地進行軟件開發。 目前業界有太多口惠而不實的軟件工程。作為一門工程學科我們可能還需要走很長的路。軟件開發是一門藝術，盡管非常晦澀難懂。其精髓在於這是一個在給定環境下運用各種不同方法和工具的大雜燴，即一個協調統一的開發係統。除瞭提供這種集成係統的規則外，我們的“軟件工程”隻不過是“這裏有一個框架和一些可選擇的組閤。尋找正確的候選者並在特定開發環境中把它們恰當地組閤在一起，則是留給學生的練習。” 2.?什麼在起作用然而現實情況是，軟件開發的藝術在過去的半個世紀裏有瞭長足的發展。同樣數目的開發人員能夠在更短的時間內更高質量地完成更大規模的項目，因此我們更應該去做一些更有幫助的事情。其中棘手的問題是，如何弄清哪些事情是正確的。 早在1970年之前，人們就有基於幾十年實踐經驗總結的寶貴教訓。例如，曾幾何時FORTRAN的GOTO語句和COBOL的ALTER語句被視為處理復雜編程問題的強大工具，然而10年後，編程經理不再使用這些語句，因為使用這些功能的程序在需求變更時很難維護。 所有這些來之不易的教訓形成瞭開發者經驗的概念。當一個程序員犯過足夠多的錯誤並在錯誤中吸取瞭各種教訓後，他就會逐漸成長為軟件開發的行傢。遺憾的是，軟件開發人員總是會重新經曆這些錯誤，因為沒有一個關於這些軟件開發經驗教訓的係統總結或者統一標準。 20世紀60年代末，第三代編程語言中齣現瞭各種各樣的編程方法，軟件設計方法開始興起。早期，大傢隻是把一些經常犯的錯誤和實踐經驗公布於眾。不過，很快軟件專傢們開始將這些實踐經驗總結成係統的設計方法學。這些方法學在細節上各有不同但是很多特徵是有共同點的，所以它們都屬於結構化開發（Structured Development，SD）。因為它們是相當抽象的視圖——有關軟件設計的一張大圖，而且讀者會發現它能夠很方便地使用專門的錶示法。很多倡導者也很學術化，錶示法往往傾嚮於圖形化，這使集閤論和圖論中的理論約束也得以應用。 結構化開發是20世紀中期最簡單也是最重要的軟件開發成果。毫不誇張地說，它讓軟件開發擺脫瞭雜亂無章的狀態。除此之外，它是數據處理的增長動力，數據處理在20世紀80年代演變為重要的信息技術。在企業界，很多入門級的COBOL程序員艱難地做齣瞭大量的報錶，從而為日常的企業運行提供瞭前所未有的可視性。更好的是，這些報告通常相當準確。 當然，結構化開發在軟件開發的漫漫長路上僅是第一步。正如所預期的，它是新的，但不是萬能的，從20世紀70年代起它的一些缺陷就開始顯現瞭。隻有理解這些缺陷是什麼，纔能理解20世紀80年代麵嚮對象開發的發展原因和發展方式。用戶評價
說實話，我一直覺得軟件開發領域，尤其是在一些大型、復雜的項目中，存在著很大的“經驗主義”成分。很多時候，我們依靠的是開發者的直覺和過往的經驗來做決策，這雖然在小項目裏問題不大，但一旦項目規模上來，就會齣現各種難以預料的難題，比如需求變更難以控製，係統集成睏難重重，技術債務不斷積纍等等。這本書的書名“基於模型的軟件開發”，給瞭我一種全新的視角。它似乎在提倡一種更加“工程化”的開發方式，用明確的模型來約束和指導開發過程，減少不確定性。我猜想，這本書會強調“模型”作為軟件開發核心的地位，它不僅僅是圖紙，而是整個開發流程的驅動力。我希望書中能夠詳細闡述如何構建不同層次的模型，從高層次的業務模型到低層次的實現模型，以及這些模型之間是如何相互關聯、相互轉化的。我還對書中關於“模型驗證”和“模型轉換”的內容非常感興趣。如何確保模型能夠準確地反映業務需求，如何將模型有效地轉換為可執行的代碼，以及在模型發生變化時如何自動更新代碼，這些都是我亟待解決的問題。
评分最近幾年，隨著人工智能和大數據技術的飛速發展，軟件開發的復雜度也在不斷攀升。傳統的開發模式，在麵對如此龐雜的需求和技術挑戰時，顯得有些捉襟見肘。我一直在尋找一種能夠提升開發效率、保證軟件質量的“新範式”。“基於模型的軟件開發”這個書名，恰好觸動瞭我內心的期待。我猜測，這本書不僅僅是關於某個具體的模型工具或技術，而是關於一種全新的軟件開發哲學。它可能強調的是“以模型為中心”的設計和開發流程，將模型視為軟件的“靈魂”，而代碼隻是“軀殼”。我希望書中能夠深入探討模型在軟件生命周期各個階段的貫穿性作用，從最初的概念驗證，到詳細的設計，再到最後的部署和維護。我尤其對書中關於“模型復用”和“模型驅動的係統演化”的章節充滿好奇。如何在不同的項目之間共享模型？當業務需求發生變化時，如何通過修改模型來驅動整個係統的升級和演化，而不是進行大規模的重寫？這些都是我非常關心的問題。這本書的齣現，讓我看到瞭軟件開發走嚮更加智能化、自動化和可預測化的可能。
评分這本書的封麵設計就足夠吸引眼球瞭，深邃的藍色背景，簡潔而現代的字體，仿佛預示著這本書將帶領讀者進入一個嚴謹而充滿智慧的領域。我一直對軟件開發的理論性部分很感興趣，雖然我是一名從業多年的程序員，每天都在與代碼打交道，但總覺得在宏觀層麵，對軟件構建的本質缺乏更深刻的理解。這本書的書名“基於模型的軟件開發”，正是我一直以來尋找的方嚮。我期待它能提供一種係統性的方法論，讓我能夠跳齣日常編碼的細節，從更高層次去審視軟件的設計、構建和演進。我希望這本書不僅僅是堆砌理論，而是能夠提供清晰的邏輯框架，讓我理解模型在軟件開發生命周期中的作用，它如何指導我們進行需求分析、架構設計，甚至是後期的維護和演化。尤其是模型驅動開發（MDD）和模型驅動架構（MDA）等概念，我一直覺得它們是軟件工程領域非常有潛力的方嚮，但相關的實踐和落地案例往往比較零散。我希望這本書能在這方麵提供一些詳實的指導，讓我能夠理解如何將模型有效地轉化為可執行的代碼，以及在實際項目中如何評估和選擇閤適的模型驅動方法。同時，我也對書中的案例分析部分充滿期待，理論的學習離不開實踐的支撐，希望通過真實的案例，我能夠更好地理解書中提齣的概念和方法。
评分最近在技術社區裏，聽瞭不少關於“軟件架構演進”的討論，也看到很多文章在談論“領域驅動設計”（DDD）和“微服務”的結閤。雖然這些話題聽起來很吸引人，但總感覺缺少一個貫穿始終的、更底層的原理來指導。這本書的齣現，似乎正是填補瞭這一空白。“基於模型的軟件開發”這個名字，讓我聯想到一種更加規範、更加可預測的開發方式。我猜想，這本書可能會探討如何將業務需求、係統設計等抽象概念，用一種標準化的“模型”來錶示，然後通過對這些模型的操作，自動生成代碼，或者至少是輔助代碼的生成。這聽起來有點像“所見即所得”的開發模式，但又更加側重於軟件的內在邏輯和結構。我特彆好奇，書中會如何處理模型與代碼之間的映射關係，以及如何保證這種映射的正確性和效率。另外，在快速迭代的敏捷開發環境中，如何有效地運用基於模型的開發方法，避免模型本身的更新滯後於業務需求的變化，也是我非常關心的問題。我希望這本書能提供一些切實可行的策略，讓我能夠將模型的力量融入到敏捷的開發流程中，實現更高效、更健壯的軟件構建。
评分作為一個在軟件行業摸爬滾打多年的老兵，我見過太多的項目因為溝通不暢、需求模糊而最終走嚮失敗。團隊成員之間對需求的理解存在偏差，是導緻這些問題的重要原因之一。這本書的書名“基於模型的軟件開發”，讓我眼前一亮。我猜測，它可能提供瞭一種解決上述問題的有效途徑。通過構建清晰、標準的模型，可以作為團隊成員之間溝通的“共同語言”，確保大傢對軟件的各個方麵都有統一的認識。我特彆期待書中能夠深入探討模型在需求獲取和溝通環節中的作用。它是否能幫助我們更早地發現需求的遺漏和衝突？是否能讓非技術人員也能夠理解和參與到軟件的設計過程中？我還對模型在代碼生成和自動化測試方麵的應用很感興趣。如果模型能夠直接驅動代碼的生成，那麼開發效率是否會得到極大的提升？如果模型本身就可以作為測試用例的來源，那麼軟件的質量是否會更有保障？這本書的名字給我一種“規範、嚴謹、高效”的感覺，我希望它能夠真正地為軟件開發的實踐帶來一些革命性的改變。
評分ok
評分看不懂。。
評分好，東東不錯，快遞給力，好評！
評分ok
評分好
評分ok
評分ok
評分ok
評分我基本不評價，實在生氣！拿到公司去報銷，公司說是盜版的，掃碼都掃不上，看來傳說中的某東賣假貨是真的啊！
相關圖書
本站所有內容均為互聯網搜尋引擎提供的公開搜索信息，本站不存儲任何數據與內容，任何內容與數據均與本站無關，如有需要請聯繫相關搜索引擎包括但不限於百度，google,bing,sogou 等
© 2025 book.qciss.net All Rights Reserved. 圖書大百科 版權所有