UML教学日历管理系统

1、教学日历管理系统一、信息收集1、定义教学日历定义：所谓教学日历，是一个教学班的教学活动安排。2、需求用户功能需求：需要一个教学日历电子化管理程序。老师可以用它来录入日历，管理本人的教学日历；校、院级相关管理人员可以集中管理教学日历；提供教学日历WORD文档生成与查询功能。性能要求：支持网络连接运行与脱机运行。安全性要求：教学日历录入与修改仅限任课教师，若电子文档审核后不得再修改。教学日历审核分教研室级和院级。一个教学日历的管理权限限于任课教师可以管理他的任课，院部管理人员可以管理其下所有教师的任课，校级管理人员可以管理全校所有课程。3、业务过程1）由学校统一提供课程开设情况2）任课教师录入或修

2、改教学日历3）报请教研室主任审核，审核不通过转2）4）上缴院教务办并报请院主管教学负责人审核，审核不通过转2）5）院内存档6）上缴学校教务处7）校内存档4、业务资料收集用户可提供的原始资料和结果资料：现用教学日历，见附件1。附件1 教学日历长沙理工大学教学日历教研室主任：院部教学主管：(签字或盖章)填报时间： 2009年9月6日 审查同意时间：2009年9月8日上课总周数：12周 自第3周至第14周教学总时数：60学时 本期总学时数：60学时 本期周学时：5学时2009 /2010学年第1学期讲 课： 40学时课 堂 讨 论： 学时院(部)：计算机与通信工程学院任课教师：龙鹏飞实验/上机课：2

3、0学时校内现场教学： 学时课程：C#程序设计教学班号：01校 外 教 学： 学时大 作 业： 学时 月日周星期章节教学内容教学要求作业布置课内教学时数课外时数备 注9213/112219233/32C#数据类型：包括值类型与引用类型、装箱与拆箱的概念与使用、类型指转换等掌握值类型与引用类型、装箱与拆箱的概念、类型转换规则2229253/5上机（1）编写程序：建立一个控制台应用程序、一个Windows应用程序要求：掌握开发工具提供的主要项目类型29284/13成员、变量和常量：讲解类型成员分类、访问控制等掌握类成员分类，掌握类事件的定义和使用2239304/34操作符和表达式：讲解操作符和表达式

4、掌握主要运算符及运算规则2241055/15流程控制：重点讲解switch多分支控制语句，以讲解foreach语句基本原理掌握所有控制结构22510 75/36深入讲解类：类的概念，类的成员，类访问修饰符，类事件掌握构造函数、索引器、事件、this等的概念和用法2261095/5上机（2）建立一个类库项目和一个可执行项目，测试类库的调用要求：类库中包含两个名字空间，每个名字空间至少包含一个类；执行项目中测试类库中的所有类及方法210126/17继承与多态：讲解继承、多态，讲解接口及实现掌握继承与多态的概念与使用方法，掌握接口定义和实现方法22710146/38常用类型：讲解Math、字符串类型

5、掌握主要类的主要方法，如Math、String、StringBuilder等2810197/18常用类型：讲解窗体类和主要控件类，及 Windows应用程序开发基础掌握Windows应用程序开发方法和主要GUI类型22910217/3补充1GDI+编程：讲解GDI基本编程及相关类型，如Graphics, Pen, Brush, Color, Pens , Brushes, Font等了解GDI+，掌握基本GDI编程方法221010237/5上机（3）编写程序：计算圆的面积和圆柱体的表面积与体积要求：将圆类定义为基类，圆柱体定义为圆类的派生类210268/19泛型基础：讲解泛型类型的定义、使用限

6、制和泛型继承掌握基本的泛型类型定义和使用方法221110288/310、11可空类型、泛型接口、泛型方法和泛型委托：讲解可空类型量的定义和使用方法掌握可空类型量的定义和使用方法，了解泛型接口、方法，掌握泛型委托22121129/112遍厉器：讲解与foreach相关的集合类型定义了解遍厉器依赖的集合定义方法22131149/3补充2常用集合类型：讲解常用集合类型掌握常用集合类型的使用方法22141169/5上机（4）编写程序：封装向量为一个集合类要求：foreach可以作用于定义的类上，并支持成员的索引器访问211910/113、14匿名方法，异常处理：讲解匿名方法定义与使用，讲解C#异常处理

7、方式了解匿名方法的定义和使用，掌握C#程序中的异常处理2215111110/315文件IO操作：讲解文件及相关概念与相关类掌握主要的目录和文件类，掌握主要的字节流处理类。2216111611/115文件IO操作：讲解文件及相关概念与相关类掌握主要的目录和文件类，掌握主要的字节流处理类。2217111811/3补充3ADO.NET：讲解数据集相关概念、定义和使用方法掌握程序操作数据库的方法2218112011/5上机（5）改造上机（2）的向量类定义，使其支持新的格式化输出要求：在上机（2）的向量类基础上重定义ToString()以支持新的格式2112312/1补充3ADO.NET：讲解数据集相关

