UML教学日历管理系统Word下载.docx
《UML教学日历管理系统Word下载.docx》由会员分享，可在线阅读，更多相关《UML教学日历管理系统Word下载.docx（33页珍藏版）》请在冰点文库上搜索。
上课总周数：
12
周自第
3
周至第
14
周
教学总时数：
60
学时本期总学时数：
学时本期周学时：
5
学时
2009
/
2010
学年第
1
学期
讲课：
40
课堂讨论：
院（部）：
计算机与通信工程学院
任课教师：
龙鹏飞
实验/上机课：
20
校内现场教学：
课程：
C#程序设计
教学班号：
01
校外教学：
大作业：
周／星期
章／节
教学内容
教学要求
作业
布置
课内
教学
时数
课外
备注
21
3/1
2
23
3/3
C#数据类型：
包括值类型与引用类型、装箱与拆箱的概念与使用、类型指转换等
掌握值类型与引用类型、装箱与拆箱的概念、类型转换规则
25
3/5
上机
（1）
编写程序：
建立一个控制台应用程序、一个Windows应用程序
要求：
掌握开发工具提供的主要项目类型
28
4/1
成员、变量和常量：
讲解类型成员分类、访问控制等
掌握类成员分类，掌握类事件的定义和使用
30
4/3
4
操作符和表达式：
讲解操作符和表达式
掌握主要运算符及运算规则
10
5/1
流程控制：
重点讲解switch多分支控制语句，以讲解foreach语句基本原理
掌握所有控制结构
7
5/3
深入讲解类：
类的概念，类的成员，类访问修饰符，类事件
掌握构造函数、索引器、事件、this等的概念和用法
5/5
上机
（2）
建立一个类库项目和一个可执行项目，测试类库的调用
类库中包含两个名字空间，每个名字空间至少包含一个类；
执行项目中测试类库中的所有类及方法
6/1
7
继承与多态：
讲解继承、多态，讲解接口及实现
掌握继承与多态的概念与使用方法，掌握接口定义和实现方法
6/3
常用类型：
讲解Math、字符串类型
掌握主要类的主要方法，如Math、String、StringBuilder等
19
7/1
讲解窗体类和主要控件类，及Windows应用程序开发基础
掌握Windows应用程序开发方法和主要GUI类型
7/3
补充1
GDI+编程：
讲解GDI基本编程及相关类型，如Graphics,Pen,Brush,Color,Pens,Brushes,Font等
了解GDI+，掌握基本GDI编程方法
7/5
上机（3）
计算圆的面积和圆柱体的表面积与体积
将圆类定义为基类，圆柱体定义为圆类的派生类
26
8/1
泛型基础：
讲解泛型类型的定义、使用限制和泛型继承
掌握基本的泛型类型定义和使用方法
11
8/3
10、11
可空类型、泛型接口、泛型方法和泛型委托：
讲解可空类型量的定义和使用方法
掌握可空类型量的定义和使用方法，了解泛型接口、方法，掌握泛型委托
9/1
遍厉器：
讲解与foreach相关的集合类型定义
了解遍厉器依赖的集合定义方法
13
9/3
补充2
常用集合类型：
讲解常用集合类型
掌握常用集合类型的使用方法
9/5
上机（4）
封装向量为一个集合类
foreach可以作用于定义的类上，并支持成员的索引器访问
10/1
13、14
匿名方法，异常处理：
讲解匿名方法定义与使用，讲解C#异常处理方式
了解匿名方法的定义和使用，
掌握C#程序中的异常处理
15
10/3
文件IO操作：
讲解文件及相关概念与相关类
掌握主要的目录和文件类，掌握主要的字节流处理类。
16
11/1
17
18
11/3
补充3
ADO.NET：
讲解数据集相关概念、定义和使用方法
掌握程序操作数据库的方法
11/5
上机（5）
改造上机
（2）的向量类定义，使其支持新的格式化输出
在上机
（2）的向量类基础上重定义ToString（）以支持新的格式
12/1
12/3
进程和线程：
讲解C#中多线程编程
掌握基本的多线程程序编写方法
13/1
上机（6）
文件操作和绘图操作训练
掌握基本文件操作方法，掌握基本绘图操作方法
13/3
上机（7）
数据库操作训练
掌握以编码方式实现数据库数据访问
13/5
上机（8）
可视化数据库操作训练
掌握以设计器方式实现数据库数据访问，包括控件数据绑定
14/1
上机（9）
创建一个Web应用程序用来查询数据库中的数据
创建一个Web应用程序访问数据库，包括添加记录、删除记录和更新记录
14/3
上机（10）
创建一个Web服务，并在客户端测试
创建一个简单Web服务，在Web应用程序和Windows应用程序中测试
注：
1、教学内容与要求包括：
讲课、课堂讨论、习题课、现场教学、实验课、大作业、课程设计等。
2、本日历一式二份，经授课教师所在院（部）主管教学负责人审查同意后，一份交由授课教师留存，一份交授课教师所属院（部）存档。
3、教学日历执行情况由任课教师在完成教学任务后根据教学执行情况总结备查。
二、系统分析
系统分析阶段主要解决两个方面的问题：
系统功能需求和系统数据（数据字典或实体对象）。
1、系统功能需求-用例模型
即使初步的功能需求也需要两步：
从业务工人哪里获取；
从系统数据哪里获取。
从业务工人获取的功能需求是“粗”的，但这些需求可以界定问题域边界。
现实世界中的一切事物（对象）相互间都存在关联（有直接的、有间接的），不能将一切事物都拉入到系统，需要的只是哪些对解决问题有帮助的东西。
问题域边界可以限制我们应该将哪些事物（对象）引入到系统。
用户要求系统支持脱机和连机运行，系统需要本地数据库和网络数据库（本地数据库宜采用文件系统或MSAccess数据库）。
根据系统将运行的实际情况是：
任课教师常常采用脱机运行。
因此，有关任课教师的操作需要分别提供脱机和连机操作。
为了不使本教学案例过于复杂，只考虑连机运行。
（但对网络数据库的操作代码应适当兼顾脱机运行，以便后期实现连机代码较为容易）
业务角色：
问题域中的一个岗位，担任一定的任务。
任课教师是一个角色，担当本人教学日历录入、管理、导入、导出、生成WORD格式文档等；
教研室主任是一个角色，审核本教研室的教研室所授课程的教学日历等；
院部教学主管是一个角色，审核本院部所承担的课程的教学日历等；
院级管理员是一个角色，管理本院的课程教学日历、导入、导出等；
校级管理员是一个角色，管理全校教学日历、导入、导出等；
访客也是一个角色，可以查看系统任何非敏感信息，其对系统操作没有任何副作用。
用例：
表示用户的一个功能需求。
一个用例由代表功能的名称（如，取款）和实现功能的事件流（如，取款过程）描述组成。
根据用户需求和角色任务，初步分析出如下用例：
录入教学日历，审核教学日历，管理教学日历，导入教学日历，导出教学日历，生成教学日历WORD兼容格式文档，查询教学日历等。
功能需求可以用UML中的用例模型（即角色、用例和用例图的集合）表示。
系统用例模型如图1所示。
图1系统用例图
2、系统数据-数据模型
系统数据分析与数据字典、实体类相关。
实体类表现在数据库中就是表。
对于管理信息系统，可以从业务过程所使用的资料中找。
对于教学日历（业务）管理，所使用的就是资料附件1。
从附件1中可以分析出下列数据字典：
1）学校名称，学年学期，院部名称，任课教师，课程，教学班号，教研室主任，院部教学主管，填报时间，审查同意时间，教学总学时，（本期）上课总周数，（本期）开始周，（本期）结束周，本期总学时，本期周学时，（本期）讲课学时，（本期）实验学时，（本期）上机学时，课堂讨论学时，校内现场教学学时，校外教学学时，大作业学时，表底说明；
2）描述每次课：
上课月日，上课周星期，章节，教学内容，教学要求，作业布置，课内教学时数，课外时数，是否上机，备注。
第1步，分类
1）学校：
名称
2）院部：
3）学期：
首年，学期（1|2），表底说明（避免冗余，并允许每个学期有变化）
4）教师：
5）课程：
名称，教学总学时，讲课学时，实验学时，上机学时
6）教学班：
教学班号，（本期）上课总周数，（本期）开始周，（本期）结束周，本期总学时，本期周学时，（本期）讲课学时，（本期）实验学时，（本期）上机学时，课堂讨论学时，校内现场教学学时，校外教学学时，大作业学时
7）教学日历：
教研室主任，院部教学主管，填报时间，审查同意时间（，表底说明：
归入学期）
8）教学细节：
上课月日，上课周，星期，节次，章节，教学内容，教学要求，作业布置，课内教学时数，课外时数，是否上机，备注
第2步，补充
1）增加教研室：
增加“教研室”，目的是控制“教研室主任”角色职责范围。
2）增加校级用户：
名称，口令，角色（0-访客，1-管理员）
3）增加院部级用户：
名称，口令，角色（0-访客，1-管理员，2-教学日历审核员[院部教学主管]）
4）教师类中，添加：
口令，角色（0-普通教师，1-教学日历审核员[教研室主任]）
5）参考业务过程，我们通过设置教学日历状态，来控制过程。
因此在教学日历上添加：
状态（0-初始化状态，1-录入状态，2-教研室主任审核状态，3-院部教学主管审核状态，4-完成状态）
6）由于教学日历是教学班的附属，且是一对一关系，因此可以将教学日历中的属性合并到教学班。
7）课程中，在不同年级里可能有相同名称，而其它属性值可能不一样，因此添加：
年级
8）为了显示数据按需要的顺序，在院部，教研室，教师，校级用户，院部级用户，课程添加“编号”属性
第3步，综合并取英文名称
1）学校（university，永远只有一条记录，取单数形式）：
名称（name）
2）院部（depts）：
名称（name），编号（code）
3）教研室（staffrooms）：
4）教师（teachers）：
名称（name），编号（code），性别（sex），口令（pwd），角色（role）
5）校级用户（uni_users）：
名称（name），编号（code），口令（pwd），角色（role）
6）院部级用户（dept_users）：
7）学期（terms）：
首年（firstYear），学期（term），第一天日期（firstDayOfTerm），日历尾部说明（descOfDoc）
8）课程（courses）：
名称（name），编号（code），类别（optionType），学分（credit），教学总学时（totalHours），讲课学时（lectureHours），实验学时（expHours），上机（ComputerExpHours），考核方式（examType），备注（note），年级（grade）
9）教学班（teaches）：
教学班号（code），（本期）上课总周数（thisTotalWeeks），（本期）开始周（thisBeginWeek），（本期）结束周（thisEndWeek），本期总学时（thisTotalHours），本期周学时（thisWeekHours），（本期）讲课学时（thisLectureHours），（本期）实验学时（thisExpHours），（本期）上机学时（thisComputerExpHours），课堂讨论学时（discHours），校内现场教学学时（inHours），校外教学学时（outHours），大作业学时（bigWorkHours），教研室主任（director），院部教学主管（principal），填报时间（makeDate），审查同意时间（signDate），状态（state）
10）教学细节（details）：
上课月日（monthDay），上课周（week），星期（dayOfWeek），节次（classOfDay），章节（cs），教学内容（content），教学要求（requirement），作业布置（works），课内教学时数（inHours），课外时数（outHours），是否实践课（isExp），备注（note）
第4步，绘制实体类关系图（类属性已省略）
3、完善用例图
除了用户提出的业务功能需求外，维护各实体类（表）对象（记录）也是系统的重要工作，是系统向外公开服务，如uni_users，该实体类代表校级用户，对它的维护，意味着需要添加记录（新建用户）、删除记录（删除用户）、修改记录（修改用户密码）。
另外，要发挥分析人员创新性思维，提出一些必须向用户提供的辅助功能，如dept_users，该实体类代表院部级用户，对它的维护，除添加记录（新建用户）、删除记录（删除用户）、修改记录（修改用户密码）外，为了方便用户，为用户校级用户提供向所有院部一次性添加一个同名用户的功能。
这些都是用例。
（1）学校（university）
修改学校名称
（2）校级用户（uni_users）
新建校级用户，删除校级用户，修改校级用户密码
（3）院部（depts）
新建院部，删除院部，修改院部属性
（4）院级用户（dept_users）
新建院级用户，删除院级用户，修改院级用户密码，（在所有院部中）建立相同院级用户
（5）教研室（staffrooms）
新建教研室，删除教研室，修改教研室属性
（6）教师（teachers）
新建教师，删除教师，修改教师属性，修改教师密码，重置院部所有教师密码
（7）学期（terms）
新建学期，删除学期，修改日历尾部说明
（8）课程（courses）
新建课程，删除课程，修改课程属性，导入课程，导出课程
（9）教学班（teaches）
新建教学班，删除教学班，修改教学班属性，设置教学班上课时间并调整教学班教学细节，生成教学日历WORD兼容格式文档，导出教学日历，导入教学日历（或静态实现），改变教学日历状态（状态0到1，状态1到2，状态2到3或到2，状态3到4或2）
（10）教学细节（details）
细节属性中，可修改的属性统一称为内容。
修改细节内容，删除当前细节内容（相当于将后继细节内容上移），插入细节内容（相当于当前及后继细节内容后移），多细节内容复制，多细节内容粘贴
4、其它
本案例中，教学日历有几种状态，其状态图如下。
三、系统设计
1、数据库设计
数据库设计依赖系统分析中数据模型。
数据库设计时，需要在两个关联表中建立主键、外键约束。
主键由具有实际意义的一个或多个字段组成，主键值是唯一的。
多数情况下，一个记录建立后是不再修改的字段。
不具有实际意义的主键字段可取两种类型的一种，一种叫做自动编号，一种叫全局统一标识符（GUID）。
自动编号是整型数，占用空间少，插入记录时由数据库管理系统自动填写；
GUID是一个全球范围内唯一数据，用16个字节表示，有些数据库可以自动产生（如Access），有些数据库能通过默认值函数提供（MsSqlServer）。
实际使用中在实现导入/导出操作时GUID比自动编号方便。
根据系统分析中实体类的定义，数据库表定义如下：
（1）学校
其中，idu是主键。
（2）校级用户
其中，idua是主键，idu是外键（引用university中主键idu）
（3）院部
其中，idd是主键，idu是外键（引用university中主键idu）
（4）院级用户
其中，idda是主键，idd是外键（引用depts中主键idd）
（5）教研室
其中，idsr是主键，idd是外键（引用depts中主键idd）
（6）教师
其中，idt是主键，idsr是外键（引用staffrooms中主键idsr）
（7）学期
其中，idterm是主键，firstyear+term是唯一键。
（8）课程
其中，idc是主键，grade+name唯一。
（9）教学班
其中，idtc是主键，idc是外键（引用courses中主键idc），idt是外键（引用teachers中主键idt），idterm是外键（引用terms中主键idterm）
（10）教学班细节
其中，iddt是主键，idtc是外键（引用teaches中主键idtc）
（11）表关系图
2、界面设计
界面实现系统的人机交互，通过界面用户控制系统工作并向系统提供数据，通过界面系统向用户展示数据。
描述系统界面的类，叫做边界类。
边界类中有些还是控制类？
系统界面一般是基于GUI，用窗体表示。
边界类一般用来实现系统用例，一个用例由一个或多个边界类实现，也可能，多个用例集中在一个边界类中实现。
这取决于领域人员的习惯和设计人员的经验，但原则是方便用户。
任何系统都有一个主界面，若是桌面应用程序，这样的主界面，就是程序的主窗体。
主窗体有基于对话框的，有基于单文档的，还有基于多文档的。
多文档形式在实际应用中要多一些，当然由开发的系统本身决定的。
多文档界面又表现出两种形式，一是选项卡式多文档（类似资源管理器），一是子窗体式多文档。
选项卡式多文档主窗体中，分成了几个部分，如顶部的主菜单、工具条、底部的状态条，中部区域又分成左右两个部分：
左窗格和右窗格。
在左窗格中一般放置一个树控件，展示系统对象和控制文档产生等；
而在右窗格就是一个选项卡控件，表示文档视图。
子窗体式多文档主窗体中，分成了几个部分，如顶部的主菜单、工具条、底部的状态条，中部区域为子窗体区域。
可以通过主菜单项或工具条按钮来产生和管理子窗体，也可以定义一个带树控件的子窗体来展示系统对象和产生子窗体。
对于后一种，为了突出带树控件的子窗体而在子窗体管理上代码控制复杂些。
系统主窗体中是否需要树控件这样一种形式来展示和产生文档，完全依赖于系统静态结构：
系统文档（模型）种类的多少及它们之间的关系。
什么是文档？
文档表示系统数据，是系统模型。
文档（Document）和模型（Model）具有相同的含义。
一个实体类可以作为系统的一个模型，或一种类型的文档。
因此，实体类之间的关系可以反映到文档类之间的关系。
实体类与文档类有了这种关系，所有对实体类对象的管理可以反映到文档类对象的管理。
在关系图中，列出按一对多到一对多形成的所有路径，从中选择包含的实体类个数最大者（或叫最长路径），如果系统中最长路径上的实体类超过了3个，就应该首选树控件来管理实体类（即文档类）对象，并且管理功能布局在树节点弹出菜单上。
为什么说超过3个？
如果用户想管理位于级别3位置上的对象，首先需要知道级别1位置上对象，然后需要知道级别2位置上的对象，最后选择要管理的对象，即对这样一个对象执行管理需要3个先决条件。
如果用户想管理位于级别4位置上的对象，需要4个先决条件。
级别数越大，先决条件越多，条件只能一级一级设置，这些条件实际上是描述对象之间的关系。
无论将这些条件安排在功能执行前还是执行中由用户选择都是难以承受。
用树控件布局对象可以改变这种状况。
人眼可以同时看到一个点，或一条线、一个面、一个体，一眼望去可以看到许多东西，可以收集到许多信息，分析出它们之间的关系。
树节点可以展开，占用区域不断增大，显示内容不断增多。
树控件节点的这种布局形式特点，很适合人直观，一眼望去，对象关系尽知。
选择树控件来管理文档类对象，我们可以这样使用MVC设计模式。
M是模型，对应这里的文档，即实体类；
V是视图，对应的文档视图，当然可以是新建实体类对象的窗体，可以是修改实体类对象属性的窗体，可以是查看实体类对象的窗体等；
C是控制，控制多个对象协同工作完成特定任务，树控件当然是控制，更细些，树节点也是控制。
回到我们的项目来，从系统实体类图（或表关系图）可以列出下列路径：
①university->
uni_users
②university->
depts->
dept_users
③university->
staffrooms->
teachers->
teaches->
details
④courses->
⑤terms->
显然③是最长路径，包含实体类个数为6。
本系统适合使用树控件，控件节点代表各种实体类（文档，模型）对象相应的控制类对象。
不同实体类对象作用其上的操作也不一样，控件节点的类型应该与对应的实体类一样有所区别，因此，我们为最长路径上的每个实体类定义一个控制类。
如果需要
升级会员 