00系统分析员笔记3

原创

mb644789379f291 2023-04-25 21:45:10 ©著作权

©著作权归作者所有：来自51CTO博客作者mb644789379f291的原创作品，请联系作者获取转载授权，否则将追究法律责任

1,商业应用系统开发经历了三个阶段
一个阶段以计算为中心，分析设计围绕程序的运行效率，算法优劣，存贮优化来进行。90年代的大学课程讲的都是这些。

第二阶段以数据为中心，分析设计围绕数据流进行，以数据流程来模拟业务流程。这也就是所谓的面向过程的分析模式。

第三阶段以人为中心，分析设计围绕人的业务需求，使用要求，感受要求进行。这也就是现在的面象对象分析模式。
使用OO方法建立商业模型必须先定义涉众。商业系统无论多复杂，无论什么行业，其本质无非是人，事，物，规则。人是一切的中心，人做事，做事产生物，规则限制人事物。人驱动系统，事体现过程，物记录结果，规则则是控制。无论OO也好，UML也好，复杂的表面下其实只是一个简单的规则，系统分析员弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人，事，物之间的关系定义出来，商业建模也就基本完成了。这时候可以说，系统分析员已经完全了解了用户需求，可以进入系统建模阶段了。

2,使用OO方法建立商业模型必须先定义涉众。商业系统无论多复杂，无论什么行业，其本质无非是人，事，物，规则。人是一切的中心，人做事，做事产生物，规则限制人事物。人驱动系统，事体现过程，物记录结果，规则则是控制。无论OO也好，UML也好，复杂的表面下其实只是一个简单的规则，系统分析员弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人，事，物之间的关系定义出来，商业建模也就基本完成了。这时候可以说，系统分析员已经完全了解了用户需求，可以进入系统建模阶段了。

3,笔者做了一个建模实例，有需要有读者请到笔者的BLOG资源中心下载，实例以上一篇所述网上图书馆需求为蓝本建立了业务用例模型，之后的概念模型、系统模型则抽取了其中的借阅过程作为例子。不记得了可以后头找找。

建模第一步，从涉众中找出用户。并定义这些用户之间的关系。在ROSE中，应该使用business actor 类型。参考上一篇的需求描述，下载实例

第二步，找出每个用户要做的事，即业务用例，在ROSE中应使用Business use case类型。请参考《用例的类型与粒度》一文以帮助确定用例的粒度。笔者强烈建议为每一个business actor绘制一个业务用例图，这能很好的体现以人为中心的分析模式，并且不容易漏掉business actor需要做的事。至于以参与者为中心的视图容易漏掉某个业务用例的参与者的担心，可以在第四步中得到消除。下载实例

第三步，利用业务场景图帮助分析业务流程，在ROSE中，这个阶段最好使用活动图Activity diagram。在这个阶段，业务场景图非常重要，在绘制过程中，系统分析员必须采用第一步中定义的用户名字作为泳道名，使用第二步中定义的业务用例名作为活动名来绘制。必须这么做的原因是，如果你无法把利用已经定义出来的 business actor 和 business use case完备的描绘业务流程，那么一定是前面的定义出问题了，你需要回头审视是否 business actor 和 business use case定义不完善或错误。如果不是所有的business actor 和 business use case 都被用到，要么应该检查业务流程调研时漏了什么，要么应该检查是否定义了一些无用的business actor 和 business use case 。同时，绘制业务场景图也非常有助于选择合适的用例粒度并保持所有的用例都是同一粒度。下载实例

第四步，绘制用例场景图。与业务场景图不同的是，用例场景图只针对一个用例绘制该用例的执行过程。笔者仍然强烈推荐使用activity diagram。在用例场景图的绘制中，必须使用第一步中定义的业务用户作为泳道。必须这么做的原因是，它能帮助你发现在定义业务用例图时的错误，比如是否漏掉了某个业务用例的潜在使用者。不是每个业务用例都需要绘制场景图，只有两三个步骤的业务用例是不必一定绘制业务用例图的，但仍然需要在业务用例规约文档中写明。下载实例

