子情景4.2 用例分析,情境4：Web系统建模在线销售系统,*,(中职）UML与Rose建模应用子情境4.2ppt课件,学习情境4：Web软件建模,在线销售系统,UML及Rose建模应用,子情境4.2 用例分析,根据子项目4.1的需求分析报告，确定“在线销售系统”的参与者（如普通客户、管理员及内部员工）、用例（如注册会员、登录系统、浏览商品、检索商品、查看订单、查看购物车、指定配送地址、指定支付方式等）、参与者与用例之间的关系，最后设计出“在线销售系统”的整体系统用例图子情景描述,相关知识,1用例规约,用例图只是在总体上大致描述了系统所提供的各种服务，让用户对系统有一个总体的认识但对于每个用例还需要有详细的描述信息，以便让其他人对于整个系统有一个更加详细地了解，这些信息包含在用例规约之中而用例模型指的也不仅仅是用例图，而是由用例图和每一个用例的详细描述用例规约所组成的2泛化,用例的泛化指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系在用例的泛化关系中，子用例继承了父用例所有的结构、行为和关系，子用例是父用例的一种特殊形式此外，子用例还可以添加、覆盖、改变继承的行为。
相关知识,在UML中，用例的泛化关系通过一个从子用例指向父用例的三角箭头来表示，如图4-15所示当发现系统中有两个或者多个用例在行为、结构和目的方面存在共性时，就可以使用泛化关系这时可以用一个新的（通常也是抽象的）用例来描述这些共有部分，这个新的用例就是父用例如图4-16所示为飞机订票系统的用例图，预定飞机票有两种方式，一种是通过电话预定，另一种是通过网上预定在这里，电话订票和网上订票都是订票的一种特殊方式，因此“订票”为父用例，“电话订票”和“网上订票”为子用例图4-15 泛化关系,相关知识,当发现系统中有两个或者多个用例在行为、结构和目的方面存在共性时，就可以使用泛化关系这时可以用一个新的（通常也是抽象的）用例来描述这些共有部分，这个新的用例就是父用例如图4-16所示为飞机订票系统的用例图，预定飞机票有两种方式，一种是通过电话预定，另一种是通过网上预定在这里，电话订票和网上订票都是订票的一种特殊方式，因此“订票”为父用例，“电话订票”和“网上订票”为子用例图4-16 泛化关系示例,相关知识,在用例的包含关系中，基础用例在目的上可以完全不同，但是它们都有一段相似的行为，它们的相似是部分的相似不是整体的相似。
用例的泛化关系类似于面向对象中的继承，它把多个子用例中的共性抽象成一个父用例，子用例在继承父用例的基础上可以进行修改但是子用例和子用例之间又是相互独立的，任何一个子用例的执行不受其他子用例的影响而用例的包含关系是把多个基础用例中的共性抽象为一个被包含用例，可以说被包含用例就是基础用例中的一部分，基础用例的执行必然引起被包含用例的执行该系统有三类用户，一类是普通客户，一类是管理员，一类是内部员工参与者的识别,步骤1,注册会员 修改注册资料 管理员退出系统,用户登录系统 用户退出系统管理业务数据,浏览商品 检索商品管理系统权限,浏览商品详细信息 查看订单,商品放入购物车 查看购物车,管理业务数据 准备结账,指定配送地址 指定支付方式,完成订单 管理员登录系统,用例识别,步骤2,子情景实施,【提示】在浏览窗口中右键单击“Use Case View”（用例视图），在弹出的菜单上选择菜单项“New”（新建）下的“Use Case Diagram”（用例图）命令，从键盘输入文本“销售系统用例”命名该用例图，双击“销售系统用例”打开用例图窗口在工具箱中单击“Actor”（参与者）图标，将光标移动到用例图窗口适当位置，单击鼠标左键，就会出现名为“NewClass”参与者，重命名为“客户”，如图4-17所示。
采取此方法，依次创建参与者“管理员”、“内部员工”，如图4-20所示新建参与者,步骤3,图4-17 新建参与者示例,子情景实施,在工具箱中选择“Use Case”（用例）工具图标，将光标移动到窗口适当位置，单击鼠标左键，就会出现名为“NewUseCase”用例，输入文本“注册”进行重命名，按相同的方法依次新建如图4-18所示的其它用例提取用例,步骤4,图4-18 新建用例示例,子情景实施,在工具箱中选择“Association”（双向导向关联）图标，将光标指向参与者“客户机”，按住鼠标左键，拖动至用例“注册”，松开鼠标，在两者之间就会出现一条“线段”，创建两者间的关联完成，如图4-19所示新建参与者与用例间的双向关联,步骤5,图4-19 新建关联示例,子情景实施,参照步骤5，创建参与者与用例间的关联，如图4-20所示创建在线销售用例图,步骤6,图4-20 在线销售用例图,子情景实施,知识或技能拓展,用例的粒度,用例的粒度指的是用例所包含的系统服务或功能单元的多少用例的粒度越大，用例包含的功能越多，反之则包含的功能越少在用例建模时，很多人都会对自己系统所需要的用例个数产生疑惑对同一个系统的描述，不同的人可能会产生不同的用例模型。
如果用例的粒度很小，得到的用例数就会太多反之，如果用例的粒度很大，那么得到的用例数就会很少如果用例数目过多会造成用例模型过大和引入设计困难大大提高；如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析知识或技能拓展,如下图4-21所示为在线销售系统的维护商品信息用例，管理员需要进行商品价格的调整、商品描述信息的更新、新商品的加入以及过期商品的删除等操作图4-21 商品信息维护子系统,知识或技能拓展,还可以根据具体的操作把它抽象成四个用例，如图4-22所示，它展示的系统需求和单个用例是完全一样的图4-22 细化后的商品信息维护子系统,知识或技能拓展,当大致确定用例个数后，就可以很容易的确定用例粒度的大小对于比较简单的系统，因为系统的复杂度一般比较低，所以可以适当加大用例模型一级的复杂度，也就是可以将较复杂的用例分解成多个用例对于比较复杂的系统，因为系统的复杂度已经很高，需要加强控制用例模型一级的复杂度，即将复杂度适当地以往用例内部，让一个用例包含较多的需求信息量用例的粒度对于用例模型来说是很重要的，它不但决定了用例模型级的复杂度，而且也决定了每一个用例内部的复杂度在确定用例粒度时应该根据每个系统的具体情况，具体问题具体分析，在尽可能保证整个用例模型的易理解性的前提下决定用例的大小和数目。
Thank You!,。