软件需求工程课件20130616

1、1,理解用例,用例是黑盒？白盒？ 用例是相邻系统与系统的交互。 涉众代表/用户 与系统直接交互的对象 其他计算机系统 (“参与者”) 外部事件（如：满足 特定时间） ,2,抽象层次是面向对象方法中极其重要且非常难以把握的技巧； 要想建立好模型，就需学会站在不同的抽象层次考虑问题。 抽象层次越高，被屏蔽（或者说封装）的信息也就越多，信息量越少也就越容易理解和处理。,抽象层次,3,统一过程一般抽象层次,4,什么时候选择什么样的层次以及总共抽象多少层？-用例粒度 抽象层次与边界的选择总是相生相伴-边界,抽象层次相关的问题,5,一切都是对象； 对象都是独立的； 对象都具有原子性； 对象都是可抽象的；

2、对象都有层次性。,对象分析方法,6,2. 参与者（actor）: 定义：actor是在系统之外与系统交互的某人或某事物。如图所示：,uml核心元素,参与者位于边界之外； 参与者可以非人。,7,发现参与者：参与者的一个重要来源是涉众，从涉众中找出那些直接对系统发出动作，或直接从系统中接收反馈的涉众。在查找参与者的过程中，可以询问以下问题以帮助确定参与者： 谁负责提供、使用或删除信息？ 谁将使用此功能？ 谁对某个特定功能感兴趣？ 在组织中的什么地方使用系统？ 谁负责支持和维护系统？ 系统有哪些外部资源？ 其他还有哪些系统将需要与该系统进行交互？,uml核心元素,8,参与者一定是直接并且主动地向系统

3、发出动作并获得反馈的，否则就不是参与者。,uml核心元素,9,业务主角（busuness actor）：是参与者的一个构造类型，特别用于定义业务的参与者，在需求阶段使用。业务主角是与业务系统有着交互的人和事物，他们用来确定业务范围。业务主角的特殊性在于它针对的是业务人员而非计算机用户。 业务工人（business worker）：处于系统边界内，被动地参与了业务的执行过程。业务工人不是参与者。,uml核心元素,10,参与者与其他成员的关系 参与者与涉众（项目干系人、相关方）：参与者是涉众代表，他们的要求就是系统需求的来源； 参与者与用户（user）：用户是系统的使用者。用户是参与者的代表，或者

4、说是参与者的实例或代理。并非所有的参与者都是用户。 参与者与角色（role）：角色是参与者的职责，角色是一个抽象的概念，从众多参与者的职责中抽象出相同的那一部分，将其命名形成一个角色。一个角色代表了系统的一类职责。由于一个用户可以代理多个参与者，因此一个用户可以拥有多个职责，也就是可以被指定多个角色。,uml核心元素,11,参与者、涉众、和角色的关系,uml核心元素,12,3. 用例（use case） 基本概念：官方文档对用例是这样定义的：用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值。 一个完整的用例定义由参与者、前置条件、场景、后置条件构

5、成。如图所示：,uml核心元素,13,用例的特征： 用例是相对独立的。,uml核心元素,14,用例的特征： 用例的执行结果对参与者来说是可观测的和有意义的。,uml核心元素,15,用例的特征： 这件事必须由一个参与者发起。不存在没有参与者的用例，用例不应该自动启动。,uml核心元素,16,用例的特征： 用例必然是以动宾短语形式出现的。,uml核心元素,17,用例的特征： 一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元。下图展示了用例如何驱动软件开发活动。,uml核心元素,18,一个大系统和一个很小的系统用例粒度会有较大差别。 不论粒度如何选择，必须把握的原则是在同一个需求阶段

6、，所有用例的粒度应该是同一个量级的。 用例粒度的大小不是从用例包含的步骤的多少来判断的，粒度与边界有关。,uml核心元素,19,用例的获得：发现用例的前提条件是发现参与者。获取用例的准备工作：,uml核心元素,参与者是位于系统边界之外的； 参与者对系统有着明确的期望和明确的回报要求； 参与者的期望和回报要求在系统边界之内。,20,用例的获得：可以通过以下问题引导业务代表： 您对系统有什么期望？ 您打算在这个系统里做些什么事情？ 您做这件事的目的是什么？ 您做完这件事情有一个什么样的结果？ 在此过程中需要确保： 一个明确的有效的目标才是一个用例的来源。 一个真实的目标应当完备地表达主角的期望。

7、一个有效的目标应当在系统边界内，由主角发动，并具有明确的后果。,uml核心元素,21,用例与功能,22,用例与功能,这个事物是什么？ 这个事物能做什么？ 人们能够用这个事物做什么？,23,理解用例与功能练习,请分别从功能角度和用例角度出发描述我们所熟悉的电视。 从功能角度出发，对电视的描述是能开关，能显示节目，可以调频道，可以调声音，以上四者是独立的； 从用例角度出发，对电视的描述是有一个人要观看电视节目的用例，要完成这个用例，第一步需要先打开开关，调到自己喜欢的频道，如果声音不合适，可以调节一下，以上三者是因人的需求而相关起来的。,24,uml核心元素用例,如何理解目标与步骤的误区？假设邮局