8、概念、定义和使用方法掌握程序操作数据库的方法2219112512/316进程和线程：讲解C#中多线程编程掌握基本的多线程程序编写方法2220113013/1上机（6）文件操作和绘图操作训练要求：掌握基本文件操作方法，掌握基本绘图操作方法212213/3上机（7）数据库操作训练要求：掌握以编码方式实现数据库数据访问212413/5上机（8）可视化数据库操作训练要求：掌握以设计器方式实现数据库数据访问，包括控件数据绑定212714/1上机（9）创建一个Web应用程序用来查询数据库中的数据要求：创建一个Web应用程序访问数据库，包括添加记录、删除记录和更新记录212914/3上机（10）创建一个We

9、b服务，并在客户端测试要求：创建一个简单Web服务，在Web应用程序和Windows应用程序中测试2注：1、教学内容与要求包括：讲课、课堂讨论、习题课、现场教学、实验课、大作业、课程设计等。2、本日历一式二份，经授课教师所在院(部)主管教学负责人审查同意后，一份交由授课教师留存，一份交授课教师所属院（部）存档。3、教学日历执行情况由任课教师在完成教学任务后根据教学执行情况总结备查。二、系统分析系统分析阶段主要解决两个方面的问题：系统功能需求和系统数据（数据字典或实体对象）。1、系统功能需求-用例模型即使初步的功能需求也需要两步：从业务工人哪里获取；从系统数据哪里获取。从业务工人获取的功能需求是

10、“粗”的，但这些需求可以界定问题域边界。现实世界中的一切事物（对象）相互间都存在关联（有直接的、有间接的），不能将一切事物都拉入到系统，需要的只是哪些对解决问题有帮助的东西。问题域边界可以限制我们应该将哪些事物（对象）引入到系统。用户要求系统支持脱机和连机运行，系统需要本地数据库和网络数据库（本地数据库宜采用文件系统或MS Access数据库）。根据系统将运行的实际情况是：任课教师常常采用脱机运行。因此，有关任课教师的操作需要分别提供脱机和连机操作。为了不使本教学案例过于复杂，只考虑连机运行。（但对网络数据库的操作代码应适当兼顾脱机运行，以便后期实现连机代码较为容易）业务角色：问题域中的一个岗

11、位，担任一定的任务。任课教师是一个角色，担当本人教学日历录入、管理、导入、导出、生成WORD格式文档等；教研室主任是一个角色，审核本教研室的教研室所授课程的教学日历等；院部教学主管是一个角色，审核本院部所承担的课程的教学日历等；院级管理员是一个角色，管理本院的课程教学日历、导入、导出等；校级管理员是一个角色，管理全校教学日历、导入、导出等；访客也是一个角色，可以查看系统任何非敏感信息，其对系统操作没有任何副作用。用例：表示用户的一个功能需求。一个用例由代表功能的名称（如，取款）和实现功能的事件流（如，取款过程）描述组成。根据用户需求和角色任务，初步分析出如下用例：录入教学日历，审核教学日历，管

12、理教学日历，导入教学日历，导出教学日历，生成教学日历WORD兼容格式文档，查询教学日历等。功能需求可以用UML中的用例模型（即角色、用例和用例图的集合）表示。系统用例模型如图1所示。图1 系统用例图2、系统数据-数据模型系统数据分析与数据字典、实体类相关。实体类表现在数据库中就是表。对于管理信息系统，可以从业务过程所使用的资料中找。对于教学日历（业务）管理，所使用的就是资料附件1。从附件1中可以分析出下列数据字典：1）学校名称，学年学期，院部名称，任课教师，课程，教学班号，教研室主任，院部教学主管，填报时间，审查同意时间，教学总学时，（本期）上课总周数，（本期）开始周，（本期）结束周，本期总学

13、时，本期周学时，（本期）讲课学时，（本期）实验学时，（本期）上机学时，课堂讨论学时，校内现场教学学时，校外教学学时，大作业学时，表底说明；2）描述每次课：上课月日，上课周星期，章节，教学内容，教学要求，作业布置，课内教学时数，课外时数，是否上机，备注。第1步，分类1） 学校：名称2） 院部：名称3） 学期：首年，学期（1|2），表底说明（避免冗余，并允许每个学期有变化）4） 教师：名称5） 课程：名称，教学总学时，讲课学时，实验学时，上机学时6） 教学班：教学班号，（本期）上课总周数，（本期）开始周，（本期）结束周，本期总学时，本期周学时，（本期）讲课学时，（本期）实验学时，（本期）上机学时，

