大学选课系统的分析与设计—— uml应用案例.pptVIP

1 一、问题描述 大学选课系统是与学生有着紧密的联系，具有注册、交费、选课、成绩查询等功能 为了简化本次系统分析只考虑学生注册讨论班的功能，该问题描述如下： 根据以上问题描述，该简化系统应具有如下功能： 学生搜索、注册讨论班 验证注册资格 显示讨论班及相关信息 提供成绩单 结算并显示帐单 注册成功 关闭注册 二、需求分析 采用用例驱动的方法分析需求的主要任务是识别参与者和用例，并建立用例模型，主要分为以下三个部分。 （二）识别用例（用况） 用例是一系列活动，描述真实世界中参与者与系统相互交互的方式。 通过分析选课系统的功能需求，确定有如下用例： （1）注册讨论班 （2）退出讨论班 （3）参加讨论班 （4）完成讨论班 （5）通知学生计划改变 （6）分发成绩单 （7）输出收费计划表 （8）输入成绩 （9）指导讨论班 （10）生成教学进度 系统的用例图如下所示： （三）用例的事件流描述 根据事件流描述，活动框图如下所示： 三、静态建模 进一步分析系统需求，发现类以及类之间的关系，确定它们的静态结构和动态行为，是面向对像分析的基本任务。 系统的静态结构模型主要用类图和对象图描述。 静态建模主要分为两步： 1）定义类 2）确定类的名字、属性和操作，建立类图。 （二）类图 四、动态建模 动态模型描绘了参与每个用例的对象之间的交互。开发动态模型的起点是用例以及在对象构建期间决定的对象。通常使用协作图来描绘满足用例需要的对象间消息通信，针对单个类实例的行为，用状态图描绘该类状态的改变。 五、组件建模 W W W . W A T S O N W Y A T T . C O M 大学选课系统的分析与设计 UML应用案例 　　本文主要以“学生注册讨论班”为例，运用UML建模语言对大学的选课系统进行了分析。从问题分析到最后的系统设计，主要从以下几个方面进行了陈述： 问题描述 需求分析 静态建模 动态建模 组件建模 部署建模 学生想要注册某门讨论班，于是向注册员提交其姓名和学生编号； 注册员验证该学生是否有资格注册这门讨论班； 注册员验证后，提供讨论班列表，并验证是否适合学生的课程安排； 注册员统计费用并通知学生； 在学生确认后，注册员将该学生注册到讨论班，并将费用加入学生帐单； 注册员向学生提供注册成功的确认信息。 返回 识别参与者 识别用例 确定事件流 返回 （一）识别参与者（角色） 参与者表示与系统进行交互的任何人或物。可以包括人（不只是最终用户）、外部系统和其它机构。 通过分析选课系统的功能需求，确定有以下三个参与者： （1）学生：在系统中申请注册讨论班的人 （2）注册员：完成验证注册信息的人或外部系统 （3）教授：指导或协助讨论班和管理学生成绩 返回 返回 用例还可以事件流来描述，用例的事件流是对完成用例行为所需的事件的描述。事件流描述了系统应该作什么，而不是描述系统应该怎样做。 11. 注册员把学生注册到该讨论班。 12. 注册员把相应的费用加到学生账单中。 13. 注册员向学生提供已经注册成功的确认。 10. 学生表示愿意注册该讨论班。 14. 当学生得到确认信息时用况结束 5. 注册员验证学生是否有资格注册这门课。 6. 注册员检验讨论班是否适合学生已有的课程安排 7. 注册员根据讨论班目录中公布的费用、适用的学生费用和适用的税，计算出这门课的收费。 8. 注册员通知学生相关费用。 9. 注册员确认学生表示愿意注册该讨论班。 4．学生从可供选择的讨论班列表中，选出他希望注册的讨论班。 4．学生从可供选择的讨论班列表中，选出他希望注册的讨论班。 2．学生向注册员提交其姓名和编号 3．注册员确定该学生是否有资格在这所学校注册讨论班。 1．学生想去注册讨论班。 注册员 学 生 名称：注册讨论班 描述：把现有的有资格的某一学生注册到某个讨论班。 前提条件：学生已在大学注册。 后置条件：如果学生具有注册资格，并且该讨论班仍有空位，则学生注册到该讨论班。 活动的基本过程： 事件流续表： 候选过程A：学生没有资格注册讨论班。 A3. 注册员确定学生没有资格注册讨论班。 A4. 注册员通知学生，她没有资格注册。 A5. 用况结束。 候选过程B：学生不具备注册这一讨论班所需要