书籍介绍
这本书最独特的地方，在于它把UML从'软件工程师的专属语言'重新定义为'不懂技术的人与技术沟通的桥梁'。在绝大多数UML教材拼命让非技术人员硬啃建模术语时，它反其道而行：用'人、事、物、规则'这样朴素的现实视角，拆解参与者、用例、对象这些抽象概念，让产品经理、需求人员也能借UML真正听懂开发在做什么。读者反复提到的正是这一点——它'扭转了对UML的看法'，是'少有的看着好看的技术图书'。它适合那些需要与开发团队对话、却又不想被编程语言绑架的人。当然，也有读者嫌它话多、500多页里塞了太多科学故事，这恰是它取舍的代价：重启发，轻精简。若你追求的是快速查阅的工具书，它未必称职；但若你想理解'为什么需要UML'以及建模背后的思考，它值得一读。
作者简介
谭云杰，博客http：//coffeewoo.itpub.net及http：//blog.csdn.net/coffeewoo博主。资深架构师，PMP获得者，擅长于系统建模和系统分析设计，具有丰富的项目实践管理经验。曾经从事过电力、政府、航空等多个行业的管理软件开发工作和工作流中间件产品的研发工作，拥有十多个软件项目的分析设计经验和架构设计经验，其中不乏中型和大型软件项目。目前就职于IBM中国研发中心，从事Websphere Process Server产品的研发工作。作者使用UML进行系统分析建模至今已八年有余，对系统建模、分析和设计有深刻而独到的见解。在其博客上发表的00系统分析员之路系列文章短短时间内便获得了十余万的点击量，深受读者喜爱。读者可以通过访问作者博客或者发Email至[email protected]与作者联系。
AI导读
核心看点
- 以UML为载体，将面向对象分析设计思想融入建模过程
- 贯穿全书实例，有机整合软件系统开发各阶段知识
- 结合RUP统一过程，指导从需求到设计的完整建模流程
读者共识
- 讲解生动易懂，扭转了对UML枯燥晦涩的刻板印象
- 作者经验丰富，思路清晰，非简单堆砌知识
- 虽文字稍显冗长，但作为全程建模参考书价值极高
精彩摘录
- "RUP即Rational Unified Process，是Rational公司开发的软件过程产品。The Unified Software Development Process也指的是RUP，不过去掉了前面的公司名。本文分别采用“统一软件过程”和“RUP”作为其全称和简称。 就笔者所了解，当前国内业界普遍关心的一个问题是：RUP的剪裁原理是什么，有没有工程化的RUP剪裁过程。本文将讨论上面两个问题。本文有不少观点来自个人心得，有不妥之处，敬请斧正。 第一部分 RUP的剪裁原理 首先介绍“软件过程也是软件”这一著名原理，然后指明RUP的剪裁原理是：软件过程开发的再工程。 一、 软件过程也是软"
- "建模（Modeling），是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解，同时把这种理解概念化，将这些逻辑概念组织起来，构成一种对所观察到对象的内部结构和工作原理的便于理解的表达。 模型要能够真实反映客观事物就需要一个论证过程，使得模型建立过程是严谨的，并且结果是可追溯和验证的。 对于一种软件建模方法来说，为现实世界建立模型也要是严谨的，可追溯和可验证的，除了描述清楚需求，还要能很容易将这个模型转化为计算机也能够理解的模型。 建立模型的过程是一个抽象的过程，要建立模型，首先要知道如何抽象现实世界。 现实世界的本质无非是由人，事，物和规则组成的。 UML中，人 - 参与者"
- "业务模型映射了原始需求信息，之后要经历一个概念化（Conceptual）的过程建立适合计算机理解和实现的模型，这个模型称为分析模型。（Analysis Model） 分析模型有： 1. 边界类 2. 实体类 3. 控制类 在这个阶段，还可以对这些分析类在不同的视角上进行分类和整理，得到包，组件和节点。软件架构也是在这个阶段产生。"
- "在设计模型中，概念模型中的边界类可以被转化为操作界面或系统接口；控制类可以被转化为计算程序或控制程序，例如工作流，算法体等；实体类可以转化为数据库表，XML文档或者其他持久化类。 这个转化过程是有章可循的，可以遵循的规则有： 1. 软件架构和框架 2. 编程语言 3. 规范或中间件"
- "统一过程归纳和集成了软件开发活动中的最佳实践，它定义了软件开发过程中最重要的阶段和工作（四个阶段和九个核心工作流），定义了参与软件开发过程中的各种角色和他们的职责，还定义了软件生产过程中产生的工件，并提供了模板。最后，采用演进式软件生命周期（迭代）将工作，角色和成果物串在一起，形成了统一过程。 UML是一种语言，用来描述软件生产过程中要产生的文档，统一过程则指导如何产生这些文档以及这些文档要讲述什么的方法。 （重量级）统一过程 vs. （轻量级）敏捷方法"
- "要解决问题领域就要归纳出所有必要的抽象角度（用例），为这些用例描述出可能的特定场景，并找到实现这些场景的事物，规则和行为。再换个说法，如果我们找到的那些事物，规则和行为实现了所有必要的用例，那么问题领域就被解决了。这就是用例驱动方法的原理。 在统一过程中，一个用例就是一个分析单元，设计单元，开发单元，测试单元甚至部署单元。 用例可以驱动的内容包括： 1. 逻辑视图：该视图以图形方式说明关键的用例实现，子系统，包和类，即，人，事，物，规则，是如何分类组织的。 2. 进程视图：以图形方式说明了系统中进程的详细组织结构，其他包括类和子系统到进程和线程的映射，即，人，事，物，规则，是如何交互的。 3."
- "视图用于组织UML元素，表达出模型某一方面的含义。 视图面临的问题是如何正确的应用？ 什么地方用视图？应用那一种视图？总共需要哪些视图？ 软件有着很多不同的方面，静态的，动态的，结构性的，逻辑性的，软件建模即要针对这些方面分别建模，用例图，对象图，类图，包图，活地图等。这些视图从不同的方面描述了一个软件的结构和组成，所有这些视图的集合表达了一个软件的完整含义。所以，建模最主要的工作就是为软件绘制那些表达软件含义的视图来完整地表达软件的含义。 不同的干系人习惯于从不同的视角看待软件，因此软件建模另一项重要的工作是为不同的干系人从他们所关心的视角展示视图。"
- "1. 一切都是对象 2. 对象都是独立的 3. 对象都具有原子性 4. 对象都是可抽象的 5. 对象都有层次性"
目录
大象希形写给读者的话关于本书如何阅读本书光盘使用说明第一部分 准备篇——需要了解 第1章 为什么需要UML 第2章 建模基础 第二部分 基础篇——在学习中思考 第3章 UML核心元素 第4章 UML核心视图 第5章 UML核心模型 第6章 统一过程核心工作流简介第三部分 进阶篇——在实践中思考 第8章 准备工作 第9章 获取需求 第10章 需求分析 第11章 系统分析 第12章 系统设计 第13章 开发 第14章 测试第四部分 高级篇——在提炼中思考 第15章 理解用例的本质 第17章 理解建模的抽象层次 第18章 划分子系统的问题 第19章 学会使用系统边界 第20章 学会从接口认知事物 第21章 学会正确选择 第22章 学会使用设计模式附录 UML视图常用元素参考图目录表目录 后记
用户评论
醍醐灌顶，浅显易懂，例子贴切，诀窍实用。建议：因为用作教材，所以希望某些观点可以分得更细，条理更明晰。
工具书，翻翻，束之高阁，存着
少有的看着好看的技术图书。讲解得很好，至少扭转了不少我对UML的看法
有点啰嗦
以前折腾UML时读过。
pm也应该必读 尤其是b端的
4.5 真的很不错，还是国内作者写的，尤其难能可贵
醍醐灌顶，这么多年终于明白“用例”是什么意思，能干什么
干货是真有，且难得真诚，就是特么枯燥。
作者就是那种传说中的学霸吧，上可梳理需求建立需求档案，中可梳理流程建立分析模型，下可搭建框架动手开发，时不时还会来点中国古典艺术，小说之类，一枚爱好文学的理工选手，厉害~反正这书，对没开发基础的我来说，也够看了，不枯燥的专业书。至于有人诟病的“太虚”，作者书名就说了，大象无形嘛，全靠体会。
求书
收藏