第5章 需求分析与建模.ppt

* 5.4 用例分析------用例业务建模之涉众 第三方 与这项业务而关联的非业务方的其他人或事 （比如，借阅人借书时需要交费，若交费是通过网上银行支付的，则网上银行就成为了网上借书系统的一个涉众） 第三方的期望对系统来说不起决定性意义，但会起到限制作用 （最终在系统中，这种期望将体现为标准、协议和接口） 另一种第三方是项目监理，系统分析员也必须弄清楚监理的期望 * 5.4 用例分析------用例业务建模之涉众 相关的法律法规 国家和地方法律法规 （例如，借阅系统要建立借阅人档案，就必须保障借阅人的隐私权； 要与网上银行交易，必须遵守信息安全法等。） 必须得遵守一些行业规范和标准 （例如，网上借阅需要遵守HTML规范，借阅者才能正常浏览网页） * 5.4 用例分析------用例业务建模之涉众 用户 预期的系统使用者。用户可能包括上述的任何一种涉众 用户涉众模型建立的意义是：每个用户将来都可能是系统中的某个角色，是实实在在参与系统的，需要编程实现相应的系统功能 上述的其它涉众，则有可能只是在需求阶段有用，最终并不与系统发生交互 在建模过程中，概念模型的建立和系统模型的建立都只从用户开始分析，而不再理会其它的涉众。（其它涉众体现在文档中即可） * 5.4 用例分析------用例业务建模之涉众 业主 业务提出者 业务管理者 业务管理者 第三方 相关的法律法规 用户 * 5.4 用例分析------业务建模一般步骤和方法 本方法并非唯一正确，仅供参考 Step1 从涉众中找出参与者，定义这些参与者之间的关系 Step2 找出每个参与者要做的事，即业务用例 1）注意用例的粒度 2）建议为每个business actor绘制一个业务用例图，这能很好的体现以人为中心的分析模式，并且不容易漏掉business actor需要做的事。至于以参与者为中心的视图容易漏掉某个业务用例的担心，可以在第3、4步中得到消除 Step3 利用业务场景图帮助分析业务流程 1）本阶段最好使用活动图Activity diagram 2）绘制时要采用Step1定义的参与者名作为泳道名，用Step2定义的业务用例名作为活动名。（若无法完备地描绘业务流程，那么一定是前面的定义有问题）（若不是所有actor 和use case 都被用到，则应该检查业务流程有无遗漏，或是否有无用的actor 和 use case ） * 5.4 用例分析------业务建模一般步骤和方法 Step4 绘制用例场景图（用活动图）。 1) 与业务场景图不同，用例场景图只针对某用例绘制其执行过程 2) 使用Step1定义的参与者作为泳道名。(能助你发现在定义业务用例图时的错误) 3) 步骤简单的业务用例是不必绘制场景图，只需要写用例规约 Step5 从Step3或Step4中绘制的活动图中找到每一步活动将使用到的事物或产生的结果。（这是找到物的过程。）找到后，应当建立这些物之间的关系（业务实体模型）。 Step6 上述过程中，随时补充词汇表Glossary。将此过程中的所有业务词汇、专业词汇等一切在建模过程中使用到的需要解释的名词。（为模型建立人与读者就模型达成一致理解提供保证）。 * 5.4 用例分析------业务建模一般步骤和方法 Step7 根据涉众(利益相关者)的期望审视模型，确定业务范围（决定哪些业务用例在系统范围内） 去除的业务用例有两种情况： 1、该业务用例是被调用一方，应改为 boundary 类型，意味着将来它是一个外部接口。 2、该业务用例主动调用系统内业务用例，应改为business actor类型。（由业务用例转换而成的business actor不是人，而通常是一个外部系统进程，因此应该在被调用的系统内业务用例与它之间增加一个boundary元素，意味着我们的系统将为这样一个外部进程提供一个接口） 说明：上述的7个步骤并非一次性完成的，在每一个步骤中都可能导致对以前步骤的调整。即使建模已经完成，当遇到变化或发现新问题时，上述步骤应当从头到再执行一次。这也是RUP倡导的迭代开发模式。 * 5.4 用例分析------用户、业务用例和业务场景 回头看看需吧，图书馆主任是这么说的： 我们原本是传统的图书馆，要求读者亲自来到图书馆，这显得非常不方便，而且随着藏书的增加和读者群的增长，尤其而且大量的读者到图书馆， 使得图书馆的场地不足，工作人员也不够了。 想借助网络，让读者通过网络借/还书，这样可以省掉大量的场地维护和工作人员成本支出，同时计算