wellhead的博客

问：业务用例和系统用例的区别是不是可以这样理解呢，如果把业务用例进行功能上的细分的话，分成若干个小的用例，那么这些小的用例是不是就是系统用例？ 就象维护人员档案，如果细分成添加档案，修改档案，删除档案，查看档案等等。。。 如果你的答案是肯定的话，那我是不是可以继续这样理解：一般情况下，业务用例实际上是在一个比较高的层面上来看业务逻辑，更接近于用户的直接需求，而系统用例则是业务逻辑的详细的划分，更接

 UML 中包括有很多种图形。我最初学习 UML 是通过三友的《UML 用户指南》，这本书是一本很详尽的著作（另外一本更详尽的著作是三友的《UML 参考手册》），是 UML 领域最重要的著作之一，然而却不利于初学者掌握重点。因为时间有限，我没有能够读完用户指南的全书。对于一个形式主义者，很容易陷入大量 UML 的细节之中，使用昂贵的建模工具（ROSE、Together、PowerDesigner、

需求分析阶段的工作（一） 抛开前一篇文章谈的总体思路，我们今天来谈一下需求分析工作实质性的做些什么。在这里，我们，将主要关注于分析层面，也即 UML 中的用例模型和逻辑模型。 在这里要申明的是逻辑模型并不能完全算需求分析阶段的工作，因为它包含了设计模型的概念，但是我又把它归纳了一块到需求分析阶段，原因在于逻辑模型中存在了业务对象模型和分析模型的概念。 言归正传，先来看用

 前文介绍了系统用例，在这一节中，我们将讨论的是用例描述 和逻辑模型 的工作。 从任何一个环节我们都会看到用例，但是仅仅依靠用例本身的图来描述用例是不够的，为什么呢？因为用例它所要描述的是一个场景，换句话说，就是用例是描述了某件详细的事情。如果作为一个场景的话必然要考虑这么几个问题： l          谁在这个场景中做事？ l          什么时候进入这个场景