第5讲-用例建模

高级软件工程兰州理工大学计算机与通信学院张秋余[e-mail]学习路线图OOUMLOOPDP…Case-Study…学习路线图::……………………234567891011认识问题分析问题解决问题业务分析与设计过程最终用户(提出问题)开发团队(解决问题)以用户的身份站在用户的角度认识问题获取需求—用例建模技术第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如果我开发一个猪圈自动供食供水系统，猪的前蹄触发一个开关系统就供食或供水。很显然这里的参与者是小猪。通常，用例图中的参与者用一个小人表示。但是这个小人具有一定的误导性，往往让初学者(包括客户)理解为一个真实的人。PigWatersupplyorforfood小人与圣小猪问题的解决方法从实际应用出发来确定参与者——引入适当的构造型进行扩展，如图中的pigactor思考：参与者与系统边界？场景1：某企业要求开发一个企业信息管理系统，并与原来已有的库存系统相连接系统之外，重点明确新老系统间的接口场景2：某企业要求开发一个企业信息管理系统，并把原来已有的库存管理系统加以改造，成为企业信息管理系统的一部分系统之内，新系统存在一个“改造库存系统”用例，工作量要比上述大很多“已有的库存系统”是一个参与者参与者的命名对参与者赋予能表达其角色(作用)的名称不规范的参与者命名：用职务名称和个人姓名来命名例如，张三、老李、校长、科长…若使用系统的人（职务名称）变化的话，就不是参与者了规范的参与者命名：用能知道其角色的名称来命名例如，学生、订单管理员、维护部门…即使使用系统的人改变，从系统来看，使用者的角色（作用）是相同的。识别参与者：考勤卡系统开发者：谁将使用这个应用程序？客户：所有用它来记录可记帐以及不可记帐的工时的雇员……开发者：现在考勤卡应用程序是什么样的？客户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者：这个收费项目代码可以从什么地方得到？……开发者：谁来管理收费项目代码？客户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。……EmployeeAdministrativeUser参与者之间的关系：泛化参与者之间的关系可以通过泛化来定义，一个参与者的抽象描述可以被一个或多个具体的参与者所共享——责任重叠如系统中经理可以参加雇员的所有用例用例A雇员用例B经理用例C泛化关系的误用登录验证身分用户浏览信息注册成员搜索产品留言普通浏览者回复留言发送邮件系统管理员参与者之间泛化关系的实例：参与者：经理、安全主管、保安用例：管理人事、批准预算、批准安全证书、监视周边实际业务：安全主管可以担任经理和保安的角色，也即能够参与经理和保安参与的工作。但经理或者保安却不能担任安全主管的角色。系统模型如右图：3识别用例关键词：提供的价值——业务功能用例的特征：用例实例是系统执行的一系列动作(执行过程)，这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例（场景）简介：参与者使用系统达到某个目标记住了，我是(系统)用例识别用例：考勤卡系统开发者：谁将使用这个应用程序？客户：所有用它来记录可记帐以及不可记帐的工时的雇员……开发者：现在考勤卡应用程序是什么样的？客户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者：这个收费项目代码可以从什么地方得到？……开发者：谁来管理收费项目代码？客户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。……RecordTimeCreateChargeCode用例的命名参与者（执行者）视角：动宾结构：（状语）动词+（形容词）宾语顾客购买商品信用卡支付extend要点：用例粒度-1用例是一组用例实例的抽象。其内部要有路径，路径要有步骤；用例的粒度指的是用例所包含的系统服务或功能单元的多少。注意事项：用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。最常犯错误：粒度过细，陷入功能分解。用例粒度比较下列两图用例的粒度，哪个粒度大？哪个粒度小？用例粒度-2——常见错误把步骤当用例把系统活动当用例会员输入用户名验证用户名和密码会员登录include查询订单建立数据库连接执行SQL语句includeinclude用例粒度-3——常见错误“四轮马车”问题的避免C(Create)、R(Read)U(Update)、D(Delete)CRUD能为Actor提供什么价值？CRUD会掩盖业务，锐变成关系数据库的建模：系统就是数据的增删改查关心数据的存储和维护，反而忽略了用户的目的删除用户修改用户增加用户管理员查询用户用例粒度-4——采用管理用例解决四轮马车问题如果确实是CRUD，怎么消除？如果CRUD不涉及复杂的交互，用一个用例“管理××”即可不管是C、R、U、D，都是为了完成“管理”目标多数的基本数据管理业务都可以用一个用例表示管理员管理用户用例粒度-5灵活处理CRUD管理员管理用户增加用户extend可以把包含复杂交互的路径独立出去形成用例——用例扩展关系的利用找出用例的思路——识别要点用例要考虑如下要点来寻找参与者的工作是什么？参与者的角色(作用)是什么？参与者是否生成、参照、删除系统信息？参与者是否需要把外部变更通知给系统？系统是否需要把内部事情通知给参与者？是否存在进行系统维护的用例？用例数量的参考基准1个系统中存在十几个用例