学籍管理系统报告

学籍管理系统报告

题目：

指导教师：

学生姓名：

学号：

学院：

专业班级：

摘要

本文介绍了面向对象与构件的技术的发展，并用该技术设计一个学籍管理系统。该系统用标准建模语言来描述，描述了系统的用例图，时序图，以及类图。

学籍管理系统是典型的信息管理系统。其开发主要包括后台数据库的操作以及前端应用程序的开发两个方面。对于前者要求建立起数据完整性强、数据安全性好的数据库库。而对于后者则要求应用程序功能完备,易使用等特点。

关键字：构件, 标准建模语言，学籍，

ABSTRACT

The report describes Object-Oriented and Component technology, and uses this technology to design a Study Management System. It is depicted by Unified Modeling Language. Including User Case Diagram, Timing Diagram and Class Diagram are described in the report.

Study Management System is a typical information management system. Its development includes two main aspects: back-end database manipulation and front-end application. The needs of database are strong integrity and perfect security. The needs of application are full function and easy operation.

KEY WORDS: component, unified modeling language, study,

目录

1面向对象与构件技术.................................................................................................................. I V

1.1概述 (1)

1.2构件的基本特征 (1)

1.3构件的实现 (1)

1.4构件技术与构件化 (2)

2标准建模语言UML的出现 (3)

3系统设计 (4)

3.1系统设计用例图 (4)

3.2Student注册时序图 (5)

3.3 Administrator登分时序图 (6)

3.4制定修课计划时序图 (6)

4 系统类图 (8)

4.1系统类图说明 (9)

4.2类说明 (9)

总结 (11)

参考文献 (12)

感谢 ................................................................................................................ 错误！未定义书签。

1面向对象与构件技术

1.1概述

构件是软件开发、复用和软件组装的实体单元，包括以下要素：构件类型(componenttype)、构件实现(componentimplement)、提供接口(provides-interfaces)和依赖接口(requires-interface)。

1.构件类型(componenttype)：构件类型表明构件是处理什么问题和提供哪些接口功

能，它包含了构件类型的名称。

2.构件实现(componentimplement)：对构件类型的具体实现称为构件实现，一个构件

类型可能有多个构件实现。

3.提供接口(provides-interfaces)：提供接口指构件提供给外部程序使用的接口。

4.依赖接口(requires-interface)：依赖接口指构件运行时所必须依赖的外部程序接口。

（参考文献[6]）

1.2构件的基本特征

1.复用：复用是构件最基本的性质，构件的设计必须满足未来能在新的应用、项目

中使用。

2.封装：构件封装对外界隐藏构件的设计和实现细节，仅通过接口与外界交互。这

可以保证构件功能复用的完整性和构件开发及交付的独立性。

3.组装：构件可以通过组装形成新的构件或系统，组装是构件复用的手段，同时具

备可插拔，便于替换，系统可以由不同的开发商开发的构件组装而成。

4.粒度：构件是有大小的，越是跟领域相关的构件粒度越大，小粒度的构件可以方

便的组装成较大粒度的构件。

5.层次：构件可以按层次进行划分，企业级应系统的复杂逻辑可以通过层次来解决，

不同的层次需要不同层次的构件。按照MVC的体系架构，可以把构件划分为：

展现层、控制层、业务层、运算层及数据层等。（参考文献[1]）

1.3构件的实现

目前软件市面上有三个代表性的构件技术标准分别是：COM/DCOM、CORBA和EJB。

https://www.360docs.net/doc/a712736565.html,/DCOM：COM(Conponent Object Model)是由Microsoft公司推出的构件接口

标准，DCOM是指可以分布式布的COM。

2.CORBA：CORBA(Common Object Request Broker Architecture)是由对象管理组织

(OMG)提出的构件技术标准。

3.EJB：EJB是由SUN公司提出的构件技术标准。

以上三种构件标准实现的构件互相依赖的方式仍然是基于对象接口式的，当系统复杂度到一定规模时，整个系统会因依赖关系混乱而陷入失控。

比较理想的构件模型是构件之间是数据耦合的，每个构件只单独与数据总线发生

联系。当需求发生变化时，可以对各个单独的构件进行添加、减少或者修改而不影响整体的架构和性能。基于数据耦合的构件，据有很高的独立性，对需求变化有较强的适应能力。

1.4构件技术与构件化

构件技术与构件化的区别在于，构件化的关注点不在于构件本身的技术实现，而在于如何把应用系统分解成稳定、灵活、可重用的构件，在于如何利用已有的构件库组装出随需应变的应用软件，从一个面向构件的环境中去分析应用，如何做出灵活、重用的构件来思考。但是，构件技术是构件化的基础，它为构件的工厂化生产提供技术保障。

