第9章第10章 面向对象方法学软件工程—软件建模技术UML.ppt

第9，10章 面向对象方法学软件工程——软件建模技术UML  4 需求建模 用例图 目标 理解用例图的概念和内容。 理解活动图的概念和内容。 能够使用用例图和活动图对一个简单的系统进行需求分析。 目标 理解需求分析与用例图之间的关系。 掌握参与者、用例、关系的概念。 学会通过分析需求画出用例图。 任务 分析的项目引入中的系统的需求，确定系统中的参与者和主要用例，并画出用例视图。 案例描述 XXX是一所以培养软件开发人才为目标的高等院校，为适应IT产业发展对技术人才的需求，近年来扩大了招生规模，随着在校学生的增加，学院计划改善包括图书馆在内的各项教学设施，拟开发《图书管理系统》使其可以满足学生的要求。 需求 需求是指系统必须符合的条件或具备的功能。 需求问题是引起软件项目的高风险率的最主要原因 缺乏需求 对需求的不正确理解 需求的不完整 需求的变化 需求的误区 一个常见的误区是，开发人员都急着进入系统设计阶段或编码实现阶段，而不愿在需求分析阶段多下工夫。 但是连需求都没弄清楚，对什么编码呢？这就象一个建筑师说他必须尽快为建筑添砖加瓦，却还搞不清楚房子面向什么方位，房子的尺寸是多少，房子的内部设施是什么。 这看起来象是在说一个笑话，但在软件开发过程中是确实存在的。 需求说明了客户需要的是什么，没有需求，客户会不断的要求我们修改这里修改那里。 有了需求，我们才有目标，才能根据需求对软件进行测试，才能向客户证明我们已经达到了这个目标。 无论如何，我们都不想听到客户抱怨说开发的系统不是他们所想要的，这样的情况会浪费太多的人力和物力。 现实案例 建筑效果图 建筑规划图 建筑平面图 需求建模 如何使用UML对需求建模呢？一般系统都有几十、几百项需求描述，大的系统甚至包含了几千项需求。理解和掌握这些需求的唯一途径就是将它们组织成若干个可被理解的模块。需求的组织可以按照许多方式进行，按照功能、地点、平台、性能等等。 需求建模 需求建模 如何使用UML对需求建模呢？如图： 需求建模 使用UML对需求建模的优势？ 1、帮助项目人员按照实际情况对系统可视化。 2、对系统的描述一目了然，方便与用户的交流和沟通。 3、不易产生二义性，利于系统的分析和设计。 用例模型 在需求阶段，用例模型把系统看做一个黑箱，并且将参与者和系统之间的交互描述为叙述性的用户输入和系统响应。 参与者参与某个用例，用例定义了一个或多个参与者与系统之间的交互序列。 用例图 用例图是显示一组用例、参与者以及它们之间关系的图。 用例图从用户的角度而不是开发者的角度来描述对软件产品的需求，分析产品所需的功能和动态行为 用例图常用来对需求建模，用例图是至关重要的，它的正确与否直接影响到客户对最终产品的满意度 用例图的内容： 参与者 用例 泛化、扩展和包含关系 参与者（Actor) 参与者( Actor) 是系统外部的一个人或物，它以某种方式参与了系统的执行过程。 参与者对系统而言总是外部的 参与者在系统的不同组成部分可能扮演不同的角色 参与者用一个人形的图案表示 参与者（Actor) 例如，正在读书的某研究生同时也担当了助教工作，那么他扮演了两个角色：学生和助教。 另外，每一个参与者都必须有简短的描述，从业务角度描述参与者是什么。 在楼层停靠电梯的用例中，电梯控制系统中的到达传感器是主要参与者，而人是次要参与者 识别参与者 客户给销售员发来传真订货， 销售员下班前将当日订货单汇总输入系统。 谁是系统的Actor？ 答案： 销售员 识别参与者 寻呼台系统。用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑。 这个叙述里，谁是寻呼台系统的Actor? 用户？气温？时间？ 答案：用户，气温，时间都是Actor 识别参与者 商品销售系统。顾客通过网络下单之后，系统计算出总计金额，税金，运费，并将数目传递给一个外挂的会计系统，该系统是另外购买的。 有几个Actor？ 参与者 使用以下问题有助于发现系统的参与者 ①谁使用系统？ ②谁安装系统、维护系统？ ③谁启动系统、关闭系统？ ④谁从系统中获取信息，谁提供信息给系统？ ⑤在系统交互中，谁扮演了什么角色？ ⑥系统会与哪些其他系统相关联？ 用例 (UseCase) 用例是对一组序列动作的描述，系统执行这些动作将对用例的参与者产生可以观察的结果。 参与者和用例分别描述了“谁来做？”和“做什么？”这两个问题。 用例用实线的椭圆表示 用例定义了一个或多个参与者与系统之