8、是一个目标系统，作为寄信人这样一个参与者，对邮局有着寄信的愿望。以完整目标作为用例：,25,uml核心元素用例,如何理解目标与步骤的误区？假设邮局是一个目标系统，作为寄信人这样一个参与者，对邮局有着寄信的愿望。如果以完成这个完整目标的步骤作为用例：,26,例：有这样一个需求：“客户提出要建立的系统界面很友好，在每个页面上都要有操作提示。”,不存在没有参与者的用例,27,例：“每天自动统计网页访问量，生成统计报表，并发送至管理员信箱。”这个需求的参与者是谁？,参与者可以非人,28,uml核心元素边界,边界在uml图符里的定义只是一个简单的矩形框，矩形框的四个边决定了边界的内外。 边界本质上是面向

9、对象方法的一个很重要的概念，与封装的概念师出同源。 系统边界是看不到的，与其说是系统边界，倒不如说是需求的集合。,29,uml核心元素边界,边界决定视界 边界决定抽象层次 灵活使用边界 边界是无形的,30,事件驱动的用例,现在我们讨论将工作划分为用例的万无一失的方法，并继续探索构建 最好产品之路。,31,项目启动,业务事件 清单,网罗知识,风险 承担者,上下文 范围,编写规格 说明书,为需求 作原型,想法和需要,潜在需求,潜在需求,做试验的需求,已经建立起来 的工作范围 可能太大,32,33,如何发现最合适的用例？,一、理解工作 我们今天研究的任何领域的工作都有太大而难于理解的趋势。 当我们说

10、“工作”的时候，并不是仅仅指计算机系统，不管是现有系统还是期望的系统。我们指的是开展业务的整个系统。 因为该工作的范围很大，如果试图从整体上来处理它，不仅是我们这些作为系统分析师和设计者的人不能理解该工作，我们的顾客和用户也会没有机会来向我们解释工作。 通过发现工作更小的、更专门的部分，我们有更好的机会来发现用户，用户是这部分工作的专家。,34,如何发现最合适的用例？,我们需要将工作划分为小一些的部分。出于需求收集和系统分析的需要，我们寻找符合以下条件的部分： 是“自然的”部分-它们是工作的明显的部分； 与工作的其他部分的连接数目最少； 有一个明确定义的范围； 有一些规则来定义它们的范围； 有

11、可以描述和量化的边界； 可以使用业务专家熟悉的名称来命名，业务专家指客户、顾客和用户； 它们的存在可以很容易地确定； 用户知道； 我们可以确定一个或多个用户，他们是这部分工作的专家。,35,如何发现最合适的用例？,二、用例和它们的范围 这个工作的范围必须包括预期的参与者和他要做的工作，也包括工作的相邻系统的知识。在我们为工作建立了一个令人满意的范围之后，再将它分解为较小的部分。从这些部分中我们来确定用例。我们可以采取以下步骤： 首先，建立工作的范围。 确定围绕工作的相邻系统。 确定工作与相邻系统之间的联系。 从联系开始，识别影响工作的业务事件。 研究对业务事件的响应。 确定组织对事件能作出的最

12、好响应。 确定产品在响应中的角色。 确定产品的用例。 针对每个用例导出需求。,36,如何发现最合适的用例？,三、工作 工作是客户的业务活动。 不管这种活动是什么-不管它是商务的、科学的、工程的，或其他形式的-我们打算构建自动化产品将是一个有助于工作的工具。 问：为了理解工作，从哪里入手？ 答：首先必须知道它与外界是怎样联系的。 问：展示工作与外界联系最有用的方法是什么？ 答：展示工作与外界联系的最方便、最有用的方法是使用一个上下文范围图。,37,预测和调度 道路除冰的 工作,气象站,气象 预报局,道路工程,热像图 提供者,卡车车库,经验法则： 工作上下文范围包括了所有允许你改变的东西， 以及一

13、些你不能改变的东西。,38,如何发现最合适的用例？,三、工作-外界 相邻系统是与我们的工作相连的世界的一部分。 问：我们为什么要对相邻系统感兴趣？ 答：因为它们常常作为我们的工作提供服务的顾客，或者它们提供我们的工作所需的服务。通过上下文范围图中建立起来的联系，你可以看到这一点。通过这些联系，相邻系统对工作产生重要影响。 经验法则：你从越远的地方来看期望的自动化系统，就越可能发现产品的有用之处。,39,如何发现最合适的用例？,四、业务事件 业务对事件做出响应。 我们将对每个事件的响应视为要研究的一个工作单元。 通常，业务事件的响应是通过数据流的到达来触发的。,喂，我们新修了一条道路，我们在路上

