UML 狀態機的問題，透過圖書和論文來找解法和答案更準確安心。 我們找到下列特價商品、必買資訊和推薦清單

分析模式：可複用的物件模型

為了解決UML 狀態機的問題，作者（美）馬丁·福勒 這樣論述：

要開發複雜的企業應用，先要為業務領域建立準確而深刻的分析模型。本書不是通過簡化的案例講述抽象的理論，而是直接給出來自真實專案的複雜模型，並以“模式”的方式進行歸納。本書不僅包括這些模式本身，還體現了作者豐富的實踐經驗和對建模技術的深入洞見。 本書主要包括兩部分：第一部分介紹來自人員與組織管理、觀察與測量、存貨與會計、計畫、金融衍生品交易等多個業務領域的“分析模式”；第二部分則給出一系列“支援模式”，用於將分析模型實現為具體的軟體。 具有一定經驗的架構師、業務分析師以及高級開發人員通過研讀本書可以很快將書中的模式和思路應用於實踐，有效提高開發水準。軟體發展的入門者閱讀本書儘管未必能立刻領悟其全

部內涵，但也足以打開一扇通向新境界的窗戶，為日後的提高奠定基礎。 馬丁·福勒（Martin Fowler） 世界軟體發展大師，ThoughtWorks首席科學家。他是一位作家、演說者、諮詢師和泛軟體發展領域的意見領袖。他致力於改善企業級的軟體設計，對優秀的設計以及支撐優秀設計的工程實踐孜孜以求。他在重構、物件導向分析設計、模式、XP和UML等領域都有卓越貢獻，著有《重構：改善既有代碼的設計》《分析模式：可複用的物件模型》《領域特定語言》《企業應用架構模式》等經典著作。 第1章 緒論 1 1.1 概念模型 1 1.2 模式的世界 4 1.3 本書中的模式

7 1.4 概念模型與業務過程再造 9 1.5 模式和框架 9 1.6 模式的使用 10 參考文獻 12 第一部分　分析模式 第2章 責任 15 2.1 參與方（Party）模式 16 2.2 組織層級（Organization Hierarchies）模式 17 2.3 組織結構（Organization Structure）模式 18 2.4 責任（Accountability）模式 20 2.5 責任知識層（Accountability Knowledge Level）模式 21 2.6 參與方類型泛化（Party Type Generalizations）模式 23 2.7 分層責

任（Hierarchic Accountability）模式 24 2.8 運作範圍（Operating Scopes）模式 26 2.9 崗位（Post）模式 27 參考文獻 28 第3章 觀察和測量 29 3.1 數量（Quantity）模式 30 3.2 換算率（Conversion Ratio）模式 31 3.3 複合單位（Compound Units）模式 32 3.4 測量（Measurement）模式 34 3.5 觀察（Observation）模式 35 3.6 子類型化觀察概念（Subtyping Observation Concepts）模式 38 3.7 規程（Proto

col）模式 38 3.8 雙重時間記錄（Dual Time Record）模式 39 3.9 被否決觀察（Rejected Observation）模式 40 3.10 有效觀察、假定和推測（Active Observation, Hypothesis, and Projection）模式 40 3.11 關聯觀察（Associated Observation）模式 41 3.12 觀察過程（Process of Observation）模式 42 參考文獻 45 第4章 在企業財務領域使用觀察模式 46 4.1 企業片段（Enterprise Segment）模式 47 4.2 測量規程（

Measurement Protocol）模式 53 4.3 範圍（Range）模式 61 4.4 有範圍現象（Phenomenon with Range）模式 62 4.5 使用結果框架（Using the Resulting Framework）模式 66 參考文獻 67 第5章 引用對象 68 5.1 名稱（Name）模式 69 5.2 標識方案（Identification Scheme）模式 70 5.3 物件合併（Object Merge）模式 72 5.4 物件等價關係（Object Equivalence）模式 74 參考文獻 75 第6章 存貨和會計 76 6.1 帳戶（Ac

