瀏覽紀錄

TOP
1/1
無庫存,下單後進貨(採購期約45個工作天)
大象:Thinking in UML(第二版)(簡體書)
人民幣定價:68元
定  價:NT$408元
優惠價: 87355
可得紅利積點:10 點

無庫存,下單後進貨(採購期約45個工作天)

商品簡介

作者簡介

名人/編輯推薦

目次

書摘/試閱

《大象:Thinking in UML(第2版)》以UML為載體,將面向對象的分析設計思想巧妙地融入建模過程中,通過貫穿全書的實例將軟件系統開發過程中方方面面的知識有機地結合在一起,用生動的語言和精彩的事例將復雜枯燥的軟件過程講解得津津有味。
  全書分為四個部分。第一部分講述面向對象分析的一些基本概念,及學習建模需要了解的一些基本知識。第二部分對UML的基礎概念重新組織和歸納整理,進行擴展和討論,引申出針對UML的這些概念在面向對象方法中應用方法的思考。第三部分以一個實例貫穿全篇,闡述如何使用UML從頭到尾地實施一個項目。第四部分針對在現實中經常遇到并且較難掌握的問題進行深入的探討,升華在前幾篇學習到的知識。
  《大象:Thinking in UML(第2版)》可供正在學習編程、軟件工程等知識,準備將來從事IT行業的讀者、正努力向設計師或系統分析員轉變的技術人員及期望對軟件分析設計更上一層樓的設計人員學習和提高之用。
譚云杰,CSDN專家博客coffeewoo博主。資深架構師,PMP獲得者,擅長于系統建模和系統分析設計。從事過電力、政府、航空等多個行業的管理軟件開發工作和工作流中間件產品的研發工作,擁有十多個軟件項目的分析設計經驗和架構設計經驗,其中不乏中型和大型軟件項目。目前就職于某著名跨國軟件企業中國研發中心,從事產品研發工作。
  作者使用UML進行系統分析建模至今已十年有余,對系統建模、分析和設計有深刻而獨道的見解。在其博客上發表的OO系統分析員之路系列文章短短時間內便獲得了十幾萬的點擊量,深受讀者的喜愛。
2012最震撼本土原創!
  這是一本講軟件的分析、設計與建模的書
  這是一本將晦澀的概念與項目的實踐緊密結合的書
  這是一本讓您與似是而非的感覺做個了斷的書
  這是一本充滿思想與智慧的書
  ……
  字字珠璣,醍醐灌頂
  從來沒有一本書,帶給軟件開發人員如此醍醐灌頂的感受。
  軟件江湖盛傳的“UML第一書”,開發人員夢寐以求的“九陽真經”,真正助您打通軟件開發“任督二脈”。
  萬眾矚目的《大象——Thinking in UML》(第二版),大陸和臺灣地區同步重磅推出。
  面對眼花繚亂的軟件開發新技術,是選擇繼續疲于應付?還是畢其功于一役?
  CSDN超級名博Coffeewoo 之12年軟件分析設計與建模純甘經驗分享。
大象希形
再版序
寫給讀者的話
關于本書
如何閱讀本書
免費下載資源使用說明
Part I 你需要了解
第1章 為什么需要UML
1.1 面向過程還是面向對象
1.1.1 面向過程方法
1.1.2 面向過程的困難
1.1.3 面向對象方法
1.1.4 面向對象的困難
1.2 UML帶來了什么
1.2.1 什么是UML
1.2.2 統一語言
1.2.3 可視化
1.2.4 從現實世界到業務模型
1.2.5 從業務模型到概念模型
1.2.6 從概念模型到設計模型
1.2.7 面向對象的困難解決了嗎
1.3 統一過程簡介
1.3.1 RUP是什么
1.3.2 RUP與UML
1.3.3 RUP與軟件工程
1.3.4 RUP與最佳實踐
1.3.5 RUP與本書
第2章 建模基礎
2.1 建模
2.2 用例驅動
2.3 抽象層次
2.4 視圖
2.5 對象分析方法

