电子商务系统分析与设计技术4-ok

1、CASEJ M U集美大学工商管理学院信息管理与信息系统教研室第4讲电子商务系统分析与设计技术第4章 业务建模与用例模型主要内容用例与用例构建方法需求分析实例-餐馆系统的用例构建需求分析工具使用介绍引子-系统建模的着手点一 是从面向对象分析设计开始,依次建立用例图,时序图及类图,由类图转化成概念数据模型及物理数据模型二 是从结构化分析开始,依次产生流程分析模型,概念数据模型及物理数据模型三 结合两种方法用例分析的第一步是确定系统能够做什么？谁来使用这个系统？这些分别叫角色（actors）和用例（use cases）。从本质上讲，一个用例是用户与计算机之间为达到某个目的的一次典型交互作用：用例描

2、述了用户提出的一些可见的需求；用例可大可小；用例对应一个具体的用户目标；用例图 用例图描述系统外部的执行者与系统的用例之间的某种联系。所谓用例是指对系统提供的功能（或称系统的用途）的一种描述；执行者是那些可能使用这些用例的人或外部系统；用例和执行者之间的联系描述了“谁使用哪个用例”。用例图用例图着重于从系统外部执行者的角度来描述系统需要提供哪些功能，并且指明了这些功能的执行者是谁；用例图在UML方法中占有十分重要的地位，人们甚至称UML是一种用例驱动的开发方法。用例图-图符用例图中的图符： 用例 参与者 系统：用于界定系统功能范围，描述该系统功能的用例都置于其中，而描述外部实体的执行者都置于其

3、外。 关联：连接执行者和用例，表示执行者所代表的系统外部实体与该用例所描述的系统需求有关。1、用例用例就是一个用来描述参与者如何使用系统来实现其目标的一组场景的集合。通常可以把它暂时理解为功能中的模块（虽然这并不严密，但更加实用）。用例强调的是一组场景，在这组场景不多但相互之间存在功能上的共性，就像一个大功能模块下的多个子模块。这组场景中的每一个，又分别形成一个个子用例。子用例再细分，又可以再形成各自的子用例。用例分析就是这样由粗到细的逐步细分，从而形成一系统的用例图。用例图分析到多细，应当由业务需求的情况决定。分得过粗，就不足以说清楚业务的相关细节，或者使一张用例图信息过多，影响人们的理解；

4、分得过细，不仅会增加工作量，还会丢失许多用例间的相互关系，得不偿失。 用例图-图符用例图中的图符： 使用：由用例A连向用例B，表示用例A中使用了用例B中的行为或功能。 扩展：由用例A连向用例B，表示用例B描述了一项基本需求，而用例A则描述了该基本需求的特殊情况。 注释体：对UML实体进行文字描述 注释连接：将注释体与要描述的实体连接，说明该注释体是针对该实体所进行的描述。使用扩展用例图-试读包含与扩展关系小结包含关系表示一种从属关系，即子用例是主用例中相对独立的、必须调用的一部分功能。在用例分析中，我们应当将多个用例都共有的、相对独立的功能提取出来形成一个子用例，为日后代码复用提供有力保障。扩

5、展关系表示一个功能是对另一个功能的扩展，即被扩展功能不一定调用扩展功能，但扩展功能是对被扩展功能的加强与延伸。2、参与者用例模型中的参与者，除了表示操作系统的人，还表示处于系统边界之外，与系统边界内的用例有关联的其它系统。因此，只有定义好一个系统的边界，才能定义哪些是这个系统内的用例，哪些是这个系统内外的参与者。用例模型对本系统与其它系统相互关联的分析，为我们日后开发过程中，为其它系统提供接口，或与其它系统进行接口，提供了依据 参与者之间的关系用例图用例模型的获取：获取执行者获取用例思考：先获取执行者还是用例？用例图获取执行者：谁使用系统的主要功能（主要使用者）？谁需要系统支持他们的日常工作？

