软件发展到现在，几乎没有项目再从刀耕火种开始，多少都会采用现成的、开源的或自开发的软件框架，同时，也越来越重视软件架构的建立。

很多项目中，没有用例实现这一步骤，在系统用例确定了之后，直接进入系统设计阶段，进行类设计、表设计等。但是，仔细思考，我们发现用例和类之间似乎有一道鸿沟，我们不知道类是如何被推导出来的，观察系统用例实现场景（下图），我们找不到类的痕迹。实现用例是跨越从系统需求到设计模型之间的那道桥梁。

之前的工作是确定需求范围，也就是就有世界有哪些东西；而现在的工作时确定系统范围，即新世界有哪些东西。需求范围≠系统范围。不是所有需求都要在系统中实现，也不是所有系统功能都是从需求中来。

工作流程不规范，环境不理想，怎么办？想办法让它变得理想，而不是一味的抱怨。

大部分人都游荡在黑暗中，他们只知道抱怨，却从不想办法寻找寻找电灯开关。
—— David Weiden

复杂的世界总是由一些简单的物质构成的，简单的物质构成了世界的本源，其他都是表象。领域建模正是要发现表象下的本质，找出那些最基本的对象以及它们之间的关系，并描绘出这些对象如何交互而形成了我们正在分析的问题领域。

一个完整的业务模型包括业务用例场景、业务用例规约、业务用例实现场景、业务用例视图、业务用例实现视图、业务对象模型、业务规则。其中业务用例场景、业务用例规约、业务用例实现场景是重点。

前面两篇博客，我们得到了涉众分析报告和涉众简档，规划了业务范围。现在可以开始获取需求的进程了。主角、边界、用例是相生相灭的关系，边界定义最重要，定义了边界，主角就能定义，一旦定义了主角，用例就能发现。

上一阶段的战略分析让我们“心中有数”，需要分析阶段才是我们命中需求的关键。

项目正式启动前，需要进行战略分析，了解项目产生的背景、运行环境、系统规模、软硬件环境以及客户期望。进行战略分析的主要信息来源有项目招标书、技术方案、合同等文件以及与客户领导进行沟通获取有效信息。

前面两篇博客总结了UML的元素、视图，就好比已经掌握了词汇与语法，接下来的建模就是真正写文章了。写成什么文章是由软件过程所确定的软件生命周期来决定的。因此，要建立什么样的模型，首先要确定的是该项目我们要采用什么样的生命周期。
本篇博客参考《大象-Thinking in UML》书中以RUP为例来进行讲解，因此涉及的所有模型是服务于RUP的各个生命周期的。