写软件就是要解决用户的需求，我们需要表达和传递下面这些信息：
在“需求分析”阶段，我们要搞清楚
在问题领域中的现实世界里，都有哪些实体，如何抽象出我们真正关心的属性，实体之间的关系是什么，在这个基础上，用户的需求是什么，软件如何解决用户的需求。
在“设计与实现阶段”，我们要搞清楚
软件是怎么解决这些需求的？
在“测试”和“发布”阶段，我们要搞清楚
软件真的解决了这些需求了么
我们先看看两个初中水平的题目：
这两个问题看似不容易，并且毫不相干，但是本书的读者应该都能毫不费力地用类似的方法来解答。我想最常见的思路是:
这个问题实质上是二元一次方程求解：
鸡兔同笼：
x+y=35;4*x+2*y=94.
果冻搬砖：
x+y=1000;4*x–15*y=3525
我们还可以用二维坐标系图示的方法来得出直观的解法：
鸡兔同笼的图示解法
看典型解题者的解题过程，有下面的步骤：
1）理解，抽象：理解问题，过滤掉非核心信息，抽象出关键信息和它们之间的关系。（雉就是野鸡，我没看见过活的野鸡，在这个问题中它等同于家鸡，鸡长啥样？一只鸡有几个头，几只脚，兔子长啥样...鸡头、兔头、鸡脚、兔脚要满足一些关系）
2）找到合适的数学模型：啊，这就是二元一次方程求解。
3）根据模型和解法，按部就班地解决问题：这要依赖于对数学原理（交换律，等价性…）和基本操作的掌握。
分析和设计有许多方法：
11.2图形建模和分析方法
我们要给事物建造出一个“模型”，描述事物、事物的属性、事物之间的关系（静态的）以及各个事物之间的信息传递（动态的）。
下面简要介绍各种方法，详细的介绍和具体的应用可以参照专门的教科书和文献。
11.2.1表达实体和实体之间的关系（EntityRelationshipDiagram,EntityRelationshipModel，MindMap）
思维导图（MindMap）
“一图胜千言”，人们经常用图形来帮助他们了解概念，强化记忆。思维导图是其中的一个例子。思维导图没有严格的语法定义，一般来说是从图形的正中开始写下一个概念，然后按照绘图者所关心的属性扩展，几乎每个人都能马上开始画图。这个看似简单的工具其实很适合团队一起讨论和理解核心概念–例如，我们的主要用户有什么特点、什么需求。
图xxxx思维导图的例子
思维导图形式灵活，适用于很多鼓励探索、发散思维的场合（如头脑风暴会议），但是它的图形元素缺乏严格的语法和语义。
实体关系图(EntityRelationshipDiagram)
如果我们着重于表达现实世界中的实体和它们之间的关系，那么实体关系图ERD是最自然的表达方式。下面是实体关系图的一个例子，表达了大多数读者都比较熟悉的“图书馆借书”的场景：
在我们分析实体之间的关系时，这就是一个理解和抽象的过程，例如，我们可以通过自然语言的帮助把各种元素归类到它们在ERD里适当的类型中。这样的做法也用在了10.3节“功能驱动的设计”中。请看下表：
表：xxxx英语语言中不同的词性和ERD的元素的分类
英语语言中的不同词性
ERD中的类型
普通名词
(表示一类事物，如银行、客户、书籍等)
实体类型
专有名词
（表示一个特定的人或事物）
实体
及物动词（客户取出存款）
关系的类型
不及物动词（利息可以升高或降低）
属性的类型
形容词（这种活期账户是无利息的）
实体的属性
当我们要表示实体之间的静态关系时，ERD是一个合适的工具。
用例图（UseCaseDiagram，UCD)
上一章提到的用例（UseCase）也有图形化的表示。用例图主要有下列的元素：
11.2.2表达数据的流动（DataFlowDiagram）
从下图来看，流过的数据还真不少。我们简要地列出几个例子：
读者可以查询、预定、借出书籍。
新书入库的时候，书的各种属性会被录入到系统内的“图书数据库”，同时内部管理系统能触发流程，让预定某书的读者知道，他关心的书已经到货。
11.2.3表达控制流（FlowChart,FiniteStateMachine）
我们在计算机理论基础课上都学过有限状态自动机（FiniteStateMachine,FSM）,在程序设计语言基础课上都学过基本的流程图，这里不再赘述。
11.2.4统一的表达方式（UnifiedModelingLanguage,UML）
这些图形建模方法各有特点，它们使用了不同的几何图形、标注规则、专有词汇和颜色。人们自然会想，能否有一个统一的表达方式？UML就是这样的回答。UML在20世纪90年代伴随面向对象的方法发展，在工业界的应用和反馈中成熟起来，2004年发布的UML2.0是一个相对稳定的版本。
表xxxx各种图示建模方法的大致特点
各种分析建模方法
从结构化数据的角度看
从面向对象的角度看
从控制的角度看
强调静态
ERD
ClassDiagram
强调动态，交互
DFD，UCD，ActivityDiagram
SequenceDiagram
FSM，FlowChart，UMLStateMachine
对于这些图形化的辅助工具的价值，不同的人有不同的看法。
在《CodersatWork》这本书里面，Java架构师，畅销书《EffectiveJava》的作者JoshuaBloch对于“你用过UML设计工具么”的回答是：
“没有。能把设计画成图，让别人理解当然很好。但是说实话我真的记不起来哪些模块应该是圆形，哪些是方形。”
谷歌研究院的院长PeterNorvig被问及同样问题的时候说：
“我从来不喜欢UML类型的工具，如果你不能通过计算机语言表达(UML要表达的东西)，那就是这种语言的弱点。“
像任何新技术一样，以UML为代表的图形化分析方法的确解决了不少实际问题，但是也引发了一些误解、误用、狂热和“银弹”的信仰。UML的设计者和推动者之一GradyBooch说到：
11.3其他设计方法
形式化的方法（FormalMethod）
很多软件需求（例如计算机语言的编译器）可以抽象为对符号的运算和变换，很多软件的某些核心功能需要严密地验证，保证没有问题。一些科学家一直在努力，希望用无歧义的、形式化的语言描述我们要解决的问题，然后用严密的数学推理和变换一步一步把软件实现出来，或者证明我们的实现的确完整和正确地解决了问题。在这个领域一个比较成熟和经过实践考验的方法是ViennaDevelopmentMethod（VDM）。