Part II 在學習中思考
第3章 UML核心元素
3.1 版型
3.2 參與者
3.2.1 基本概念
3.2.2 發現參與者
3.2.3 業務主角
3.2.4 業務工人
3.2.5 參與者與涉眾的關系
3.2.6 參與者與用戶的關系
3.2.7 參與者與角色的關系
3.2.8 參與者的核心地位
3.2.9 檢查點
3.3 用例
3.3.1 基本概念
3.3.2 用例的特征
3.3.3 用例的粒度
3.3.4 用例的獲得
3.3.5 用例和功能的誤區
3.3.6 目標和步驟的誤區
3.3.7 用例粒度的誤區
3.3.8 業務用例
3.3.9 業務用例實現
3.3.10 概念用例
3.3.11 系統用例
3.3.12 用例實現
3.4 邊界
3.4.1 邊界決定視界
3.4.2 邊界決定抽象層次
3.4.3 靈活使用邊界
3.5 業務實體
3.5.1 業務實體的屬性
3.5.2 業務實體的方法
3.5.3 獲取業務實體
3.6 包
3.7 分析類
3.7.1 邊界類
3.7.2 控制類
3.7.3 實體類
3.7.4 分析類的三高
3.8 設計類
3.8.1 類
3.8.2 屬性
3.8.3 方法
3.8.4 可見性
3.9 關系
3.9.1 關聯關系(association)
3.9.2 依賴關系(dependency)
3.9.3 擴展關系(extends)
3.9.4 包含關系(include)
3.9.5 實現關系(realize)
3.9.6 精化關系(refine)
3.9.7 泛化關系(generalization)
3.9.8 聚合關系(aggregation)
3.9.9 組合關系(composition)
3.10 組件
3.10.1 完備性
3.10.2 獨立性
3.10.3 邏輯性
3.10.4 透明性
3.10.5 使用組件
3.11 節點
3.11.1 分布式應用環境
3.11.2 多設備應用環境
第4章 UML核心視圖
4.1 靜態視圖
4.1.1 用例圖
4.1.2 類圖
4.1.3 包圖
4.2 動態視圖
4.2.1 活動圖
4.2.2 狀態圖
4.2.3 時序圖
4.2.4 協作圖
第5章 UML核心模型
5.1 用例模型概述
5.2 業務用例模型
5.2.1 業務用例模型主要內容
5.2.2 業務用例模型工件的取舍
5.2.3 何時使用業務用例模型
5.3 概念用例模型
5.3.1 概念用例模型的主要內容
5.3.2 獲得概念用例
5.3.3 何時使用概念用例模型
5.4 系統用例模型
5.4.1 系統用例模型的主要內容
5.4.2 獲得系統用例
5.5 領域模型
5.5.1 讀者須知
5.5.2 基本概念
5.5.3 領域模型的主要內容
5.6 分析模型
5.6.1 如何使用分析模型
5.6.2 分析模型的主要內容
5.6.3 分析模型的意義
5.7 軟件架構和框架
5.7.1 軟件架構
5.7.2 軟件框架
5.7.3 何時使用架構和框架
5.8 設計模型
5.8.1 設計模型的應用場合
5.8.2 設計模型的主要內容
5.8.3 從分析模型映射到設計模型
5.9 組件模型
5.9.1 何時使用組件模型
5.9.2 廣義組件的用法
5.10 實施模型何時使用實施模型
第6章 統一過程核心工作流簡介
6.1 業務建模工作流程
6.1.1 工作流程
6.1.2 活動集和工件集
6.1.3 業務建模的目標和場景
6.2 系統建模工作流程
6.2.1 工作流程
6.2.2 活動集和工件集
6.2.3 系統建模的目標
6.3 分析設計建模工作流程
6.3.1 工作流程
6.3.2 活動集和工件集
6.3.3 分析設計的目標
6.3.4 推薦的分析設計工作流程簡介
6.4 實施建模工作流程
6.4.1 工作流程
6.4.2 活動集和工件集
6.4.3 推薦的實施建模工作流程
第7章 迭代式軟件生命周期

