UML选课系统建模.docx
《UML选课系统建模.docx》由会员分享，可在线阅读，更多相关《UML选课系统建模.docx（12页珍藏版）》请在冰点文库上搜索。
UML选课系统建模
用UML图表达，能体现你从整体到细节的掌控能力，它能体现出最清晰的思路，最直接的思想。
如果代码是“文字”的话，我认为UML就是类似人说的一种“语言”！
所以用“语言”比起用“文字”我们能更方便的与他人交流,比如你告诉他你是怎么实现一个功能的，你还得让对方看你的代码，代码简明还好，要是很复杂的话，一来别人可能暂时看不懂，二来你讲解也会很费劲。
而用图的话，就十分直观，配合图你再适当的说明思路，别人便很容易就理解你了。
而且一个会“说话”的人，还体现出这个人的素质、水平必定很高，别人会感到你这个人很有内涵！
以上是从个人来说的，而对于学校来说，它的作用就更大了，它是一个系统的蓝图！
在编制一个系统时，我们必须首先要画好图纸，明确目标、计划、步骤。
直到系统后期的维护，我们仍然要以图为根据做修改。
一、学校选课系统UML建模的前期分析
1、学校用计算机管理的选课系统
●注册管理员设置一个学期的所有课程信息，一个课程可以有多个课程选修单
●学生可以选择6门必修课和2门选修课
●当某学生在学期注册了，则注册（billing）系统会得到通知，在该学期给该学生开设账号
●学生在注册后一段时间可以使用系统增加/撤销所选课程
●老师使用这个系统接受他们课程的选课名单
●注册系统的用户将得到密码（password），用于登录的确认
2、确定参与者以及他们的要求
—注册管理员：
维护所有课程信息
—老师：
要求选课名单
—学生：
维护选课表
—记账系统：
从注册中心接受记账信息
3、维护所有课程信息的事件流
用例开始于注册管理员登录到注册系统并敲入他的密码时。
系统检验此密码是否有效，并提示注册管理员选择当前学期或者下个学期。
注册管理员敲入他期望的学期。
然后系统提示选择他期望的活动，包括：
增加选择，取消选择，审查选择或退出系统。
a）如果选择增加选择，则执行增加课程的子事件流。
b）如果选择取消选择，则执行删除所有课程信息的子事件流。
c）如果选择审查选择，则执行审查所有课程信息的子事件流。
d）如果选择退出系统，则用例结束。
4、建立选课表子事件流
a）系统检索来自课程目录系统的一个有效得课程申请的列表，并把这个表显示给学生。
b）学生根据这个有效的课程申请列表选择6门主修课申请和2门选修课申请。
c）一旦学生作出他的选择，系统为学生建立一个选课表，包括了这个学生选择的课程申请。
d）执行“提交选课表”子事件。
二.基本概念
UML（UnifiedModelingLanguage的缩写）
统一建模语言，是用来对软件密集系统进行可视化建模的一种语言。
UML为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。
UML建模的类别：
静态建模机制：
描述软件系统的结构。
动态建模机制：
描述软件系统的行为。
三、选课系统UML建模的九种图
1、 用例图
定义：
呈现了一些学生和一些课程，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
学生选课系统的参与者：
学生登录选课界面，查询选课课表并且选课
图中元素：
角色、用例、关系线
2、 类图
定义：
显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。
类图不显示暂时性信息。
图中元素：
类、接口、关系线
图中内容：
类的属性和方法的声明都有3种常用的作用域范围
注意抽象类与抽象（虚）方法的表示方法
注意接口的表示方法。
接口里的属性和方法都是要在一个类里具体定义实现的，所以接口的方法本身就是抽象（虚）方法（不能再图里表示出来）【类、接口没有虚属性这一说】
如果属性或方法具有下划线，则说明它们是静态的。
3、 包图
定义：
多个图形元素的集合。
将图形封装在一个代表整体结构划分的简单集合图形中，即称之为包。
图中元素：
包、角色、关系线
图中内容：
包图（也可直接理解为命名空间、文件夹）一般也就是系统的架构图。
包与包之间只能用“调用”关系表示
4、组件图
定义：
组件图提供系统的物理视图，它的用途是显示系统中的软件与其他软件组件（例如，库函数）的依赖关系。
选课系统组件图示例
图中元素：
组件（构件）、关系线
组件：
系统中一种物理的、可代替的部件、它封装了实现并提供了一系列可用的接口。
一个组件代表一个系统中实现的物理部分，包括软件代码（源代码，二进制代码，可执行代码）或者一些类似内容，如脚本或者命令文件。
它是系统物理设计的基本单元。
图中内容：
和包图一样用于描述软件系统架构。
5、 部署图
定义：
表示该软件系统如何部署到硬件环境中。
它的用途是显示该系统不同的组件将在何处物理地运行，以及它们将如何彼此通信。
图中元素：
节点、组件（构件）、关系线
节点（用立方体表示）：
可表示一个物理设备，也可以代表在该系统软件上运行的软件系统
图中内容：
和包图一样用于描述软件系统架构。
带阴影的立方体表示处理器：
具有处理能力的节点，即可以执行构件。
空心立方体表示设备：
没有处理能力的节点，至少是不关心其处理能力的节点。
例如打印机
6、 时序图（顺序图）
定义：
用来显示对象之间的关系，并强调对象之间消息的时间顺序，同时显示了对象之间的交互。
学生选课的时间顺序
图中元素：
角色，生命线（虚线），条状矩形和消息
图中内容：
长细的方条表示的是某一方法的周期。
“→”表示调用下层的某一方法（有参数则传参给下一层）
7、状态图
定义：
描述指定对象的所有可能状态，以及有各种事物触发的状态迁移。
表示从状态到状态的控制流。
图中元素：
角色、状态、状态转换、起始状态（
）
图中内容：
起始状态只能有一个，而终止状态不唯一。
系统某一操作也能引起自身状态的改变（如余额）。
8、活动图
定义：
描述需要执行的活动及其执行步骤顺序。
表示从活动到活动的控制流。
图中元素：
状态、状态转换、起始状态、终止状态、活动
图中内容：
图中可以包含具体对象的具体状态（没有画出）。
活动图体现的是系统所以功能的执行流程。
注意：
状态图和活动图的区别
活动图适合描述多个对象和多个用例的活动顺序
状态图适合描述跨越多个用例的单个对象的状态变化
也就是说活动图用于对软件功能整体流程的描述，而状态图是针对某一对象在软件功能中所有能引起其状态变化的描述。
9、合作图（协作图）
定义：
用于显示对象之间如何进行交互以执行特定用例或用例中特定部分的行为，以显示对象之间的关系。
图中元素：
活动者、对象、连接
注意：
协作图与时序图的区别
协作图的重点是将对象的交互映射到它们之间的链上，但是时序图却不把链表示出来。
时序图可以描述对象的创建和撤销的情况，而在协作图中，对象要么存在要么不存在。
如果需要强调时间和序列，最好选择序列图；如果需要强调上下文相关，最好选择协作图。
四、心得体会
在项目设计阶段，我觉得顺序图、活动图、状态图比较重要，结合传统数据流图、功能角色表等图表，我个人觉得其重要性并没有想象的那么大，一般用户还是会按照功能清单方式来做项目的定义，我们的做法是定义功能点，做出清单出来。
顺序图在这些图例里面比较直观，用户能很快参与到讨论中，活动图和传统的流程图类似，也是一个补充，状态图在业务系统分析时往往会被忽视，对关键对象是一定要做状态分析的，经常会在做状态分析的时候发现业务上忽视的问题。
类图在设计阶段可以用
在设计阶段，除了类图、状态图外，其它的UML图都不是非常管用，我不怎么喜欢在设计阶段做大量的UML图例和文档。
我个人觉得UML的价值不在设计阶段，主要是在业务分析阶段，怎么能尽快的让客户和设计人员理解业务、进行沟通。
五、参考文献
〔1〕张龙详.UML与系统分析设计.人民邮电出版社，2001
〔2〕郑巧英.杨宗英信息管理自动化.上海交通大学出版社，1998
〔2〕陈英.UML多视点建模机制应用研究.北京理工大学学报.2001
升级会员 