第五步，从第三步或第四步中绘制的活动图中找到每一步活动将使用到的或产生的结果。这是找到物的过程。找到后，应当建立这些物之间的关系。在ROSE中，这称为业务实体模型。应该使用business entity 类型。下载实例

第六步，在上述过程中，随时补充词汇表Glossary。将此过程中的所有业务词汇，专业词汇等一切在建模过程中使用到的需要解释的名词。这份文档将成为模型建立人与读者就模型达成一致理解的重要保证。

第七步，根据上一篇中提到的业主，老板等涉众的期望审视建立好的模型，确定业务范围，决定哪些业务用例在系统建设范围内。那些不打算纳入建设范围内的业务用例有两种情况，一种是该业务用例是被调用一方，那么应该把它改为 boundary 类型，意味着将来它是一个外部接口。另一种是该业务用例主动调用系统内业务用例，那么应该将它改为business actor类型。与普通business actor不同的是，由业务用例转换而成的business actor不是人，而通常是一个外部系统进程，因此应该在被调用的系统内业务用例与它之间增加一个boundary元素，意味着我们的系统将为这样一个外部进程提供一个接口。严格来说，那些需要纳入建设范围的business use case 应当对应的生成一个 business use case realization，以后的设计工作将归纳到这些实现用例中。但笔者觉得这一步并非很关键的，实际中本人也经常省略这一步，而将协作图，象活动图，类交互图等直接在business usecase下说明。不过本实例中笔者还是按照正规方法来建模

4,我们已经建立了一个完整的业务模型。但这决不是建模工作的全部，以上过程只说明了建立一个完整业务模型的过程，不能说这样就建立了一个很好的业务模型。因为上述的过程中并没有提及业务分析过程。分析过程全凭系统分析员的经验，对OO的理解和对行业业务的把握能力，对原始业务模型进行归纳，整理，抽象，重构，以建立一个更高效，合理，扩展性更强的模型
5,如何从业务用例转化到概念用例和系统用例,清楚的表明将来的系统是为谁在服务，他们都是干什么的，有什么特点，有什么关系。对用例方法来说，这是最基本的出发点。用例，是以人为本的。
6,业务场景图可能不止一个。同样一项业务，会有很多种不同的业务实现方式，例如借阅图书业务，就有可能第一次借书，又还书又借书，VIP客户借书，借书时借证已经到期....等等许多种场景。对于这些场景来说，每一个都不能漏掉或省略，至少必须在文档中体现出来，除非已经很明确这个业务场景不包括在系统范围之内。这些业务场景图的意义在于，它已经绘制出了一份系统蓝图，将来的系统建设很大程度将依据这些场景图进行
7,我们得到了用户、业务用例以及业务场景。这三项工作成果已经形成了基本的需求框架，并圈定了业务范围。就笔者的工作习惯而言，在得到这三个成果后，就会暂停调研，而通过评审会，研讨会等形式充分论证这些成果的正确性和完备性。求得业务专家，用户代表，开发方，项目经理等各方的一致认可，将其作为第一份基线。笔者很少在这个基线形成之前深入细化需求，因为需求过程，或说用例过程是一个自顶向向下的过程，RUP中的每一个迭代实际上仍然是一个瀑布模型，大家都知道，如果上一步没有形成基线就进行下一步，对瀑布模型来说是无法控制的。
8,业务场景。该场景只描述了业务框架，接下来要对业务用例进行场景分析。用例场景分析要用到三种视图，业务用例实现视图、业务用例场景、业务实体模型（领域模型），每个业务用例还应当写一份用例文档，也称为用例规约（UseCase Specification）。若有非功能性需求，例如性能要求，吞吐量要求等，还应当写一份补充用例规约。用例规约将在下一篇描述
9,•首先是业务用例实现视图。并非所有的业务用例都一定要最终在系统中实现，因此，这个视图的含义是表达由需求范围到系统范围的映射关系。这个视图没什么技巧，也可以省略，不过笔者建议不要省略。需求应当保持过程的连续和可追溯性，这是软件过程可控的重要保证
10，•针对每个业务用例实现，应当对用例的实现过程进行场景模拟。上一篇是业务场景，而用例实现既然已经谈到“实现”，则应当将计算机包括进来，从人-机交互的视角来模拟业务场景。这是概念模型的一种，表达用户的实际业务在计算机环境下是如何实现的，给用户一个初步印象，告诉他们将来他们将怎样来做业务。请注意，虽然计算机已经参与需求描述，但是要尽量避免使用计算机术语，因为这时的文档仍然属于需求文档，是要与用户交流的，太多的计算机术语会大大降低用户对需求的理解能力。霍金在写时间简史时曾经说过，在书中加入哪怕一个数学公式，都会让书的销量减半。业务用例场景是概念模型的一种，但不是概念模型的全部。概念模型本篇不打算讨论，简单说一下，概念模型主要包括业务架构和系统原型。
应当在业务用例实现里添加活动图用以描述用例场景，下图为示例，用活动图绘制。如果有多个场景，则应当绘制多个场景图。
11，•用例场景有另一个重要意义，是帮助系统分析员发现和定义业务实体。业务实体一般来说就是调研时用户所提供的各类表单或报表，但在很多情况下，并非每一份表单就是一个业务实体，所有业务表单也不一定涵盖全了所有业务实体。很多系统分析员声称业务实体的发现过程是全凭经验的，到底有哪些业务实体，靠经验进行提取。笔者要说，经验固然重要，但经验有一个最大的缺陷---不能重复和验证。即，这些实体是怎么从业务中提取出来的？它们是怎样参与业务的？这些实体已经足够支持业务了吗？凭经验分析者无法通过文档将这个提取过程记录下来，而脑子里的东西是无法共享和传承的，越大的团队，越复杂的项目，尤其是横向结构的项目组结构下，这个缺陷越严重。很多人觉得用UML和RUP描述的需求总是一块块分离的，不知道是怎么出来的，觉得很乱，原因就在于此
12，第一、我们通用用例实现视图，从业务用例中找出了那些我们将在系统中实现的用例，并且记录了要在系统中实现的用例是如何映射到原始需求的。这提供了需求可追溯的验证。