Part III 在實踐中思考
第8章 準備工作
8.1 案例說明
8.2 了解問題領域
8.2.1 了解業務概況
8.2.2 整理業務目標
8.3 做好涉眾分析
8.3.1 什么是涉眾
8.3.2 發現和定義涉眾
8.3.3 涉眾分析報告
8.4 規劃業務范圍
8.4.1 規劃業務目標
8.4.2 規劃涉眾期望
8.5 整理好你的思路
8.5.1 劃分優先級
8.5.2 規劃需求層次
8.5.3 需求調研計劃
8.6 客戶訪談技巧
8.6.1 溝通的困難
8.6.2 溝通技巧
8.7 提給讀者的問題
第9章 獲取需求
9.1 定義邊界
9.1.1 盤古開天--從混沌走向清晰
9.1.2 現在行動:定義邊界
9.1.3 進一步討論
9.1.4 提給讀者的問題
9.2 發現主角
9.2.1 女媧造人--誰來掌管這個世界
9.2.2 現在行動:發現主角
9.2.3 進一步討論
9.2.4 提給讀者的問題
9.3 獲取業務用例
9.3.1 炎黃之治--從愚昧走向文明
9.3.2 現在行動:獲取業務用例
9.3.3 進一步討論
9.3.4 提給讀者的問題
9.4 業務建模
9.4.1 商鞅變法--強盛的必由之路
9.4.2 現在行動:建立業務模型
9.4.3 進一步討論
9.4.4 提給讀者的問題
9.5 領域建模
9.5.1 風火水土--尋找構成世界的基本元素
9.5.2 現在行動:建立領域模型
9.5.3 進一步討論
9.5.4 提給讀者的問題
9.6 提煉業務規則
9.6.1 牛頓的思考--揭穿蘋果的秘密
9.6.2 現在行動:提煉業務規則
9.6.3 進一步討論
9.6.4 提給讀者的問題
9.7 獲取非功能性需求
9.7.1 非物質需求--精神文明是不可缺少的
9.7.2 現在行動:獲取非功能性需求
9.7.3 進一步討論
9.7.4 提給讀者的問題
9.8 主要成果物提給讀者的問題
第10章 需求分析
10.1 關鍵概念分析
10.1.1 阿基米德杠桿--找到撬動地球的支點
10.1.2 現在行動:建立概念模型
10.1.3 進一步討論
10.1.4 提給讀者的問題
10.2 業務架構
10.2.1 拼圖游戲--我們也想造個世界
10.2.2 現在行動:建立業務架構
10.2.3 進一步討論
10.2.4 提給讀者的問題
10.3 系統原型
第11章 系統分析
11.1 確定系統用例
11.1.1 開始規劃--確定新世界的萬物
11.1.2 現在行動:確定系統用例
11.1.3 現在行動:描述系統用例
11.1.4 進一步討論
11.1.5 提給讀者的問題
11.2 分析業務規則
11.2.1 設定規則--沒有規矩不成方圓
11.2.2 現在行動:分析業務規則
11.2.3 提給讀者的問題
11.3 用例實現
11.3.1 繪制藍圖--世界將這樣運行
11.3.2 現在行動:實現用例
11.3.3 進一步討論
11.3.4 提給讀者的問題
11.4 軟件架構和框架
11.4.1 設計架構--新世界的骨架
11.4.2 什么是軟件架構
11.4.3 什么是軟件框架
11.4.4 軟件架構的基本構成
11.4.5 應用軟件架構
11.4.6 提給讀者的問題
11.5 分析模型
11.5.1 設計功能零件--讓世界初步運轉起來
11.5.2 現在行動:建立分析模型
11.5.3 進一步討論
11.5.4 提給讀者的問題
11.6 組件模型
11.6.1 設計功能部件--構建世界的基礎設施
11.6.2 現在行動:建立組件模型
11.6.3 進一步討論
11.6.4 提給讀者的問題
11.7 部署模型
11.7.1 安裝零部件--組裝一個新世界
11.7.2 現在行動:建立部署模型
11.7.3 提給讀者的問題
第12章 系統設計
12.1 系統分析與系統設計的差別
12.2 設計模型
12.2.1 按圖索驥--為新世界添磚加瓦
12.2.2 現在行動:將分析模型映射到設計模型
12.2.3 進一步討論
12.2.4 提給讀者的問題
12.3 接口設計
12.3.1 暢通無阻--構建四通八達的神經網絡
12.3.2 現在行動:設計接口
12.3.3 進一步討論
12.3.4 提給讀者的問題
12.4 包設計
12.4.1 分工合作--組織有序世界才能更好
12.4.2 現在行動:設計包
12.4.3 進一步討論
12.5 提給讀者的問題
第13章 數據庫設計
13.1 關公戰秦瓊--面向對象與關系模型之爭
13.2 相輔相成--面向對象的數據庫設計
13.3 平衡的藝術--數據庫設計的方法和策略
13.3.1 OR-Mapping策略
13.3.2 對象-關系平衡策略
13.4 進一步討論--數據庫設計到底有多重要
第14章 開發
14.1 生成代碼
14.1.1 現在行動:生成代碼
14.1.2 進一步討論
14.2 分工策略
14.2.1 縱向分工策略
14.2.2 橫向分工策略
14.2.3 選擇適合你的開發分工策略

