统一建模语言UML7电力营销系统案例——获取需求.pptVIP

统一建模语言UML 电力营销系统案例——获取需求 定义边界 对于全新的项目，分析员首先要做的工作就是定义边界。 边界可大可小，很多时候依靠建模者的经验和意识。 定义边界的目的是为我们确定一个分析的起点。 定义边界 如何定义边界？ 通过前景文档中的业务目标来定义边界？ 还是通过业务模块划分的方式来定义边界？ 通过业务目标定义边界 电力营销系统业务目标一：“为用电客户提供业务办理自动化服务，提高办事效率，方便客户，为客户提高更好的服务” 分析： 此业务目标为谁服务？ 用电客户－得到一个用电客户服务边界 用电客户服务边界 启示 各业务管理部门位于边界以内，是业务工人，他们的期望可以暂且不考虑。 疑问： 前述的各种XXX管理功能到哪里去了？ 释疑： 每个业务目标都会有一个边界 每个边界有不同的参与者 在不同的边界内将推导出不同的业务用例。 内部管理目标边界 进一步讨论之一 上述划分边界的结果与以前所谓划分子系统有什么差别？ 仅从名称上看，二者非常相似。 仔细考虑可以发现诸多不同： 划分依据： 子系统划分没有明确的依据，没有明确的判断标准来决定何种划分方式是合理的。 业务目标划分方式有着明确的依据。针对每个业务目标，可以明确决定系统内外，明确决定哪些涉众与此业务目标利益相关，进而得到若干业务用例。 进一步讨论之二 大部分边界划分的方式是从谁使用系统这个角度来划分的。这和从业务目标角度划分有何区别？ 按这种方式划分存在若干问题： 无法获得明确的业务用例。 无法知道这些涉众对边界的真实目的是什么，只能盲目的将涉众所有的期望堆积在边界里。 面对诸多的用例，如何进行组织？如何分包？ 按这种方式划分存在若干问题： 导致业务用例过多，关联关系混乱。 无法区分业务主角和业务工人。 会出现非常多的用例在边界里，如果都与边界外的涉众关联上，业务用例视图将混乱一片。 进一步讨论之三 是否任何时候以业务目标为依据来划分边界都是有效的呢？ 当待开发的是计算密集型或者控制密集型系统时，似乎难以找到明确的业务目标，即使找到，数量也很少，此时使用业务目标为依据划分边界似乎很别扭。 例如：玩家－玩游戏 其实，对于非交互密集型系统，即使没有明确的业务目标，也有明确的功能目标，即系统特性，可以以这些系统特性为边界，得到不同的主角与用例： 例如：控制系统、游戏引擎、声效等 控制系统为边界， 键盘、鼠标、手柄－发出前进动作、发出射击动作…… 发现主角 得到涉众分析报告，已经定义了边界，我们可以据此寻找业务主角。 主角：代表了涉众利益，站在边界外，直接与边界代表的系统交互，对系统有明确的要求，并从系统中获得明确的结果。 发现主角 是否所有的涉众都会成为业务主角？ 只有那些直接与系统交互的涉众才能成为业务主角。 发现主角—用电客户服务边界 在此边界外有两个涉众：用电客户、银行。 用电客户涉众主角分析 情形一：用电客户不直接使用系统，而是通过到营业大厅填写纸面申请，由营业大厅业务员代为填写电子申请单并提交。 用电客户不直接与边界所代表的系统交互，营业大厅业务员成为代表涉众利益的业务主角。 发现主角—用电客户服务边界 情形二：业务范围包括网上办理业务，用电客户可以直接使用系统进行办理业务。 用电客户本身就是业务主角。 情形三：一些大用电客户，供电企业设置了专职检查和服务联络人员为其专门服务，这些专职人员可以直接为大客户办理业务。 专职检查人员成为代表涉众利益的主角。 发现主角—用电客户服务边界 银行涉众主角分析 前述分析中，已经取消了实时联网收费的期望，仅保留离线收费，每日结算收费方式。即银行的收费行为与系统之间不会有直接的交互。每日会有某位营业出纳从银行处获得每日收费记录，并将其导入系统。 此时，营业出纳将代表银行成为系统的一个业务主角。 发现主角－内部管理业务边界 依据前面的涉众分析报告，内部管理业务边界之外的涉众有： 营业财务管理部门、电表抄表部门、电费管理部门、资产管理部门、现场施工部门、业务服务部门、用电检查部门。 发现主角－内部管理业务边界 营业财务管理部门涉众主角分析 该部门设置了营业会计、营业出纳、营业收费员。这三个角色会按照财会准则各自负责自己的部份，保障财产安全。 财务管理部门设有财务主任，负责财务工作的安排、人员工作情况的评估、业务规则的制定。 代表业务目标是规范化和管理职能，行使了内部管理职能的业务主角是：财务主任。 发现主角－内部管理业务边界 电表抄表部门涉众主角分析 该部门大部分工作人员－抄表工，携带抄表机或抄表单外出工作，他们不直接使用系统，而是将抄回的结果交给内勤人员，有内勤代他们将抄表结果导入或者录入计算机。 抄表工作由抄表班长按片区、按变压器线路等将工作分配给抄表工。 其中抄表班长行使了内部管理职能