第二、针对每个用例实现，我们引入了计算机，将实际的业务从人-机交互的角度模拟了执行过程。不仅得到了一个业务怎样在计算机环境下执行的概念模型，同时也给用户描述了他们将怎么和计算机交互以达到他们的目标。笔者提醒大家，用例场景非常非常的重要，后续工作就得靠它们了！！绝对要认真对待，深入调研，不可漏掉一个场景，也不可模糊不清。

第三、通过对场景的分析，给了我们重要的线索去发现业务实体。而我们发现了业务实体之后，又通过用例场景来验证这些实体是否支持了用例的实现
13，先说说业务规则。笔者习惯将业务规则分为三种。

一种是全局规则，这种规则一般与所有用例都相关而不是与特定用例相关，例如actor要操作用例必须获得相应的授权，用例的操作与授权级别相关，或者用户在系统中的所有操作都要被记录下来等等。这类规则笔者习惯于，并且也建议将它们写到用例的补充规约里面去，因为它们一般与具体的业务功能性要求没有直接关系。有时候，这类规则也被写到软件架构文档中。关于用例补充规约以后再讨论。

第二种是交互规则。这种规则产生于用例场景当中，例如当提交一份定单时，哪些数据是必须填写的，用户身份是否合法。当然也包括一般理解上的业务流程流转规则等，例如金额大于一万元的定单被定为VIP定单进入特殊流程等。这类规则一般要写到用例规约中。交互规则实际上还有两个是比较特殊的，一个入口条件，也称为前置条件，即actor满足什么条件才能启动用例;另一个是出口条件，也称为后置条件，即用例结束后会产生哪些后果。稍后参看示例。

第三种是内禀规则。所谓内禀规则是指业务实体本身具备的规则，并且不因为外部的交互而变化的规则。例如，每张定单至少要有一件商品，同一类商品数量不能大于5件等。同时也包括大家所熟悉的数据效验规则，例如身份证号必须是15或18位，邮编必须是6位等等。这类规则是业务实体的内在规则，因此应该写到领域模型文档中，稍后参看示例