vinep的专栏

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

从任何一个环节我们都会看到用例，但是仅仅依靠用例本身的图来描述用例是不够的，为什么呢？因为用例它所要描述的是一个场景，换句话说，就是用例是描述了某件详细的事情。如果作为一个场景的话必然要考虑这么几个问题：l         谁在这个场景中做事？l         什么时候进入这个场景？l         这个场景在做什么？l         这个场景有没有特殊规则？l     

需求定义通过需求捕获，将系统建立不同的问题域，对每个问题域进行上下文关系分析。问题域可以用组件图来描述；上下文关系用上下文关系图来描述，它描述的其实是业务用例。按照上下文关系的每个事件建立脉络。脉络及框架分析对上下文关系的每个事件进行分析，进行流程分析，描述事件的具体流程，可以用活动图和DFD来描述，在OO中，一般使用活动图。下一步对活动中的业务实体进行分析，可以通过类图来描述