UML软件建模技术2.1用例图.pptVIP

包含用例与扩展用例的区别 举例： 小明去上街是一个用例，上厕所用例与上街用例可以是包含也可以是扩展用例。 一定要上厕所是包含关系，可上可不上是扩展关系。 包含关系 上街之前必须要上厕所是包含关系。 扩展关系 上街之前如果内急才要上厕所是扩展关系。 包含用例与扩展用例的区别 相对于基础用例，扩展用例是可选的；包含用例则不是。 如果缺少扩展用例，基础用例还是完整的；缺少包含用例，则基础用例就不完整了。 扩展用例的执行需要满足某种条件；包含用例不需要。 扩展用例的执行会改变基础用例的行为；包含用例不会。 任务解决 读者需要借书籍，也需要还书籍 。 读者可以预约书籍，也可以撤消预约 。 管理员根据读者要求提供服务。 管理员可以添加、修改、删除读者 。 管理员可以添加、修改、删除书籍 。 湖南科技职业学院软件学院 2.1 用例图 * 强调需求分析在项目开发中的重要性。举例：在软件开发过程中，一个常见的误区是，开发人员都急着进入系统设计阶段或编码实现阶段，而不愿在需求分析阶段多下工夫。但是连需求都没弄清楚，对什么编码呢？这就象一个建筑师说他必须尽快为建筑添砖加瓦，却还搞不清楚房子面向什么方位，房子的尺寸是多少，房子的结构怎样。没有弄清楚需求而盲目动手开发，很有可能导致最终客户要的是红衣服，而我们做出了蓝裤子。 * 问题：如何使用UML对需求建模呢？在各种描述方式中，图形往往是最直观的。对系统的描述一目了然，方便与用户的交流和沟通。 * * ①谁使用系统？ ②谁安装系统、维护系统？ ③谁启动系统、关闭系统？ ④谁从系统中获取信息，谁提供信息给系统？ ⑤在系统交互中，谁扮演了什么角色？ ⑥系统会与哪些其他系统相关联？ * 参与者和用例分别描述了“谁来做？”和“做什么？”这两个问题。 * 根据需求分析作出用例后，并不是一切就万事大吉了，还需要对用例的正确性进行分析。错误的或描述不清的用例可能会导致错误的需求分析，并把我们的设计实现工作带入歧路。 第二章　需求建模 2.1 用例图 软件建模技术 1. 理解用例及用例图的概念 3.掌握用例之间的关系 2. 如何创建用例图 本节目标 1.用例图的作用 3.用例之间的关系 2.用例图的创建方法 本节重难点 问题引入 　　作为一名HNS图书馆管理系统的项目开发人员，你需要站在用户的角度分析该系统的需求，确定系统中的参与者和主要用例，并画出用例视图。 How To ? 认识用例图 我们可以使用用例(use case)作为需求建模的起点。 以用例为起点进行需求建模，可以使我们的焦点集中在客户身上 。 用例图是显示一组用例、参与者以及它们之间关系的图。 用例图从用户的角度而不是开发者的角度来描述对软件产品的需求，分析产品所需的功能和动态行为。 用例图包括以下三方面的内容： 参与者 用例 依赖、泛化和关联关系 概 念 参与者（ Actor ） 　　参与者(actor ，有些书翻译成“角色”)是一种特殊的类，是系统外部的一个实体，这个实体可以是任何的人或物，它以某种方式参与了用例的执行过程。参与者用一个人形的图案表示 。 参与者 识别参与者 谁使用系统？ 谁安装系统、维护系统？ 谁启动系统、关闭系统？ 谁从系统中获取信息，谁提供信息给系统？ 在系统交互中，谁扮演了什么角色？ 系统会与哪些其他系统相关联？ 识别参与者 客户给销售员发来传真订货， 销售员下班前将当日订货单汇总输入系统。 谁是系统的Actor？ 销售员 寻呼台系统。用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑。 这个叙述里，谁是寻呼台系统的Actor? 用户？气温？时间？ 三个都是 商品销售系统。顾客通过网络下单之后，系统计算出总计金额，税金，运费，并将数目传递给一个外挂的会计系统，该系统是另外购买的。 有几个Actor？ 顾客 会计系统 概 念 用例（UseCase）　 　　用例（UseCase）是对一组序列动作的描述，系统执行这些动作将对用例的参与者产生可以观察的结果。在图形上，用例用实线的椭圆表示。 识别用例 参与者希望系统提供什么功能 系统是否存储和检索信息 当系统改变状态时，是否通知参与者 是否存在影响系统的外部事件，是哪个参与者通知系统这些外部事件 识别用例 Email客户端（如：outlook express） A在北京发邮件给深圳的B，系统提醒B ”你有新邮件” ，B收邮件。 识别用例 一个论坛类的应用 用户可以提问，别人来回答，如果有自己问题被解答的话，就给提问者发一份邮件通知。 如何判断一个用例是否