6、谁来维护、管理系统使其能正常工作（辅助使用者）？系统需要控制哪些硬件？系统需要与其他哪些系统交互？对系统产生的结果感兴趣的是哪些人？用例图获取用例：执行者要求系统提供哪些功能？执行者需要读、产生、删除、修改或存储系统中的信息有哪些类型？必须提醒执行者的系统事件有哪些？执行者必须提醒系统事件有哪些？怎样把这些事件表示成用例中的功能？主要内容用例与用例构建方法需求分析实例需求分析工具使用介绍关于图书馆系统的需求1.这是一个图书馆支持系统；2.图书馆将图书和杂志借给借书者。借书者已经预先注册，图书和杂志也预先注册；3.图书馆负责新书的购买。每一本图书都购进多本书。当旧书超期或破旧不堪时，从图书馆中去

7、掉。4.图书管理员是图书馆的员工。他们的工作就是和读者打交道并在软件系统的支持下工作。关于图书馆系统的需求5.借阅人可以预定当前没有的图书和杂志。这样，当他所预定的图书和杂志归还回来或购进时，就通知预定人。当预定了某书的借书者借阅了该书后，预定就取消。或者通过显式的取消过程强行取消预定。6.图书馆能够容易地建立、修改和删除标题、借书者、借阅信息和预定信息。7.系统能够运行在所有流行的技术环境中，包括Unix, Windows和OS/2，并应有一个现代的图形用户界面 (GUI)。8.系统容易扩展新功能。角色图书馆的角色定为:图书管理员和借书人角色分析:图书管理员是软件系统的用户；而借书者则是来借

8、阅或预定图书杂志的客户。偶尔，图书管理员或图书馆的其他工作人员也可能是一个借书者。借书者不直接和系统交互，借书人的功能由图书管理员代为执行 用例的寻找图书馆系统中的用例有：1. 借书2. 还书3. 预定关于图书馆系统的需求1.这是一个图书馆支持系统；2.图书馆将图书和杂志借给借书者。借书者已经预先注册，图书和杂志也预先注册；3.图书馆负责新书的购买。每一本图书都购进多本书。当旧书超期或破旧不堪时，从图书馆中去掉。4.图书管理员是图书馆的员工。他们的工作就是和读者打交道并在软件系统的支持下工作。关于图书馆系统的需求5.借阅人可以预定当前没有的图书和杂志。这样，当他所预定的图书和杂志归还回来或购进

9、时，就通知预定人。当预定了某书的借书者借阅了该书后，预定就取消。或者通过显式的取消过程强行取消预定。6.图书馆能够容易地建立、修改和删除标题、借书者、借阅信息和预定信息。7.系统能够运行在所有流行的技术环境中，包括Unix, Windows和OS/2，并应有一个现代的图形用户界面 (GUI)。8.系统容易扩展新功能。用例完整版图书馆系统中的用例有：1. 借书 2. 还书 3. 预定4. 取消预定 5. 增加标题6. 修改或删除标题7. 增加书目 8. 删除书目9. 增加借书者10. 修改或删除借书者对用例的进一步描述 1如果借阅者没有预定：确定标题确定该标题下有效的书目确定借书者 图书馆将书借

10、出登记一个新的借阅以用例“借书”描述：2如果借阅者有预定：确定借书人确定标题确定该标题下有效的书目图书馆将相应的书目借出登记一个新的借阅取消预定用例图 所有的用例必须始于角色，而且有些用例也结束于角色。角色是位于你所工作的系统外部的人或其他系统。用例图的构建外部参与者所理解的系统功能一个用例模型由若干用例图来描述主要元素:用例和参与者 用例和参与者如何识别 用例的粒度如何把握Key2Key1构建用例步骤Step1:识别系统边界和Actor（识别Actor的一个作用之一就是确定系统边界）Step2:识别用例（从最终客户的角度的出发，捕获功能需求）Step3:书写用户文档（明确用例，以便在设计阶段

