大学选系统的分析与设计_第1页
大学选系统的分析与设计_第2页
大学选系统的分析与设计_第3页
大学选系统的分析与设计_第4页
大学选系统的分析与设计_第5页
已阅读5页,还剩18页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、大学选课系统的分析与设计大学选课系统的分析与设计 uml应用案例应用案例本文主要以“学生注册讨论班”为例,运用uml建模语言对大学的选课系统进行了分析。从问题分析到最后的系统设计,主要从以下几个方面进行了陈述:l问题描述l需求分析l静态建模l动态建模l组件建模l部署建模一、问题描述一、问题描述l大学选课系统是与学生有着紧密的联系,具有注册、交费、选课、成绩查询等功能l为了简化本次系统分析只考虑学生注册讨论班的功能,该问题描述如下: 学生想要注册某门讨论班,于是向注册员提交其姓名和学生编号; 注册员验证该学生是否有资格注册这门讨论班; 注册员验证后,提供讨论班列表,并验证是否适合学生的课程安排;

2、 注册员统计费用并通知学生; 在学生确认后,注册员将该学生注册到讨论班,并将费用加入学生帐单; 注册员向学生提供注册成功的确认信息。根据以上问题描述,该简化系统应具有如下功能:学生搜索、注册讨论班验证注册资格显示讨论班及相关信息提供成绩单结算并显示帐单注册成功关闭注册返回二、需求分析二、需求分析 采用用例驱动的方法分析需求的主要任务是识别参与者和用例,并建立用例模型,主要分为以下三个部分。识别参与者识别用例确定事件流返回(一)识别参与者(角色)(一)识别参与者(角色) 参与者表示与系统进行交互的任何人或物。可以包括人(不只是最终用户)、外部系统和其它机构。 通过分析选课系统的功能需求,确定有以

3、下三个参与者: (1)学生:在系统中申请注册讨论班的人 (2)注册员:完成验证注册信息的人或外部系统 (3)教授:指导或协助讨论班和管理学生成绩返回(二)识别用例(用况)(二)识别用例(用况) 用例是一系列活动,描述真实世界中参与者与系统相互交互的方式。 通过分析选课系统的功能需求,确定有如下用例: (1)注册讨论班 (2)退出讨论班 (3)参加讨论班 (4)完成讨论班 (5)通知学生计划改变 (6)分发成绩单 (7)输出收费计划表 (8)输入成绩 (9)指导讨论班 (10)生成教学进度系统的用例图如下所示:返回(三)用例的事件流描述(三)用例的事件流描述 用例还可以事件流来描述,用例的事件流

4、是对完成用例行为所需的事件的描述。事件流描述了系统应该作什么,而不是描述系统应该怎样做。 学 生注册员1学生想去注册讨论班。3注册员确定该学生是否有资格在这所学校注册讨论班。2学生向注册员提交其姓名和编号4学生从可供选择的讨论班列表中,选出他希望注册的讨论班。4学生从可供选择的讨论班列表中,选出他希望注册的讨论班。5. 注册员验证学生是否有资格注册这门课。6. 注册员检验讨论班是否适合学生已有的课程安排7. 注册员根据讨论班目录中公布的费用、适用的学生费用和适用的税,计算出这门课的收费。 8. 注册员通知学生相关费用。 9. 注册员确认学生表示愿意注册该讨论班。 10. 学生表示愿意注册该讨论

5、班。 14. 当学生得到确认信息时用况结束 11. 注册员把学生注册到该讨论班。 12. 注册员把相应的费用加到学生账单中。 13. 注册员向学生提供已经注册成功的确认。名称:名称:注册讨论班描述:描述:把现有的有资格的某一学生注册到某个讨论班。前提条件:前提条件:学生已在大学注册。后置条件:后置条件:如果学生具有注册资格,并且该讨论班仍有空位,则学生注册到该讨论班。活动的基本过程:活动的基本过程:事件流续表:事件流续表:候选过程候选过程a:学生没有资格注册讨论班。 a3. 注册员确定学生没有资格注册讨论班。 a4. 注册员通知学生,她没有资格注册。 a5. 用况结束。候选过程候选过程b:学生

6、不具备注册这一讨论班所需要的必备条件。 b5. 注册员确定学生没有资格注册该讨论班。 b6. 注册员通知学生,她不具备注册这一讨论班所需要的必备条件 b7.注册员通知学生,她需要具备的条件。 b8. 用况从活动基本过程中的步骤4继续执行。候选过程候选过程c:学生决定不注册讨论班,虽然有讨论班可供其选择。 c4.学生查看讨论班列表,但没有找到他想要注册的项。 c5. 用况结束。根据事件流描述,活动框图如下所示:返回三、静态建模三、静态建模进一步分析系统需求,发现类以及类之间的关系,确定它们的静态结构和动态行为,是面向对像分析的基本任务。系统的静态结构模型主要用类图和对象图描述。 静态建模主要分为

7、两步: 1)定义类 2)确定类的名字、属性和操作,建立类图。返回(一)定义类(一)定义类该系统主要有三种类型的类: 参与者类参与者类(actor class):代表出现在用况中的参与者 用户界面类用户界面类(user interface class):组成系统用户界面的屏幕显示、菜单和报表,即ui元素 业务类业务类 (business class):描述业务的地点、物品、概念和事件 在静态建模中用类模型表示概念模型,而着手进行概念模型的最简单的方法是把领域模型作为设计基础,于是要采用类-职责-协作(crc)模型并把它直接转换成类图 crc卡片的布局如下图所示:该系统该系统crc模型如下模型如下

8、该列为参与者类该列为业务类该列为用户界面类返回(二)类图(二)类图识别出系统中的类后,还要识别出类间的关系(关联、聚合、组合、类属、依赖、实现关系,前面已讲过),然后就可以建立类图了。在处理复杂问题时,通常使用分类的方法来有效地降低问题的复杂性。在面向对象建模技术中,也可以采用同样的方法将客观世界的实体映射为对象,并归纳成类。类、对象及它们之间的关系是面向对象技术中最基本的元素。类图是面向对象系统最常用的图,类图描述了类集、接口集、协作及它们之间的关系。类间的关系如下图所示:用户界面包中有如下三个类:1.成绩单2.注册讨论班3.安全登录返回四、动态建模四、动态建模 动态模型描绘了参与每个用例的

9、对象之间的交互。开发动态模型的起点是用例以及在对象构建期间决定的对象。通常使用协作图来描绘满足用例需要的对象间消息通信,针对单个类实例的行为,用状态图描绘该类状态的改变。u状态图:为依赖状态展示不同行为的类开发状态图u协作图:描绘对象间交互的鸟瞰视图返回返回返回五、组件建模五、组件建模 组件建模的目标, 把系统中在类分布到更大的内聚的组件当中。重构(refactor)传统的对象设计,以便将其作为组件进行部署。为了能够把对象设计组件化,需要执行五个步骤,通常这五个步骤是迭代执行的: 1处理非业务/领域类。 2定义类契约。 3简化继承与聚合的层次结构。 4确定领域组件。 5定义领域组件契约。 组组 件

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论