转载来自： https://bit-kaki.blog.csdn.net/article/details/80067462
最近终于把《大象》这本书读完了，从去年11月到现在，用了整整五个月。
一方面是因为这段时间工作上的事情，生活上的事情都比较多，很少有整块时间阅读；
读完最后的感觉仿佛自己打通了任督二脉，很多以前工作上的问题一下子茅塞顿开。
一个系统从零到一，以前知道大概怎么做，现在总算明白一些为什么这么做以及使用UML的好处是什么？
虽然书中有部分内容自己并不完全赞同，但这本书整体的思想上给了我很大的启发。
总的来说，抛开具体的工具和概念，我觉得这本书给了我以下几点启示：
1.UML是一种语言
语言是用来沟通的主要方式，包含了单词和语法
UML 的单词就是各种元素、视图和模型，语法就是建模的方法
语言最基本的功能是能清楚地表达和传递信息
UML最基本的就是通过模型将需要做的系统清楚表示出来
2.UML采用的是面向对象的方法
面向对象是一种认知世界的方法，在面向对象方法里，一切有名字的东西都是对象
对象和对象之间彼此独立，只有在某个特定场景下，它们的某一个特定实例才相互联系在一起
每个对象都是一个整体，内部不可分割，外部只能通过边界和其他对象对接
对象参与每个场景时都会展现其某一个方面性质，这方面性质都可以抽象出来
3.建模的实质是将现实世界抽象为模型
同样的事物在不同的世界观的人眼里会产生不同的结果，而这个世界观在建模里对应的是抽象角度
一旦决定了抽象角度，就确定了一个目标
一个由抽象角度确定了的目标需要由静态事物加上特定条件下产生的一个特定场景来完成，即静态的事情（物）+特定的条件（规则）+特定的动作（参与者的驱动）=特定的场景（事件）
建模其实也就是由人+事+物+规则，将现实世界抽象为模型
4.项目的启动
项目的启动首先源自“老大”的愿景，在老大看来，为什么要开发这个系统
然后是进行涉众分析，谁关心这个系统？会涉及到他的什么利益？
再次是投入，愿意花多少钱，允许多少时间？
最后是风险，比如客户参与少；没有度量方式；技术风险；重要人物反对；以前曾被取消过……
5.客户访谈技巧
一般来说系统分析员是计算机专家，习惯于从计算机角度来看问题；客户是业务专家，习惯身边的人也熟悉这个业务领域。
所以系统分析员需要改变自己的立场，了解业务是什么，还要弄清业务为什么。
首先，应该有一个详细的涉众分析报告，循序渐进地从接触到深入了解客户；
其次，不要急于深入业务细节，而是先就一些大框框进行沟通，借此习惯和了解对方的沟通方式；
再次，双方的时间是有限的，因此每一次会面都需要争分夺秒，用最快的时间把问题搞清楚；
最后，系统分析员需要承担每次会谈结果记录，并且需要正式的反馈和确认，以便之后和客户在需求变更时候有依据。
6.需求获取
在对每个业务进行需求调研时候首先要明确该业务的边界，每个边界的划分则指明了需求分析的起点
找到业务主角，访谈业务主角或者从业务主角的角度来看与系统的交互，就可以得到业务用例
根据业务用例用合适的视图表达出来就构建除了业务模型
业务建模常见的视图有两种：活动图和时序图
活动图中活动是主要的内容，表达的内容是业务主角或业务工人做什么；时序图中，消息是主要的内容，表达的内容是业务主角或业务工人之间传递的是什么
7.需求分析
需求分析首先要找到关键概念，关键概念是指支撑起客户整个业务架构的那条主线，在UML方法里，就是由一些关键的业务用例构成
根据各个关键概念，梳理出相关的概念用例，获取概念模型
每个概念模型表示一个功能，各个概念模型之间通过软件架构联系起来
从概念模型入手，根据找到业务主线找到每个大的业务构件，再通过领域模型分解为小的构件,再根据概念模型找到各个小的构件之间的依赖关系。
如此就得到了项目的业务架构
8.系统分析和设计
将每个业务模型抽象为描述系统的模型，就得到了系统模型
业务用例抽象为系统用例的基本方法有：映射、抽象、合并、拆分、演绎等
系统分析的成果是获取到系统的每个分析类，这些分析类基本上可以分为实体、边界、控制三类，和开发中的MVC正好对应
将分析类的成果考虑具体实现语言和实现方式，也就是系统设计，得到的成果就是开发中可直接用的类、包和接口
9.理论和实际
《大象》这本书尽管作者举了很多生动的例子，画了大量的图，但整体来说是依然是非常枯燥的
对于书中理论，抽象程度都比较高，专业的词汇也比较多，所以看下去真的很难
不过UML作为目前可视化建模语言的工业标准，其本身也源于面向对象分析和设计的方法
目的就是为了更清晰、简单的表达软件设计中的动态和静态信息
所以如果能结果实际项目来看会往往觉得豁然开朗的感觉，但强行去从概念理解往往会让自己更懵
另外我觉得uml的学习最大的成果是有这样一种思维方式，如何分析和设计一个系统
但真正在无比推崇“敏捷开发”的现在，我觉得uml很多时候还不如一个高真的axure更能传递清楚软件设计的信息
（一）为什么需要UML？
一、UML的定义
UML,即Unified Modeling Language又称统一建模语言或标准建模语言，是始于1997年一个OMG（对象管理组织）标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。
UML是一种是面向对象软件的标准化建模语言，要弄清UML，首先得搞清楚面向对象和面向过程。
二、面向对象和面向过程
面向对象和面向过程是两种不同描述世界的方法。
面向过程：世界视为过程，世界由一个个相互关联的小程序构建来的。但是构成一个系统的因素太多，要把所有可能的因素都考虑到，把所有因素的因果分析都分析清楚，再把这个过程模拟出来实在是太困难了。
面向对象：世界视为对象，世界由一个个相互独立、相互之间没有因果关系的对象构成。但是难点在于为什么这样抽象对象？怎样组合对象？对象的组合表达了怎样的含义？
以知乎上的一个例子来区分面向过程和面向对象：
面向过程：
为了把大象装进冰箱，需要3个过程。
1) 把冰箱门打开（得到打开门的冰箱）
2) 把大象装进去（打开门后，得到里面装着大象的冰箱）
3) 把冰箱门关上（打开门、装好大象后，获得关好门的冰箱）
每个过程有一个阶段性的目标，依次完成这些过程，就能把大象装进冰箱：
冰箱开门(冰箱)
冰箱装进(冰箱, 大象)
冰箱关门(冰箱)
面向对象：
为了把大象装进冰箱，需要做三个动作（或者叫行为）。
每个动作有一个执行者，它就是对象。
1) 冰箱，你给我把门打开
2) 冰箱，你给我把大象装进去（或者说，大象，你给我钻到冰箱里去）
3) 冰箱，你给我把门关上
依次做这些动作，就能把大象装进冰箱：
冰箱.开门()
冰箱.装进(大象)
冰箱.关门()
三、面向对象的困难
面向对象是把世界看作是由许多对象组成的，然而现实世界和对象世界之间存在着一道沟壑，这道沟壑的名字叫抽象，抽象是面向对象的精髓所在，同时也是面向对象的困难所在。要跨越这道沟壑，我们需要：
一种把现实世界映射到对象世界的方法；
一种从对象世描述现实世界的方法；
一种验证对象世界行为是否正确反映了现实世界的方法。
而UML就是跨越这道沟壑的方法。
四、UML的特点
UML是一种建模用的语言，就是一种建模用的语言，包含模型和关系，类似于语言中的基本词汇和语法。
UML的特点是统一，形成一种标准让人和机器都能读懂。
UML的优点是可视化，通过原模型和表示法，更加准确直观表达出文字难以表达的内容。
五、从现实世界到业务模型
建模是对客观事物建立一种抽象方法，用来表征事物以及对事物本身的理解。
知道如何抽象现实世界:人、事、物、规则，人驱动系统、事体现过程、物记录结果、规则是控制；
在UML里：参与者（actor）代表人，用例（use case）代表事，业务对象模型（business object model）代表物，业务场景（business scenario）代表规则。
六、从业务模型到概念模型
UML通过称之为概念化的过程（Conceptual）来建立适合计算器理解和实现的模型，这个模型成为分析模型（Analysis Mode）。
原模型包含：边界类、实体类、控制类。
边界类类似于系统中的界面，决定操作能不能做，代表了事；
实体类由领域模型转化而来，重新表达了业务实体，代表了物；
控制类表达了需求中的动态信息，体现了规则。
七、从概念模型到设计模型
实现类可以简单地从分析类映射而来：
边界类可以被转化为操作界面或者系统接口；
控制类可以被转化为计算程序或者控制程序，例如工作流、算法题等。
实体类可以转化为数据库表、XML文档等。
UML的三个模型的建立过程解决了面向对象的三个困难。
（二）建模基础
一、建模
建模（Modeling），是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解，同时把这种理解概念化，并这些逻辑概念组织起来，构成一种对所观察的对象的内部结构和工作原理的便于理解的表达。
建模主要包含两个问题，一个是怎么建？另一个是模是什么？
怎么建？
同样的事物在不同的世界观的人眼里会产生不同的结果，而这个世界观在建模里对应的是抽象角度，抽象的角度不同决定了建模方向的不同。
无论在需求分析、系统分析还是系统设计上，要采用面向对象的方法，在面对问题领域的时候首先不要决定去通盘考虑，而是找出问题领域里包含的抽象角度，把抽象角度找全了，并且这些角度都分析清楚了，问题领域也就解决了。
做需求的时候，首要目标不是要弄清楚业务是如何一步一步完成的，而是要弄清楚有多少业务的参与者？每个参与者的目标是什么?参与者的目标就是抽象角度，也就是用例。
模是什么？
一旦决定了抽象角度，就确定了一个目标。
一个由抽象角度确定了的目标需要由静态事物加上特定条件下产生的一个特定场景来完成，即静态的事情（物）+特定的条件（规则）+特定的动作（参与者的驱动）=特定的场景（事件）
这个就是上一章里说到认识世界的四个要素联系起来了：人、事、物、规则。
综合以上所示，建模公式的就是：
二、用例驱动
从建模公式我们可以知道，要想解决问题领域就需要归纳出所有必要的用例，实现了这些用例，问题也就解决了。
所以为了实现这些用例，我们就需要实现与之相关的分析、设计、实现、测试，这就是用例驱动。
用例具体可以驱动的具体内容有：
逻辑视图：建模公式中的“人”、“事”、“物”、“规则”是如何分类资质的；
进程视图：建模公式中的“人”、“事”、“物”、“规则”是如何交互的，它们的关系如何；
部署视图：建模公式中的“人”、“事”、“物”、“规则”是如何部署在物理节点上的；
实施视图：建模公式中的“人”、“事”、“物”、“规则”是如何构成系统的“零部件”，以及我们如何组织人力生产和组装这些“零部件”以坚持最终系统；
用例驱动视图为：
三、抽象层次
抽象层次是面向对象方法中极其重要但又非常难以掌握的技巧，抽象层次越高，具体信息越少，概括能力越强
抽象层次是为了帮助人去更容易理解事物，它将一部分具体的信息封装起来用一个新的概念去替代，比如长度的单位，天所学所用的光年相对于米、公里这些常见单位来说更加抽象，但说太阳系距离银河系中心大约有27000光年就比说这个距离是255439722759681600000米更容易让人理解
抽象有两种方法，一种是自顶向下，另一种是自底向上。
自顶向下的方法适用于让人们从头认识一个事物；
自底向上的方法适用于在实践中改进和提高认识。
软件开发中，主体上应当采用自顶向下的方法，用少量的概念覆盖系统需求，再逐步降低抽象层次，直到代码编写。同时应当辅以自底向上的方法，通过总结在较低抽象层次的实践经验来改进较高层次的概念以提升软件质量。
四、视图
视图用于组织UML元素，表达出模型的某一方面的含义。
视角是人们观察事物的角度。
针对每个视图来说，不同的视角展示了同样信息的不同认知角度以便于理解。
在建模里，UML里定义了用例图、对象图、类图、包图、活动图等不同的视图，不同类型的视图表示从不同的视角描述了一个软件的结构和组成，而所有这些视图的集合表达了一个软件的完整含义。
一个好的模型，需要为特定的信息选择正确的视图，为特定的干系人展示正确的视角。
五、对象分析方法
一切都是对象
在面向对象方法里，一切有名字的东西都是对象，都应当使用对象的观点来看待它。
对象都是独立的
对象和对象之间都是天然独立的，只有在某个特定场景下，它们的某一个特定实例才相互联系在一起。
对象都具有原子性
无论在什么时候，在分析过程中都应当将对象视为一个原子，原子是个整体，内部不可分割，外部通过边界和其他对象对接。这种方式也叫做面向接口编程。
对象都是可抽象的
对象参与每个场景时都会展现其某一个方面性质，这方面性质都可以抽象出来。对象所参与的场景越多，其越具有抽象价值。
对象都有层次性
对象都是有抽象层次的，高层次描述粗略但适应范围广，低层次描述精确但适应能力窄。需要根据问题领域的复杂程度设定多个抽象层次并使用合适的抽象程度对象进行描述。
（三）UML核心元素之参与者、用例
一、版型
在UML里有一个概念叫版型（stereotype），也被称为类型、构造型。
版型是由UML里的元素扩展而来，每个元模型都有很多版型，比如用例有“业务用例”、“业务用例实现”等版型。当我们需要时候我们也可以根据UML里的元素自定义版型来辅助建模。
二、参与者
参与者（actor）是在系统之外与系统交互的某人或某事物，在建模过程中处于核心地位。
参与者和系统之间有一个明确的边界，参与者只能存在于边界之外，边界之内的所有人和事物都不是参与者。
每个用例都必须有参与者，参与者可以非人，但一定是启动业务的主角。
三、业务主角和业务工人
业务主角（business actor）是参与者的一个版型，用于定义业务的参与者。业务主角是与业务系统有着交互的人和事物，他们用来确定业务范围。
业务范围：项目所涉及的所有客户业务，有没有计算机系统参与都客观存在；
系统范围：软件将要实现对应业务的系统功能。
业务主角是针对业务范围来说的，是客观存在的，考虑业务主角时候需要抛开计算机的概念，这样才能彻底搞清楚客户的业务。
接下来这段完全就是我的亲身经历，所以贴上来以作鞭策。
业务工人（business worker）是指的系统边界内，被动参与了业务的执行过程的人。
四、参与者相关关系
涉众（stakeholder），也称为干系人，是与要建设的这个系统有利益相关的一切人和事。参与者就是涉众代表，对系统提出要求来获得他所代表的涉众的利益。
用户（user），指的是系统的使用者，是参与者的代表，一个用户可以代理多个参与者。
角色（role），指的是参与者的职责，一个角色代表了系统中的一类职责。
五、用例
用例的基本概念
用例（Use case）是一种把现实世界的需求捕获下来的方法。用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值。
在UML里，除了用例之外，所有其他元素都是封装独立的。用例推动这些UML元素关联起来，从而实现某个功能。所以说用例是UML建模中最重要的一个元素。
一个完整的用例定义由参与者、前置条件、场景、后置条件构成。如下图所示：
一个系统的功能性是有一些对系统有愿望的参与者要做的一些事情构成的，事情完成后就达成了参与者的一个愿望，当全部参与者的所有愿望都能够通过用例来达到，那么这个系统就被确定下来了。
用例的特征
用例是相对独立的。
用例的执行结果对参与者来说是可观测和有意义的。
这件事必须由一个参与者发起。不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。
用例必然是以动宾短语形式出现的。
一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至部署单元。
用例的粒度
用例的粒度是指的一个用例所描述事件的大小。
在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜，即一个用例可以描述一项完整的业务流程。
在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。
现实情况中，根据系统的大小选择不同用例粒度，可以更好适应其需求范围。
不论粒度如何选择，必须把握的原则是在同一个需求阶段，所有用例的粒度应该是同一个量级的。
用例的获得
用例的来源就是参与者对系统的期望。
一个明确的有效的目标才是一个用力的来源。
一个真实的目标应当完备地表达主角的期望。
一个有效的目标应当在系统边界内，由主角发动，并具有明确的后果。
六、用例相关的误区
用例和功能的误区
用例需要从使用者的观点出发来描述软件；功能是脱离使用者的愿望而客观存在的。
用例是系统性的，以开灯为例，需要描述谁在什么情况下通过什么方式开灯结果是什么；功能是孤立的，只要按下开关灯就亮。
用例可以解释为一系列完成一个特定目标的功能的组合，针对不同的应用场景，这些功能体现不同的组合方式。
目标和步骤的误区
一个用例是参与者对目标系统的一个愿望，一个完整的事件，为了完成这个事件需要经由很多步骤，但这些步骤不能够完整地反映参与者的目标，不能够作为用例。
用例粒度的误区
用例的粒度不是越小越好，太小了会使建模无比繁琐且没意义；
一个系统里用例粒度如果不一，会使系统边界不确定，从而系统结构混乱。
七、业务用例和业务用例实现
业务用例（business use case）是用例版型中的一种，专门用于需求阶段的业务建模。
业务模型是针对客户业务的模型，与计算机系统建模无关，只是业务领域的一个模型。
业务用例的参与者是业务主角，如果说用例是用来获取功能性需求，那么业务用例用来获取功能性业务。
业务用例实现（business use case realization）是用例版型中的一种，专门用于需求阶段的业务建模。
业务用例实现是业务用例的一种实现方式，表达了同一项业务的不同实现方式。
业务用例和业务用例实现的关系举例如图
（四）UML核心元素之边界类、实体类
一、边界
边界在UML图符里定义只是一个简单的矩形框，矩形框的四个边决定了边界的内外。
边界本质上是面向对象方法的一个很重要的概念，与封装的概念相似。在面向对象里，任何一个对象都有一个边界，外界只能通过这个边界来认识对象，与对象打交道。
边界决定视界；
边界决定抽象层次。
边界是无形的，但是在面向对象的方法里，从业务建模到接口设计边界都可以发挥重要的作用。
二、业务实体
业务实体是类的一种版型，特别用于在业务建模阶段建立领域模型，代表业务角色执行业务用例时所处理或使用的“事物”。
业务实体是来自现实世界的，所有业务实体在现实世界里都有与之对应的事物；
业务实体一定是在分析业务流程的过程当中发现的，与业务用例场景无法的事物，即使存在，也不会为它建模；
业务实体具有对象的所有性质，包括属性、方法和对象的独立性。
属性是用来保存业务实体特征的一个记录，业务实体的属性集合决定了它的唯一性；
方法是访问一个业务实例的句柄，它规定了外部可以怎样来使用它。
获取业务实体：
- 建立业务用例场景；
- 从业务用例场景中逐个分析动词后面的名次，它们就是业务实体的备选对象；
- 分析这些业务实体之间的关系，并决定哪些应当单独建模，哪些应当作为属性。
三、包
包是一种容器，就如文件夹一样。
包可以容纳任何UML元素，也包括子包。包之间的关系定义只有依赖关系，好的分包具有高内聚，低耦合的性质。
- 领域包（Domain Package）用于分类业务领域内的业务单元，每个包代表业务的一个领域，领域包视图可用于展示这些业务领域的高层次关系；
- 子系统（Subsystem）用于分类系统内的逻辑对象并形成子系统，子系统包视图可用于展示系统的高层次逻辑结构关系；
- 组织结构包（Organization unit）用于分类业务领域中的组织结构，它可以直接用来表述企业的资质结构；
- 层包（Layer）用于分类软件中的层次，层可以用于展示软件的架构信息。
四、分析类
分析类用于获取系统中主要的“职责簇”，代表系统的原型类，是系统必须处理的主要抽象概念的“第一个关口”。
分析类可以产生系统的的设计类和子系统。
分析类是从业务需求向系统设计转化过程中最为主要的元素，它们在高层次抽象出系统实现业务需求的原型，业务需求通过分析类逻辑化，被计算机所理解。
分析类包含三种，分别是边界类（boundary）、控制类（control）和实体类（entity）。
边界类
边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。
- 参与者与用例之间应当建立边界类；
- 用例与用例之间如果有交互，应当为其建立边界类；
- 如果用例与系统边界之外的非人对象有交互，比如第三方系统，应当为其建立边界类；
- 在相关联的业务对象有明显的独立性要求，也应当为它们建立边界类。
从架构角度上来说，边界类主要位于展现层。
控制类
控制类用于对一个或几个用例所特有的控制行为进行建模。
控制类来源于对用例场景当中动词的分析和定义，包括限制动词的描述。
从架构角度上来说，控制类主要位于业务逻辑层。
实体类
实体类是用于对必须存储的信息和相关行为建模的类。
实体类源于业务建模中的业务实体。
从架构角度上来说，实体类主要位于数据持久层。
分析类的三高
分析类是从业务需求向系统设计转化过程中最为主要的元素，它们在高层次抽象出系统实现业务需求的原型，业务需求通过分析类被逻辑化，成为可以被计算机理解的语义。
- 高于设计实现
- 高于语言实现
- 高于实现方式
分析类的抽象层次较高，只需要专注在实现需求上，也因此比设计和实现更加稳定。
五、设计类
设计类是系统实施中一个或多个对象的抽象，设计类所对应的对象取决于实施语言。设计类用于设计模型中，它直接使用与编程语言相同的语言来描述。
设计类由类型、属性和方法构成，设计类的名称、属性和方法也直接映射到编码中相应的class、property和method。
类
类对对象进行定义，而对象又实现用例。
类是对对象某一方面特征的归纳和抽象，而对象则是类实例化的结果。
属性
属性是对象特征，属性同时表明了对象的唯一性。
方法
方法是访问对象或影响其他对象的属性或关系的唯一途径，由类进行定义。
可见性
类的属性和方法都有可见性的定义，常见的有：
- 公有：除了类本身以外，属性和方法对其他模型元素也是可视的。
- 保护：属性和方法只对类本身、它的子类或友元是可视的。
- 私有：属性和方法只对类本身和类的友元是可视的。
- 实施：属性和方法只在类本身的内部是可视的。
（五）UML核心元素之关系、组件和节点
一、关系
关系抽象出对象之间的联系，让对象构成某个特定的结构。
关联关系（association）
关联关系是用一条直线表示的，描述不同类的的对象之间的结构关系。
单向关联关系是用一条带剪头的直线来表示，表明A关联B，但是B不关联A，比如用力模型里，参与者单向关联用例。
依赖关系（dependency）
依赖关系是用一条带箭头的虚线表示的，用来描述一个对象的修改会导致另一个对象修改。
依赖关系也有单向依赖和双向依赖之分，但双向依赖非常不推荐。
扩展关系（extends）
扩展关系是用一条带箭头的虚线加版型<
扩展用例是用例场景中的某个“支流”，是一种可选的，即使该扩展用例不存在，其基本用例也是完整的。
使用场景有：
表明用例的某一部分是可选的系统行为；
表明只在特定条件下才执行分支流，比如触发警报；
表明可能有一组行为段，其中的一个或多个段可以在基本用例的扩展点处插入；
表明多个基本用例中都有可能出发一个可选的分支流。
包含关系（include）
包含关系是用一条带箭头的虚线加版型<
包含用例是用例场景里关键的核心业务，是一种必选的，如果包含用力不存在，其基本用例也就不完整了。
使用场景有：
从基本用例中分解出这样的行为：它对于了解基本用的主要目的并不是必需的，只有它的结果比较重要；
分解出两个或更多个用例所共有的行为。
实现关系（realize）
实现关系是用一条带空心箭头的虚线表示，特别用于在用例模型中连接用例和用力实现，说明基本用例的一个实现方式。
实现所代表的含义是，基本用例描述了一个业务目标，但是该业务目标有多种可能的实现途径，每一种实现途径可以用用例实现来表示，而用例实现和基本用例之间就构成了实现关系。
精化关系（refine）
精化关系是用一条带剪头的虚线加版型<
精化关系也可以用于模型与模型之间，表示某个模型是通过精化另一个模型而得来的。
精化关系的子对象并没有增加、减少、改变基本对象的行为和属性，仅仅是更加细致和明确化。
泛化关系（generalization）
泛化关系是用一条带空心箭头的直线表示，说明两个对象之间的继承关系。
泛化关系的子对象继承了基本对象的所有特征，并且子对象可以增加、改变基本对象的行为和属性。
聚合关系（aggregation）
聚合关系是用一条带空心菱形箭头的直线表示，常用于类图，表达实体整体由部分构成的语义。
聚合关系的整体和部分不是强依赖，即使整体不存在了，部分仍然存在。
组合关系（composition）
组合关系是用一条带实心菱形箭头的直线表示，常用于类图，表达实体整体拥有部分的语义。
组合关系是一种强依赖的特殊聚合关系，如果整体不存在了，部分也将消亡。
二、组件
组件是系统中实际存在的可更换部分，符合一套接口标准并实现一组接口。
一个组件应当是一个独立的业务模块，有着完备的功能，可独立部署，一个组件可以看成是一个完备的服务。
组件一般都是在较高的抽象层次定义的，在许多应用项目中并不需要组件建模。但是，如果采用了组件化的开发架构，或者从一开始就决定采用组件化开发模式，那么从系统分析开始就应当着手建立组件模型，并在后续的模型中逐步精化。
三、节点
节点是带有至少一个处理器、内存以及可能还带有其他设备的处理元素。
在实际工作中，一般说来服务器、工作站或客户机都可以称为一个节点。
（六）UML核心视图之静态视图：用例图、类图
静态视图
静态视图就是表达静态事物的，只描述事物的静态结构，不描述其动态行为。
用例图
用例图采用参与者和用例作为基本元素，以不同的视角展现系统的功能性需求。
对客户来说，用例图是他们业务领域的逻辑化表达；对建设单位来说，用例图是系统蓝图和开发的依据。
业务用例视图
业务用例视图需要从业务主角和业务模块两个视角来展现业务建模的结果。
从业务主角的视角有利于向业务主角确认其业务目标是否都已经齐全。
从业务模块视角有利于从业务的完整性角度出发检查完成某个业务的所有业务主角和业务用例是否已经齐全。
业务用例实现视图
业务用例实现视图展现业务用例有哪些实现途径。
业务用例是业务需求，而业务用例实现则是业务的实现途径。
概念用例视图
概念用例视图用于展现从业务用力中经过分析分解出来的关键概念用例，并表示概念用例和业务用例之间的关系，包括扩展、包含和精化关系等。
系统用例视图
系统用视图以业务用例为单位，将对业务用例进行分析后得到的系统用例展现出来。
系统用例实现视图
系统用例实现视图展现系统用例的实现方式。
小结
用例图包括业务用例视图、业务用例实现视图、概念用例视图、系统用例视图和系统用例实现视图。
在实际项目中，不是所有的用例图都一定要采用。根据情况可进行适当裁减，在许多项目中实际只有系统用例视图。
类图
类图用于展示系统中的类及其相互之间的关系。
类图是现实世界问题领域的抽象对象的结构化、概念化、逻辑化描述。
概念层类图
概念层类图位于业务建模阶段，描述的是现实世界中问题领域的概念理解，以领域模型图来表示的。
说明层类图
说明层类图位于概念模型阶段，描述的是问题领域在接口层次的抽象描述，以分析类和分析模型图来表示。
实现层类图
实现层类图位于设计阶段，描述的代码的实现，类图中的类直接映射到可执行代码，必须明确采用哪种实现语言、什么设计模式、什么通信标准、遵循什么规范等。
（七）、UML核心视图之动态视图：活动图、时序图
动态视图
动态视图是描述事物动态行为的，不能独立存在，必须特指一个静态视图或UML元素，说明在静态视图规定的事物结构下它们的动态行为。
活动图
活动图描述了为了完成某一个目标需要做的活动以及这些活动的执行顺序。
UML中有两个层面的活动图，一种用于描述用例场景，另一种用于描述对象交互。
活动图实际上描述的是业务流程，是一种过程化的分析方法，因此在使用活动图时候，要随时保持清醒的头脑，活动图只是我们用来描述业务目标的达成过程并借此来发现对象的工具，不是我们的分析目标，也不是编程的依据，它只是对象的应用场景之一。
用例活动图
用例表达了参与者的一个目标，用例场景则描述了如何来达到这个目标，而活动图用来描述用例场景，也就是业务流程。
对象活动图
对象活动图用于展示对象的交互。
泳道
活动图描述了业务流程中活动的执行顺序，却没有描述出执行业务流程的职责；而在面向对象的分析观点里，业务的执行过程不是重要的，对象职责才是最重要的。所以引入了泳道技术。
泳道代表了一个特定的类、人、部门、层次等对象的职责区。将登机的用例活动图加入泳道以后，可以得到：
业务场景建模
在实际情况中，客户的业务通常是以业务流程的形式存在的，所以我们经常以业务主角作为泳道，以从业务主角出获取的业务用例作为活动来编排活动图。这样的好处有：
帮助发现业务用例
帮助检查业务用例粒度
帮助检查业务主角
帮助检查业务用例
用例场景建模
在获取业务用例之后，我们经常以业务主角和业务工人作为泳道、以工作单元作为活动来编排活动图来描述用例场景。这样的好处有：
帮助发现概念用例
帮助发现角色
帮助发现业务实体
帮助建立领域模型
时序图
时序图用于描述按时间顺序排列的对象之间的交互模型
时序图中包含对象和主角实例，以及说明它们如何交互的消息，主要用来确定对象的职责和接口。
业务模型时序图
业务模型时序图用于为领域模型中的业务实体交互建模，目标是实现业务用例。
概念模型时序图
概念模型时序图是依据业务模型场景采用分析类来重新绘制一遍，目标同样是实现业务用例。
因为分析类本身代表了系统原型，所以这时的时序图已经有了实现的影子。
设计模型时序图
设计模型时序图使用设计类作为对象绘制，目标是实现概念模型中的某个事件流，一般以一个完整交互为单位，消息细致到方法级别。
因为设计模型时序图工作量实在太大，不需要为每一个交互都绘制时序图，但一定要有足够的概念模型时序图来支撑需求与实现之间的过渡。
（八）、项目开始前的准备工作
一、了解问题领域
软件是一种工具，是用来辅助人们解决某一问题的。软件的价值就在于它能够符合问题领域的需要，并达到人们解决问题的期望。软件项目总是从了解问题领域开始的。
1.了解业务概况
2.整理业务目标
二、做好涉众分析
在了解业务概况和业务目标以后，首先要做的不是去了解业务的细节，而是去发现与这个目标相关的人和物。
1.什么是涉众。涉众是与要建设的业务系统相关的一切人和事，他们与项目有利益关系，都可能对系统建设造成影响。
2.如何发现和定义涉众。
业主：系统的出资方、投资者——关心的是建设成本、建设周期以及建成后的效益。
业务提出者：业务范围、业务模式和业务规则的制定者——关心系统建设能够带的社会影响、效率提升、管理改进、成本节约等宏观效果。
业务管理者：实际管理和监督业务执行的人员——关心系统将如何实现他们的管理职能，如何下达指令、如何得到反馈、如何评估结果等。系统建设的好坏与业务管理者的关系最多，也是系统分析员最需要下功夫的。
业务执行者：底层的业务操作人员——关心系统会给他们带来什么样的方便，或怎样的改变他们的工作模式。
第三方：与这项业务有关系的，但并非业务方的其他人或事——对系统不会产生决定性影响，但大多会起到限制作用。
承建方：你的老板——关心通过这个项目是否能赚到钱、是否能积累核心竞争力、是否能树立品牌、是否能开拓市场。
相关的法律法规——既指的国家和地方法律法规，也指的行业规范和标准。
用户：预期的系统使用者，涉众代表——实实在在参与系统的，需要编程实现的系统中一个角色。
3.涉众分析报告
涉众概要：为每个涉众进行编号，并说明涉众的基本信息和涉众在系统中的角色。涉众分析时候最重要的是准确描述涉众情况和他们对系统建设的期望，而不是进入业务细节。
涉众简档：描述涉众在系统中承担的职责，以及涉众在系统中的成功标准。
用户概要：说明代表涉众使用系统的用户说明。业务需求来自于涉众，但是界面需求很可能来自预期的系统用户。
用户简档：将一些典型的用户代表的一些信息描述出来。
消费者统计：说明系统的预期使用人群和他们的特点，使用系统的频率和方式，消费者对此系统的普遍期望等。
三、规划业务范围
在开始进行需求之前，必须先规划业务范围。这个范围并不是指系统的建设范围，而是指出需求调研应当被局限在哪些部分。
1.规划业务目标
取消一个业务目标；
调整一个业务目标。
2.规划涉众期望
取消一个涉众；
减少一个涉众期望；
调整一个涉众期望。
四、整理好你的思路
根据涉众分析报告就可以有的放矢地根据涉众关心的问题规划出需求调研计划。
1.划分优先级
涉众优先级标准：根据涉众是业务核心成员、主要业务模块的参与者还是边缘业务模块的参与者进行排序；
期望优先级标准：根据期望是核心业务、核心业务的重要辅助部分还是一些边缘业务进行排序划分。
优先级矩阵：
2.规划需求层次
第一层次：业务架构。围绕业务背景、业务目标、业务目标人员、业务参与人员、组织结构、岗位设置等展开，建立业务用例模型的业务用例视图、领域模型视图。
第二层次：业务流程。针对每个业务目标，将参与这个业务目标的业务目标人员。业务参与人员。组织结构和岗位设置组织起来，建立业务用例实现、用例场景、分析场景在内的完整业务用例模型和概念模型。
第三层次：工作细节。针对每个参与上述业务流程的参与者展开，建立系统用例模型、初步的分析模型和初步的软件架构。
3.需求调研计划
需求调研计划是项目计划的一部分，该计划规定了哪些优先级的期望在什么时候进展到什么需求层次，由谁来负责。
五、客户访谈技巧
1.沟通的困难
一般来说系统分析员是计算机专家，习惯于从计算机角度来看问题；客户是业务专家，习惯身边的人也熟悉这个业务领域。
所以系统分析员需要改变自己的立场，了解业务是什么，还要弄清业务为什么。
首先，应该有一个详细的涉众分析报告，循序渐进地从接触到深入了解客户；
其次，不要急于深入业务细节，而是先就一些大框框进行沟通，借此习惯和了解对方的沟通方式；
再次，双方的时间是有限的，因此每一次会面都需要争分夺秒，用最快的时间把问题搞清楚；
最后，系统分析员需要承担每次会谈结果记录，并且需要正式的反馈和确认，以便之后和客户在需求变更时候有依据。
2.沟通的技巧
建立平等的对话平台——系统分析员应当首先学习业务相关的背景知识，在与客户交谈过程中不仅仅是询问和聆听，还要参与；其次，适当将技术与业务结合起来，以浅显易懂的方式引导客户理解一些技术层面的知识；
做足准备工作——在短时间内把粗略的业务搞清楚，谈话过程中不仅是充当提问者和聆听者的角色，而且要能和客户就某些业务问题交换意见，才能得到客户的信任，引起交流的兴趣；
以我为主——每次谈话都要有明确的目标；
改变沟通策略——了解对方的沟通习惯和思维方式，并根据这个适当改变沟通的策略；
把握需求节奏——每次不要涉及太多的问题，把握好需求层次；
记录和反馈——记录每次谈话的结果，形成文档后交还给客户阅读。
（九）、需求获取
一、定义边界
定义边界的目的是为我们确定一个分析的起点。
每个业务目标都会有一个边界存在，每个边界的划分则指明了需求分析的起点。
二、发现主角
不是所有的涉众都会成为业务主角，只有那些直接与系统交互的涉众才能被称为业务主角。一个涉众可以衍生出多个主角。
涉众虽然是系统的利益相关者，但却未必直接与系统交互，他可以找到替代他行使利益的另一个角色。
业务主角总是在边界之外，只有边界之外的事物才有权利向由边界代表的系统提出要求。
业务主角可能带代表了多个涉众利益，对系统也有着许多要求，但是对于一个特定的边界来说，由于边界代表了某个业务目标，那些与业务目标无关的要求也不应当在该边界中体现出来。
业务主角，之所以加上业务二字，是因为业务主角确实区别于系统参与者，它有可能不会转化成一个系统参与者，但能够映射到现实业务中的工作岗位设置、工作职能说明。
三、获取业务用例
获取业务用例的方法有很多，可以从岗位手册、业务流程指南、职务说明等一些文件中获得，也可以从涉众分析中获得灵感。
除此之外，还一种方法就是业务主角访谈，可以通过以下问题引导业务主角代表说出他们的业务需求：
您对系统有什么期望
您打算在这个系统里做些什么事情？
您做这件事的目的是什么？
您做完这件事希望有一个什么样的结果？
业务用例找到了后，还应当用适当的视图把它们展现出来。
业务用例获取到已经把客户的业务弄清楚了就可以考虑结束了，不必等到事无巨细每件事都定义清楚。可以采用迭代式开发。
四、业务建模
业务用例场景用来描述该业务的实际过程中是如何做的，主要用到了活动图、时序图、协作图。
活动图侧重于描述参与业务的各个参与者在该业务当中所执行的活动。这种图适合于分析参与者的职责，并且有利于将业务用例分解成为更小的单元，为获得概念用例乃至系统用例带来好处。
时序图用于描述对象之间按一定的顺序互通消息而完成一个特定的目标。
活动图和时序图的差别：
活动图强调职责，时序图强调顺序；
活动图中活动是主要的内容，表达的内容是业务主角或业务工人做什么；时序图中，消息是主要的内容，表达的内容是业务主角或业务工人之间传递的是什么。
协作图本质上与时序图是可以互换的，只是表达不同的视角。
五、领域模型
领域是我们分析问题时将整体分解以后的相对独立的部分。
实际工作中，并不需要把问题完全分解成领域，也不需要为每个领域都建模，而只挑选那些对业务来说重要的、对过程来说核心的或者对系统来说复杂和困难的哪些部分来建模。
提出领域问题
了解关心该领域的所有可能的涉众是如何理解和要求该领域的。问题来源于业务核心、重点、难点，也可能来源于特殊的应用环境或客户特殊的要求，
分析领域问题
根据提出的领域问题提出假设，再获取解决方案。
建立领域模型
绘制出领域模型静态图，绘制出领域对象、领域对象之间的关系以及领域对象与业务对象之间的关系。
验证领域模型
验证领域模型的正确性以及业务用例如何使用这些领域模型。
领域模型和用例分析方法
用例分析方法可以说明一个系统的功能性需求，但是对于一个关联性的问题，因为用例本身是独立的，无法表达涉及跨越多个用例的问题。此时用领域模型可以很好解决这个问题。
用例分析方法只能够分析功能性需求，对于非功能性需求只能用领域模型来分析。
问题领域的原则
1.简单需求无需建立领域模型；
2.只针对核心业务建立；
3.针对难点建立；
4.关注非功能性需求。
领域模型与用例模型
在针对功能性需求时候，领域模型是对用例模型的抽象、优化和扩展。
六、提炼业务规则
业务规则是用来指导人们怎么做系统。
全局规则
全局规则是指那些对于系统大部分业务或系统设计都起约束作用的规则，主要用来限制功能性需求。
交互规则
交互规则产生于用例场景当中，活动转移、状态变迁和对象交互时必然会有的一些限制性条件。
内禀规则
内禀规则是指那些业务对象本身具备的，并且不因为外部的交互而变化的规则。
七、非功能性需求
可靠性
可靠性包括安全性、事务性和稳定性三个方面
可用性
可用性用来衡量人们使用一个软件产品的满意程度
有效性
有效性包括性能、可伸缩性、可扩展性三个方面。
可移植性
（十）、需求分析
一、关键概念分析
关键概念是指支撑起客户整个业务架构的那条主线，在UML方法里，就是由一些关键的业务用例构成。
需求分析就是要找到这些关键的业务用例，并且对它们进行分析，建立概念模型，依据概念模型搭建业务架构，然后为了验证这个架构或者进行技术可行性分析开发出系统原型。
概念模型始于业务用例，是针对需求中的关键业务，或者说业务核心来建立的。
概念模型是需求转入系统之间的桥梁。
获取概念用例
概念模型的构建是通过围绕业务主线，从业务用例当中挑选出一些业务用例进行关键概念分析。
当关键业务用例挑选出来之后，根据业务主线的需要，为这些业务用例找出概念用例。
分析概念用例
分析概念用例的过程也业务用例建模一样，仍然是绘制概念用例的场景图（活动图、时序图等），然后从中找到关键的对象，最后再为这些关键对象绘制一些协作图以说明这些对象之间的关系和交互场景。
建立概念模型
每分析清楚一个概念用例，就能得到它的关键对象。
关键对象都是一些实体对象，需要采用MVC模式进行分析，用这三个元素建立实现用例场景的对象模型。
每个概念模型表示一个功能，各个概念模型之间通过软件架构联系起来。
领域模型和概念模型
概念模型不一定针对业务，针对的是问题，这些问题可以与业务无关。
概念模型是只针对业务的，它要解决的问题从业务理解向系统理解转化之前，通过概念建模来在项目早起发现并解决问题。
二、业务架构
一个基本原则：技术服务于业务。
业务架构，实际上就是对需求细致分析和深刻理解的基础上，抽象出若干相对独立的业务模块，形成自洽的业务构件。
从概念模型入手，根据找到业务主线找到每个大的业务构件，再通过领域模型分解为小的构件,再根据概念模型找到各个小的构件之间的依赖关系。
每个业务构件的产生都来自于各类模型和场景，都是“功能点”的集合。
业务构件可以封装业务实体以及对业务实体的处理，也可以只封装处理逻辑。
业务架构是拼图单元的话，软件架构就是拼图的方法，可以说业务架构+软件架构=业务系统。
建模的价值，关于每种模型的价值，可以更深的感受下：
三、系统原型
抛弃型原型，就是当原型目的达到后，原型的使命也就结束了。主要用于验证核心业务的理解是否正确。
渐进型原型，从开发原型时，就考虑将来要在它基础上逐步完善，乃至形成最终系统。主要用于吧核心业务、业务架构和软件架构结合起来。
（十一）、系统分析
一、确定系统用例
系统用例由业务用例抽象而来，系统用例描述系统，业务用例描述业务。
业务用例抽象为系统用例的基本方法有：
映射：映射是最简单最直接的方法；
抽象：当业务场景当中的备选用例不能够被直接映射时，需要进行一些抽象；
合并：当业务场景当中的备选用例不具备独立性时，它必然是其他某个时间的组成部分；
拆分：有时业务用例场景当中的一个备选用例粒度很大，就需要进行拆分；
演绎：有时业务用例场景当中找不到备选用例，或者不适合用计算机来实现，但是能够遇见到某个可能的系统用例潜伏在这个场景当中，就需要演绎找出来。
在确定系统用例后，可以采用活动图、时序图、交互图等进行系统用例的描述。
软件工程当中，需求的可追溯性是很重要的。从业务需求到系统需求的过程关键就在映射、抽象、合并、差分和演绎的过程能否被记录下来。
根据阶段不同，使用不同的粒度：在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜；在概念建模阶段，用例的粒度以每个用例能描述一个完整的事件流为宜；在系统建模阶段，用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。
二、分析业务规则
业务规则对一个组织的运转来说至关重要，从管理制度到业务手册、从操作规范到岗位指南，业务规则充斥着整个企业的方方面面。
分析业务规则的目的是从业务规则当中发现出那些将对系统构成重大影响的部分，将其转化为系统需求，并且针对这一部分进行有针对性的架构、框架、程序的设计。
分析全局规则
全局规则是那些对于系统大部分业务或系统设计都起约束作用的那些规则。
全局规则在应用程序当中就被反应到了软件结构当中，通过软件架构来对用例产生影响。
分析交互规则
交互规则产生于用例场景当中。用例场景是由活动图、交互图等来描述的，不论是活动、状态还是业务对象，它们在活动转移、状态变迁和对象交互时必然会有一些限制性条件，这些条件就是交互规则。
交互规则产生于用例场景当中，很可能是跨用例的，为了避免依赖的出现，应当将较复杂的交互规则设计成单独的对象或模块。
分析內禀规则
内禀规则是业务对象本身具备的，并且不因为外部的交互而变化的规则。
内禀规则非常类似于对象的封装原则，所以交给程序员来处理即可。
三、用例实现
一个用例可能有多个用例实现，每个用例实现都是设想的一种实现方式。
要为用例实现建模，我们需要经过一下三个步骤：
1.需要再用例场景当中发现和定义实体对象；
2.需要用控制对象来操作和处理实体对象当中的数据；
3.需要用边界对象来构建接受外部指令的界面。
用边界对象、控制对象和实体对象实现场景后，我们就得到了分析类图。
分析类是高层次抽象出系统实现业务需求的原型，业务需求通过分析类被逻辑化，成为可以被计算机理解的语义。分析类抽象层次高于设计实现，高于语言实现，也高于实现方式。
高于设计实现意味着，在为需求考虑系统实现的时候，可以不理会复杂的设计要求，专心地为从需求到实现搭建一座桥梁；
高于语言实现意味着，在为需求考虑系统实现的时候，可以不理会采用哪一种语言来编写，而能专注在需求实现上；
高于实现方式意味着，在为需求考虑系统实现的时候，可以不考虑采用哪一种具体实现方式，只需要用一个程序逻辑来完成需求即可。
四、软件架构和框架
架构设计考虑使用一个软件层次结构、一个或多个软件框架以及连接这些软件层次和软件框架之间的接口，将功能性需求和非功能性需求有机结合在一起，在进行系统设计之前就充分考虑到了系统各功能部件如何在整个系统内安置。
软件架构是一种思想，一个系统蓝图，对软件结构组成的规划和职责设定。软件架构的意义就是要将这些可逻辑划分的部分独立出来，用约定的接口和协议将它们有机地结合在一起，形成职责清晰、结构清楚的软件架构。
软件框架是是软件架构的一种实现，是一个半成品。它通常针对一个软件架构当中某一个特定的问题提供解决方案和辅助工具。
五、分析模型
分析类的推导过程为：
1、通过用例确定了系统需求；
2、通过用例实现，得到了系统需求的计算机视角理解；
3、规定了软件架构，确定了软件层次；
4、在每一个软件层次上决定了适用的软件框架；
5、分析了用例实现在每个软件层次上是如何动作的；
6、根据每个软件层次上所使用的软件框架并使用分析类来实现用例；
7、综合各个软件层次得到的分析类，形成分析模型；
8、得到实现了系统需求最基本的类和类方法。
六、组件模型
组件是用来容纳分析类或设计类的，建立组件的目的是为了将一些类组织在一起完成一组特定的功能。
组件可以看成一种特殊的包，不应当包含实现细节，只包含服务的接口，同时只维护调用服务的实现方式。
组件是可复用的单元。
组件是可独立变化的单元。
组件是可独立部署的单元。
组件可在软件架构支持环境下自由组装。
七、部署模型
部署模型又称为实施模型，它主要的作用就是定义构成应用程序的各个部分在物理结构上的安装和部署位置。
部署模型与应用程序和运行环境有关。
（十二）、系统设计
一、系统设计和系统分析的差别
系统分析是在不考虑具体实现语言和实现方式的情况下，将需求在软件架构和框架下进行的计算机模拟。
系统分析的目的是确定系统应当做成什么样的设想，而系统设计的目的是将这些设想转化为可实施的步骤。
二、设计模型 将分析模型里边界类、实体类和控制类根据所选用的实现语言变成设计类，细化一下已有方法，补充一些类属性，就完成了最基本的设计模型。
如果系统中许多功能具备相似的实现模式，则没有必要逐一建立设计模型。
为相似的功能建立指导性的设计模型，为复杂和特殊的功能建立设计模型。
三、接口设计
应当为每一个对象都设计接口，每个接口都对应一个实现类。
为具有相似行为的对象设计接口，将相同的行为提取出来形成接口。
为软件各层次设计接口，各层之间交互过程通过接口完成。
四、包设计
软件世界分包的应当遵循自顶向下原则、职能集中原则和互补交叉原则。
自顶向下的原则，分包时要像组织机构一样，从顶级包自顶向下延伸，避免平行化无层次分包。自顶向下的另一个重要含义是下层包不能够访问上层包，并且不能够跨层访问包，但同层次的包可以互相访问。
职能集中的原则，分包时尽量将与一组业务功能有关的类分在同一个包里。
互不交叉的原则，分包时包与包之间的类尽量独立，不要让他们产生相互依赖关系。
避免交叉依赖有两种方法，一种是将交叉依赖的类单独分包；另一种是增加新的类，并单独分包。
（十三）、在提炼中思考
一、理解用例的本质
用例是系统思维
系统是一个封闭的、由一系列相互关联、相互影响的物质构成的集合。所谓系统思维，就是考虑系统内事物的互相影响，归纳、抽象系统内的运行规律。
软件不是孤立存在的，在设计时我们必须将软件置于它所处的系统环境中：使用者、硬件、网络、应用环境等，并采用系统思维来分析和设计它。
用例具有系统性：
用例是相对独立的；
不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例；
用例的执行结果对参与者来说是可观测的和有意义的；
用例必然是以动宾短语形式出现的。
用例是面向服务的
面向服务架构的第一条准则是：业务驱动服务，服务驱动技术。
SOA的开发过程与用例的分析过程也有着极高的相似程度。
二、理解用例驱动
用例与项目管理
在项目管理中，工作包占据了非常重要的地位。
在UML里，系统用例实现就是项目管理中的工作包。
项目管理中，一个工作包的工作量控制在1至2个人周是比较容易控制的；在系统用例里，如果工作量大于这个时间，则需要通过用例实现来减少每个工作包的工作量。
用例与可扩展架构
业务驱动技术，一个好的可扩展架构是基于好的业务架构之上的。
业务架构从用例而来，每个用例定义了参与者对系统的要求，而业务系统，则需要将这些相对独立的业务单元结合起来，形成更大的业务。
在需要扩展的系统里，用例与用例之间必须避免紧耦合。
可扩展架构，其关键就在如何定义每个用例的接口，以及如何使用是和的技术架构来保证业务单元之间的交互来提供可扩展能力。
用例不但驱动软件过程，也驱动技术架构。
三、理解建模的抽象层次
将事物按层次划分是人们归纳和理解事物的重要形式。
层次不交叉，在描述事物的过程中，同一层的描述内容是“等值”的。
在进行分析设计之前，应当根据业务的复杂程度事先决定需要用多少个抽象层次来描述，并定义每个抽象层次要解决的业务问题，或者说定义每个抽象层次的关键特征。
UML建模是以用例为基础的，用例的粒度则和抽象层次直接相关，
四、划分子系统的问题
计算机子系统描述了一个软件的内部构成，它的划分依据是对象依赖，目标是构建扩展下好的软件结构；
业务子系统描述的是软件的展现形式，以用户部门或者业务为依据进行划分。
用户所谓的子系统，只是软件展示出来的样子，从面向对象的观点来看，软件内部应当维持最佳的对象结构，然后通过接口向外部展现外部所需要的样子。
五、学会使用系统边界
对象是由边界来“封装”的，接口正是边界的体现。
描述系统时候，边界用来定义系统的范围，因为系统是由用例表示的，系统边界由用例构成。
描述用例时候，边界类是用例与外界的唯一通道，边界类“封装”了用例，用例边界由边界类来决定。
描述对象时候，对象封装的结果是出现了一组接口方法，对象的边界由这边接口方法约束。
根据系统的复杂程度、业务需求规模大小决定用例的粒度，用边界分析的方法可以帮助确定用例的粒度。
边界分析的方法主要有两种：一种是根据业务从整体到局部；另一种是按照人边界和物边界进行划分。
采用边界分析方法进行分析，可以得到封装度极好、接口处清晰明了、抽象层次井然有序的分析结果。
六、学会从接口认识事物
人们认知现实世界和认识软件的过程是一致的，是从接口（表象）来认识对象而不是从对象内部（本质）来认识对象的。
将边界分析得到的结果中，每个边界都用接口来替代，就可以确定整个系统行为。
七、学会正确选择
一个系统有多个涉众，也有多个指标，所以对系统有多种期望和多个要求。所以即使在明确的期望和要求下，也需要变换立场来审视问题，做出取舍和平衡，得出最合理的设计。
此时可以用SWTO分析方法来进行判断。
S：stretch（优点）
W：weakness（缺点）
T：threat（威胁）
O： opportunity（机会）
在需求分析和设计过程中，我们也需要改变立场来获得对需求更为深入的理解。
在需求分析中过程，我们还可以多次变换视角，通过边界的改变得出不同参与者与不同用例。
八、学会使用设计模式
设计模式是面向对象设计原则和方法的应用，是在具体实践过程中解决某类问题而产生的经验总结和最佳实践。
要使用好的设计模式首先要打好基础，即你已经完全掌握了设计模式的意图和适用性。