11、识别类和类的属性）Step4:识别用例间的关系（以便在设计阶段识别类之间的交互关系）用例之间的关系 UML用例之间主要有扩展和使用两种关系，它们是泛化关系的两种不同形式。 （1） 扩展关系 当一个用例与另一个用例相似，但比另一个所做的动作多一些时，便要用到扩展关系。 在UML中，获取扩展关系的基本方法如下： 首先获取简单的、常规的用例。 对用例中的每一步，问一下“这儿可能出现什么错误” 以及“怎样才有不同的解决方法”。 将所有出现变动的部分划分出来，作为给定用例的扩展。 扩展的数目往往不止1个，需要分别列出这些扩展会使 整个用例集合更加容易理解。 如果在一次迭代开发中不能建造整个用例，应将一个

12、复杂的用例分解成一个基本用例和一些扩展，然后在第一次迭代开发中建造基本用例，而在以后的一次或多次迭代开发中实现扩展用例。 （2） 使用关系 当有许多相似的动作跨越几个用例，而又不想重复描述该动作时，便要用到使用关系。 （3） 两种关系的比较 在扩展情况下，活动者与待扩展的用例有联系，一个给定的活动者将执行基本用例及其所有的扩展。 对于使用关系，通常活动者不会和公共用例相关联。用例图示例如何描述用例用例描述活动者与系统交互中的对话，可以用一系列的步骤描述，这些步骤构成“剧本”。例如，对于一个网上商店，顾客购买一件商品的过程可以用自然语言描述如下： 顾客浏览查询商品分类目录，找出所需要的商品。顾客

13、决定购买，给出自己的信用卡信息和送货地址。商店检查信用卡的有效性，确认成交，并确定发货时间，发出发货通知。同时商店发出确认成交的电子邮件给顾客。 购买商品1、顾客浏览查询产品分类目录，找出所需要的产品。2、顾客准备结算。3、顾客填写购货信息（产品信息，数量、送货地址、送货日期）。4、系统显示价格和应付款项。5、顾客填写信用卡信息。6、系统检查信用卡的有效性，确认交易成功。7、系统确定发货时间，发出发货通知。8、系统发确认成交的电子邮件给顾客。异常处理：信用卡有效性检查失败。在（6）中，若系统检查信用卡的有效性失败，则允许顾客重新输入信用卡信息，重复步骤7、8。用例描述系统所完成的功能（what

14、 to do ），并不是规定其怎样做（how to do），用事件流来规定用例的行为。用例的事件流是对完成用例规定行为所需要的事件的描述。在描述事件流时，应该包括下列内容：用例什么时候开始，怎样开始。用例什么时候结束，怎样结束。用例和参与者之间有什么样的交工作用。用例需要什么数据。用例的标准的事件顺序。替代的或例外的事件流的描述。采用用例模板对用例进行补充说明。用例模板用例模板的说明用例标识：用例的编号。用例名称：根据用例表达的功能而取的简短明了的名称。用例命名其实是有讲究的，即必须是一个动词短语或句子，而不是一个名词短语，通常建议为一个动宾短语（如：提取存款），一个被动句（如：发票填报），或

15、者一个主谓句（如：用户提款）。用例的命名表现了用例的特点，即它代表的是参与者的操作，是一个动作。尽量不要取 “管理”或“维护”，因为这个动作应当是一个非常明确的动作，而“管理”代表的是插入、修改、删除等一系列动作，操作就变得不明确了。应用范围：就是要设计的系统。涉众利益：关注该用例的人对该用例的要求，它往往是非功能需求，或者是功能需求中的一些常常为我们所忽视的细节。如客户要求在填写一些表单的时候能够快速进行查找，而另一些系统管理员希望提高可维护性（虽然他们可能不是该用例的参与者）。编写涉众利益应当按照如下格式：使用数字编写序号，而每个涉众利益应当书写为“谁期望怎么样”。前置条件：在触发该用例相

16、关操作前必须达到的条件。事件流：是用例说明中最重要的部分，它详细描述了该用例可能出现的所有流程。基本流程：又称为“主流程”或“主成功场景”，它描述的是该用例以最正常的方式流转，并且最终获得成功的流程。基本流程在编写时，应当通过数字，对流程中的每一步进行编号。扩展流程：又称为“替代流程”、“分支流程”或“交替场景”，它描述的是基本流程在流转过程中可能出现的所有分支。扩展流程在编写时，通常使用“数字+小写字母”对扩展流程进行编号。数字代表该扩展流程是在基本流程的哪一步发生分支的。如果是任意位置满足某条件就会发生分支，则使用“*”代替。小写字母代表该扩展流程是本用例中的第几个扩展流程。扩展流程编号的