传统的软件方法学是从面向机器、面向数据、面向过程、面向功能、面向数据流等反映问题的本质;而构件技术关注的是在构件已经可用的情况下，在更高层次上的组装和复用。面向构件的软件设计方法把装配和制造分离，构件运行时负责提供标准接口和框架，负责软件装配，而构件负责软件的制造，使软件开发变成构件的组装。

2标准建模语言UML的出现

公认的面向对象建模语言出现于70年代中期。从1989年到1994年，其数量从不到十种增加到了五十多种。在众多的建模语言中，语言的创造者努力推崇自己的产品，并在实践中不断完善。但是，OO方法的用户并不了解不同建模语言的优缺点及相互之间的差异，因而很难根据应用特点选择合适的建模语言，于是爆发了一场“方法大战”。90年代中，一批新方法出现了，其中最引人注目的是Booch 1993、OOSE和OMT-2等。

Booch是面向对象方法最早的倡导者之一，他提出了面向对象软件工程的概念。1991年，他将以前面向Ada的工作扩展到整个面向对象设计领域。Booch 1993比较适合于系统的设计和构造。（参考文献[2]）

Rumbaugh等人提出了面向对象的建模技术（OMT）方法，采用了面向对象的概念，并引入各种独立于语言的表示符。这种方法用对象模型、动态模型、功能模型和用例模型，共同完成对整个系统的建模，所定义的概念和符号可用于软件开发的分析、设计和实现的全过程，软件开发人员不必在开发过程的不同阶段进行概念和符号的转换。OMT-2特别适用于分析和描述以数据为中心的信息系统。

Jacobson于1994年提出了OOSE方法，其最大特点是面向用例(Use-Case)，并在用例的描述中引入了外部角色的概念。用例的概念是精确描述需求的重要武器，但用例贯穿于整个开发过程，包括对系统的测试和验证。OOSE比较适合支持商业工程和需求分析。

此外，还有Coad/Yourdon方法，即著名的OOA/OOD，它是最早的面向对象的分析和设计方法之一。该方法简单、易学，适合于面向对象技术的初学者使用，但由于该方法在处理能力方面的局限，目前已很少使用。（参考文献[3]）

概括起来，首先，面对众多的建模语言，用户由于没有能力区别不同语言之间的差别，因此很难找到一种比较适合其应用特点的语言；其次，众多的建模语言实际上各有千秋；第三，虽然不同的建模语言大多雷同，但仍存在某些细微的差别，极大地妨碍了用户之间的交流。因此在客观上，极有必要在精心比较不同的建模语言优缺点及总结面向对象技术应用实践的基础上，组织联合设计小组，根据应用需求，取其精华，去其糟粕，求同存异，统一建模语言。

3系统设计

3.1系统设计用例图

用例图(Use Case Diagram)是UML建模的一部分，它也是UML里最基础的部分。

用例图的最主要功能就是用来表达系统的功能需求或行为。用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。用例图是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。

Enroll

图片 1

系统用例图（图片1），描述了学籍管理系统（SYS）的用户，如果登录，并使用这个系统。其中包括：

1.参与者User，该参与者为用户登录前状态。

2.参与者Student，该参与者是学生用户，Student可以注册（Enroll），制定选课计

划（Make Class Plan），选课（Choose Class），查询成绩（Select Grade）。

3.参与者Adminstrator，该参与者是系统管理员，拥有系统的最高权限。主要包括

检测选课计划的冲突（Check Class Collision），输入学分（Input Grade）。

4.用例Login，User登录的用例。

5.用例注册Enroll，Student注册为学籍管理系统一员。

6.用例Make Class Plan，Student制定修课计划。

7.用例Choose Class，Student选课，根据修课计划里的内容选课。

8.用例Select Grade，Student查询修课的成绩，根据已选课程查看修课成绩。

9.用例Input Grade，Adminstrator输入学生的成绩，根据班级编号和学号来输入。

10.用例Check Class Collision，Adminstrator确认学生修课计划有无错误。（参考文献

[4]）

3.2Student注册时序图

图片 2

Student注册时序图（图片2），描述了Student如何完成注册的功能，包括：

1.Student在User Interface中输入学号。

https://www.360docs.net/doc/a712736565.html,er Interface向数据库后台查询学号的正确性，并发回结果。

https://www.360docs.net/doc/a712736565.html,er Interface显示发回的结果，如果结果正确，则让Student继续操作，如果学

号不正确则需要Student重新输入。

4.Student在User Interface填写注册信息，并检查。

https://www.360docs.net/doc/a712736565.html,er Interface将Student填写的信息发到后台保存。

6.Database System将结果发回，并自User Interface显示结果。

7.Student完成注册。

3.3 Administrator登分时序图

图片 3

Administrator管理时序图，描述了Administrator如何给学生登记分数，包括：

1.Adminstrator选择班级号，并发给Database System。

2.Database System将学生信息显示在界面上。

3.Adminstrator选择学生的信息，并输入成绩。