count）模式 78 6.2 會計事項（Transactions）模式 79 6.3 匯總帳戶（Summary Account）模式 81 6.4 備忘帳戶（Memo Account）模式 83 6.5 過帳規則（Posting Rules）模式 84 6.6 單實例方法（Individual Instance Method）模式 85 6.7 過帳規則執行（Posting Rule Execution）模式 90 6.8 多帳戶過帳規則（Posting Rules for Many Accounts）模式 94 6.9 選擇分錄（Choosing Entries）模式 96 6.10 會計

實務（Accounting Practice）模式 97 6.11 分錄來源（Sources of an Entry）模式 99 6.12 資產負債表和損益表（Balance Sheet and Income Statement）模式 99 6.13 對應帳戶（Corresponding Account）模式 100 6.14 特化帳戶模型（Specialized Account Model）模式 101 6.15 將分錄記錄到多個帳戶（Booking Entries to Multiple Accounts）模式 103 擴展閱讀 106 參考文獻 107 第7章 使用會計模型 108 7.

1 結構模型 109 7.2 實現該結構 111 7.3 新建電話服務 113 7.4 建立通話 115 7.5 實現基於帳戶的觸發 116 7.6 劃分日間和夜間通話 117 7.7 按時間收費 119 7.8 計稅 122 7.9 結論和思考 123 參考文獻 127 第8章 計畫 128 8.1 提議活動和已實施活動（Proposed and Implemented Action）模式 129 8.2 已完成活動和已放棄活動（Completed and Abandoned Actions）模式 130 8.3 暫停（Suspension）模式 131 8.4 計畫（Plan）模式 132

8.5 規程（Protocol）模式 134 8.6 資源配置（Resource Allocation）模式 137 8.7 結果函數和啟動函數（Outcome and Start Functions）模式 140 參考文獻 142 第9章 交易 143 9.1 合同（Contract）模式 143 9.2 組合（Portfolio）模式 147 9.3 報價（Quote）模式 150 9.4 場景（Scenario）模式 153 參考文獻 160 第10章 衍生合同 161 10.1 遠期合同（Forward Contracts）模式 162 10.2 期權（Options）模式 163

10.3 產品（Product）模式 168 10.4 子類型狀態機（Subtype State Machines）模式 172 10.5 並列的應用和領域層級結構（Parallel Application and Domain Hierarchies）模式 177 參考文獻 182 第11章 交易包 183 11.1 包的多重訪問級別（Multiple Access Levels to a Package）模式 183 11.2 相互可見性（Mutual Visibility）模式 186 11.3 包的子類型化（Subtyping Packages）模式 189 11.4 結論和思考 19

0 參考文獻 190 第二部分　支援模式 第12章 資訊系統分層架構 193 12.1 兩層架構（Two-Tier Architecture）模式 194 12.2 三層架構（Three-Tier Architecture）模式 195 12.3 展示層和應用邏輯層（Presentation and Application Logic）模式 198 12.4 資料庫交互（Database Interaction）模式 203 12.5 結論和思考 206 參考文獻 206 第13章 應用門面 208 13.1 一個醫療衛生領域的例子 208 13.2 門面的內容 209 13.3 通用方法

213 13.4 操作 213 13.5 類型轉換 214 13.6 多個門面 216 參考文獻 217 第14章 類型模型設計範本模式 218 14.1 實現關聯（Implementing Associations）模式 220 14.2 實現泛化（Implementing Generalization）模式 226 14.3 物件創建（Object Creation）模式 232 14.4 物件銷毀（Object Destruction）模式 233 14.5 入口點（Entry Point）模式 234 14.6 實現約束（Implementing Constraints）模式 236

14.7 其他技術的設計範本 237 參考文獻 238 第15章 關聯模式 239 15.1 關聯類型（Associative Type）模式 240 15.2 鍵控映射（Keyed Mapping）模式 242 15.3 歷史映射（Historic Mapping）模式 243 參考文獻 247 第16章 後記 248 參考文獻 249 附錄A 技術和標記法 250 A.1 類型圖 250 A.2 交互圖 259 A.3 事件圖 260 A.4 狀態圖 261 A.5 包圖 262 參考文獻 263 附錄B 模式一覽表 265

