建模和UML

1.利润=需求-设计
在软件开发中，需求工作致力于解决 产品好卖的问题
设计工作致力于解决降低成本的问题。二者不能相互
取代。

2.核心工作流
<1>业务建模：
描述组织内部各系统如何协作，使得组织可以为其他
组织提供有价值的服务。

<2>需求
聚集于待开发系统的边界，详细描述系统要卖得出去必须具有的表现
功能和性能。

从卖的角度思考那些是涉众在意的，不能改变的契约，那些不是

<3>分析
提炼系统内需要封装的核心领域机制。

其中只有一个领域（核心领域）的知识是系统在
市场上面生存的理由。

<4>设计
将核心域知识和非核心域知识结合，最终实现系统。
代码确实是设计，但是代码不是分析，不是需求，不是业务建模。

组织要解决什么问题   业务建模
为了解决组织的问题，待开发系统应该提供什么功能和性能 需求

需求规格

为了提供功能，系统内部应该有什么样的核心机制 分析
为了提供性能，系统的核心机制如何用选定技术实现 设计

3.不同工作流产生的工件之间的确保不在于形式，而在于内容，
也就是思考的边界。

4.
工作流   思考焦点          可选UML元素  推荐UML元素
业务建模 组织内系统之间                 用例图，类图，序列图
需求     系统边界                       用列图，文本
分析     系统内核心领域                 类图，序列图，状态图
设计     系统内各领之间                 不画，代码即可。   

5.UML沟通仅限于开发团队内部，UML模型不是用来和涉众沟通的。

6.客户是一大堆涉众，它们所在领域不同，学历不同，
关注的利益各自不同，怎么能寄希望一个模型和所有涉众
沟通。

那么，和涉众交流的介质是什么？不是模型本身，而是模型的各种视图。
面对打领导，我们可以给他放幻灯片交流愿景
中层干部喜欢看文档，我们可以按照他喜欢的格式给他炮制文档
一线操作工只关心他那一块小工作，我们可以制作原型界面和他交流
有时候甚至有的涉众根本不喜欢看任何东西，我们可以通过谈话视图和他交流。

见鬼说鬼话，见人说人话。
看人上菜。

和涉众交流的内容应该聚集于需求的素材--涉众利益
涉众希望什么担心什么，而不是需求。

同样，软件需求不是由涉众直接提供的，而是由需求工程师综合不同涉众的利益
编造出来的。涉众没有资格、也没有责任提供需求，这一点后面在“需求启发”一章中再详述

7.和涉众交流的形式应该采用视图，而不是模型
和涉众交流的内容应该聚焦涉众利益，而不是需求。

8.和涉众交流的形式应该采用视图，而不是模型
和涉众交流的内容应该聚焦涉众利益，而不是需求。

9.建模的目的是帮开发团队思
考，它可以指引开发团队发现到底需要向涉众了解什么，但不是直接拿着模型和涉众交流

10.本书到现在为止，已经说了很多回“偷懒”，就是强调世上无易事，好的方法应该能强迫你思考，
强迫你付出心血和汗水来获得竞争优势，反之就是忽悠，就像现在一些甜得发腻的伪敏捷宣传