信息系统开发方法与实践教程作者曲翠玉第8章课件.ppt

2006-8-21 第8章 用例图 主讲：曲翠玉 本章内容 需求判定方法 用例建模:用例图与用例描述 面向对象的系统分析 需求判定 需求结构化 用例描述与用例图 概念数据建模 对象关系型建模 分析类图—顺序图﹑协作图﹑状态图﹑活动图 候选策略的生成与选择 外包﹑软件来源﹑硬件﹑实现等问题。 需求判定方法 传统的需求判定方法 座谈与倾听 管理问卷 座谈与问卷结合 直接观察用户 分析工作流程及其他文档 现代系统需求判定方法 联合应用设计(JAD) 在需求判定期间使用原型化 用例建模的作用 在需求分析中，用例图只说明系统实现什么功能，不必说明怎么实现，表示了从系统的外部用户的观点看系统应具有的功能的高级视图。 用例图元素 参与者（Actor） 用例（Use Case） 系统边界 箭头 参与者（Actor） 参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。 参与者可以是人，可以是事物，也可以是时间或其他系统等。 参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。不要求参与者与系统的实际用户一一对应。 用例 用例是参与者想要系统做的事情 用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者意愿的可观察结果(UML对用例的定义) 我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。 系统边界 系统边界是用来表示正在建模系统的边界。 系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。 箭头 箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。 箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。 用例图元素之间的关系 角色之间的关系 用例之间的关系 泛化关系 包含关系 扩展关系 用例和角色之间的关系 角色间的泛化 由于角色实质上也是类，所以它拥有与类相似的关系描述，即角色之间存在泛化关系 泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。 用例间的泛化关系 代表一般与特殊的关系。它的意思和面向对象程序设计中继承的概念是类似的。 不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。 在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。 用例间的包含关系 基本用例用来描述在多个用例中都有的公共行为。 其它用例使用基本用例，并把它所包含的用例行为做为自身行为的一部分。 在包含关系中箭头的方向是从其它用例到基本用例。 用例的扩展关系 在以下几种情况下，可使用扩展用例： 表明用例的某一部分是可选的系统行为（可以将模型中的可选行为和必选行为分开） 表明只在特定条件（如例外条件）下才执行的分支流 用例建模1 某种商品的订购方式有两种：电话订购和Internet订购，绝大部分客户采用电话订购。有的订购用户会索要商品目录，所有用户都必须提供用户信息。 用例图练习 任何行业都要进行商品的订购，在订购供应品前，需要查看销售和库存数据，销售经理会定期生成管理报表。 Order supplies(订购供应品) Produce management reports(生成管理报表) Track sales and inventory data(跟踪销售和库存数据) 参与者有：Supplier(供应商) ﹑Manager(销售经理) 商品订购用例图 电子投票系统用例图 用例描述 简要描述：对用例的角色、目的简要描述 前置条件：执行用例之前系统必须要处于的状态，或者要满足的条件 基本事件流：描述该用例的基本流程，指每个流程都“正常”运作时所发生的事情，没有任何备选流和异常流，而只有最有可能发生的事件流； 其他事件流：表示这个行为或流程是可选的或备选的，并不是总要执行它们 异常事件流：表示发生了某些非正常的事情所要执行的流程 后置条件：用例一旦执行后系统所处的状态 一个家教网站的前台客户系统 后台管理系统用例图 用例描述 用例名称：网站公告发布 参与者：负责人 简要说明： 负责人用来填写和修改家教网站首页的公告，公告最终显示在家教网站的首页上。 基本事件流: 1.负责人鼠标点击“修改公告”按钮。 2.系统出现一个文本框，显示着原来的公告内容。 3.负责人可以在文本框上修改公告，也可以完全删除，重新写新的公告。 4.负责人编辑完文本框，按“提交”按钮，首页公告就被修改。 5.用例终止。 思考与练习 （1）【绘制商品订购的用例图】 任何行业都要进行商品的订购，在订购供应品前，需要查看销售和库存数据，销售经理会定期生成管理报表。 思考与练习 （2）【绘制酷我音乐盒的用例图】