面向對象是怎樣工作的（第2版）

為了解決UML 狀態機的問題，作者（日）平澤章 這樣論述：

本書以圖配文的形式，直觀易懂地詳細介紹了物件導向的全貌及其中包含的各項技術，包括物件導向程式設計、框架、設計模式、UML、建模、物件導向設計和敏捷開發等。對於各項技術是如何使用的（How），書中只進行最小限度的說明，而重點介紹這些技術究竟是什麼樣的（What）以及為什麼需要這些技術（Why）。另外，書中設有“程式設計往事”專欄，介紹了作者年輕時的一些經歷；還設有“物件的另一面”專欄，以與正文不同的視角講解物件導向這一概念普及的背景和原因，通俗有趣。 平澤章 就職於UL System株式會社，多次參與面向大型金融機構的第三次線上系統的開發等系統開發工作，後負責技術諮詢業務，2

001年轉為現在的職務。著有《UML建模教程》，是Working Effectively With Legacy Code、Refactoring: Improving the Design of Existing Code日文版譯者之一。 侯振龍（譯者） 管理科學與工程專業碩士，日語一級，軟體發展工程師，具有十年以上對日軟體發展經驗，現就職於某日本獨資企業。 第1章 物件導向：讓軟體發展變輕鬆的技術 1 1.1　物件導向是軟體發展的綜合技術 3 1.2　以物件為中心編寫軟體的開發方法 4 1.3　從程式設計語言演化為綜合技術 4 1.4　在混亂的狀態下去理解，就會覺得很

難 5 1.5　混亂之一：術語洪流 6 1.6　混亂之二：比喻濫用 7 1.7　混亂之三：“一切都是對象”綜合征 8 1.8　三種混亂增大了理解的難度 9 1.9　因為不理解，所以才感覺神秘 10 1.10　消除這三種混亂，就能看到物件導向的真面目 10 1.11　本書的構成 11 第2章 似是而非：物件導向與現實世界 13 2.1　如果只理解概念，就容易混亂 15 2.2　對照現實世界介紹物件導向 15 2.3　類指類型，實例指具體的物 16 2.4　多態讓消息的發送方法通用 18 2.5　繼承對共同點和不同點進行系統的分類和整理 20 2.6　物件導向和現實世界是似是而非的 22 2.7

　現實世界的人和物不是由類創建的 23 2.8　現實世界的人和物並不只是根據消息來行動 24 2.9　明確定義為程式設計結構 25 2.10　軟體並不會直接表示現實世界 25 2.11　與現實世界的相似擴大了可能性 26 專欄 對象的另一面 成為潮詞的物件導向 27 第3章 理解OOP：程式設計語言的歷史 29 3.1　OOP的出現具有必然性 31 3.2　最初使用機器語言編寫程式 31 3.3　程式設計語言的第一步是組合語言 32 3.4　高階語言的發明使程式更加接近人類 33 3.5　重視易懂性的結構化程式設計 34 3.6　提高副程式的獨立性，強化可維護性 35 3.7　實現無GOTO

程式設計的結構化語言 38 3.8　進化方向演變為重視可維護性和再使用性 39 3.9　沒有解決全域變數問題和再使用性差的問題 41 專欄 程式設計往事 COBOL編譯器的雞和蛋的問題 45 第4章 物件導向程式設計技術：去除冗餘、進行整理 47 4.1　OOP具有結構化語言所沒有的三種結構 49 4.2　OOP的結構會根據程式設計語言的不同而略有差異 51 4.3　三大要素之一：類具有的三種功能 51 4.4　類的功能之一：匯總 52 4.5　類的功能之二：隱藏 55 4.6　類的功能之三：創建很多個 58 4.7　執行個體變數是限定訪問範圍的全域變數 61 4.8　三大要素之二：實現調用