4.Adminstrator Interface输入合法性，并将数据存入Database System。

5.Database System发回结果并显示。

3.4制定修课计划时序图

图片 4

制定修课计划时序图（图片4），描述了Student如何制定修课计划，包括：

1.Student 制定修课计划，并发给Database System。

2.Database System用检测系统Check Point来检查修课计划是否合法。

3.Database System将班级列表Class List发送给Student。

4.Student选择课程。

5.系统检测Class List是否合法，保存Class List Plan。

6.Database System显示制定结果

4 系统类图

图片 5

4.1系统类图说明

系统类图（图片5），描述了系统中各个类与其他不同的类的关联，其中包括：

1.CStudent学生类。

2.CTeacher教师类。

https://www.360docs.net/doc/a712736565.html,lass课程类。

4.CDepartment学院类。

https://www.360docs.net/doc/a712736565.html,lassPlan课程计划类。

6.CUserInterface用户接口类。

7.CAdministrator管理员类。

8.CAdministrator管理员接口类。

9.CDatabase数据库类。（参考文献[5]）

4.2类说明

1)CStudent类

CStudent学生类，包括了学生的各类信息：

1.StudentNumber学号。

2.StudentName学生姓名。

3.CDepartment学院信息。

https://www.360docs.net/doc/a712736565.html,lassPlan学生制定的修课计划。

CStudent学生类可以完成：

1.Enroll注册。

2.SelectClassGrade查询课程成绩。

3.MakeClassPlan制定修课计划。

2)CTeacher类

CTeacher教师类，包括了教师的信息。

3)CClass类

CClass课程类，包含了各门课程的信息。

4)CDepartment类

CDepartment学院类，是这个系统的核心之一，因为该系统是用学院类来规范

管理CTeacher和CStudent的信息，包括：

1.StudentList学生列表。

2.TeacherLIst老师列表。

3.ClassList课程列表。

4.ClassPlanCheckPoint学院选课约束条件。

5)CClassPlan类

CClassPlan类是用于存放学生制定的学习计划，包括：

1.ClassList课程列表。

2.GradeList成绩列表。

3.StudentNumber学号。

4.ClassPlanCheckPointNumber修课计划约束。

6)CUserInterface类

CUserInterface类主要用来实现学生操作的界面，并保存学生的信息。

7)CAdministrator类

CAdministrator管理者类，包括管理者的信息，以及管理者可以实行的操作，

包括：

1.AdmNumber 管理者编号。

2.AdmName 管理者名称。

8)CAdmInterface类

CAdmInterface管理者接口类，用于实现管理者可以完成的操作，已经管理者

的信息，包括：

1.AdmNumber管理者编号。

2.DepartmentNumber学院标号，当管理者要操作时，可以按学院进行划分。

3.StudentNumber学生编号，管理者要操作的学生的编号。

9)CDatabase类

CDatabase类，用于实现与数据库的交互，包括连接，查询，插入，删除，修

改等功能，具体有：

1.AdminstratorList管理员列表，记录了管理员的编号及基本信息。

2.CDepartmentList学院列表，记录了CStudent，CTeacher，CClass的信息，

管理员可以通过这个接口完成对学生、老师、课程、修课计划约束条件的

查询，修改，插入，删除操作。

总结

本文主要阐述了如下几个方面内容：

1.介绍了面向对象与构件技术的产生及发展。并阐述了面向对象与构件技术的一些关

键词，及基本特征。

2.简单描述了标准建模语言（UML）的出现及功能。

3.用面向对象及构建的方法设计了一个学籍管理系统。

4.描述了学籍管理系统的用例图。

5.描述了学籍管理系统的时序图。

6.描述了学籍管理系统的类图。

在本文的编写过程中曾遇到一系列的问题，因为以前对面向构件这种设计模式了解不多，在设计系统初期，经常出现问题，在同学的帮助下，并参考了大量资料后，慢慢对面向对象与构件技术有了一些较深入的了解。

面向对象与构件技术，能帮助我们在程序设计及编码阶段，更有条理的设计程序，让程序更易复用。在今后的学习及工作过程中，我会更进一步学习面向对象及构件技术，提高自己的设计软件及编写代码的水平。

参考文献

[1] 赵志芳. 面向对象技术和UML[J]. 宁波职业技术学院学报, 2001,(01)

[2] 张同军, 李勇, 董明哲. UML建模在消防监督系统开发中的应用[J]. 鞍山师范学院学报, 2003,(04)

[3] 俞晓箴. UML的实时应用软件开发环境[J]. 培训与研究-湖北教育学院学报, 2002,(02)

[4] 江科. 小软件开发中的管理[J]. 湖南工业职业技术学院学报, 2003,(02)

[5]谢中才.学分制的教学管理框架[J].江苏高教，2001.(5):

[6]古莉，刘玉生.基于UML设计数据库模型.计算机与现代化，2001.(5)