14、放了一个气象站，道路坐标是,工作,道路工程,改变的道路,40,如何发现最合适的用例？,四、业务事件 时间性的业务事件通过时间流逝来触发-是时候该我们的工作来做某些事情了。,工作,卡车车库,又到了为卡车车库 产生除冰调度计划的时间,道路除冰调度计划,41,如何发现最合适的用例？,五、发现业务事件 我们已经知道，业务事件是针对工作所发生的一些事情。 问：如何发现对工作都发生了哪些业务事件？ 答：如果针对工作发生了某事，工作必然会接受到它发生的通知。这表明在外界（记住：事件是在工作范围之外的发生的）和工作之间必然存在某种形式的交流。在时间触发事件的情况中，也存在一种交流，但这次是从工作流向外界的信息

15、。（如果工作做了一些事情，却没有任何人或外界系统，这是意义不大的。） 问：寻找工作与外界之间交流的地方在哪里？ 答：上下文范围图,42,预测和调度 道路除冰的 工作,气象站,气象 预报局,道路工程,热像图 提供者,卡车车库,请注意连接相邻系统与工作的数据流。,气象站读数,热像图,区域气象预报,失效的气象站报警,改变的道路,改变的气象站,新的气象站,卡车故障,道路除冰调度计划,修订的除冰调度计划,卡车变化,已处理的道路,未处理的道路,43,请注意连接相邻系统与工作的数据流。,44,如何发现最合适的用例？,六、工作对事件的响应 针对每个业务事件，有一个预先计划的对它的响应，即无论在什么时候业务事件

16、发生所要进行的工作。 对一个业务事件的响应是持续的。为什么？ 答：它包括了所有工作要完成的事情，直到从逻辑上来说无事可做为止-所有的处理已经完成，所有要存储的数据已被存储，所有的相邻系统已经通知到。,相邻系统,处理过程,处理过程,处理过程,存储的 数据,存储的 数据,工作边界,45,如何发现最合适的用例？,七、相邻系统的角色 相邻系统是为工作提供信息和服务或从工作接收信息和服务的系统。一个相邻系统可能是一个组织、一个人、一种技术，或三者的组合。 相邻系统是业务事件的顾客方。 当你研究对事件的响应时，请考虑相邻系统希望从事件中得到什么？扮演的角色或可能潜在的角色是什么？ 相邻系统的技术能力如何？

17、是否有能力与该产品进行交互？它是人吗？它是否具备某种交互技术能力？ 从相邻系统的角度来看，期望的成果是什么？ 从工作的角度来看，期望的成果是什么？,46,如何发现最合适的用例？,七、相邻系统的角色 你要构建的产品很大程度上是由相邻系统决定的。显然我们要理解相邻系统，以及它们在工作中潜在的角色。所以，让我们更仔细地来看一下相邻系统的类型、特征和能力。 主动的相邻系统。主动的相邻系统通常是人，他们发起事件。,银行的工作,银行的顾客,身份证明,数目？,取款的数目,钱,47,经验法则：主动的相邻系统通常是人，他们有目的地发起业务事件。,工作,卡车车库管理者,除冰调度计划,48,如何发现最合适的用例？,

18、七、相邻系统的角色 自动化的相邻系统。一个自动化的相邻系统是某种外部实体，诸如一个公司、一个政府部门等。一个自动化的相邻系统发送或接收单一的数据流。它不与工作进行交互。自动化的相邻系统与我们研究的工作行为上是独立的，但是有联系。自动化的相邻系统通过单向的数据流与工作进行通信。,工作,记录读数,气象站读数,气象站,49,如何发现最合适的用例？,七、相邻系统的角色 合作的相邻系统。合作的相邻系统是可以信赖的，在访问时它们 的行为可以精确预测。合作的相邻系统是计算机化的。,热像图 提供者,工作,产品的范围,50,如何发现最合适的用例？,八、确定要构建的最佳产品 确定要构建的最佳产品设计哪些因素呢？

19、产品的目标。 工作的范围。 相邻系统。 在前期确定的风险承担者将影响产品的边界。 来自外部团体的影响。 你所在的组织所确定的市场定位。 建立产品的范围。,51,如何发现最合适的用例？,九、创新的产品 我们的工作不是用限定的费用及时地给客户他想要的东西，而是给他从未梦想过的东西；当他得到的时候，他认识到这就是他一直想要的东西。,52,如何发现最合适的用例？,十、技术重要吗？ 技术对我们的工作来说，只在它们处于我们的工作之外时才是重要的。,53,54,事件驱动的用例-小结,通过引入业务事件的思想，我们可以合理地切除一部分工作，用于进一步的建模和研究。 通过理解每个相邻系统对工作的影响，我们理解了产品范围的限制。 通过对工作行为建模，我们得到了范围。 通过使用业务事件来分割工作，我们有了一个指导方法，来发现所有的工作部分。这些工作部分出于相同的业务上的原因而结合在一起。 事件驱动的用例是业务事件响应（活动和数据）的一部分，这些事件响应由产品来执行。,55,用例描述模板,注：模板的斜体部分为可选部分 用例名称（以用户的语