第5讲-用例建模

高级软件工程,学习路线图,认识问题,分析问题,解决问题,业务分析与设计过程,最终用户(提出问题),开发团队(解决问题),以用户的身份站在用户的角度认识问题获取需求用例建模技术,第5讲用例建模,5.1理解需求5.2从业务模型获取需求5.3建立用例模型5.4编写用例文档5.5重构用例模型5.6其他问题,需求建造“正确”的系统,什么是需求？客户可接受的、系统必须满足的条件或具备的能力由用户提出RUP中的FURPS+软件质量准则功能性（Functionality）需求定义的重点可用性（Usability）可靠性（Reliability）性能（Performance）可支持性（Supportability）+，意为设计约束、实施、接口以及物理需求等,需求难在何处：石头问题,初次需求：我要一块石头再需求：差不多，但我要小一点的再需求：很好，不过我要蓝色的再需求：啊，没有那么小再需求：咳，还是原来那个好了,真实的需求：小一点的蓝色大理石,难捕获，易变！,如何获取好的需求做好需求收集,需求收集包括五个关键步骤找到可以帮助你理解这个系统的人领域专家倾听这些相关人员的描述，并从他们的角度来理解系统理解需求利用一个容易理解的模型来描述用户如何使用这个系统以及为他们提供的价值服务需求建模详细地描述系统和客户、以及系统和外部系统之间的交互动态行为建模重构上述详细描述以保证它易读易懂重构模型,解决需求问题的对策,难捕获,易变,从用户视角看问题,建立合理的结构,用例,以用例为中心组织业务需求,用例,可用性,可靠性,网络协议,业务规则,硬件接口,界面约束,性能,第5讲用例建模,5.1理解需求5.2从业务模型获取需求5.3建立用例模型5.4编写用例文档5.5重构用例模型5.6其他问题,从业务模型获取需求的方法,从业务用例模型中获取系统需求，来构建系统用例模型。主要有3个步骤：1.寻找业务改进点从业务用例模型中寻找系统改进点；2.定义项目远景结合系统远景，获取系统用例来表达需求；3.导出系统需求采用需求启发技术，从涉众中获得,1.寻找业务改进点,业务模型描述业务现状，这些现状可能是：有些可能一直运转的很好，不需要改进，也就没有必要作为软件需求来由系统实现更多的业务在运转过程中存在这样或那样的问题，这些问题就成为业务待改进的改进点，也就很可能作为软件需求而存在需求的重点如：操作实现复杂、劳动效率低,2.远景(Vision),系统改进点不等同于软件需求，需从远景入手用户的远景：用户根据自身的工作特点和支付能力决定哪些应该改进，哪些不需要改进。它表明用户改进的目标，也将成为软件项目的开发目标业务模型描述了“现实是什么”，远景则描述“希望的改进”，主要体现为：远景表达了“为什么要开发这个系统”，即在业务现状(业务模型)下，开发系统是为了达到什么目标？,3.导出系统需求,从业务改进点入手，结合项目远景，导出系统需求，具体措施为：对于每一个业务改进点，明确是不是为了达到远景目标的需要？如果是，则作为软件需求而存在，并把相应地模型（用例模型）作为系统模型；如果不是，则不作为需求而存在可能作为一项潜在的需求考虑、也可能直接被抛弃,实例分析：旅店系统开发远景,随着旅店声誉日益提高，住宿人员越来越多，旅客为了能够获得好的房间，均提前预订房间然而，随着预订的增多、预订周期的拉长，前台服务员工作压力也日益增大，还经常出现工作的失误，使得已经预订好房间的旅客也不能按期入住，这给酒店的声誉带来不好的影响为此，旅店老板想到了用计算机来管理希望能够通过计算机来自动管理这些预订业务，但由于目前资金的问题，目前只开发一个单机版的系统，不提供网上业务；并且旅店方面的其它业务暂不考虑信息化问题旅店老板委托某计算机公司开发该系统，并承诺如果系统运转良好的话，将会考虑进一步合作事宜,远景：旅店预订系统,A很荣幸地成为项目经理，并被要求在两个月之内发布该系统的第一个版本，同时还被要求要为后续的开发提供必备的接口结合现状和老板的要求，考虑到项目可扩展的要求，A首先进行了简单的业务建模了解了业务现状的工作流程之后，A初步定义了项目的远景（项目的目标）方便、快捷、准确地为旅客预订房间旅客可以方便的取消预订的房间旅店经理能够定期的获取预订的信息，根据这些信息可以及时调整房间的价格及时、快速地计算房间费用、预订费用、取消预订后退款金额等信息预留接口：可为以后的网络版，以及其它业务系统的开发提供支持,结合远景，获取系统需求(本质),第5讲用例建模,5.1理解需求5.2从业务模型获取需求5.3建立用例模型5.4编写用例文档5.5重构用例模型5.6其他问题,1.需求从何而来获取原始需求,需求只能来自涉众(stakeholders)、或相关利益者、或角色等等最终用户、客户政府、法律、文化开发人员、管理人员竞争对手但并不是直接从涉众中来你们的需求是什么？根据远景确定需求,涉众无法直接提供需求的现象,涉众无法陈述自己的需要涉众说的是解决方案而不是需求涉众难以构想新的工作方法涉众的利益矛盾涉众抵制变更“最好也要有”过度的要求需求引发新的需求,获取需求的技巧需求启发技术,获取需求：考勤卡应用程序,开发者：谁将使用这个应用程序？客户：所有用它来记录可记帐以及不可记帐的工时的雇员开发者：现在考勤卡应用程序是什么样的？客户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者：谁来管理收费项目代码？客户：嗯，必要的时候由我来添加这个代码。而每个经理总会告诉他的下属应该填写什么。,2识别参与者(Actor),从需求中识别参与者参与者：在系统之外，通过系统边界与系统进行有意义交互的任何事物,要点：任何事物,任何事物举例：小人与圣小猪-1,如果我开发一个猪圈自动供食供水系统，猪的前蹄触发一个开关系统就供食或供水。很显然这里的参与者是小猪。通常，用例图中的参与者用一个小人表示。但是这个小人具有一定的误导性，往往让初学者(包括客户)理解为一个真实的人。,小人与圣小猪问题的解决方法,从实际应用出发来确定参与者引入适当的构造型进行扩展，如图中的,思考：参与者与系统边界？,场景1：某企业要求开发一个企业信息管理系统，并与原来已有的库存系统相连接系统之外，重点明确新老系统间的接口场景2：某企业要求开发一个企业信息管理系统，并把原来已有的库存管理系统加以改造，成为企业信息管理系统的一部分系统之内，新系统存在一个“改造库存系统”用例，工作量要比上述大很多,“已有的库存系统”是一个参与者,参与者的命名,对参与者赋予能表达其角色(作用)的名称不规范的参与者命名：用职务名称和个人姓名来命名例如，张三、老李、校长、科长若使用系统的人（职务名称）变化的话，就不是参与者了规范的参与者命名：用能知道其角色的名称来命名例如，学生、订单管理员、维护部门即使使用系统的人改变，从系统来看，使用者的角色（作用）是相同的。,识别参与者：考勤卡系统,开发者：谁将使用这个应用程序？客户：所有用它来记录可记帐以及不可记帐的工时的雇员开发者：现在考勤卡应用程序是什么样的？客户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者：这个收费项目代码可以从什么地方得到？开发者：谁来管理收费项目代码？客户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。,参与者之间的关系：泛化,参与者之间的关系可以通过泛化来定义，一个参与者的抽象描述可以被一个或多个具体的参与者所共享责任重叠如系统中经理可以参加雇员的所有用例,泛化关系的误用,参与者之间泛化关系的实例：,参与者：经理、安全主管、保安用例：管理人事、批准预算、批准安全证书、监视周边实际业务：安全主管可以担任经理和保安的角色，也即能够参与经理和保安参与的工作。但经理或者保安却不能担任安全主管的角色。系统模型如右图：,3识别用例,关键词：提供的价值业务功能用例的特征：用例实例是系统执行的一系列动作(执行过程)，这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例（场景）简介：参与者使用系统达到某个目标,识别用例：考勤卡系统,开发者：谁将使用这个应用程序？客户：所有用它来记录可记帐以及不可记帐的工时的雇员开发者：现在考勤卡应用程序是什么样的？客户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者：这个收费项目代码可以从什么地方得到？开发者：谁来管理收费项目代码？客户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。,用例的命名,参与者（执行者）视角：动宾结构：（状语）动词+（形容词）宾语,要点：用例粒度-1,用例是一组用例实例的抽象。其内部要有路径，路径要有步骤；用例的粒度指的是用例所包含的系统服务或功能单元的多少。注意事项：用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。最常犯错误：粒度过细，陷入功能分解。,用例粒度,比较下列两图用例的粒度，哪个粒度大？哪个粒度小？,用例粒度-2常见错误,把步骤当用例把系统活动当用例,用例粒度-3常见错误,“四轮马车”问题的避免C(Create)、R(Read)U(Update)、D(Delete)CRUD能为Actor提供什么价值？CRUD会掩盖业务，锐变成关系数据库的建模：系统就是数据的增删改查关心数据的存储和维护，反而忽略了用户的目的,用例粒度-4采用管理用例解决四轮马车问题,如果确实是CRUD，怎么消除？如果CRUD不涉及复杂的交互，用一个用例“管理”即可不管是C、R、U、D，都是为了完成“管理”目标多数的基本数据管理业务都可以用一个用例表示,用例粒度-5,灵活处理CRUD,可以把包含复杂交互的路径独立出去形成用例用例扩展关系的利用,找出用例的思路识别要点,用例要考虑如下要点来寻找参与者的工作是什么？参与者的角色(作用)是什么？参与者是否生成、参照、删除系统信息？参与者是否需要把外部变更通知给系统？系统是否需要把内部事情通知给参与者？是否存在进行系统维护的用例？用例数量的参考基准1个系统中存在十几个用例(或更少)1个用例中有多个用例实例(场景)，如：读者管理,4构建用例图,什么是用例图：表达参与者与用例关系的图形,实例分析：旅游业务申请系统,阅读“旅游业务申请系统”问题陈述（P84），完成下列工作：识别系统参与者识别系统用例构建用例图,见参考教材UML2面向对象分析与设计,识别系统参与者,从参与者的角度识别用例,旅游业务申请系统参考用例图,第5讲用例建模,5.1理解需求5.2从业务模型获取需求5.3建立用例模型5.4编写用例文档5.5重构用例模型5.6其他问题,撰写用例文档（用例规约）,用例文档：更进一步对用例进行详细说明需求规格说明书的核心，而用例图作为用例文档的索引图（也称软件功能总图）有层次的文档文档中每一句话都有其价值,用例图是骨架，而用例文档则是其内在的肉,谁来写用例文档（用例规约）,最完美：业务人员接受训练，写出完美的用例文档不现实最现实：业务人员提供素材，开发人员写用例文档可获取真实需求最糟糕：业务人员不管，完全由开发人员杜撰脱离实际、闭门造车,用例文档（用例规约）的组成,用例标识(UC)、名称、描述涉及的参与者、涉及的用例涉众利益参与者的利益关系前置条件PreConditions、后置条件PostConditions事件流基本路径Flowofevents备选路径Alternateflow补充约束字段列表、业务规则非功能需求、设计约束待解决问题相关图(用例图、活动图、类图),涉众利益,同样是“取钱”为什么家里的抽屉不用密码，取款机要用？为什么取了钱以后要“系统扣除帐户金额”,涉众利益的冲突,编写用例文档的过程就是描述如何满足涉众之间的利益，达到涉众利益的平衡涉众有轻重缓急,寻找涉众的思路,区分涉众与参与者涉众是与当前用例存在利益关系的人或组织参与者是启动或参与用例执行过程的人或外部事物可能的涉众有：当事人（如一台戏中的观众）操作对象的主人,什么是前置、后置条件？,前置条件约束是在用例开始前系统的状态作为用例的入口限制，它阻止参与者触发该用例直到满足所有条件说明在用例触发之前什么必须为真后置条件约束用例执行后系统的状态用例执行后什么必须为真对于存在各种分支事件流的用例，则可以指定多个后置条件,定义前置、后置条件,前置、后置条件必须是系统能检测到的前置条件必须是系统在用例开始前就能检测到的,应用前置、后置条件,某些用例依赖于其他用例一个用例在离开系统时，可能是另一个用例的前置条件（例如：“登录”和“管理系统”）有助于识别漏掉的用例如果一个用例的前置条件不能由执行其他用例满足，可能意味着丢失了用例（例如：“管理订单”却没有“登录”用例）,事件流描述-用例交互四部曲,1.动作,4.响应,2.验证,3.处理,系统,重点写：1和4（可观测的、体现客户利益的文字）,例1：使用业务语言,错误描述：技术语言：无法与用户沟通例：系统通过JDBC建立数据库连接，传送SQL查询语句，从“商品表”查询商品的详细信息正确描述：业务语言(用户语言)例：系统按照查询条件搜索商品的详细信息,事件流描述要点举例,例2：描述参与者与系统交互过程,以参与者或系统作为主语描述参与者系统示例出纳员接收顾客的付款顾客的付款数可能高于商品总额出纳员录入顾客所付的现金总额系统显示出应找还给顾客的余额，打印付款收据,例3：不细化GUI,避免出现过细的GUI描述会员从下拉框中选择类别会员在相应文本框中输入查询条件会员点击“确定”按钮,用例文档中的补充约束,用例的重点在于描述功能需求，而其它方面的需求可用补充约束来描述：与特定用例相关的补充约束，作为该用例文档中一部分来描述一些全局性的补充约束，单独形成一份独立的文档，如“补充需求规约”文档什么是补充约束？字段列表（数据需求）业务规则（功能需求）非功能需求（非功能性需求）设计约束条件等等,用例文档（用例规约）的组成,用例标识(UC)、名称、描述涉及的参与者、涉及的用例涉众利益参与者的利益关系前置条件PreConditions、后置条件PostConditions事件流基本路径Flowofevents备选路径Alternateflow补充约束字段列表、业务规则非功能需求、设计约束待解决问题相关图(用例图、活动图、类图),用例文档范例：记录时间,UC01：“RecordTime”用例文档用例名称：RecordTime（记录时间）用例标识：UC01涉及的参与者：雇员、系统管理员描述：雇员利用“RecordTime”用例来登记他们的工时，系统管理员用这个用例为任何雇员登记时间前置条件：用户必须已经登录到这个系统后置条件：系统将雇员的工时正确的记录到数据库中,用例文档范例：记录时间(续),正常事件流：雇员查看当前时间之前输入的数据；雇员从已有的支付号码中选择一个，这些收费代码是按客户和项目组织的；雇员从当前的时间段选择一个日期；雇员输入以正整数表示的工时；系统在视图中显示这个数据，并在以后的视图中看到这个数据。备选事件流1：雇员更改他的时间雇员查看当前时间之前输入的数据；雇员选择一个已有的条目；雇员改变工时；在视图中更新这个信息，并在以后的视图中都可以看到。,用例文档范例：记录时间(续),非功能需求：无设计约束：无部署约束：用户可以从客户端或雇员的家中访问到“RecordTime”用例，如果是从客户端访问，则要考虑到客户端的防火墙未解决的问题雇员是否可以在以前的考勤卡上输入和更改时间雇员是否可以在以后的考勤卡上输入和更改时间，例如，在休假之前？,什么是场景？,场景是看待用例的另一种方法，是用例的一次执行过程，是按照特定条件执行事件流时的具体流程、执行实例；场景文档：按照时间顺序依次描述参与者与用户的交互过程，可用活动图来描述；【用途】：用户可以按照场景的描述来验证系统是否达到了预期目标。,活动图-简述用例流程,实例分析：撰写用例文档,用例文档参考模板旅店预订系统用例文档“UC01-预订房间”用例文档，P97“UC02-取消预订”用例文档，P98“UC03-登录”用例文档，P99“UC04-调整价格”用例文档，P100,见参考教材UML2面向对象分析与设计,实例分析：撰写用例文档,旅行申请系统主要用例文档“UC01-申请旅游团”用例文档，P101“UC02-管理参加人”用例文档，P102“UC03-完成支付”用例文档，P104“UC04-打印旅游确认书和余额缴款单”用例文档，P105“UC05-导出财务信息”用例文档，P106,实例分析：撰写用例文档,场景设计（重点）场景1：申请距出发日期两个月以上的旅游团,P107场景2：申请距出发日期不到一个月的旅游团，P107场景3：所申请的旅游团已满，P107场景4：没录入申请信息而直接选择结束，P108对于一个真实项目来说，用户的真实数据可使需求更贴近业务，便于测试用例（测试数据）的设计,第5讲用例建模,5.1理解需求5.2从业务模型获取需求5.3建立用例模型5.4编写用例文档5.5重构用例模型5.6其他问题,重构用例模型（进一步完善、改进）,利用用例建模的高级技术重构用例模型描述用例关系降低用例的复杂度通过用例关系将复杂的用例进行适当的分解，提高需求的复用性和可扩展性等，从而使用例模型的结构更合理、更简单描述用例分级寻找重要的用例可以根据用例的重要程度进行分级，以便后续迭代计划的制定，高级别的用例优先考虑相关用例分包按应用组织用例把相关的用例打包，表示用例图的分层，以用于大规模系统的用例建模,Extend(扩展)通过扩展关系对基用例增加附加的行为Include(包含)基用例中复用被包含用例的行为提取公共步骤，便于复用Generalization(泛化)派生用例继承基用例的行为并可添加新行为,1、用例关系,用例关系：扩展,扩展：某个用例在特定情况下，包含其他用例(扩展用例)的行为，表示某个用例的功能被扩展扩展使用带有的虚线表示。箭头由扩展的用例指向原用例，通过扩展点指明在原用例中的扩展位置,扩展关系,基用例路径本身是完整的，可能是一条被扩展的路径。其特点主要表现为：扩展路径步骤多扩展路径内部还有扩展点扩展之扩展,扩展关系误用,思考：错在哪？如何修改？,识别扩展点的思路,执行者的选择系统验证步骤失败处理,扩展点必须是系统能感知的,用例关系：包含,包含：某个用例中包含了其他用例的行为用带有的虚线来表示。箭头由原用例指向被包含部分的用例用例的复用,何时用包含关系？,某些步骤在多个用例重复出现，且能单独形成价值用例步骤较多时，可用Include简化（慎用，增加用例模型的复杂性）,扩展VS包含,老大知道老二,什么时候该我上场呢？不知道！被动,扩展VS.包含-1,包含：由用例A连向用例B，表示用例A中使用了用例B中的行为或功能扩展：由用例B连向用例A，表示用例A描述了一项基本需求，而用例B则描述了该基本需求的特殊情况，即一种功能扩展,范例：网络购物系统,范例：用例之间扩展和包含关系,现实业务描述（用例的上下文）：短途旅行但汽车的油不足以应付全部路程。那么为汽车加油的动作在旅行的每个场景(事件流)中都会出现，不加油就不会完成旅行。吃饭则可以由司机决定是否进行，不吃饭不会影响旅行的完成。,用例关系：泛化,泛化：表示子用例继承了父用例,泛化关系的用途,同一业务目的不同技术实现：一个用例可以特化另一个普通用例（普通用例泛化特殊用例）,什么是用例泛化关系？,是指一种从子用例到父用例的关系，它指定了子用例如何特化父用例的所有行为和特征。,旅游申请系统重构后的用例模型,-88-,2、用例分包用例的组织方式,对用例进行分包的作用让用例图更为清晰地表现出系统的业务逻辑关系和层次对系统进行模块的分割，这将影响到今后的开发和系统的最终表现形式常见的分包方式按参与者分包按主题分包按开发团队分包按发布情况分包,分包经验：先按主题分包，主题内再按参与者、开发团队和发布情况分包,主题是一种比类和对象抽象层次更高、粒度更大的概念，用以建立系统的高层抽象视图；注意：每个主题内部的对象类必须具有某种意义上的内在联系,利用分包机制组织用例模型,申请业务审查系统顶层用例包图,3、用例分级,用例和迭代开发的关系迭代开发中开发周期是围绕用例的需求来组织的一个迭代周期需要被指派一个到多个用例。如果某个用例在一个迭代周期中处理起来太复杂的话，那就采用简化版本和完整版本的用例，分阶段来完成。如图所示：,用例分级的原则,用例分级的基本原则寻找高级别用例高级别用例是那些对系统核心架构影响最大的用例获得高级别用例的5种途径：对架构设计有重要影响的用例，如：在领域层中包含多个类的用例、或者需要持久化（数据存储）的用例不需要花费很多努力就可以从中获得重要信息和线索的那些用例，即代表主要的在线业务流程的用例含有开发风险、时间紧迫或功能复杂的用例涉及到重要技术研究或者新技术和高风险的用例能产生直接经济效益或者降低成本的用例,用例分级实施策略-1,可以使用一个简单的但是有些不精确的分类方法，如将用例划分成高、中、低三个等级,网络购物系统,用例分级实施策略-2,依照上述的影响用例级别的特性(5种途径)给用例打分（特性也可能带有权值）,旅游业务申请系统,第5讲用例建模,5.1理解需求5.2从业务模型获取需求5.3建立用例模型5.4编写用例文档5.5重构用例模型5.6其他问题,用例建模中常见的问题,用例分解不是功能分解一个用例可能需要多个功能来实现，一个功能也可能被用于多个用例，注意扩展和包含关系的使用；用例图不是流程图用例图不阐述任何流程，用例图只展现系统中所有参与者、用例以及他们之间的关系捕获需求如何避免用例关系的误用明确每种关系的适用场合理解用例关系的定义；可以通过包含和泛化关系复用用例的行为；通过扩展关系可在不影响系统原有行为的基础上为某个基用例添加新的行为。,“企业进、存、销管理系统”功能性需求包括以下内容：（1）采购员根据生产原料的使用情况判断采购用品，对需要订购产品信息统计订货的，并制作产品订单。最后根据订单进行采购活动。（2）仓库管理员负责产品的库存管理。包括产品入库管理、处理盘点信息、处理报损产品信息和一些信息的设置。这些设置信息，包括：供应商信息、产品信息。仓库管理员每天对产品进行一次盘点，当发现库存产品有损坏时，及时处理报损信息。当产品生产后，将产品进行入库。当产品销售后时，产品进行出库处理。（3）统计人员负责