端公用化的多態 63 4.9　三大要素之三：去除類的重複定義的繼承 67 4.10　對三大要素的總結 70 4.11　通過嵌入類型使程式師的工作變輕鬆 71 4.12　將類作為類型使用 72 4.13　程式設計語言“退化”了嗎 74 4.14　更先進的OOP結構 74 4.15　進化的OOP結構之一：包 75 4.16　進化的OOP結構之二：異常 76 4.17　進化的OOP結構之三：垃圾回收 78 4.18　對OOP進化的總結 80 4.19　決心決定OOP的生死 81 第5章 理解記憶體結構：程式師的基本素養 83 5.1　理解OOP程式的運行機制 85 5.2　兩種運行方式：編譯器與解

譯器 85 5.3　解釋、運行中間代碼的虛擬機器 88 5.4　CPU同時運行多個執行緒 89 5.5　使用靜態區、堆區和棧區進行管理 91 5.6　OOP的特徵在於記憶體的用法 94 5.7　每個類只載入一個類資訊 95 5.8　每次創建實例都會使用堆區 96 5.9　在變數中存儲實例的指標 97 5.10　複製存儲實例的變數時要多加注意 99 5.11　多態讓不同的類看起來一樣 103 5.12　根據繼承的資訊類型的不同，記憶體配置也不同 105 5.13　孤立的實例由垃圾回收處理 107 專欄 程式設計往事 OOP中dump看起來很費勁？ 113 第6章 重用：OOP帶來的軟體重用和思

想重用 115 6.1　OOP的優秀結構能夠促進重用 117 6.2　類庫是OOP的軟體構件群 119 6.3　標準類庫是語言規範的一部分 120 6.4　將Object類作為祖先類的繼承結構 121 6.5　框架存在各種含義 122 6.6　框架是應用程式的半成品 123 6.7　世界上可重用的軟體構件群 124 6.8　獨立性較高的構件：組件 125 6.9　設計模式是優秀的設計思想集 125 6.10　設計模式是類庫探險的路標 128 6.11　擴展到各個領域的思想的重用 129 6.12　通過類庫和模式發現的重用的好處 130 第7章 化為通用的歸納整理法的物件導向 133 7.1　

軟體不會直接表示現實世界 135 7.2　應用於集合論和職責分配 137 7.3　在上流工程中化為通用的歸納整理法 139 7.4　兩種含義引起混亂 140 7.5　分為OOP的擴展和歸納整理法進行思考 141 7.6　為何化為了通用的歸納整理法 142 專欄 對象的另一面 語言在先，還是概念在先 143 第8章 UML：查看無形軟體的工具 145 8.1　UML是表示軟體功能和結構的圖形的繪製方法 147 8.2　UML有13種圖形 148 8.3　UML的使用方法大致分為三種 150 8.4　UML的使用方法之一：表示程式結構和動作 151 8.5　類圖表示OOP程式的結構 151 8.

6　使用時序圖和通信圖表示動作 154 8.7　UML的使用方法之二：表示歸納整理法的成果 156 8.8　使用類圖表示根據集合論進行整理的結果 157 8.9　表示職責分配的時序圖和通信圖 160 8.10　UML的使用方法之三：表示非物件導向 163 8.11　使用用例圖表示交給電腦的工作 163 8.12　使用活動圖表示工作流程 164 8.13　使用狀態機圖表示狀態的變化 165 8.14　彌補自然語言和電腦語言缺點的“語言” 166 第9章 建模：填補現實世界和軟體之間的溝壑 171 9.1　現實世界和軟體之間存在溝壑 173 9.2　電腦擅長固定工作和記憶工作 174 9.3　通

過業務分析、需求定義和設計來填補溝壑 175 9.4　建模是順利推進這3個階段的工作的技術 176 9.5　應用程式不同，建模的內容也不一樣 177 9.6　業務應用程式記錄現實中的事情 178 9.7　對圖書館的借閱業務進行建模 179 9.8　使用用例圖來表示圖書館業務 181 9.9　用概念模型表示圖書館系統的資訊 183 9.10　業務應用程式中只有資料是無縫的 184 9.11　嵌入式軟體替換現實世界的工作 186 9.12　嵌入式軟體中設備的研究開發很重要 187 9.13　使用狀態機圖來表示全自動工作的情形 189 9.14　嵌入式軟體一直執行單調的工作 190 9.15　建模蘊