14、课堂讨论学时，校内现场教学学时，校外教学学时，大作业学时7） 教学日历：教研室主任，院部教学主管，填报时间，审查同意时间（，表底说明：归入学期）8） 教学细节：上课月日，上课周，星期，节次，章节，教学内容，教学要求，作业布置，课内教学时数，课外时数，是否上机，备注第2步，补充1） 增加教研室：名称增加“教研室”，目的是控制“教研室主任”角色职责范围。2） 增加校级用户：名称，口令，角色（0-访客，1-管理员）3） 增加院部级用户：名称，口令，角色（0-访客，1-管理员，2-教学日历审核员院部教学主管）4） 教师类中，添加：口令，角色（0-普通教师，1-教学日历审核员教研室主任）5） 参考业务过

15、程，我们通过设置教学日历状态，来控制过程。因此在教学日历上添加：状态（0-初始化状态，1-录入状态，2-教研室主任审核状态，3-院部教学主管审核状态，4-完成状态）6）由于教学日历是教学班的附属，且是一对一关系，因此可以将教学日历中的属性合并到教学班。7）课程中，在不同年级里可能有相同名称，而其它属性值可能不一样，因此添加：年级8）为了显示数据按需要的顺序，在院部，教研室，教师，校级用户，院部级用户，课程添加“编号”属性第3步，综合并取英文名称1） 学校（university，永远只有一条记录，取单数形式）：名称（name）2） 院部（depts）：名称（name），编号（code）3） 教研

16、室（staffrooms）：名称（name），编号（code）4） 教师（teachers）：名称（name），编号（code），性别（sex），口令（pwd），角色（role）5） 校级用户（uni_users）：名称（name），编号（code），口令（pwd），角色（role）6） 院部级用户（dept_users）：名称（name），编号（code），口令（pwd），角色（role）7） 学期（terms）：首年（firstYear），学期（term），第一天日期（firstDayOfTerm），日历尾部说明（descOfDoc）8） 课程（courses）：名称（name），编号（c

17、ode），类别（optionType），学分（credit），教学总学时（totalHours），讲课学时（lectureHours），实验学时（expHours），上机（ComputerExpHours），考核方式（examType），备注（note），年级（grade）9） 教学班（teaches）：教学班号（code），（本期）上课总周数（thisTotalWeeks），（本期）开始周（thisBeginWeek），（本期）结束周（thisEndWeek），本期总学时（thisTotalHours），本期周学时（thisWeekHours），（本期）讲课学时（thisLectureHou

18、rs），（本期）实验学时（thisExpHours），（本期）上机学时（thisComputerExpHours），课堂讨论学时（discHours），校内现场教学学时（inHours），校外教学学时（outHours），大作业学时（bigWorkHours），教研室主任（director），院部教学主管（principal），填报时间（makeDate），审查同意时间（signDate），状态（state）10） 教学细节（details）：上课月日（monthDay），上课周（week），星期（dayOfWeek），节次（classOfDay），章节（cs），教学内容（content），教

19、学要求（requirement），作业布置（works），课内教学时数（inHours），课外时数（outHours），是否实践课（isExp），备注（note）第4步，绘制实体类关系图（类属性已省略）3、完善用例图除了用户提出的业务功能需求外，维护各实体类（表）对象（记录）也是系统的重要工作，是系统向外公开服务，如uni_users，该实体类代表校级用户，对它的维护，意味着需要添加记录（新建用户）、删除记录（删除用户）、修改记录（修改用户密码）。另外，要发挥分析人员创新性思维，提出一些必须向用户提供的辅助功能，如dept_users，该实体类代表院部级用户，对它的维护，除添加记录（新建用户）

20、、删除记录（删除用户）、修改记录（修改用户密码）外，为了方便用户，为用户校级用户提供向所有院部一次性添加一个同名用户的功能。这些都是用例。（1）学校（university）修改学校名称（2）校级用户（uni_users）新建校级用户，删除校级用户，修改校级用户密码（3）院部（depts）新建院部，删除院部，修改院部属性（4）院级用户（dept_users）新建院级用户，删除院级用户，修改院级用户密码，（在所有院部中）建立相同院级用户（5）教研室（staffrooms）新建教研室，删除教研室，修改教研室属性（6）教师（teachers）新建教师，删除教师，修改教师属性，修改教师密码，重置院部所有

21、教师密码（7）学期（terms）新建学期，删除学期，修改日历尾部说明（8）课程（courses）新建课程，删除课程，修改课程属性，导入课程，导出课程（9）教学班（teaches）新建教学班，删除教学班，修改教学班属性，设置教学班上课时间并调整教学班教学细节，生成教学日历WORD兼容格式文档，导出教学日历，导入教学日历（或静态实现），改变教学日历状态（状态0到1，状态1到2，状态2到3或到2，状态3到4或2）（10）教学细节（details）细节属性中，可修改的属性统一称为内容。修改细节内容，删除当前细节内容（相当于将后继细节内容上移），插入细节内容（相当于当前及后继细节内容后移），多细节内容复

