业务建模模板.docx

作业：结合自己的毕业设计，完成需求分析业务建模 主要工作： 针对项目特点，分析业务现状，识别业务参与者、业务用例、业务工人、业务实体。 （采用活动图对业务流程进行图形化建模）1业务现状： 某旅店可对外开放50个双人间和20个单人间，房间费用视情况按季节调整，但周一到周五提供半价（周末全价）折扣。 旅客可以直接入住房间（如果有空房），也可提前预订；入住和预订都需要登记个人信息八 旅‘V总前预订房间时，需提交一定的订金；入住时间24小时之前，旅客可以取消预订，并退回所有订金，24小时以内则不退还订金。 退房时缴纳全部的住宿费用。 服务员每月为经理提供房间的预订情况和入住情况的详细信息。 2业务用例图（业务参与者，业务用例）： BE睿在布'3针对业务用例住宿的活动图（流程图.数据流图）： 4识别业务工人和业务实体，完成业务对象模型的建模 5需要注意的地方： （1）针对业务用例的建模，可以针对项L1特点采用序列图或活动图，其中序列图强调对象之间的消息传递，使用RationalRose建模，序列图中较难体现分支、循环和并发。活动图侧重描述活动和活动之间的关系（顺序、分支、循环、并发），如果要在活动图中体现对象之间的交互，可以添加泳道，但为了保证图形的清晰化，建议泳道不要超过四个。 （2）业务用例只有1个，针对该业务用例采用活动图进行图形化建模；若业务用例有多个，且多个业务用例之间也具有联系，建议采用总体活动图+子活动图的方式展开。 用例建模（需求分析） 从用户的角度去看待问题 针对业务建模中提到的功能，从业务用例模型中寻找系统改进点，结合系统远景，获取系统用例来表达需求，最终确定系统功能点。此阶段主要工作为：识别系统参与者，识别系统用例，识别用例与用例之间的关系，完成用例描述。 可能存在的对应关系（并非一一对应）： （1）业务用例一〉系统（子系统）（2）业务参与者-〉系统参与者 （3）业务工人一〉系统参与者（4）业务实体->实体类 （5）业务工人的操作（活动）一〉系统用例1-识别系统参与者 系统在哪些部门使用 谁向系统提供信息、使用和删除信息。 谁与系统的需求有关联 谁使用系统的功能（用例） 谁对系统进行维护 与外部系统是否有关联 时间参与者：一种习惯用法，用于激活那些系统定期的、自动执行的用例―^-~用例A 用例B用例C2-识别系统用例 参与者的工作是什么 参与者的角色（作用）是什么 参与者是否生成、参照、删除系统信息 参与者是否需要把外部变更通知给系统 系统是否需要把内部事情通知给参与者 是否存在进行系统维护的用例用例之间的关系 .Include（包含）4-基用例中复用被包含用例的行为*提取公共步骤，便于复用 -Extend（扩展）：通过扩展用例对基用例增加附加的行为 -Generalization（泛化）：同一业务目的的不同技术实现用例描述（用例规约） 表3“预约挂号”用例文档 用例名|预约挂号 参与者涉众扩展点前置条件后置条件简要描述注册用户可通过该用例完成预约挂号业务注册用户注册用户、医院打印预约单、打印挂号费、支付挂号费用户成功登录到本系统用户的预约信息被记录到系统中基本事件流该用例起始于注册用户需要通过该系统进行预约挂号（A-1）；用户设定查询条件（D-1），查询到需要预约的医院、科室以及出诊信息: 参与者涉众扩展点前置条件后置条件 系统显示可预约的出诊信息（A-2,D-2）；用户选择一个可用的出诊信息，进行预约： 系统显示有关本次预约的详细信息（D-3）: 用户提交本次预约记录： 系统保存本次预约记录，并提示用户预约成功（A-3）。 备选事件流预约成功的记录，系统提供三个扩展点：打印预约单、打印挂号费、支付挂号费A-*用户在提交该预约前，随时都可能中止本次预约系统显示中止确认的消息： 用户可以结束该用例，也可以选择继续。 A-1当用户已经有成功预约且还没看病的预约记录时系统显示用户已有的预约记录： 针对每个预约记录，系统提供三个扩展点：打印预约单、打印挂号费、支付挂号费A-2无法查询到所要的出诊信息 系统显示没有可用的出诊信息; 注册用户可以重新输入查询条件进行查询，也可以结束该用例。 A-3保存信息失败 L系统显示保存失败，并提示用户需要再次提交； 虫注册用户可以重新提交，也可以结束用例。 补充约束数据需求（有关数据需求尚需进一步细化）D-l0前初步应该包括：医院名称、类别、科室名称、预约时间、医生姓冬、医生职称等。 D-2出诊信息应包括：医院冬称、类别、课程需称、出诊时间、医生姓冬、医生职称、医生特长等内容。 D-3预约信息应包括：出诊时间、医院、科室、医生姓名、医生职称、挂号费用等补充约束业务规则B-1每个医生每次出诊所能看病的人数有一左的限制，当某个医生的预约人数满员后即不可预约B-2一个用户每个时间段最多只能