信息管理系统-实验课件1.pptVIP

实验部分 需求建模 一 用例图 本章目标 理解用例图的概念和内容。 理解活动图的概念和内容。 能够使用用例图和活动图对一个简单的系统进行需求分析。 章节安排 §用例图 §活动图 本节目标 理解需求分析与用例图之间的关系。 掌握参与者、用例、关系的概念。 学会通过分析需求画出用例图。 任务 分析本章的项目引入中的系统的需求，确定系统中的参与者和主要用例，并画出用例视图。 需求 需求是指系统必须符合的条件或具备的功能。 需求问题是引起软件项目的高风险率的最主要原因 缺乏需求 对需求的不正确理解 需求的不完整 需求的变化 需求建模 需求建模 如何使用UML对需求建模呢？如图： 需求建模 使用UML对需求建模的优势？ 1、帮助项目人员按照实际情况对系统可视化。 2、对系统的描述一目了然，方便与用户的交流和沟通。 3、不易产生二义性，利于系统的分析和设计。 用例图 用例图是显示一组用例、参与者以及它们之间关系的图。 用例图从用户的角度而不是开发者的角度来描述对软件产品的需求，分析产品所需的功能和动态行为 用例图常用来对需求建模，用例图是至关重要的，它的正确与否直接影响到客户对最终产品的满意度 用例图的内容： 参与者 用例 泛化、扩展和包含关系 参与者（Actor) 参与者( Actor) 是系统外部的一个人或物，它以某种方式参与了系统的执行过程。 参与者对系统而言总是外部的 参与者在系统的不同组成部分可能扮演不同的角色 参与者用一个人形的图案表示 识别参与者 客户给销售员发来传真订货， 销售员下班前将当日订货单汇总输入系统。 谁是系统的Actor？ 答案： 销售员 识别参与者 寻呼台系统。用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑。 这个叙述里，谁是寻呼台系统的Actor? 用户？气温？时间？ 答案：用户，气温，时间都是Actor 识别参与者 商品销售系统。顾客通过网络下单之后，系统计算出总计金额，税金，运费，并将数目传递给一个外挂的会计系统，该系统是另外购买的。 有几个Actor？ 参与者 使用以下问题有助于发现系统的参与者 ①谁使用系统？ ②谁安装系统、维护系统？ ③谁启动系统、关闭系统？ ④谁从系统中获取信息，谁提供信息给系统？ ⑤在系统交互中，谁扮演了什么角色？ ⑥系统会与哪些其他系统相关联？ 用例 (UseCase) 用例是对一组序列动作的描述，系统执行这些动作将对用例的参与者产生可以观察的结果。 参与者和用例分别描述了“谁来做？”和“做什么？”这两个问题。 用例用实线的椭圆表示 用例 识别用例的最好办法就是从分析系统的参与者开始，考虑每个参与者是怎样使用系统。 根据下面的一些问题来识别用例： ①参与者希望系统提供什么功能； ②系统是否存储和检索信息； ③当系统改变状态时，是否通知参与者； ④是否存在影响系统的外部事件，是哪个参与者通知系统这些外部事件。 识别用例 Email客户端（如：outlook express），A在北京发邮件给深圳的B，系统提醒B”你有新邮件”，B收邮件。 识别用例 一个论坛类的应用，用户可以提问，别人来回答，如果有自己问题被解答的话，就给发问者发一份邮件通知。 注意：发邮件这个用例可以是单独的用例，也可以是由回答用例扩展出来的用例 用例 如何判断一个用例是否是一个优秀的用例呢？ ①用例是否描述了应该做什么，而不是如何做？ ②用例的描述是否采取了参与者的视点？ ③用例是否对参与者有价值？ ④用例描述的时间流是否是一个完整场景？ ⑤是否所有的参与者、用例都有相应的关联用例或关联参与者？ 用例与事件流 用例描述的是参与者与系统之间的对话，但是这个对话的细节并没有在用例图中表述出来，针对每一个用例我们可以用事件流来描述这一对话的细节内容。 事件流可分为：基本事件流 、备选事件流 用例与事件流 银行自动取款机(ATM)系统中的“提款”用例可以用事件流表述如下 用例与事件流 提款─备选事件流 备选流一：用户可以在基本流中的任何一步选择退出， 转至基本流步骤5。 备选流二：在基本流步骤1中，用户插入无效信用卡，系统显示错误并退出信用卡，用例结束。 备选流三：在基本流步骤２中，用户输入错误密码，系统显示错误并提示用户重新输入密码，重新回到基本流步骤2；三次输入密码错误后，信用卡被系统没收，用例结束。 用例之间的关系 泛化关系