简介《软件工程课程设计》报告以中小型宾馆管理系统为完整案例面向计算机相关专业学生与软件工程入门者可用于课程设计参考、项目实训对照与答辩准备。压缩包仅含1个doc文档约862KB正文按绪论、可行性研究分析、软件需求分析、系统模型等章节展开配有数据流图、数据字典与功能需求条目。报告中技术、经济、运行三方面的可行性论证以及订房、入住、房间状态更新、账单计算、退房等业务的用例描述能帮助读者理解C#界面开发与SQL Server数据库设计如何应用到实际项目中。目前已有4674人学习读者可获得一套可直接套用的课程设计文档框架借鉴按用户、客房、预订、账务划分模块的思路以及错误处理与备份恢复策略的写法。1. 需求立住带过几轮软件工程课程设计之后我发现最容易出问题的一步是选题之后没有把需求固定下来写代码本身反而并不难。某高校一份中小型宾馆管理系统的任务书功能栏只写了“住宿管理、客房管理、退房管理”三行字学生照着做到最后答辩被问“押金怎么扣”“换房之后房态谁改”“结算按几天算”答不上来。这套方案要解决的就是这个问题用一套 C# SQL Server 的单机桌面系统把宾馆前台从登记、换房、加消费到结算的完整链路做成可演示、可测试、可写进报告的闭环。它适合正在做软件工程课程设计、需要一份结构完整报告的人也适合想拿这套模块划分直接改成其他门店管理系统的从业者。2. 可行性与需求边界把“给宾馆做套系统”拆成 10 条能验收的功能点2.1 三条可行性怎么写才不像凑字数技术可行性回答的是“用现有条件能不能做出来”并非“技术先不先进”。我见过太多报告在这里写“采用了先进的三层架构和面向对象思想因此技术上可行”这句话放到任何题目下都成立老师一眼就知道是凑的。真正能站住的技术可行性要落到三件具体的事上机器、工具链、人的能力。调研对象是某宾馆前台员工以青年为主岗位配了能跑 Windows 的电脑日常会打字、会开关软件开发工具是 Visual C# 加 SQL Server都在单机上跑不需要服务器和网络布线系统定位单机版不开放在线预订也就不存在高并发和公网安全的问题。这三条一摆技术可行性的结论才是推出来的不是喊出来的。经济可行性要有现金流不能只写“计算机便宜了”。把一次性投入和年运行成本列成表再和原来的人工方式对比项目金额人力7 人 × 4000 元/人月 × 1 月2.8 万元布线耗材0.2 万元工作站 2 台1.0 万元一次性投入合计4.0 万元新系统年运行成本人力物资 0.4 维护 0.20.6 万元/年原人工方式年运行成本2.4 万元/年每年节省2.0 万元/年有了这两行回收期就能算出来。取 5% 折现率三年累计折现值约 5.45 万元已经覆盖 4.0 万元投入回收期落在第三年内三年后净收益约 1.25 万元。这张表的作用不是精确到百元而是让老师看到你知道“投资回收期”是怎么算出来的。折现率取多少、人力按几个人月算写在表下面一行说明即可不用长篇解释。运行可行性最容易被写成一句话带过其实它有具体内容系统装在宾馆前台现有的 PC 上不连外网病毒和外部攻击的入口天然被切断操作人员每天接触的就是登记、退房这几件事界面按现实流程排培训半天就能上手数据量上一间中小型宾馆几十间房登记表一年几千条记录SQL Server 单机完全扛得住。这三条合起来才叫“运行上可行”。2.2 功能边界的两次收敛第一次收敛是把业务动作翻译成系统功能点。前台嘴里说的是“来客人了开间房”“客人要换个安静点的”“退房结账”这些是业务语言不能直接当功能列表。翻译之后是十条用户登录、按房型和价格查可用房、登记入住、离店结算、按时间段和房型统计客房使用情况、客房信息维护、用户信息维护、押金管理、添加消费、修改密码。这十条每一条都能对应到一个界面、一组数据表、一条测试用例这才叫可验收。第二次收敛是把功能点按角色切开。系统有三类用户服务员、管理员、系统用户。切完之后画成矩阵谁动哪张表一目了然编号功能点服务员管理员系统用户F01登录、修改本人密码是是是F02按房型、价格、房号查可用房是是否F03入住登记是否否F04换房是否否F05添加消费是否否F06结算退房是否否F07押金查看与自动扣除只读只读否F08客房、房型维护只读是否F09消费记录删除、财务统计否是否F10用户信息维护否否是这张表的价值在于它同时是一份权限设计文档。写报告时它是需求分析写代码时它是界面按钮的显示条件答辩时它是你回答“为什么服务员不能删消费记录”的依据。边界还有一半是“不做什么”这部分往往比“做什么”更能体现思考。本系统不做在线预订因为单机不连外网不做身份证读卡因为硬件不在预算内不做多门店连锁因为数据模型会从七张表膨胀到十几张。把这三条明确写进报告老师问“为什么不做在线预订”时你答“系统定位单机、前台代客录入、不开放外网入口”这就是一句有准备的话而不是临场编。2.3 数据流图和数据字典报告里最容易画虚的两张图数据流图不是系统架构图它讲的是数据从哪来、经过什么加工、存到哪去。本系统有四条主流程客房、住宿、消费品、员工。四张图的骨架是一样的以住宿流程为例服务员录入住宿数据写入住宿数据存储服务员修改住宿数据更新同一个存储管理员查询住宿数据从存储里读出来展示。画的时候只要保证每个加工都有输入流和输出流每个数据存储都能在数据字典里找到对应条目图就不会虚。数据字典是给数据流图做注解的格式要统一。以登记信息为例一条完整的条目长这样字段类型长度取值范围或说明客户编号字符20系统按日期加序号生成唯一客房号字符10必须是客房表中存在的房号客户姓名字符30非空客户性别字符1男 / 女客户证件字符20身份证、护照、驾照等证件号字符30非空登记时间日期时间—精确到分钟预住天数整数—大于 0联系电话字符20可空押金金额—两位小数精确到元在店状态字符1在店 / 已结算享受折扣率金额—0.50 至 1.00登记人号整数—关联系统用户表剩下的客房信息、客房类型信息、换房信息、消费信息、结算信息、用户信息六条按同样格式补齐字段名和数据库列名一一对应。这一步做完第四章建表基本就是抄写不会出现“报告里叫押金额、代码里叫 Deposit”的对不上。性能需求单独成段写别混在功能里。查询响应小于 1 秒数据更新小于 100 毫秒宿费、押金、房价三类金额都按两位小数计算、结果精确到人民币元。这三条后面要变成测试用例第 6 章会用到。3. 总体架构与角色权限三层结构、三类用户与一次登录的完整链路3.1 三层结构怎么落到目录课程设计最容易出的问题是三个人合写最后所有 SQL 都塞在按钮点击事件里谁改谁的代码都要冲突。三层结构不是画在报告里好看的它对应的是磁盘上四个工程HotelSys/ ├── HotelSys.UI/ # 界面层只负责取值、校验、展示 │ ├── FrmLogin.cs │ ├── FrmWaiterMain.cs │ ├── FrmAdminMain.cs │ └── FrmCheckIn.cs ├── HotelSys.BLL/ # 业务层房态规则、计费规则、事务编排 │ ├── CheckInService.cs │ ├── RoomService.cs │ └── BillService.cs ├── HotelSys.DAL/ # 数据层参数化 SQL、连接管理 │ ├── SqlHelper.cs │ └── RoomDal.cs └── HotelSys.Model/ # 实体层与表结构一一对应的类 ├── CheckInModel.cs └── RoomModel.cs职责边界用一句话卡死UI 层不出现SELECTDAL 层不判断“这间房能不能住”BLL 层不碰任何控件。判断“能不能住”属于业务规则写在 BLL拼 SQL 属于数据访问写在 DAL。这条线划清楚之后界面改版不用动业务代码业务规则调整也只改一个文件。再补一条工程上的细节连接字符串放在App.config不要硬编码在SqlHelper里。课程设计单人做无所谓三人合作时这一条能省掉无数次“你那边能跑我这边连不上”的争执。3.2 权限矩阵三种角色到底谁动哪张表2.2 那张功能矩阵是给需求看的落到代码要再翻译成数据权限。原则只有一条每个角色只碰自己业务范围内的表。角色可写表只读表服务员登记信息、换房信息、消费信息、结算信息、本人的用户记录客房信息、客房类型信息、押金流水管理员客房信息、客房类型信息、消费信息删除、本人的用户记录登记信息、结算信息、换房信息、押金流水系统用户用户信息无权限控制要落在两个位置。界面上按角色隐藏按钮这是给用户看的DAL 层在写操作前再校验一次当前登录用户的角色这是给自己兜底的。只做前者换个账号手动调接口照样能写进去答辩演示时老师让你用服务员账号点一下“删除消费”按钮是灰的但如果你当场打开数据库改数据就露馅了。两层都做成本不高说服力差很多。登录成功后把用户编号、姓名、角色三个字段塞进一个静态的会话类里后续每次写操作从里面取操作人编号登记表、消费表、结算表都要记这个字段。这一列在审计时是“后悔药”客人投诉某笔消费能查到是谁录的。3.3 登录模块一次校验要走完的四步登录是整个系统唯一一个所有角色共用的入口也是答辩现场第一个演示的功能它必须稳。完整的处理链路是四步输入有效性校验、账号存在性判断、密码比对、按角色跳转。public LoginResult Login(string account, string password) { // 第一步非空与长度校验。账号密码上限 20 位防止超长输入打爆界面 if (string.IsNullOrWhiteSpace(account) || string.IsNullOrWhiteSpace(password)) return LoginResult.EmptyInput; if (account.Length 20 || password.Length 20) return LoginResult.TooLong; // 第二步参数化查询绝不拼接字符串 const string sql SELECT UserId, UserName, UserRole, PasswordSalt, PasswordHash FROM SysUser WHERE UserAccount acc AND IsEnabled 1; DataTable dt SqlHelper.Query(sql, new SqlParameter(acc, account)); if (dt.Rows.Count 0) return LoginResult.NotFound; // 第三步加盐哈希比对库里不存明文 DataRow row dt.Rows[0]; string expect HashHelper.Compute(password, row[PasswordSalt].ToString()); if (!string.Equals(expect, row[PasswordHash].ToString(), StringComparison.OrdinalIgnoreCase)) return LoginResult.WrongPassword; // 第四步带角色返回由调用方决定打开哪个主窗体 return LoginResult.Success( Convert.ToInt32(row[UserId]), row[UserName].ToString(), Convert.ToInt32(row[UserRole])); }代码里有几个决定值得展开说。返回LoginResult对象而不是bool是因为调用方需要拿到角色和用户编号也需要区分失败原因用于记日志。但界面上统一提示“账号或密码错误”不要把“账号不存在”和“密码错误”分开显示分开提示等于告诉别人哪个账号是有效的。密码用加盐哈希存PasswordSalt是 8 位随机串PasswordHash是盐加密码再算摘要。课程设计里明文存密码的情况太常见了答辩时被问到“数据库被人拷走怎么办”这就是一道送分题反过来就是一道送命题。跳转按角色分三个主窗体服务员主窗体只有客房查询、入住登记、换房、添加消费、结算、押金查看、改密七个入口管理员主窗体是客房管理、消费管理、财务统计、客户查询、改密系统用户主窗体只有用户管理和改密。三个窗体的菜单项数量差得越明显演示时角色权限这件事越直观。4. 数据库与业务落地7 张表撑起入住、换房、消费、结算全流程4.1 七个实体与它们的关系本系统的实体有七个客房类型、客房、登记信息、换房信息、消费信息、结算信息、系统用户。关系这样描述一个客房类型下有多个客房是一对多一间客房历史上会有多次登记但同一时刻最多一条“在店”记录一条登记对应多条消费一条登记对应多条换房记录一条登记对应零或一条结算一个系统用户可以登记多条入住记录。这里有个设计选择值得写进报告换房要做成独立表不能直接改登记表里的房号。改房号虽然省一张表但客人问“我前天明明住的是 308怎么单子上写 512”就查不出来了。独立表的代价是多一次插入收益是完整留痕这个取舍在答辩时讲出来比多画一张图有用。E-R 图画完之后要做一次自检每个实体至少出现在一条关系里每个关系两端都有明确的重数。画完发现“结算信息”和“登记信息”是一对一那结算表里就该有一个指向登记表的外键并且加唯一约束不能靠应用层自觉。4.2 建表语句与字段约定字段类型有三个约定金额一律用DECIMAL(10,2)不用FLOAT状态一律用TINYINT加取值注释不用中文字符串时间一律用DATETIME不用字符串存日期。这三条不是洁癖是后面算钱不出错的底线。-- 客房类型房价、面积、配置由管理员维护 CREATE TABLE RoomType ( TypeId INT IDENTITY(1,1) PRIMARY KEY, TypeName NVARCHAR(20) NOT NULL, Area DECIMAL(6,2) NOT NULL, Price DECIMAL(10,2) NOT NULL, -- 日租金 Facility NVARCHAR(200) NULL -- 房间配置描述 ); -- 客房房态 0 空闲 / 1 在住 / 2 维修 / 3 预留 CREATE TABLE Room ( RoomNo VARCHAR(10) PRIMARY KEY, TypeId INT NOT NULL REFERENCES RoomType(TypeId), FloorNo INT NOT NULL, Phone VARCHAR(20) NULL, RoomState TINYINT NOT NULL DEFAULT 0, CONSTRAINT CK_Room_State CHECK (RoomState IN (0,1,2,3)) ); -- 登记信息一次入住一条IsSettled 0 表示仍在店 CREATE TABLE CheckIn ( CheckInId BIGINT IDENTITY(1,1) PRIMARY KEY, CustomerId VARCHAR(20) NOT NULL, RoomNo VARCHAR(10) NOT NULL REFERENCES Room(RoomNo), CustomerName NVARCHAR(30) NOT NULL, Gender CHAR(1) NOT NULL, CertType NVARCHAR(20) NOT NULL, CertNo VARCHAR(30) NOT NULL, CheckInTime DATETIME NOT NULL, PlanDays INT NOT NULL, Company NVARCHAR(50) NULL, Phone VARCHAR(20) NULL, Deposit DECIMAL(10,2) NOT NULL, Discount DECIMAL(4,2) NOT NULL DEFAULT 1.00, -- 0.50 ~ 1.00 OperatorId INT NOT NULL REFERENCES SysUser(UserId), IsSettled BIT NOT NULL DEFAULT 0, Remark NVARCHAR(200) NULL ); -- 换房记录只增不改保留完整轨迹 CREATE TABLE RoomChange ( ChangeId BIGINT IDENTITY(1,1) PRIMARY KEY, CheckInId BIGINT NOT NULL REFERENCES CheckIn(CheckInId), OldRoomNo VARCHAR(10) NOT NULL, NewRoomNo VARCHAR(10) NOT NULL, ChangeTime DATETIME NOT NULL, OperatorId INT NOT NULL REFERENCES SysUser(UserId) ); -- 消费信息Amount 用计算列避免应用端各算各的 CREATE TABLE Consumption ( ConsumeId BIGINT IDENTITY(1,1) PRIMARY KEY, CheckInId BIGINT NOT NULL REFERENCES CheckIn(CheckInId), ItemName NVARCHAR(50) NOT NULL, UnitPrice DECIMAL(10,2) NOT NULL, Quantity INT NOT NULL, Amount AS (UnitPrice * Quantity) PERSISTED, ConsumeTime DATETIME NOT NULL, OperatorId INT NOT NULL REFERENCES SysUser(UserId) ); -- 结算信息一条登记最多结算一次用 UNIQUE 卡死 CREATE TABLE Settlement ( SettleId BIGINT IDENTITY(1,1) PRIMARY KEY, CheckInId BIGINT NOT NULL UNIQUE REFERENCES CheckIn(CheckInId), SettleTime DATETIME NOT NULL, RoomFee DECIMAL(10,2) NOT NULL, OtherFee DECIMAL(10,2) NOT NULL, TotalFee DECIMAL(10,2) NOT NULL, OperatorId INT NOT NULL REFERENCES SysUser(UserId) ); -- 系统用户三种角色密码只存盐和摘要 CREATE TABLE SysUser ( UserId INT IDENTITY(1,1) PRIMARY KEY, UserAccount VARCHAR(20) NOT NULL UNIQUE, UserName NVARCHAR(30) NOT NULL, UserRole TINYINT NOT NULL, -- 1 服务员 / 2 管理员 / 9 系统用户 PasswordSalt CHAR(8) NOT NULL, PasswordHash CHAR(32) NOT NULL, IsEnabled BIT NOT NULL DEFAULT 1 );Consumption表里的Amount用持久化计算列是这套表结构里最省事的一处设计。金额由数据库算界面、报表、结算三处引用的永远是同一个值不会出现明细加起来和合计对不上的情况。4.3 表间关系与三条业务约束三条约束决定了系统的正确性必须落到数据库层面不能只写在文档里。第一条一间房同一时刻只能有一条未结算的登记。如果用的数据库版本支持筛选索引一行就能解决CREATE UNIQUE INDEX UX_CheckIn_Live ON CheckIn(RoomNo) WHERE IsSettled 0;这条索引建上之后“一间房开出两张在店单”这种事故在数据库层面就不可能发生比在代码里写十行if判断都可靠。第二条结算完成时房态必须回到空闲。这件事必须和写结算记录放在同一个事务里中间任何一步失败就整体回滚。手工先改房态再写结算中间断电一次房就永远卡在“在住”状态只能进数据库改这是血泪经验。第三条消费只能挂到未结算的登记记录上。客人已经退房结完账隔天再往那条记录上加一笔消费账就永远对不平。实现方式是插入前查一次IsSettled同时在 BLL 层拦住所有对已结算记录的写入口。4.4 四个核心事务入住、换房、加消费、结算入住登记是整个系统的入口它要同时干两件事占房和写单。用一条带条件的UPDATE拿房比先查后改更稳public bool CheckIn(CheckInModel m) { using (var conn new SqlConnection(SqlHelper.ConnStr)) { conn.Open(); using (var tran conn.BeginTransaction()) { try { // 占房只有当前房态是 0空闲才更新成功 var occupy new SqlCommand( UPDATE Room SET RoomState 1 WHERE RoomNo no AND RoomState 0, conn, tran); occupy.Parameters.AddWithValue(no, m.RoomNo); // 影响行数为 0说明房已被占或状态不对直接回滚 if (occupy.ExecuteNonQuery() ! 1) { tran.Rollback(); return false; } var insert new SqlCommand( INSERT INTO CheckIn(CustomerId, RoomNo, CustomerName, Gender, CertType, CertNo, CheckInTime, PlanDays, Company, Phone, Deposit, Discount, OperatorId, IsSettled) VALUES(cid, room, name, gender, ctype, cno, time, days, company, phone, deposit, discount, op, 0), conn, tran); // 参数绑定省略逐个 AddWithValue 即可 insert.ExecuteNonQuery(); tran.Commit(); return true; } catch { tran.Rollback(); throw; } } } }UPDATE Room ... WHERE RoomState 0这一句在单机版里等价于一把乐观锁。服务员手快点了两下“登记”第二次影响行数是 0方法直接返回失败界面上提示“该房间已被占用请刷新房态”。这一句比任何防重复提交的前端拦截都管用。换房的逻辑是三步写在一个事务里插一条换房记录、把旧房房态改回空闲、把新房房态改成在住。三条语句任何一条失败都回滚。顺序上要先查新房是否空闲再动旧房否则出现“旧房放了、新房没占上”的中间态客人就没房住了。加消费最简单插一条Consumption记录即可金额由计算列自动得出。唯一要注意的是OperatorId必须从会话里取不能让界面随便传。结算最复杂因为它要算房费和天数SELECT c.CheckInId, c.CheckInTime, c.Discount, t.Price, CASE WHEN DATEDIFF(DAY, c.CheckInTime, GETDATE()) 0 THEN 1 ELSE DATEDIFF(DAY, c.CheckInTime, GETDATE()) END AS RealDays, ISNULL((SELECT SUM(Amount) FROM Consumption WHERE CheckInId c.CheckInId), 0) AS OtherFee FROM CheckIn c JOIN Room r ON c.RoomNo r.RoomNo JOIN RoomType t ON r.TypeId t.TypeId WHERE c.CheckInId id AND c.IsSettled 0;天数怎么算是老师最爱追问的点因为原任务书里只写了“预住天数”没写实际住了几天怎么算。我一般会在报告里明确一条业务规则按自然日计费退房当日 12:00 前离店不计新的一天12:00 至 18:00 之间离店加收半天18:00 之后离店加收一天。规则写清楚代码照着实现答辩时被问到就翻到这一页。房费等于实际天数乘以日租金再乘以折扣率其他消费从消费表汇总总额减去押金就是需要补收或者退还的金额。4.5 押金定时扣除12:00 与 18:00 的幂等设计任务书里有一条容易被忽略但很出彩的需求每天 12:00 自动扣一天房费18:00 自动扣半天房费服务员只能查看不能改。这条需求的难点不在定时器在幂等——程序重启、定时器重复触发、手动点了一次刷新都可能让同一笔扣款执行两遍。做法是加一张押金流水表用联合主键天然去重CREATE TABLE DepositLog ( CheckInId BIGINT NOT NULL, DeductDate DATE NOT NULL, Slot TINYINT NOT NULL, -- 1 表示 12:00 整天2 表示 18:00 半天 Amount DECIMAL(10,2) NOT NULL, CreateTime DATETIME NOT NULL, PRIMARY KEY (CheckInId, DeductDate, Slot) );定时器每分钟醒一次比对当前小时和分钟是否命中 12:00 或 18:00命中就扫一遍所有IsSettled 0的登记记录往DepositLog里插一条。同一条记录同一日期同一时段插第二次会撞主键捕获异常直接跳过即可不需要额外写判断。金额方面Slot 1扣一天房费乘折扣Slot 2扣半天。服务员界面只读这张表看到的就是“今天几点扣了多少钱”一条条列出来客人问起来能对上。5. 常见问题排查答辩前必须自己先踩一遍的五个坑5.1 房态和登记记录对不上现象是演示时房间明明显示空闲点进去登记却提示“房间已被占用”或者反过来客人已经退房房态还挂着“在住”。原因基本是两个一是占房和写登记没放在同一个事务里中间失败一次就留下半截数据二是入住和退房用了两套不同的房态更新代码一处写RoomState 1另一处忘了写回0。解决办法是把房态变更收敛到一个方法里入住、换房、退房、维修全部调它别各写各的。再给CheckIn表加上 4.3 那条筛选唯一索引数据库层面兜底。演示前跑一遍“开房—退房—再开同一间”的循环跑通了再上台。5.2 结算金额差一分钱现象是明细加起来和总额差 0.01或者押金退还金额算出来带一长串小数。原因通常是金额字段用了FLOAT或DOUBLE浮点数在二进制里存不下 0.1 这种十进制小数累加几次误差就出来了。另一个常见原因是Math.Round默认走银行家舍入2.5会变成2而不是3和人工算的对不上。解决是把所有金额字段改成DECIMAL(10,2)应用层用decimal类型接中间不做任何double转换。四舍五入统一用Math.Round(value, 2, MidpointRounding.AwayFromZero)明确按“四舍五入”而不是银行家舍入。改完之后用一个固定用例验日租金 188.88、住 3 天、打 8.5 折、消费 46.60、押金 500手算一遍再跑一遍两边对上才算过。5.3 定时扣款一天扣了两次现象是押金流水里同一天出现两条 12:00 的记录客人押金被多扣了一天的钱。原因是定时器用System.Timers.Timer且间隔设得太短或者程序重启后从零开始算把当天已经执行过的时段又跑了一遍。没有幂等键的话代码里根本发现不了重复。解决办法就是 4.5 那张DepositLog表的联合主键。另外定时器间隔别设成 1000 毫秒以下一分钟醒一次足够每次比对分钟数命中才执行。程序启动时先查一次当天已执行的时段已经在表里的直接跳过把重启这个场景也堵上。5.4 换个账号就能看到不该看的界面现象是服务员账号登录进去菜单里能看到“客房维护”点进去还能改房价或者界面上按钮是灰的但手动改一下窗体状态照样能提交。原因很单纯权限只做了界面层没做数据层。按钮隐藏是Visible false改一行代码或者换个入口就绕过去了。解决办法是双层校验。界面上按 3.2 那张权限矩阵控制菜单和按钮显示DAL 层在每个写方法开头再查一次当前登录用户的角色不在白名单里直接抛异常。这样即使界面被绕过数据也写不进去。答辩现场老师让你用服务员账号改房价你能当场演示“提示无权限”这个环节反而是加分项。5.5 报告里的数据字典和代码里的表对不上现象是报告写着“押金额”数据库列叫Deposit报告说折扣率是百分比代码里存的是 0.85数据字典列的字段有 14 个建表语句只有 12 个。原因是文档和代码分头写写完没对过。这类问题在答辩时杀伤力很大因为老师翻报告和看代码是两个动作对不上就是态度问题。解决办法是反过来做先定表结构再从表结构生成数据字典的那张表。字段名、类型、长度、取值范围全部照抄一个不落。报告里的 E-R 图、数据流图、数据字典三样东西必须能互相印证画完自己拿红笔对一遍。我一般会在提交前做一次“文档—数据库—代码”三方对照字段名不一致的一律以数据库为准改文档改完再跑一遍主流程确保没改坏。6. 验收与答辩用一份测试记录证明“能跑”而不是“看起来能跑”验收这件事最忌讳的是“我演示一遍主流程老师看着挺顺”。主流程顺是基本要求能证明系统合格的是一份可复查的测试记录。我的做法是提前写好用例表答辩时按表逐条演示每条演示完在表上打个勾整个过程像验收单一样推进。测试用例不用多覆盖三类就够功能正确性、边界、异常。下面这十条例子里前六条是主流程后四条是最容易被问到的边界编号场景输入预期结果T01服务员登录正确账号密码进入服务员主窗体菜单 7 项T02错误密码登录正确账号 错误密码提示“账号或密码错误”不进入系统T03按房型查可用房房型标准间价格≤300只列出空闲且符合条件的房间响应小于 1 秒T04入住登记空闲房 308押金 500登记成功308 房态变为在住T05重复登记同一间房再次对 308 登记本文还有配套的精品资源点击获取 
长河君 · 2026/11/4 9:56:53 · 阅读 1.2k C#+SQL Server宾馆管理系统课程设计：需求到数据库落地
简介《软件工程课程设计》报告以中小型宾馆管理系统为完整案例面向计算机相关专业学生与软件工程入门者可用于课程设计参考、项目实训对照与答辩准备。压缩包仅含1个doc文档约862KB正文按绪论、可行性研究分析、软件需求分析、系统模型等章节展开配有数据流图、数据字典与功能需求条目。报告中技术、经济、运行三方面的可行性论证以及订房、入住、房间状态更新、账单计算、退房等业务的用例描述能帮助读者理解C#界面开发与SQL Server数据库设计如何应用到实际项目中。目前已有4674人学习读者可获得一套可直接套用的课程设计文档框架借鉴按用户、客房、预订、账务划分模块的思路以及错误处理与备份恢复策略的写法。1. 需求立住带过几轮软件工程课程设计之后我发现最容易出问题的一步是选题之后没有把需求固定下来写代码本身反而并不难。某高校一份中小型宾馆管理系统的任务书功能栏只写了“住宿管理、客房管理、退房管理”三行字学生照着做到最后答辩被问“押金怎么扣”“换房之后房态谁改”“结算按几天算”答不上来。这套方案要解决的就是这个问题用一套 C# SQL Server 的单机桌面系统把宾馆前台从登记、换房、加消费到结算的完整链路做成可演示、可测试、可写进报告的闭环。它适合正在做软件工程课程设计、需要一份结构完整报告的人也适合想拿这套模块划分直接改成其他门店管理系统的从业者。2. 可行性与需求边界把“给宾馆做套系统”拆成 10 条能验收的功能点2.1 三条可行性怎么写才不像凑字数技术可行性回答的是“用现有条件能不能做出来”并非“技术先不先进”。我见过太多报告在这里写“采用了先进的三层架构和面向对象思想因此技术上可行”这句话放到任何题目下都成立老师一眼就知道是凑的。真正能站住的技术可行性要落到三件具体的事上机器、工具链、人的能力。调研对象是某宾馆前台员工以青年为主岗位配了能跑 Windows 的电脑日常会打字、会开关软件开发工具是 Visual C# 加 SQL Server都在单机上跑不需要服务器和网络布线系统定位单机版不开放在线预订也就不存在高并发和公网安全的问题。这三条一摆技术可行性的结论才是推出来的不是喊出来的。经济可行性要有现金流不能只写“计算机便宜了”。把一次性投入和年运行成本列成表再和原来的人工方式对比项目金额人力7 人 × 4000 元/人月 × 1 月2.8 万元布线耗材0.2 万元工作站 2 台1.0 万元一次性投入合计4.0 万元新系统年运行成本人力物资 0.4 维护 0.20.6 万元/年原人工方式年运行成本2.4 万元/年每年节省2.0 万元/年有了这两行回收期就能算出来。取 5% 折现率三年累计折现值约 5.45 万元已经覆盖 4.0 万元投入回收期落在第三年内三年后净收益约 1.25 万元。这张表的作用不是精确到百元而是让老师看到你知道“投资回收期”是怎么算出来的。折现率取多少、人力按几个人月算写在表下面一行说明即可不用长篇解释。运行可行性最容易被写成一句话带过其实它有具体内容系统装在宾馆前台现有的 PC 上不连外网病毒和外部攻击的入口天然被切断操作人员每天接触的就是登记、退房这几件事界面按现实流程排培训半天就能上手数据量上一间中小型宾馆几十间房登记表一年几千条记录SQL Server 单机完全扛得住。这三条合起来才叫“运行上可行”。2.2 功能边界的两次收敛第一次收敛是把业务动作翻译成系统功能点。前台嘴里说的是“来客人了开间房”“客人要换个安静点的”“退房结账”这些是业务语言不能直接当功能列表。翻译之后是十条用户登录、按房型和价格查可用房、登记入住、离店结算、按时间段和房型统计客房使用情况、客房信息维护、用户信息维护、押金管理、添加消费、修改密码。这十条每一条都能对应到一个界面、一组数据表、一条测试用例这才叫可验收。第二次收敛是把功能点按角色切开。系统有三类用户服务员、管理员、系统用户。切完之后画成矩阵谁动哪张表一目了然编号功能点服务员管理员系统用户F01登录、修改本人密码是是是F02按房型、价格、房号查可用房是是否F03入住登记是否否F04换房是否否F05添加消费是否否F06结算退房是否否F07押金查看与自动扣除只读只读否F08客房、房型维护只读是否F09消费记录删除、财务统计否是否F10用户信息维护否否是这张表的价值在于它同时是一份权限设计文档。写报告时它是需求分析写代码时它是界面按钮的显示条件答辩时它是你回答“为什么服务员不能删消费记录”的依据。边界还有一半是“不做什么”这部分往往比“做什么”更能体现思考。本系统不做在线预订因为单机不连外网不做身份证读卡因为硬件不在预算内不做多门店连锁因为数据模型会从七张表膨胀到十几张。把这三条明确写进报告老师问“为什么不做在线预订”时你答“系统定位单机、前台代客录入、不开放外网入口”这就是一句有准备的话而不是临场编。2.3 数据流图和数据字典报告里最容易画虚的两张图数据流图不是系统架构图它讲的是数据从哪来、经过什么加工、存到哪去。本系统有四条主流程客房、住宿、消费品、员工。四张图的骨架是一样的以住宿流程为例服务员录入住宿数据写入住宿数据存储服务员修改住宿数据更新同一个存储管理员查询住宿数据从存储里读出来展示。画的时候只要保证每个加工都有输入流和输出流每个数据存储都能在数据字典里找到对应条目图就不会虚。数据字典是给数据流图做注解的格式要统一。以登记信息为例一条完整的条目长这样字段类型长度取值范围或说明客户编号字符20系统按日期加序号生成唯一客房号字符10必须是客房表中存在的房号客户姓名字符30非空客户性别字符1男 / 女客户证件字符20身份证、护照、驾照等证件号字符30非空登记时间日期时间—精确到分钟预住天数整数—大于 0联系电话字符20可空押金金额—两位小数精确到元在店状态字符1在店 / 已结算享受折扣率金额—0.50 至 1.00登记人号整数—关联系统用户表剩下的客房信息、客房类型信息、换房信息、消费信息、结算信息、用户信息六条按同样格式补齐字段名和数据库列名一一对应。这一步做完第四章建表基本就是抄写不会出现“报告里叫押金额、代码里叫 Deposit”的对不上。性能需求单独成段写别混在功能里。查询响应小于 1 秒数据更新小于 100 毫秒宿费、押金、房价三类金额都按两位小数计算、结果精确到人民币元。这三条后面要变成测试用例第 6 章会用到。3. 总体架构与角色权限三层结构、三类用户与一次登录的完整链路3.1 三层结构怎么落到目录课程设计最容易出的问题是三个人合写最后所有 SQL 都塞在按钮点击事件里谁改谁的代码都要冲突。三层结构不是画在报告里好看的它对应的是磁盘上四个工程HotelSys/ ├── HotelSys.UI/ # 界面层只负责取值、校验、展示 │ ├── FrmLogin.cs │ ├── FrmWaiterMain.cs │ ├── FrmAdminMain.cs │ └── FrmCheckIn.cs ├── HotelSys.BLL/ # 业务层房态规则、计费规则、事务编排 │ ├── CheckInService.cs │ ├── RoomService.cs │ └── BillService.cs ├── HotelSys.DAL/ # 数据层参数化 SQL、连接管理 │ ├── SqlHelper.cs │ └── RoomDal.cs └── HotelSys.Model/ # 实体层与表结构一一对应的类 ├── CheckInModel.cs └── RoomModel.cs职责边界用一句话卡死UI 层不出现SELECTDAL 层不判断“这间房能不能住”BLL 层不碰任何控件。判断“能不能住”属于业务规则写在 BLL拼 SQL 属于数据访问写在 DAL。这条线划清楚之后界面改版不用动业务代码业务规则调整也只改一个文件。再补一条工程上的细节连接字符串放在App.config不要硬编码在SqlHelper里。课程设计单人做无所谓三人合作时这一条能省掉无数次“你那边能跑我这边连不上”的争执。3.2 权限矩阵三种角色到底谁动哪张表2.2 那张功能矩阵是给需求看的落到代码要再翻译成数据权限。原则只有一条每个角色只碰自己业务范围内的表。角色可写表只读表服务员登记信息、换房信息、消费信息、结算信息、本人的用户记录客房信息、客房类型信息、押金流水管理员客房信息、客房类型信息、消费信息删除、本人的用户记录登记信息、结算信息、换房信息、押金流水系统用户用户信息无权限控制要落在两个位置。界面上按角色隐藏按钮这是给用户看的DAL 层在写操作前再校验一次当前登录用户的角色这是给自己兜底的。只做前者换个账号手动调接口照样能写进去答辩演示时老师让你用服务员账号点一下“删除消费”按钮是灰的但如果你当场打开数据库改数据就露馅了。两层都做成本不高说服力差很多。登录成功后把用户编号、姓名、角色三个字段塞进一个静态的会话类里后续每次写操作从里面取操作人编号登记表、消费表、结算表都要记这个字段。这一列在审计时是“后悔药”客人投诉某笔消费能查到是谁录的。3.3 登录模块一次校验要走完的四步登录是整个系统唯一一个所有角色共用的入口也是答辩现场第一个演示的功能它必须稳。完整的处理链路是四步输入有效性校验、账号存在性判断、密码比对、按角色跳转。public LoginResult Login(string account, string password) { // 第一步非空与长度校验。账号密码上限 20 位防止超长输入打爆界面 if (string.IsNullOrWhiteSpace(account) || string.IsNullOrWhiteSpace(password)) return LoginResult.EmptyInput; if (account.Length 20 || password.Length 20) return LoginResult.TooLong; // 第二步参数化查询绝不拼接字符串 const string sql SELECT UserId, UserName, UserRole, PasswordSalt, PasswordHash FROM SysUser WHERE UserAccount acc AND IsEnabled 1; DataTable dt SqlHelper.Query(sql, new SqlParameter(acc, account)); if (dt.Rows.Count 0) return LoginResult.NotFound; // 第三步加盐哈希比对库里不存明文 DataRow row dt.Rows[0]; string expect HashHelper.Compute(password, row[PasswordSalt].ToString()); if (!string.Equals(expect, row[PasswordHash].ToString(), StringComparison.OrdinalIgnoreCase)) return LoginResult.WrongPassword; // 第四步带角色返回由调用方决定打开哪个主窗体 return LoginResult.Success( Convert.ToInt32(row[UserId]), row[UserName].ToString(), Convert.ToInt32(row[UserRole])); }代码里有几个决定值得展开说。返回LoginResult对象而不是bool是因为调用方需要拿到角色和用户编号也需要区分失败原因用于记日志。但界面上统一提示“账号或密码错误”不要把“账号不存在”和“密码错误”分开显示分开提示等于告诉别人哪个账号是有效的。密码用加盐哈希存PasswordSalt是 8 位随机串PasswordHash是盐加密码再算摘要。课程设计里明文存密码的情况太常见了答辩时被问到“数据库被人拷走怎么办”这就是一道送分题反过来就是一道送命题。跳转按角色分三个主窗体服务员主窗体只有客房查询、入住登记、换房、添加消费、结算、押金查看、改密七个入口管理员主窗体是客房管理、消费管理、财务统计、客户查询、改密系统用户主窗体只有用户管理和改密。三个窗体的菜单项数量差得越明显演示时角色权限这件事越直观。4. 数据库与业务落地7 张表撑起入住、换房、消费、结算全流程4.1 七个实体与它们的关系本系统的实体有七个客房类型、客房、登记信息、换房信息、消费信息、结算信息、系统用户。关系这样描述一个客房类型下有多个客房是一对多一间客房历史上会有多次登记但同一时刻最多一条“在店”记录一条登记对应多条消费一条登记对应多条换房记录一条登记对应零或一条结算一个系统用户可以登记多条入住记录。这里有个设计选择值得写进报告换房要做成独立表不能直接改登记表里的房号。改房号虽然省一张表但客人问“我前天明明住的是 308怎么单子上写 512”就查不出来了。独立表的代价是多一次插入收益是完整留痕这个取舍在答辩时讲出来比多画一张图有用。E-R 图画完之后要做一次自检每个实体至少出现在一条关系里每个关系两端都有明确的重数。画完发现“结算信息”和“登记信息”是一对一那结算表里就该有一个指向登记表的外键并且加唯一约束不能靠应用层自觉。4.2 建表语句与字段约定字段类型有三个约定金额一律用DECIMAL(10,2)不用FLOAT状态一律用TINYINT加取值注释不用中文字符串时间一律用DATETIME不用字符串存日期。这三条不是洁癖是后面算钱不出错的底线。-- 客房类型房价、面积、配置由管理员维护 CREATE TABLE RoomType ( TypeId INT IDENTITY(1,1) PRIMARY KEY, TypeName NVARCHAR(20) NOT NULL, Area DECIMAL(6,2) NOT NULL, Price DECIMAL(10,2) NOT NULL, -- 日租金 Facility NVARCHAR(200) NULL -- 房间配置描述 ); -- 客房房态 0 空闲 / 1 在住 / 2 维修 / 3 预留 CREATE TABLE Room ( RoomNo VARCHAR(10) PRIMARY KEY, TypeId INT NOT NULL REFERENCES RoomType(TypeId), FloorNo INT NOT NULL, Phone VARCHAR(20) NULL, RoomState TINYINT NOT NULL DEFAULT 0, CONSTRAINT CK_Room_State CHECK (RoomState IN (0,1,2,3)) ); -- 登记信息一次入住一条IsSettled 0 表示仍在店 CREATE TABLE CheckIn ( CheckInId BIGINT IDENTITY(1,1) PRIMARY KEY, CustomerId VARCHAR(20) NOT NULL, RoomNo VARCHAR(10) NOT NULL REFERENCES Room(RoomNo), CustomerName NVARCHAR(30) NOT NULL, Gender CHAR(1) NOT NULL, CertType NVARCHAR(20) NOT NULL, CertNo VARCHAR(30) NOT NULL, CheckInTime DATETIME NOT NULL, PlanDays INT NOT NULL, Company NVARCHAR(50) NULL, Phone VARCHAR(20) NULL, Deposit DECIMAL(10,2) NOT NULL, Discount DECIMAL(4,2) NOT NULL DEFAULT 1.00, -- 0.50 ~ 1.00 OperatorId INT NOT NULL REFERENCES SysUser(UserId), IsSettled BIT NOT NULL DEFAULT 0, Remark NVARCHAR(200) NULL ); -- 换房记录只增不改保留完整轨迹 CREATE TABLE RoomChange ( ChangeId BIGINT IDENTITY(1,1) PRIMARY KEY, CheckInId BIGINT NOT NULL REFERENCES CheckIn(CheckInId), OldRoomNo VARCHAR(10) NOT NULL, NewRoomNo VARCHAR(10) NOT NULL, ChangeTime DATETIME NOT NULL, OperatorId INT NOT NULL REFERENCES SysUser(UserId) ); -- 消费信息Amount 用计算列避免应用端各算各的 CREATE TABLE Consumption ( ConsumeId BIGINT IDENTITY(1,1) PRIMARY KEY, CheckInId BIGINT NOT NULL REFERENCES CheckIn(CheckInId), ItemName NVARCHAR(50) NOT NULL, UnitPrice DECIMAL(10,2) NOT NULL, Quantity INT NOT NULL, Amount AS (UnitPrice * Quantity) PERSISTED, ConsumeTime DATETIME NOT NULL, OperatorId INT NOT NULL REFERENCES SysUser(UserId) ); -- 结算信息一条登记最多结算一次用 UNIQUE 卡死 CREATE TABLE Settlement ( SettleId BIGINT IDENTITY(1,1) PRIMARY KEY, CheckInId BIGINT NOT NULL UNIQUE REFERENCES CheckIn(CheckInId), SettleTime DATETIME NOT NULL, RoomFee DECIMAL(10,2) NOT NULL, OtherFee DECIMAL(10,2) NOT NULL, TotalFee DECIMAL(10,2) NOT NULL, OperatorId INT NOT NULL REFERENCES SysUser(UserId) ); -- 系统用户三种角色密码只存盐和摘要 CREATE TABLE SysUser ( UserId INT IDENTITY(1,1) PRIMARY KEY, UserAccount VARCHAR(20) NOT NULL UNIQUE, UserName NVARCHAR(30) NOT NULL, UserRole TINYINT NOT NULL, -- 1 服务员 / 2 管理员 / 9 系统用户 PasswordSalt CHAR(8) NOT NULL, PasswordHash CHAR(32) NOT NULL, IsEnabled BIT NOT NULL DEFAULT 1 );Consumption表里的Amount用持久化计算列是这套表结构里最省事的一处设计。金额由数据库算界面、报表、结算三处引用的永远是同一个值不会出现明细加起来和合计对不上的情况。4.3 表间关系与三条业务约束三条约束决定了系统的正确性必须落到数据库层面不能只写在文档里。第一条一间房同一时刻只能有一条未结算的登记。如果用的数据库版本支持筛选索引一行就能解决CREATE UNIQUE INDEX UX_CheckIn_Live ON CheckIn(RoomNo) WHERE IsSettled 0;这条索引建上之后“一间房开出两张在店单”这种事故在数据库层面就不可能发生比在代码里写十行if判断都可靠。第二条结算完成时房态必须回到空闲。这件事必须和写结算记录放在同一个事务里中间任何一步失败就整体回滚。手工先改房态再写结算中间断电一次房就永远卡在“在住”状态只能进数据库改这是血泪经验。第三条消费只能挂到未结算的登记记录上。客人已经退房结完账隔天再往那条记录上加一笔消费账就永远对不平。实现方式是插入前查一次IsSettled同时在 BLL 层拦住所有对已结算记录的写入口。4.4 四个核心事务入住、换房、加消费、结算入住登记是整个系统的入口它要同时干两件事占房和写单。用一条带条件的UPDATE拿房比先查后改更稳public bool CheckIn(CheckInModel m) { using (var conn new SqlConnection(SqlHelper.ConnStr)) { conn.Open(); using (var tran conn.BeginTransaction()) { try { // 占房只有当前房态是 0空闲才更新成功 var occupy new SqlCommand( UPDATE Room SET RoomState 1 WHERE RoomNo no AND RoomState 0, conn, tran); occupy.Parameters.AddWithValue(no, m.RoomNo); // 影响行数为 0说明房已被占或状态不对直接回滚 if (occupy.ExecuteNonQuery() ! 1) { tran.Rollback(); return false; } var insert new SqlCommand( INSERT INTO CheckIn(CustomerId, RoomNo, CustomerName, Gender, CertType, CertNo, CheckInTime, PlanDays, Company, Phone, Deposit, Discount, OperatorId, IsSettled) VALUES(cid, room, name, gender, ctype, cno, time, days, company, phone, deposit, discount, op, 0), conn, tran); // 参数绑定省略逐个 AddWithValue 即可 insert.ExecuteNonQuery(); tran.Commit(); return true; } catch { tran.Rollback(); throw; } } } }UPDATE Room ... WHERE RoomState 0这一句在单机版里等价于一把乐观锁。服务员手快点了两下“登记”第二次影响行数是 0方法直接返回失败界面上提示“该房间已被占用请刷新房态”。这一句比任何防重复提交的前端拦截都管用。换房的逻辑是三步写在一个事务里插一条换房记录、把旧房房态改回空闲、把新房房态改成在住。三条语句任何一条失败都回滚。顺序上要先查新房是否空闲再动旧房否则出现“旧房放了、新房没占上”的中间态客人就没房住了。加消费最简单插一条Consumption记录即可金额由计算列自动得出。唯一要注意的是OperatorId必须从会话里取不能让界面随便传。结算最复杂因为它要算房费和天数SELECT c.CheckInId, c.CheckInTime, c.Discount, t.Price, CASE WHEN DATEDIFF(DAY, c.CheckInTime, GETDATE()) 0 THEN 1 ELSE DATEDIFF(DAY, c.CheckInTime, GETDATE()) END AS RealDays, ISNULL((SELECT SUM(Amount) FROM Consumption WHERE CheckInId c.CheckInId), 0) AS OtherFee FROM CheckIn c JOIN Room r ON c.RoomNo r.RoomNo JOIN RoomType t ON r.TypeId t.TypeId WHERE c.CheckInId id AND c.IsSettled 0;天数怎么算是老师最爱追问的点因为原任务书里只写了“预住天数”没写实际住了几天怎么算。我一般会在报告里明确一条业务规则按自然日计费退房当日 12:00 前离店不计新的一天12:00 至 18:00 之间离店加收半天18:00 之后离店加收一天。规则写清楚代码照着实现答辩时被问到就翻到这一页。房费等于实际天数乘以日租金再乘以折扣率其他消费从消费表汇总总额减去押金就是需要补收或者退还的金额。4.5 押金定时扣除12:00 与 18:00 的幂等设计任务书里有一条容易被忽略但很出彩的需求每天 12:00 自动扣一天房费18:00 自动扣半天房费服务员只能查看不能改。这条需求的难点不在定时器在幂等——程序重启、定时器重复触发、手动点了一次刷新都可能让同一笔扣款执行两遍。做法是加一张押金流水表用联合主键天然去重CREATE TABLE DepositLog ( CheckInId BIGINT NOT NULL, DeductDate DATE NOT NULL, Slot TINYINT NOT NULL, -- 1 表示 12:00 整天2 表示 18:00 半天 Amount DECIMAL(10,2) NOT NULL, CreateTime DATETIME NOT NULL, PRIMARY KEY (CheckInId, DeductDate, Slot) );定时器每分钟醒一次比对当前小时和分钟是否命中 12:00 或 18:00命中就扫一遍所有IsSettled 0的登记记录往DepositLog里插一条。同一条记录同一日期同一时段插第二次会撞主键捕获异常直接跳过即可不需要额外写判断。金额方面Slot 1扣一天房费乘折扣Slot 2扣半天。服务员界面只读这张表看到的就是“今天几点扣了多少钱”一条条列出来客人问起来能对上。5. 常见问题排查答辩前必须自己先踩一遍的五个坑5.1 房态和登记记录对不上现象是演示时房间明明显示空闲点进去登记却提示“房间已被占用”或者反过来客人已经退房房态还挂着“在住”。原因基本是两个一是占房和写登记没放在同一个事务里中间失败一次就留下半截数据二是入住和退房用了两套不同的房态更新代码一处写RoomState 1另一处忘了写回0。解决办法是把房态变更收敛到一个方法里入住、换房、退房、维修全部调它别各写各的。再给CheckIn表加上 4.3 那条筛选唯一索引数据库层面兜底。演示前跑一遍“开房—退房—再开同一间”的循环跑通了再上台。5.2 结算金额差一分钱现象是明细加起来和总额差 0.01或者押金退还金额算出来带一长串小数。原因通常是金额字段用了FLOAT或DOUBLE浮点数在二进制里存不下 0.1 这种十进制小数累加几次误差就出来了。另一个常见原因是Math.Round默认走银行家舍入2.5会变成2而不是3和人工算的对不上。解决是把所有金额字段改成DECIMAL(10,2)应用层用decimal类型接中间不做任何double转换。四舍五入统一用Math.Round(value, 2, MidpointRounding.AwayFromZero)明确按“四舍五入”而不是银行家舍入。改完之后用一个固定用例验日租金 188.88、住 3 天、打 8.5 折、消费 46.60、押金 500手算一遍再跑一遍两边对上才算过。5.3 定时扣款一天扣了两次现象是押金流水里同一天出现两条 12:00 的记录客人押金被多扣了一天的钱。原因是定时器用System.Timers.Timer且间隔设得太短或者程序重启后从零开始算把当天已经执行过的时段又跑了一遍。没有幂等键的话代码里根本发现不了重复。解决办法就是 4.5 那张DepositLog表的联合主键。另外定时器间隔别设成 1000 毫秒以下一分钟醒一次足够每次比对分钟数命中才执行。程序启动时先查一次当天已执行的时段已经在表里的直接跳过把重启这个场景也堵上。5.4 换个账号就能看到不该看的界面现象是服务员账号登录进去菜单里能看到“客房维护”点进去还能改房价或者界面上按钮是灰的但手动改一下窗体状态照样能提交。原因很单纯权限只做了界面层没做数据层。按钮隐藏是Visible false改一行代码或者换个入口就绕过去了。解决办法是双层校验。界面上按 3.2 那张权限矩阵控制菜单和按钮显示DAL 层在每个写方法开头再查一次当前登录用户的角色不在白名单里直接抛异常。这样即使界面被绕过数据也写不进去。答辩现场老师让你用服务员账号改房价你能当场演示“提示无权限”这个环节反而是加分项。5.5 报告里的数据字典和代码里的表对不上现象是报告写着“押金额”数据库列叫Deposit报告说折扣率是百分比代码里存的是 0.85数据字典列的字段有 14 个建表语句只有 12 个。原因是文档和代码分头写写完没对过。这类问题在答辩时杀伤力很大因为老师翻报告和看代码是两个动作对不上就是态度问题。解决办法是反过来做先定表结构再从表结构生成数据字典的那张表。字段名、类型、长度、取值范围全部照抄一个不落。报告里的 E-R 图、数据流图、数据字典三样东西必须能互相印证画完自己拿红笔对一遍。我一般会在提交前做一次“文档—数据库—代码”三方对照字段名不一致的一律以数据库为准改文档改完再跑一遍主流程确保没改坏。6. 验收与答辩用一份测试记录证明“能跑”而不是“看起来能跑”验收这件事最忌讳的是“我演示一遍主流程老师看着挺顺”。主流程顺是基本要求能证明系统合格的是一份可复查的测试记录。我的做法是提前写好用例表答辩时按表逐条演示每条演示完在表上打个勾整个过程像验收单一样推进。测试用例不用多覆盖三类就够功能正确性、边界、异常。下面这十条例子里前六条是主流程后四条是最容易被问到的边界编号场景输入预期结果T01服务员登录正确账号密码进入服务员主窗体菜单 7 项T02错误密码登录正确账号 错误密码提示“账号或密码错误”不进入系统T03按房型查可用房房型标准间价格≤300只列出空闲且符合条件的房间响应小于 1 秒T04入住登记空闲房 308押金 500登记成功308 房态变为在住T05重复登记同一间房再次对 308 登记本文还有配套的精品资源点击获取