新書推薦：
《
改变世界的哲学家们
》
售價：HK$
105.6
《
将军
》
售價：HK$
57.6
《
墓志的生成及其在唐代的衍变研究
》
售價：HK$
117.6
《
理解中国经济：在大变局中读懂新机遇
》
售價：HK$
54.0
《
饥饿与国家：苏丹的饥荒、奴隶制和权力（1883~1956）
》
售價：HK$
82.8
《
管好你的钱：人人都要懂的财富传承（一本书带你了解财富传承的7种方式）
》
售價：HK$
81.6
《
新质生产力：中国创新发展的着力点与内在逻辑
》
售價：HK$
94.8
《
“漫画强国科技”系列（全4册）
》
售價：HK$
168.0
|
| 內容簡介： |
本书以UML为载体，将面向对象的分析设计思想巧妙地融入建模过程中，通过贯穿全书的实例将软件系统开发过程中方方面面的知识有机地结合在一起，用生动的语言和精彩的事例将复杂枯燥的软件过程讲解得津津有味。
全书分为四个部分。第一部分讲述面向对象分析的一些基本概念，及学习建模需要了解的一些基本知识。第二部分对UML的基础概念重新组织和归纳整理，进行扩展和讨论，引申出针对UML的这些概念在面向对象方法中应用方法的思考。第三部分以一个实例贯穿全篇，阐述如何使用UML从头到尾地实施一个项目。第四部分针对在现实中经常遇到并且较难掌握的问题进行深入的探讨，升华在前几篇学习到的知识。
本书可供正在学习编程、软件工程等知识，准备将来从事IT行业的读者、正努力向设计师或系统分析员转变的技术人员及期望对软件分析设计更上一层楼的设计人员学习和提高之用。
|
| 關於作者： |
谭云杰：
CSDN专家博客coffeewoo博主。资深架构师，PMP获得者，擅长于系统建模和系统分析设计。从事过电力、政府、航空等多个行业的管理软件开发工作和工作流中间件产品的研发工作，拥有十多个软件项目的分析设计经验和架构设计经验，其中不乏中型和大型软件项目。目前就职于某著名跨国软件企业中国研发中心，从事产品研发工作。
作者使用UML进行系统分析建模至今已十年有余，对系统建模、分析和设计有深刻而独道的见解。在其博客上发表的OO系统分析员之路系列文章短短时间内便获得了十几万的点击量，深受读者的喜爱。
|
| 目錄：
|
大象希形
再版序
写给读者的话
关于本书
如何阅读本书
免费下载资源使用说明
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之精髓收于囊中，同时让开发框架、软件架构、设计模式、分析、设计与建模等庞大而复杂的概念，再也不像如梗在喉，真的难以形容这是一种多么美妙的感觉。之余，不得不叹服作者功力之厚、思想之深、语言之美、构思之巧，一切莫不象至极大，故此书第一版，命名为《大象》。
对于本书的第二版，我依然认为这是一个最为贴切的名字。
再版序
《大象—Thinking in
UML》自2009年出版以来，已经过去了三年。在这三年中，《大象》获得了我预期之中的关注，也获得了我意料之外的荣誉。
我所预期的，是我坚信《大象》是我所知道的唯一一本结合了面向对象方法、软件工程方法、基于UML的建模方法的全程建模的书；我相信也是唯一一本不仅仅是授技，而是试图论道的书。最重要的是在决定写作本书时，我便决心不写那种引用、翻译、拼凑各种资料的书。因为我在工作中经过学习、思考和实践，已经形成了一套自己的面向对象的建模、分析和设计方法，至少在我自己的项目中用起来得心应手。我觉得应该将这套方法传播开来。既然这套方法能够让我自己的项目获益，我相信也能够让更多的IT从业者获益。我于是非常用心地写下每一个字，每一个观点都是自己的理解和经验总结，几乎倾尽了工作十年的所有经验和思考。我相信这样的书一定会获得读者的喜爱，所以自写作时就期望着能得到读者的肯定。
而意料之外的，则是受欢迎的程度远远超过了我的预期。我没想到在本书出版的第一年，便在互动网的计算机图书销售排行版上冲上了销售榜的第三名；没想到在接下来的这三年里，销售也一直非常好，至今已经重印了6次之多；更没想到的是本书被许多学校采纳为教材或者课外资料。而最让我欣慰的则是读者的反馈。读者购买本书后的每一条反馈我都会看，不论是赞扬的还是批评的。更多的读者在阅读后会给我来信，要么询问书中不太明白的地方，要么指出书中的一些错误。甚至有读者建立了专门的QQ群来讨论与本书相关的一些问题。
与冷冰冰的销售纪录相比，我更看重这些热乎乎的评论、讨论。这为《大象》赋予了生命，或者说，之所以会有今天的第二版，它的第二次生命就是由这些读者给予的。读者对《大象》的指正都改进到了第二版中；读者对《大象》更多的期待，更是直接促成了第二版的诞生。
在准备第二版之前，我曾经想过要不要大动手术。但一方面大部分读者的反馈表明《大象》第一版挺合乎胃口。另一方面，在第一版出版后的这三年里，我应邀做了许多演讲、培训和公开课，在这些活动中我完全依据《大象》的思想和方法来讲课，获得了绝大多数学员的认可和肯定。学员们普遍反映这套方法颠覆了他们的认识，使得他们对面向对象方法、建模方法和UML的理解有了质的变化，经过学习，对软件本身也有了全新的认识。这让我意识到，《大象》里我所传达的思想和方法是符合现实需要的，目前我没有足够的理由对第一版进行大刀阔斧的更改。但第一版也绝不是完美的，除了错误、不严谨的地方，也有读者确实需要但在第一版中未涉及的内容。
因此，第二版我决定维持原有的主体不变化，包括贯穿全书的例子。一方面改正错误、完善语言组织，更重要的是补充读者期望的内容。基于此，在第二版中，最大的改变是：第一，应许多读者的要求，专门增加了第13章，深入讨论了面向对象方法与面向关系方法的区别与联系，详细讨论了面向对象的数据建模的方法；第二，在第5章中澄清了第一版中所讲的“问题领域建模”与大家所熟知的“领域驱动建模”在概念上的不同，并在第17章中详细讲述了“领域驱动建模”与“用例驱动建模”方法的使用。
在第二版即将完成的前夕，我完成了人生另一个重要的转变：随着小鱼鱼的出生，我成为了一个父亲。喜悦之情自不必多说，尽管两个月来我再没睡过完整的一觉。我相信孩子将从此永远改变我的生活方式，为了与他一起成长，我得把书送给他，并留下这段话。或许以后，他会拿着书说：看，这是爸爸为我写的，虽然我看不懂，但我知道大象鼻子很长……
再次感谢您关注和购买本书。您的意见将是我最大的收获！我将与您一同成长。
谭云杰
2012年03月
写给读者的话
近几年来，面向对象几乎成为软件技术的代名词。不论是学校设置的计算机课程，还是时下最流行的编程语言、设计方法，以及新兴的概念、标准和新思想无不被冠以面向对象的标签。而UML是面向对象方法的一面旗帜，谈到面向对象的分析和设计就不能不谈到UML。如今UML也成为面向对象分析和设计事实上的行业标准。然而什么是UML？怎样使用UML？UML仅仅是一组符号吗？可以说，UML是面向对象思想和方法的具体化和符号化。学习UML的过程就是掌握面向对象思想和方法的过程。相对学习UML的符号含义而言，掌握它们背后的方法和思想是更为重要的。古人将知识分为“技”和“道”，习技固然可以成为人杰，而悟道才能羽化升仙。希望读者不仅仅满足于学会使用UML，而应该能够从中悟道。
不论是面向对象的方法，还是面向对象的杰出代表UML，许多朋友在现实中并不能真正掌握它们。虽然用着面向对象的工具，采用面向对象的语言，却做不出一个真正符合面向对象思想的软件。笔者在工作中发现许多使用了多年UML的人其实并不真正理解UML的意义，常常用着UML却做出了并非面向对象的设计。就像一个不知道诗歌格律的人，不论采用什么文字都写不出诗歌一样；没有真正理解面向对象的思想，没有真正掌握面向对象的方法，仅仅使用UML符号并不等于可以做出面向对象的分析和设计。
人类自从有思想以来，就在不断探寻和认识自己所生活的这个世界。从本质上说，面向过程和面向对象都是人们认识这个世界的方法；而具体的技术，则是在采用这种方法认识世界的过程中被发明、总结和归纳出来的最佳实践。对于学习者而言，掌握这些技术是重要的；掌握这些技术表示你已经继承了前人的经验积累，并且是一个捷径，一如设计模式。但是，作者更建议把学习提升一个层次，超越具体技术细节去思考其背后蕴含的思想和方法。这正是本书要冠名以Thinking
in
UML的原因。本书并不是一本讲述哲学和方法论的书籍，相反，本书中将以大量的实例进行阐述，同时把作者在面向对象分析和设计领域的经验融入其中，因此本书更像是一本实战手册。本书除了讲解面向对象的基本概念和UML语言之外，将采用更大篇幅现身说法，深入浅出地把面向对象思想的精髓、分析思路、推导方法传授给读者。本书的讲解均来自实际工作，乃作者多年工作经验和最佳实践的总结和归纳。这些经验和最佳实践来源于实际，更贴近于实际。
本书中某些实例或许正好与读者正面临的问题相同或相似，读者当然可以照葫芦画瓢，举一反三地去解决现实中的问题，然而这并非作者的本意。作者在构思这本书的时候，是希望以实例为线索，将思考方法和分析过程传达给读者，让读者理解某个具体解决方案背后的思考过程、分析过程和推导过程。哪怕读者经过思考得出与作者完全不同的结果，甚至证明出作者所给出的解决方案并非一个好方案，这也是作者所期望的。
希望读者在阅读本书的过程中，关注并思考作者在面对一个问题领域时的思考和分析过程，而不要沉迷于书中给出的具体实例。本书的核心是Thinking，UML只是表达的载体。如果读者能从作者的分析方法中获得灵感，对面向对象的分析和设计有所感触，开始有恍然大悟的感觉，那么作者将感到最大程度的欣慰。另外，作者的分析方法和推导过程只是作者本人在工作中自己总结出的经验，不是标准答案，更不是圣经。期望读者能够从作者的这些经验中经过思考，结合自己的实际，获得自己的方法。如果真是这样，作者的这些文字工作就真正劳有所值了。
为了让读者方便阅读，本文中的绝大部分示例图中的UML元素都是用中文命名的。在实际工作中建议除了业务模型部分外，其他模型都最好使用英文，这是因为一方面Rose对中文的支持不太好，另一方面毕竟最终代码实现是英文的，模型与实现都用英文会避免很多歧义。
本书为《大象—Thinking in
UML》的第二版，在本版中，加入了我近年来对于面向对象的数据库设计方面的一些心得体会，与大家共勉。这部分也是第一版不少读者非常期待学习但却不容易找到相关主题的内容。
最后，感谢您购买此书，希望在本书中能够找到那些正在困扰着您的问题的答案。祝大家阅读愉快！
关于本书
提到Thinking这个词，读者大多会想到一本经典技术书籍《Thinking in Java》。之所以《Thinking in
Java》会成为经典，原因在于这本书并不是教授读者Java语言本身，而是透过Java语言深入讨论其背后的思想和方法。授人以鱼不如授人以渔。
本书是讲述UML的。同样，本书也不是一本纯粹教授UML语法的书籍，而是通过UML这个表象来深入探讨面向对象的分析方法；同时将结合软件工程，传达基于对象的思考方法、分析模式和推导过程以及它们在软件工程的各个阶段如何发挥作用。本书冠以Thinking
in UML这一名称正是为了切合这个主题。作者不敢奢望本书会成为《Thinking in
Java》一样的经典书籍，但是作者在本书中倾尽了自己在面向对象分析和设计领域中的实践和经验积累。至少对那些尚未能够深入此领域，感觉面向对象仍然似是而非的朋友们，本书中将要传达的那些思路将会是一条线索，至少能够帮助你找到通往面向对象分析的大门。
本书在编写过程中，以大量实际项目中会遇到的实例引出问题，讲述作者对这一问题的分析思路和解决办法。再进一步升华，通过对实例的评点，分析思路的归纳和扩展，上升到面向对象方法理论。逐步引导读者由点到面，由表及里，最后由对工具的使用上升到思想的高度，从而能够自如地跳出工具使用的局限，真正从方法和思想的高度来看待和解决现实的问题。本书中的很多内容和思想将是你在其他书籍中看不到的。
本书为第二版，依然分为四个部分，由浅入深，从基础到高级，每个章节都有具体的实例进行说明，同时作者将耗费更多的篇幅来评点和阐述这些实例。在某些章节最后还会就一些关键概念和不容易理解的地方提出问题，让读者自行思考。与第一版不同的是，本书加入了近年来本人对于“面向对象的数据库设计”方面的一些心得体会，这也是第一版的很多读者非常期待学习的。同时，本书的第二版吸收了部分第一版读者提出的宝贵建议或杰出观点，在此表示感谢。
第一部分—你需要了解。在这一部分中，作者将从面向对象的困难和需要入手，讲述面向对象分析的一些基本概念，由此提出为什么需要UML这一话题。另一方面，也讲述了接下来学习建模需要了解的一些基本知识。
第二部分—在学习中思考。在这一部分中，作者将从实用的角度对UML的基础概念重新组织和归纳整理，同时进行一些扩展和讨论，引申出针对UML的这些概念在面向对象方法中应用方法的思考。这些内容将覆盖绝大部分实际工作的需要。通过这一部分的学习，读者将从另一个角度了解UML，知道UML能够做什么。
第三部分—在实践中思考。在这一部分中，作者将以一个实例贯穿全篇，以软件过程为纲，阐述在第一部分中学习到的那些UML元素和视图将如何在一个实际的软件过程中发挥作用，如何相互配合将一份原始需求经过层层分析和推导，最终形成可执行的代码。并且这个过程将是可验证的和可追溯的。读者在阅读本部分的时候，应关注分析过程和推导过程，思考从需求到实现是如何保证可验证性和可追溯性的。通过这一部分的学习，读者将能够学会如何使用UML来从头到尾地实施一个项目。
第四部分—在提炼中思考。在这一部分中，每个章节均会针对一个在现实中经常遇到并且较难掌握的问题进行深入的探讨。这些探讨将有助于提升面向对象的思考能力，升华在前两部分学习到的知识。
本书中用到的UML图使用Rose绘制，完整的工程文件可以从中国水利水电出版社和万水书苑免费下载，网址为http:www.waterpub.com.cnsoftdown和http:www.wsbookshow.com。
由于作者水平有限，很多内容是自己的经验总结，出现错误在所难免，欢迎广大读者批评指正。读者在阅读本书的过程中有任何不清楚的问题和批评建议，可以到作者的博客http:blog.csdn.netcoffeewoo或http:coffeewoo.itpub.net留言，或者发邮件到coffeewoo@gmail.com，作者将尽力给您答疑解惑，您的批评建议也将鞭策作者做得更好。
|
|
購物車/收銀台(
0
) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