22、制，多细节内容粘贴4、其它本案例中，教学日历有几种状态，其状态图如下。三、系统设计1、数据库设计数据库设计依赖系统分析中数据模型。数据库设计时，需要在两个关联表中建立主键、外键约束。主键由具有实际意义的一个或多个字段组成，主键值是唯一的。多数情况下，一个记录建立后是不再修改的字段。不具有实际意义的主键字段可取两种类型的一种，一种叫做自动编号，一种叫全局统一标识符（GUID）。自动编号是整型数，占用空间少，插入记录时由数据库管理系统自动填写；GUID是一个全球范围内唯一数据，用16个字节表示，有些数据库可以自动产生（如Access），有些数据库能通过默认值函数提供（Ms Sql Server）。

23、实际使用中在实现导入/导出操作时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+t

24、erm是唯一键。（8）课程其中，idc是主键，grade+name唯一。（9）教学班其中，idtc是主键，idc是外键（引用courses中主键idc），idt是外键（引用teachers中主键idt），idterm是外键（引用terms中主键idterm）（10）教学班细节其中，iddt是主键，idtc是外键（引用teaches中主键idtc）（11）表关系图2、界面设计界面实现系统的人机交互，通过界面用户控制系统工作并向系统提供数据，通过界面系统向用户展示数据。描述系统界面的类，叫做边界类。边界类中有些还是控制类？系统界面一般是基于GUI，用窗体表示。边界类一般用来实现系统用例，一个用例由

25、一个或多个边界类实现，也可能，多个用例集中在一个边界类中实现。这取决于领域人员的习惯和设计人员的经验，但原则是方便用户。任何系统都有一个主界面，若是桌面应用程序，这样的主界面，就是程序的主窗体。主窗体有基于对话框的，有基于单文档的，还有基于多文档的。多文档形式在实际应用中要多一些，当然由开发的系统本身决定的。多文档界面又表现出两种形式，一是选项卡式多文档（类似资源管理器），一是子窗体式多文档。选项卡式多文档主窗体中，分成了几个部分，如顶部的主菜单、工具条、底部的状态条，中部区域又分成左右两个部分：左窗格和右窗格。在左窗格中一般放置一个树控件，展示系统对象和控制文档产生等；而在右窗格就是一个选项

26、卡控件，表示文档视图。子窗体式多文档主窗体中，分成了几个部分，如顶部的主菜单、工具条、底部的状态条，中部区域为子窗体区域。可以通过主菜单项或工具条按钮来产生和管理子窗体，也可以定义一个带树控件的子窗体来展示系统对象和产生子窗体。对于后一种，为了突出带树控件的子窗体而在子窗体管理上代码控制复杂些。系统主窗体中是否需要树控件这样一种形式来展示和产生文档，完全依赖于系统静态结构：系统文档（模型）种类的多少及它们之间的关系。什么是文档？文档表示系统数据，是系统模型。文档（Document）和模型（Model）具有相同的含义。一个实体类可以作为系统的一个模型，或一种类型的文档。因此，实体类之间的关系可以

27、反映到文档类之间的关系。实体类与文档类有了这种关系，所有对实体类对象的管理可以反映到文档类对象的管理。在关系图中，列出按一对多到一对多形成的所有路径，从中选择包含的实体类个数最大者（或叫最长路径），如果系统中最长路径上的实体类超过了3个，就应该首选树控件来管理实体类（即文档类）对象，并且管理功能布局在树节点弹出菜单上。为什么说超过3个？如果用户想管理位于级别3位置上的对象，首先需要知道级别1位置上对象，然后需要知道级别2位置上的对象，最后选择要管理的对象，即对这样一个对象执行管理需要3个先决条件。如果用户想管理位于级别4位置上的对象，需要4个先决条件。级别数越大，先决条件越多，条件只能一级一级

28、设置，这些条件实际上是描述对象之间的关系。无论将这些条件安排在功能执行前还是执行中由用户选择都是难以承受。用树控件布局对象可以改变这种状况。人眼可以同时看到一个点，或一条线、一个面、一个体，一眼望去可以看到许多东西，可以收集到许多信息，分析出它们之间的关系。树节点可以展开，占用区域不断增大，显示内容不断增多。树控件节点的这种布局形式特点，很适合人直观，一眼望去，对象关系尽知。选择树控件来管理文档类对象，我们可以这样使用MVC设计模式。M是模型，对应这里的文档，即实体类；V是视图，对应的文档视图，当然可以是新建实体类对象的窗体，可以是修改实体类对象属性的窗体，可以是查看实体类对象的窗体等；C是控制，控制多个对象协同工作完成特定任务，树控件当然是控制，更细些，树节