‘壹’ [基于Web服务的高校教务管理系统的设计和实现] URP高校教务管理系统
一、敬困磨论文研究的意义和国内外研究现状随着我国教育改革不断深化、素质教育全面推进和高校办学规模不断扩大，高校教学资源日益紧张，如何提高资源的使用率，处理成倍增长的信息量，已成为管理职能部门共同关心的焦点。因此，许多高校启动并加快了数字化校园建设的步伐，相继建成了校园网，搭建了数字化校园的硬件平台。部分高校购置了管理系统，或开发了单项管理模块，但是，不少软件的实际使用过程中或多或少存在一些缺陷尺消：如管理模式滞后，缺乏与信息技术相匹配的管理模式；功能单一，不能涵盖高校管理部门的诸多方面；可用刑不强，大量的实际问题得不到解决；缺乏统一规则，系统设计，大量数据形成信息“孤岛”。
纵观目前国内研究现状，在安全性和信息更新化方面存在有一定的不足，各现有系统资源资料单独建立，共享性差；在以管理者为主题的方式中，信息取舍依赖管理者对于信息的认知与喜好，较不容易掌握用户真正的需求，也因此无法满足用户的需求。因此，教务管理软件应充分依托校园网，实现教务信息的集中管理、分散操作、信息共享，使传统的教务管理朝数字化、物纸化、智能化、综合化的方向发展，并为进一步实现完善的计算机教务系统和全校信息系统打下良好的基础。
建立基于Web的教务管理系统可以通过网络把信息采集工作整合到行政人员的日常处理中;充分发挥处、室、部、系、校区教学管理的职能,提高各级部门的教学管理水品、质量、效率;可以解决教务管理的信息量大,信息采集难,信息反馈滞后,信息准确性低的瓶颈,从而从全面实现教务管理的网络化、自动化、数字化、使教务管理高效有序地进行.
二、毕业设计（论文）撰写采取的方法和手段
使用J2EE平台架构企业级软件：
1.Java Servlet和 JSP都要编译为Java Class 才作为Servlet运行，因此执行性能会明显提高。
2.Java Servlet和JSP中可以完全使用Java进行编程，可以完成许多简单的商业逻辑，特别是JSP，可以直接书写HTML，因此简化了页面的输出，这样就保留了脚本语言易于使用的优点
3.复杂的商业逻辑已组件的形式部署在EJB Server中。由于EJB Server提供了多种组件事务服务，使系统更能够应付大量的并发用户和管理复杂的事务逻辑亮斗。
4.EJB Server中集成的组件命名服务可以使组件位置透明化，简化了组件的部署和客户端的应用的维护。
三、毕业设计（论文）的主要内容
高校信息管理系统是高校组织工作不可缺少的一部分，一个功能齐全，简单一用的高校信息管理系统能有效地减轻管理工作人员第负担，提高工作效率。随着经济的发展，人员交流来往的频繁，管理更加需要一套信息系统以提高信息管理的快捷及准确性。
本系统将采用B/S模式，基于servlet+MySQL 数据库+jsp+javabeen技术实现。主要包括如下功能模块:
1、登录模块
登录模块用来以不同的用户身份登录系统，并以不同的权限操作系统。本系统的用户类型分别有管理员用户和普通用户，管理员用户又为高级管理员用户，高级管理员具有所有权限，普通管理员不能添加，删除个人信息和修改自己的密码。
2、信息查询模块
信息查询模块可以供普通用户对自己的各种信息查询和管理员对每个的各种信息进行查询。
3、信息更新模块
信息更新模块是管理员对数据库进行操纵的模块，分别可以对信息进行添加、修改、删除信息。对每个部门的管理, 可以添加、 修改、 删除、 所属上级组织组织负责人、 联系方式。对缴纳的费用进行修改汇总，对表现优异学生信息的修改, 以及对其添加删除。
4、系统维护
系统维护模块，只能管理员访问，高级管理员可以修改自己密码，删除除自己之外的管理员用户，添加管理员；普通管理员只能查看自己信息。
（三）、实验方案及可行性分析
1、系统方案
该系统用Java语言开发，是基于J2EE的WEB应用B/S结构开发模式，采用JSP+Javascript+Html作为其动态页面，，系统数据库采用MySQL5.0，运行平台：MyEclipse，操作系统为WindowsXP，采用Tomcat6.0.33作为WEB服务器软件。
2、可行性分析：
可行性研究的目的是用最小的代价在尽可能短的时间内确定问题是否能够解决。也就是说可行性研究的目的不是解决问题，而是确定问题是否值得去解，研究在当前的具体条件下，开发新系统是否具备必要的资源和其它条件。下边我们来一起探讨一下这个方案是否可以实现，我们从3个方面讨论：
一、 技术可行性
高校信息管理系统采用JSP编程语言来进行开发，采用JSP+Javascript+Html作为其动态页面，运用MyEclipse作其开发平台，使用JavaScript来对系统的表单进行验证，MySQL数据库作为后台支持。当前笔者以前有过相类似系统的开发，对其一般性的软件和操作环境，编译环境都比较的熟悉，加上指导教师的指导，所以当前这个系统从技术上来说是可行的。
二、经济可行性
由于该系统只作研究使用，不作商用，在经济上要求很低，只需基本的硬件设备，人员方面，由个人独立开发，所以，从经济上来说是可行的。
三、 管理可行性
该系统是毕业设计课题研究，在教师的指导下由个人独立完成，因此，在管理
上，系统的完成期限是可控的。
四、课题研究所需的参考文献
参考文献：
[1] 邓子云.JSP网络编程[M].长沙:电子工业出版社,2009.8:69-285.
[2] 吴亚峰,苏亚光.Java项目案例开发[M].北京:电子工业出版社,2008.1:92-250.
[3] 李晓娜,黄艳.JavaScript从入门到精通[M].北京:清华大学出版社,2008.3:135-311.
[4] 张孝祥.深入Java Web开发内幕[M].北京:电子工业出版社,2006.8:42-397.
[5] 张孝祥,徐明华,邱加永.JSP基础与案例开发详解[M].北京：清华大学出版社,2001
[6] 刘世峰，《数据库基础与应用》,中央广播电视大学出版社，2004
[7] 郭剑毅等，基于C/S与B/S的高校科研管理信息系统的设计与实现，计算机工程与应用
[8] 李玉梅，动态WEB数据库应用研究，昆明理工大学硕士学位论文，2004
‘贰’ URP教务系统。错过了上星期的选课，现在显示不可选不可退。有什么办法
没办法，只能按照现在的课表上课
‘叁’ 【Unity3D】URP下的GrabPass方案
GrabPass和AlphaBlend都有渲染物体包含背景物体颜色的特点，不同的是，AlphaBlend渲染像素时，只能基于该像素的激棚前一次DrawCall结果来混合，而GrabPass渲染此像素时，可以得到其他像素颜色，能做出扰动、折射之类的效果。
然而URP管线并不支持GrabPass，虽然官方事例中提到可以用OpaqueTexture代替功能，但顾名思义，OpaqueTexture是在不透明物体渲染之后截取的一张RT，其中不包含半透明物体，因此我们需要手动实现GrabTexture功能。
注：OpaqueTexture实际是在半透明物体渲染之前，也就是说是在天空盒渲染之后，甚至在BeforeRenderTransparent之后CopyColor。
如果想要完全和GrabPass一致，可能是做不到的，Unity自带的GrabPass，能在此物体DrawCall的前一次DrawCall来Blit一张图片，而我们是无法打开一个渲染队列的，例如半透明物体整体在一个队列中，我们无法在其中插一个Blit。
OnRenderImage、OnPerPost之类的方法也不推荐研究，不说URP是否支持，就算支持，他们对渲染位置的控制也有限。
比他们控制能力更高一层的是CommandBuffer，CommandBuffer的控制精度在渲染队列之间，例如能在半透明渲染之后、或后处理之前插上几个渲染命令。
我在2018BuildIn管线下替代GrabPass（原因是当时说GrabPass性能消耗高）就明仔则用的这种方法，在每个需要Grab的物体上加个脚本，脚本将自己注册到一个全局的单例管理器中，同时关闭粒子的Renderer组件，单例管理器组织一个CommandBuffer，先Blit一张图片，然后渲染需要GrabTexture的物体，这样的缺点是，当渲染物体为半透明物体（实际上需要Grab的物体大多是放在半透明渲染队列中，并且基本是粒子）时，半透明物体的排序不受Unity控制，可能需要花心思重新排序。场景切戚困换时，需要花心思维护管理器，维护管理器中的Renderer（物体增减）、Camera（多相机）、CommandBuffer（重新排列）等。
我一开始也沿用上述的方案，只不过URP下Camera.AddCommandBuffer无法正确将CommandBuffer加到渲染队列中，我采用了RenderFeature来载入CommandBuffer在渲染队列之间的位置。
不幸的是，需要Grab的特效依旧没有被渲染出来，经过排查，CommandBuffer.DrawRenderer方法无法渲染粒子的ParticleSystemRenderer，在google上查，发现别人也出现了类似的问题，MeshRenderer以及SpriteRenderer可以正常渲染，经过对Unity官方人员的询问得知，这是Unity一直以来的Bug，在2018.4中被修复，但因为未来可能需要重新用DOTS实现，所以2019暂时不去修复。
Unity人员建议用多相机解决这个问题，这和我们想法一致。
这个方案就是为每个需要渲染GrabTexture特效、物体的相机，增加一个特效相机，这个特效相机除了cullingmask外，参数和生成它的主要相机完全一致。
利用layer，让主要相机不去渲染这个物体，在后处理前用CommandBuffer Blit一张纹理，设置特效相机的cullingmask只渲染这个需要GrabTexture的物体。
这里注意下URP下的多相机流程，和BuildIn下不同，BuildIn下，多相机是用相机深度来控制相机渲染次序，而URP下，是利用相机的Camera Stack，将主要相机类型设置为Base，其他在此之后渲染的相机设为Overlay，将Overlay相机加入到Base Camera的Camera Stack中。
当时我的脚本是这样的：
除此之外还需要写一个RenderFeature，这个Feature在每个相机后处理前截一张RT，因为这个RT我们是交给外面的粒子用，所以Execute最后不释放，等下一次执行时再释放再重新申请：
这里说几个坑， 官方文档 提到：在照相机渲染完成后，将删除所有未明确释放的临时纹理，但我们需要的是跨相机渲染，这个临时申请的RT我们还可以拿到，并且内容没有被清空或覆盖。
在只有Game窗口时可以正常挨个执行，但假如中间穿插了SceneView相机，可能就会渲染出问题。
其次CommandBuffer.Blit截取RT时，如果RT尺寸不同，例如复制到的RT时复制源相机的1/4，那么截到的画面只能是左上角的1/4。如果用CommandBuffer.Blit传入纹理的重载，则不会出现这个问题，但Blit是否传入纹理还会影响Blit的调用时机，所以不建议降采样。
这个方法的好处是，将渲染粒子完全交给了Unity，我们无需考虑排序，只要考虑在什么地方截帧就好了。
缺点是增加了相机管理的复杂度，因为几乎每个相机（除了阴影相机外）都会被传入RenderFeature，所以每增加一个其他用途的相机都要小心翼翼，如果出错就要重新排查。
上面说用多相机的原因，是因为CommandBuffer无法渲染粒子系统。不过URP不可能渲染不出粒子，经过实验， ScriptableRenderContext ，也就是RenderFeature.Execute传进来的context参数，通过调用DrawRenderers方法，可以渲染粒子系统。这和上述的多相机方案差不多，都是利用Unity本身的机制渲染物体，Unity可以帮助我们排序、剪裁。
只有shader的tag中的LightMode属性在这个Feature的shaderTagIdList中才会被渲染出来，此外DrawRenderers还能控制队列、排序方法等。
比起2018手动组织渲染队列，以及多相机方案，这个方法的好处是复杂度很低，无需考虑渲染排序（管理中的Grab物体无需考虑，管理之外的半透物体依旧需要考虑），无需考虑多场景等等。
如果说有什么劣势，就是对抓屏纹理降采样，至少我做不到，当我试图给Blit方法传递材质时，总会出现各种各样的错误。
‘肆’ urp高校教务管理系统选课未显示咋办
取消。
管理员有功能腔庆可以强制调整或者取消，或者就是你以为选好了，其实网络问题就没有提交成功。
课程安排管理支持一对一，一对多和小组课程的设置，以及按计划和每小时设置课程，以满足不同业务类型学校的不同教育需求，它同时谨圆逗支持祥卖流行课程的发布。