17、后面应当描述进入该扩展流程的条件。最后，和基本流程一样，通过数字编号，详细描述该扩展流程的整个流程。如果在扩展流程中还会出现分支，则如上递归地描述该扩展流程的扩展流程。异常流程：是对该用例的所有基本流程和扩展流程可能出现的所有异常情况及其处理流程的描述。与扩展流程一样，异常流程首先通过“数字+小写字母”进行编号，描述出现异常的条件。如果是任意位置都可能满足异常条件，则使用“*”代替数字。随后，编写出处理该异常的整个流程。按照以上步骤，罗列出所有可能出现的异常情况。后置条件：又称为“成功保证”，就是执行基本流程获得成功以后所达到的状态（条件）。后置条件往往体现的是执行该用例的最终目的。非功能需求

18、：我们可以把它们简称为“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。补充规格说明书：该用例对应的补充规格说明书。用例建模通过用例可以获取用户需求，规划和控制项目。一个用例模型由若干幅用例图组成。创建用例模型的工作包括： 定义系统；寻找活动者和用例；描述用例；定义用例之间的关系；确认模型；1. 寻找活动者为获取用例首先要找出系统的活动者。下述问题有助于发现活动者：谁将使用系统的主要功能（主活动者）？谁需要借助系统的支持来完成日常工作？谁来维护和管理系统（副活动者）？系统控制

19、哪些硬件设备？系统需要与哪些其他系统交互？哪些人或系统对本系统产生的结果（值）感兴趣？Q1:为了给一笔交易进行估价需要访问房管局，是否需要在用例“交易估价”与“房管局”之间建立连接关系？A1：不需要！因为这不是一个用户需求，只是系统为满足用户的需求所要做的事情！Q2:如果系统每天晚上生成一个文件，该文件随后给记帐系统获取，那么记帐系统是一个相关的活动者吗？A2：是！记帐系统需要从系统中获取一个文件，那么它便对系统提出了一个功能方面的需求。因为用例是所有外界需要的功能！Q3:一个公共服务公司，它的用例之一是“发送帐单”，但是没有哪个客户来主动请求获取他的帐单，那么该用例的活动者是？A3：最佳的选

20、择是把帐单处理部门视作活动者，因为它要从用例中获取信息。Q4:对于一个教学管理系统，直接运用系统操作的教学管理人员是活动者。如果校长只是阅读教务人员从该系统获得的有关教学报表，自己并不直接操作系统，那么校长是活动者吗？A4：不是！校长只是系统的间接使用者，与系统没有发生交互，不能定位活动者。Q5:某些设备与信息系统相联，并直接向系统提供外界信息或在系统的控制下运行，例如某实时系统所连接的外部传感器，它们自动向系统发送外部状态信息，那么该设备可以定位成活动者吗？ A5：可以！只要与系统直接发生交互，都可以确认为活动者。2. 寻找用例活动者需要系统提供哪些功能？活动者自身需要做什么？活动者是否需要

21、读取、创建、删除、修改或存储系统中的某类信息？系统中发生的事件需要通知活动者吗？活动者需要通知系统某些事情吗？从功能观点看，这些事件能做什么？2. 寻找用例为了完整描述用例，还需要知道活动者的某些典型功能能否被系统自动实现。例如：活动者的日常工作是否因为系统的新功能而被简化或提高了效率？还有一些不是针对具体活动者的问题，而是针对整个系统的问题，因为有时候在获取用例的时候可能还不知道活动者是什么。系统需要何种输入输出？输入从何处来？输出到何处去？当前运行系统的主要问题是什么？主要内容用例与用例构建方法需求分析实例需求分析工具使用介绍主要内容Power Designer工作环境认识Power Designer BPM模型例子 Power Designer 用例模型例子 工作区间的对象流览器输出窗口下面开始创建一个BPM用例创建一个新的BMP模型STEP1:从 File 菜单中选择 New。 STEP2:在 N