Part IV 在提煉中思考
第15章 測試
15.1 質量保證--新世界需要穩健運行
15.2 設計和開發測試例
15.3 提給讀者的問題
第16章 理解用例的本質
16.1 用例是系統思維
16.2 用例是面向服務的
16.3 善用用例方法
第17章 理解用例驅動
17.1 用例與項目管理
17.2 用例與可擴展架構
第18章 用例驅動與領域驅動
18.1 用例驅動與領域驅動的差異
18.2 領域驅動的理想與現實
18.3 如何決定是否采用領域驅動方法
第19章 理解建模的抽象層次
19.1 再討論抽象層次
19.1.1 層次高低問題
19.1.2 層次不交叉問題
19.2 如何決定抽象層次
19.3 抽象層次與UML建模的關系
第20章 劃分子系統的問題
20.1 面向對象的子系統問題
20.2 UC矩陣還適用嗎
20.3 如何劃分子系統
第21章 學會使用系統邊界
21.1 邊界是面向對象的保障
21.2 利用邊界來分析需求
21.2.1 邊界分析示例一
21.2.2 邊界分析示例二
21.3 邊界意識決定設計好壞
第22章 學會從接口認知事物
22.1 怎樣描述一件事物
22.2 接口是系統的靈魂
第23章 學會正確選擇
23.1 屁股決定腦袋--學會綜合權衡
23.2 理辯則明--學會改變視角
第24章 學會使用設計模式
24.1 如何學習設計模式
24.2 如何使用設計模式
附錄 UML視圖常用元素參考
圖目錄
表目錄
後記
大象希形
  ■可遇而不可求
  中國象棋,只有32棵棋子,規則簡單,但水平高低之間,不在于是否掌握了馬走日象走田。正如UML,簡單說只有元素、視圖與模型,但水平高低之間,絕不在于誰能在視圖之上畫出各種元素堆積的模型,而是在于誰能夠借助UML提供的這些工具,靈活自如地為復雜項目的開發提供一個成熟的、統一的、系統的、廣泛適用的系統分析設計與建模方法,即軟件的統一過程。
  說到統一過程,不能不提一下RUP,正是由于RUP與UML師出同門,造就了RUP在軟件統一過程中的霸主地位。不過一提到RUP,文檔、模型、迭代、組件、架構、軟件層次等詞匯,嚼蠟般的概念撲面而來,可以想象學習的感受。RUP的官方文檔晦澀而枯燥;相關的圖書,缺少透徹的理解與思想,有時還不如官方文檔好看。痛苦在于,明明你知道RUP就是把守通向實現技術自由之夢想之路的任督二脈,卻又無力打通。而于菜鳥同志們來說,層出不窮的開發框架,云山霧罩的設計模式,龐大復雜的體系和概念、無處著力的分析設計與建模從何學起?如何學起?
  這就是一本解決這些問題的書。
  坦率地說,這樣的書不是策劃而來,全憑幸運之神的眷顧。而于廣大讀者,這是一部可遇而不可求的技術寶作。
  ■天上人間
  有句俗話叫吃水不忘挖井人,說起UML,不能忘記Ivar,James,Grady這三個UML的創始人———三位方法學大師,在軟件領域,他們是教父級人物。但是并非所有讀者都認可這個觀點,原因是他們飽受UML與RUP之晦澀復雜之苦,并且始終也未得其門而入。不能被大眾所掌握,再巧妙再高深的知識也只是形同雞肋。
  本書第一版的字字句句,如鵜鶘灌頂,使好多困擾本人多年的似是而非的晦澀技術概念,茅塞頓開。本書第二版面市之際,我已經知道,那種無以言表的美好感覺,并非我的獨自感受,兩萬余名第一版的讀者,無不向譚云杰老師致以深深的敬意。正是因為大家的感恩心情,使譚老師在軟件技術的征途上,這三年來更加時刻不敢懈怠;正是因為大家的感恩心情,譚老師又斟出了自己多年來對于面向對象的數據庫的分析、設計與建模方面的心得,與朋友們共勉。這就有了本書的第二版。
  有一點必須聲明,作者本人非常惶恐于拿他與Ivar,James,Grady三位大師相提并論。本人也并沒有任何對三位大師的不恭之意,我只是想說:三位大師在天上,譚老師在人間。
  ■大象
  老子說,大象希形,大音希聲。我的理解大概是,象至極大,形之其次;音至極美,聲之其次;器至極巧,工之其次。能把UML講得如蛋清般清沏,已屬罕見,在讀完這書之後,又突然發現已然把朝夕膜拜的RUP之精髓收于囊中,同時讓開發框架、軟件架構、設計模式、分析、設計與建模等龐大而復雜的概念,再也不像如梗在喉,真的難以形容這是一種多么美妙的感覺。之余,不得不嘆服作者功力之厚、思想之深、語言之美、構思之巧,一切莫不象至極大,故此書第一版,命名為《大象》。
  對于本書的第二版,我依然認為這是一個最為貼切的名字。
  ……

購物須知

為了保護您的權益,「三民網路書店」提供會員七日商品鑑賞期(收到商品為起始日)。

若要辦理退貨,請在商品鑑賞期內寄回,且商品必須是全新狀態與完整包裝(商品、附件、發票、隨貨贈品等)否則恕不接受退貨。

大陸出版品因裝訂品質及貨運條件與台灣出版品落差甚大,除封面破損、內頁脫落等較嚴重的狀態,其餘商品將正常出貨。

無現貨庫存之簡體書,將向海外調貨:
海外有庫存之書籍,等候約20個工作天;
海外無庫存之書籍,平均作業時間約60個工作天,然不保證確定可調到貨,尚請見諒。