扩展流：
2a.读取证券信息（份数、价格）失败;
2a1.系统报错，用例结束。
3a.读取汇率失败（某支证券的币种到结算币种的转换汇率不存在）：
3a1.系统告知用户结算汇率不存在，无法计算资产总额，用例结束。
明确需求后，当我们打开软件系统这只盒子，进入它的内部，把盒子内的一切东西、机关要害都搞清楚、弄明白，也就完成了软件开发从需求，到分析，到设计，到编程实现的这么一个过程，而我们最终送给客户的必须是一个高质量的大礼包。
那么，这只盒子内部有何宝物呢？由外而内，由大而小，一个软件分别由系统，子系统（subsystem）与构件（component），以及对象组成。一个系统由一个或多个子系统组成，而一个子系统可以由一个或更多的子系统（或构件）组成。构件里面装的则是对象，对象又由属性和方法（即通常所说的函数）组成。类（对象）正是现代软件的最小组成单元，就像组成有机人体的基本单元——细胞。
下图用UML包图表现了这样一种软件系统的嵌套解剖视图。
层次分明
“分而治之”是工程界对付复杂技术问题最常用的手段。作为一个复杂的系统，软件也不例外，清晰而严谨分层的结构往往是优秀软件设计的一个主要特征。
分层有横切、纵切两种。软件设计从系统，到子系统和构件，再到类与对象，再到类的内部属性和方法，以及某个方法的编程实现，既是由外而内，也是从高到低，从高层的架构设计（系统、子系统），到低层的类与类的关系、类内部的设计，就像山脉与山峰、森林与树叶的关系。
对应着这样的高、低层关系，在软件设计中，目前世界上已有大量的架构模式、设计模式、实现模式和各种分层的框架可供我们借鉴、重用。
动静结合
经常有初学者问：用UML建模的时候，我们到底要画几张图才算表达完整，哪些图最重要？其实有一个非常简单的回答:动静结合。客观世界是由物质（如微观粒子）组成的，而物质是运动的。
巧合的是，软件这个虚拟世界也不例外。因此在我们设计软件的时候，既要说明有哪些物质（如构件、对象、属性等）存在，也不要忘了描述物质之间的运动（如交互、状态变迁等），两者是相辅相成的。
以下我们展现了参与“打印帐户报告!”用例实现的主要对象之间，为了完成这一功能所结成的静态关系（用UML类图表示）和动态关系（我们选择了UML协作图）。
事实上，只有细致考虑了对象之间的静态和动态关系（不管利用何种媒介，大脑抑或文档），我们的软件设计才算是完整的，编程才有正确的依据。不然，您的程序代码从何而来？
逐步求精
软件开发从软件的需求（问题域）到可执行的高级程序设计语言源代码（解决域），这中间究竟经历了多少思考步骤和权衡过程？是一步到位吗？
实际上宏观地从软件需求，到代码实现;软件设计中的从分析对象，到设计对象，再到实现对象，或者从设计模式到模式的编程实现，这些都是一个逐步求精的过程。
结束语
UML建模对于软件设计的重要性，对于一名老练的OO程序员来说，是不言而喻的。
UML作为一种图形化建模语言规范，凝聚了世界上许多大师级OO建模、设计专家多年来的宝贵经验，它的表达手段异常灵活和丰富，面对UML 2.x十几种图符，希望我与Craig Larman大师合作的《太极建模诗》能给读者朋友们带来一些有效的帮助。
协作图用于显示组件及其交互关系的空间组织结构，它并不侧重于交互的顺序。协作图显示了交互中各个对象之间的组织交互关系以及对象彼此之间的链接。与序列图不同，协作图显示的是对象之间的关系。
另一方面，协作图没有将时间作为一个单独的维度，因此序列号就决定了消息及并发线程的顺序。协作图是一个介于符号图和序列图之间的交叉产物，它用带有编号的箭头来描述特定的脚本，以显示在整个脚本过程中消息的移动情况。
用例图（use case diagram）就是由主角、用例以及它们之间的关系构成的图。该图说明了用例模型中的关系。可以将用例图组织到用例包中，并归用例包所有，让特定包中仅显示互为关联关系的内容。
用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。
参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
文章来源于领测软件测试网 https://www.ltesting.net/