含著軟體發展的樂趣 191 第10章 物件導向設計：擬人化和職責分配 195 10.1　設計的目標範圍很廣 197 10.2　相比運行效率，現在更重視可維護性和再使用性 198 10.3　設計目標之一：去除重複 199 10.4　設計目標之二：提高構件的獨立性 200 10.5　提高構件獨立性的訣竅 202 10.6　設計目標之三：避免依賴關係發生迴圈 203 10.7　物件導向設計的“感覺”是擬人化和職責分配 205 10.8　進行了職責分配的軟體創建的奇妙世界 206 第11章 衍生：敏捷開發和TDD 211 11.1　僅靠技術和技術竅門，軟體發展並不會成功 213 11.2　系統地匯

總了作業步驟和成果的開發流程 214 11.3　限制修改的瀑布式開發流程 214 11.4　瀑布式開發流程的極限 215 11.5　靈活回應變化的反覆運算式開發流程 216 11.6　RUP按時間分解和管理開發 217 11.7　打破諸多限制的XP 219 11.8　快速編寫優秀軟體的敏捷宣言 221 11.9　支援敏捷開發的實踐 222 11.10　先編寫測試代碼，一邊運行一邊開發的測試驅動開發 222 11.11　在程式完成後改善運行代碼的重構 224 11.12　經常進行系統整合的持續集成 225 11.13　敏捷開發和TDD源於物件導向 226 11.14　不存在最好的開發流程 227

專欄 程式設計往事 過去不被允許的XP 231 第12章 熟練掌握物件導向 233 12.1　物件導向這一強大概念是原動力 235 12.2　時代追上了物件導向 236 12.3　物件導向的熱潮不會結束 237 12.4　將物件導向作為工具熟練掌握 238 12.5　享受需要動腦的軟體發展 239 第13章 函數式語言是怎樣工作的 241 13.1　物件導向的“下一代”開發技術 243 13.2　函數式語言的7個特徵 244 13.3　特徵1：使用函數編寫程式 244 13.4　特徵2：所有運算式都返回值 246 13.5　特徵3：將函數作為值進行處理 250 13.6　特徵4：可以靈活

組合函數和參數 252 13.7　特徵5：沒有副作用 256 13.8　特徵6：使用分類和遞迴來編寫迴圈處理 261 13.9　特徵7：編譯器自動進行類型推斷 266 13.10　對7個特徵的總結 270 13.11　函數式語言的分類 271 13.12　函數式語言的優勢 271 13.13　函數式語言的課題 272 13.14　函數式語言和物件導向的關係 273 13.15　函數式語言會普及嗎 275 後記 279 致謝 280  

動物醫院管理資訊系統之前台系統研發

為了解決UML 狀態機的問題，作者趙偉鈞 這樣論述：

近年來，隨著社會結構的改變，寵物已成為人們的夥伴，甚至如同家人一般的重要，因此動物醫院也大量增加。但是動物醫院的工作繁雜，不同種類的動物有著不同的習性與身體構造，診療的方式也不盡相同，所以需要動物醫院管理資訊系統來輔助。本研究以某一動物醫院管理資訊系統為例，針對實際使用後發現的缺點加以改良，重新開發其前台系統。現有動物醫院管理資訊系統功能繁多，對中小型的動物醫院來說反而造成操作負荷，且受硬體系統更新的影響，原設計的操作畫面過小。此外其病歷表採純文字輸入，檢視診療圖片時須切換頁面相當不便。因此本研究致力於改善這些現存缺點，主要的改善包括：(一)自動分類排序的掛號看診功能、(二)寵物病歷表的新舊

病歷自動連結、(三)寵物病歷中圖文整合等。透過本研究完成開發一套適合中小型動物醫院的前台系統，此系統具有更好操作、更高效率、更合用以及較低成本的特性。