最近帮几批学生和同事梳理JavaWeb方向的毕业设计，我发现"万达商铺租赁管理系统"这种题目出现的频率相当高。项目本身不算复杂，核心就是SSM框架加一套商铺租赁业务闭环——商铺管理、租户管理、租赁合同、租金账单、缴费记录和统计报表。但同样是做这个题目，有人能做出能答辩、能演示、能讲清楚设计逻辑的完整系统，有人却卡在框架配置、表结构、Mapper映射这些地方反复返工。差距不在代码量，而在是否真正理解了这个业务系统该怎样拆解、怎样设计、怎样落地。
这篇文章我不讲虚的，直接从我自己做这类系统的经验出发，把从需求建模、数据库设计到核心功能实现、论文写作的完整路径捋一遍。适合正准备动手做SSM毕业设计或课程设计的同学，也适合想快速接手商铺租赁类管理系统的开发者做参照。
1. 为什么SSM在商铺租赁这类管理系统里依然能打
1.1 被说"过时"的SSM，为什么还是毕设和中小项目的首选
先说个现实情况。现在一提到JavaWeb开发，很多人第一反应是Spring Boot，好像不用Spring Boot就不够新潮。但你去翻阅大量本科毕业设计和中小型商用后台系统，SSM（Spring + SpringMVC + MyBatis）依然是出现频率最高的组合之一。原因不复杂：Spring负责Bean管理和事务控制，SpringMVC负责请求路由，MyBatis负责数据持久化，三层边界非常清晰，无论在教学、论文论述还是实际维护中，都容易表达清楚。
更关键的是，商铺租赁管理系统这类业务的核心是业务规则和数据库设计，不是高并发、高可用、分布式。单机加一台数据库服务器，支撑一个商场的租赁管理绰绰有余。在这个体量下，SSM的灵活性和可控性反而成了优点。你做SSM，能手动控制每一个Bean的装配方式，能清楚看到SpringMVC的请求流转路径，能亲手写Mapper XML里的每条SQL——这些底层细节的学习价值，恰恰是Spring Boot自动配置帮不上忙的地方。论文答辩时导师问"你这套架构是怎么工作的"，你能从配置到运行讲得明明白白，这就是SSM的实际优势。
1.2 一次完整的请求在SSM里是怎么流转的
把这个问题讲清楚，论文里的系统架构图基本也就画出来了。以"查询商铺列表"为例，完整链路是这样的：
前端JSP页面发起HTTP请求，请求到达DispatcherServlet（前端控制器），由它根据HandlerMapping找到对应的Controller方法。Controller层接收参数后不直接操作数据库，而是调用Service接口，Service实现类里通过@Transactional声明事务，再调用Mapper接口。MyBatis这时会通过动态代理找到对应的Mapper XML文件，解析其中的SQL语句，执行查询后把ResultSet映射为实体对象，逐层返回。最终Controller把数据放到ModelAndView，ViewResolver解析JSP视图渲染成页面反馈给浏览器。
一个典型的配置大概是这样的：
<!-- spring-mvc.xml 核心配置片段 --> <mvc:annotation-driven /> <context:component-scan base-package="com.wanda.shop.controller" /> <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/WEB-INF/jsp/" /> <property name="suffix" value=".jsp" /> </bean><!-- spring-mybatis.xml 数据源与会话工厂配置 --> <bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource"> <property name="driverClassName" value="com.mysql.cj.jdbc.Driver" /> <property name="url" value="jdbc:mysql://localhost:3306/wanda_lease?useUnicode=true&characterEncoding=utf8" /> <property name="username" value="root" /> <property name="password" value="你的密码" /> </bean> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource" /> <property name="mapperLocations" value="classpath:mapper/*.xml" /> </bean> <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.wanda.shop.mapper" /> </bean>这里要注意一个新手常犯的错误：mapperLocations的路径写错，导致Mapper接口和XML文件找不到对应关系。我建议XML统一放在src/main/resources/mapper目录下，并且Mapper XML的namespace必须严格等于Mapper接口全限定名，ID必须等于接口方法名。否则启动不报错，一调用就报Invalid bound statement，排查起来非常头疼。
1.3 想换成Spring Boot？迁移成本其实不高
如果你所在学校要求必须用Spring Boot，或者你自己想往更主流的技术栈靠，SSM这套代码迁移过去并不难。因为Service层、Mapper层、实体类、JSP页面几乎不用改，要改的主要是配置方式和依赖管理。具体来说：web.xml没了，spring-mvc.xml和spring-mybatis.xml里的配置换成Spring Boot的自动配置、application.yml数据源配置和启动类上的@MapperScan注解。Spring Boot的启动类大致是这样：
@SpringBootApplication @MapperScan("com.wanda.shop.mapper") public class LeaseApplication { public static void main(String[] args) { SpringApplication.run(LeaseApplication.class, args); } }一个核心建议：如果你的题目模板是SSM，答辩要求也是围绕SSM展开，就不要在技术上临时换框架。稳妥第一。但如果时间充裕，把两个版本都做出来，在论文里增加一个"SSM与Spring Boot的对比分析"小节，反而是加分项。
2. 商铺租赁的业务模型拆解：建表之前先想清楚这几个对象
2.1 商铺、租户、合同、账单，四张核心表搭起整个骨架
在做这个系统时，最容易犯的错是上来就写代码、建表，做到一半才发现字段不够用，业务逻辑和表结构对不上。我吃过这个亏，后来总结下来，万达商铺租赁管理系统最核心的业务对象就四类：商铺、租户、租赁合同、租金账单。
商铺是最基础的资源对象，字段包括商铺编号、所在楼层、铺位位置、建筑面积、租金单价、物业费单价、商铺状态；租户是承租方，字段包括租户名称、法定代表人、联系电话、信用等级、入驻时间；租赁合同是商铺和租户之间的核心关联对象，记录合同编号、关联商铺、关联租户、起租日期、到期日期、租金递增比例、押金金额、合同状态；租金账单则把合同约定的费用按月或按周期拆出来，字段包括账单编号、所属合同、费用类型、计费周期、应收金额、已收金额、账单状态。在此基础上可以增加缴费记录表、操作日志表、角色权限表作为扩展。
这四张表的关系一句话可以概括：一个商铺在不同时间段可以对应多份合同，一份合同关联一个商铺和一个租户，一份合同按周期拆出多个月度账单。用ER图表达时，商铺和合同是一对多，租户和合同是一对多，合同和账单是一对多。
2.2 表结构设计的几个关键字段约定
直接给出一份我建议的建表核心片段，你可以在自己的项目里直接改造复用：
CREATE TABLE `shop` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键', `shop_no` varchar(32) NOT NULL COMMENT '商铺编号', `floor` varchar(20) DEFAULT NULL COMMENT '所在楼层', `position` varchar(50) DEFAULT NULL COMMENT '铺位位置描述', `area` decimal(10,2) DEFAULT NULL COMMENT '建筑面积(平方米)', `rent_price` decimal(10,2) NOT NULL COMMENT '租金单价(元/月/平方米)', `property_fee` decimal(10,2) DEFAULT NULL COMMENT '物业费单价', `status` tinyint(4) DEFAULT '0' COMMENT '状态：0空置 1已租 2停用 3装修中', `current_tenant_id` bigint(20) DEFAULT NULL COMMENT '当前租户ID(冗余)', `del_flag` tinyint(4) DEFAULT '0' COMMENT '逻辑删除：0未删 1已删', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_shop_no` (`shop_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商铺信息表';CREATE TABLE `lease_contract` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键', `contract_no` varchar(32) NOT NULL COMMENT '合同编号', `shop_id` bigint(20) NOT NULL COMMENT '商铺ID', `tenant_id` bigint(20) NOT NULL COMMENT '租户ID', `start_date` date NOT NULL COMMENT '起租日期', `end_date` date NOT NULL COMMENT '到期日期', `rent_price` decimal(10,2) NOT NULL COMMENT '合同月租金单价', `property_fee` decimal(10,2) DEFAULT NULL COMMENT '物业费单价', `increase_ratio` decimal(5,4) DEFAULT '0.0000' COMMENT '年递增比例', `deposit` decimal(18,2) DEFAULT NULL COMMENT '押金', `pay_method` tinyint(4) DEFAULT '1' COMMENT '付款方式：1月付 2季付 3半年付 4年付', `status` tinyint(4) DEFAULT '0' COMMENT '合同状态：0执行中 1已到期 2已续租 3已退租', `del_flag` tinyint(4) DEFAULT '0', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_contract_no` (`contract_no`), KEY `idx_shop_status` (`shop_id`, `status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='租赁合同表';几个值得注意的约定：
- 金额字段一律用
decimal(18,2)，绝对不要用float或double。浮点数在二进制下存在无法精确表示的精度误差，算租金、算押金时会出现0.1+0.2不等于0.3这种尴尬问题，这在财务相关系统里是不可接受的。 - 状态字段用
tinyint加注释，不用字符串。数字状态码方便写switch，也方便扩展，比如商铺状态从0到3之间调整不影响已有代码。 - 所有表加
del_flag逻辑删除标记，物理删除是最后手段，后面我会专门讲为什么。 create_time和update_time统一用数据库时间戳默认值，减少Java代码里手写时间赋值。- 合同表里冗余了
shop_id和tenant_id，但不冗余商铺名和租户名。列表展示时如果需要显示名称，可以用JOIN查，或者单独存一个快照字段。我倾向用JOIN，保持数据一致性的责任在数据库。
2.3 商铺状态和合同状态必须联动，不能各管各的
很多初学者把商铺表和合同表当两个孤立的字典来设计，这是个大坑。实际业务里，商铺的状态是由合同的状态驱动的。一个商铺，如果存在一份"执行中"状态的合同，那它在商铺表里的状态就应该是"已租"；合同一旦到期变为"已到期"，商铺就应该回到"空置"或进入"待续租"状态。
比较好的设计是在Service层维护这个联动关系，而不是靠人工在后台页面里改。例如签约成功时，同时更新商铺表的status=1、current_tenant_id=新租户ID；退租时，更新合同状态为已退租，同时把商铺状态改回0、清空当前租户ID。这里一定要放在同一个事务里，保证数据一致性。在后面讲事务边界时我会再展开。
到期预警也是这类系统的一个常见需求。实现思路很简单：查询合同表中end_date在30天内且状态为"执行中"的记录，在首页或合同列表标注"即将到期"，提前提醒运营人员联系续租。这块逻辑写在Service层写一个定时任务，每天扫描一次即可。如果学校要求用定时任务框架，可以引入quartz或Spring自带的@Scheduled，都是一两页代码的事。
3. 核心模块实现路线：从合同录入到租金报表的完整闭环
3.1 合同录入与商铺占用冲突校验：并发场景下不能只靠页面判断
合同管理是整个系统最核心的模块。录入一份新合同时，至少要处理这几个问题：合同编号自动生成避免重复、商铺必须存在且状态为空置、起租日期不能晚于到期日期、同一商铺在同一时间段不能存在重叠的合同。
前几个都容易做，难的是"同一商铺同一时间段不能重叠"。很多人的写法是这样的：先在页面查询商铺状态，如果是空置就允许录入，录完再把商铺状态改成已租。这个方案在单用户操作时没问题，但一旦两个运营人员同时操作同一个商铺，就可能出现两个人都查到"空置"，然后两条合同都插入成功的情况。
更稳的做法是双重保障。第一层是在数据库层面加唯一约束或代办逻辑：用lease_contract表加一个uk_shop_time唯一索引，把shop_id和合同时间段通过起止日期列做约束。MySQL的普通唯一索引没法直接约束区间重叠，所以实际中更常用的是在insert之前用一条带条件的SQL做原子校验：
SELECT COUNT(*) FROM lease_contract WHERE shop_id = #{shopId} AND status IN (0, 2) AND del_flag = 0 AND #{newStartDate} <= end_date AND #{newEndDate} >= start_date如果count大于0，说明存在时间重叠的合同，直接抛出业务异常拒绝插入。这条SQL利用了B+树索引和行锁机制，在并发下相对安全。第二层是在Service方法上加@Transactional，并把insertContract和updateShopStatus放进同一个事务，保证合同创建和商铺占用标记要么都成功，要么都失败。
合同编号生成我建议用"当前时间戳+随机数"或"业务前缀+yyyyMMdd+自增序号"，比如HT20250614001。注意在插入前先查重，因为数据库只能保证唯一索引不重复，不能帮你生成有序编号。
3.2 租金账单自动生成：业务规则写在Java里，而不是SQL里
租金账单是这类系统里最有技术含量也最容易出错的部分。账单不是人工一条条录的，而是根据合同自动生成的。这里就面临一个选择：生成规则写在SQL里，还是写在Java里？
我的建议是写在Java里，并且写成可测试的独立工具类或Service方法。原因有三个。第一，租金规则包含各种条件分支：固定月租、按季度递增、首月免租、15号前起租按整月计算、15号后起租按半月计算、物业费和租金分开计费等。把这些分支逻辑堆在SQL的CASE WHEN里，SQL会变得极难阅读，测试和排查都痛苦。第二，Java代码可以写单元测试，用几组合同数据验证计算结果，这是SQL做不到的。第三，答辩时导师问你"租金怎么算的"，你直接打开代码讲分支逻辑，比讲一大段SQL直观得多。
下面是一个简化的租金计算逻辑：
public BigDecimal calcMonthRent(LeaseContract contract, LocalDate monthDate) { // 基础月租金 = 面积 * 单价 BigDecimal baseRent = contract.getArea().multiply(contract.getRentPrice()); // 年递增：从合同生效年度算起，每满一年上浮 increaseRatio int years = (int) ChronoUnit.YEARS.between(contract.getStartDate(), monthDate); if (years > 0) { BigDecimal ratio = BigDecimal.ONE.add(contract.getIncreaseRatio().multiply(BigDecimal.valueOf(years))); baseRent = baseRent.multiply(ratio).setScale(2, RoundingMode.HALF_UP); } // 首月按实际租赁天数折算（如果起租日不是1号） if (monthDate.equals(YearMonth.from(contract.getStartDate()).atDay(1))) { int totalDays = YearMonth.from(contract.getStartDate()).lengthOfMonth(); int daysFromStart = contract.getStartDate().lengthOfMonth() - contract.getStartDate().getDayOfMonth() + 1; baseRent = baseRent.multiply(BigDecimal.valueOf(daysFromStart)) .divide(BigDecimal.valueOf(totalDays), 2, RoundingMode.HALF_UP); } return baseRent; }这只是简化版本，实际项目里还会涉及季付、半年付、年付的折扣比例，以及周期起始日对齐的问题。建议把账单生成做成一个批量方法：输入合同ID，生成该合同从起租日期到到期日期之间的全部账单。生成逻辑里要注意跨年和跨月的边界，尤其2月天数变化。Spring自带的@Scheduled可以每月1号定时扫描所有执行中的合同，自动创建当月账单，这个机制非常实用。
3.3 权限设计：RBAC模型加拦截器，Controller层不能裸奔
商铺租赁管理系统至少要有三类角色：系统管理员、财务人员、运营人员。管理员管商铺和合同，财务管账单和缴费，运营管租户和合同到期提醒。这里最适合用经典的RBAC权限模型：用户表、角色表、用户角色关联表，加一个菜单权限或功能权限表。
技术实现上，登录成功后把用户ID和角色ID放进Session，然后写一个HandlerInterceptor拦截器，在preHandle里做两件事：一是检查用户是否已登录（Session里是否存在用户对象），二是检查当前请求的URL对应的功能是否需要权限。配合SpringMVC配置，把拦截器注册进去：
<mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/**"/> <mvc:exclude-mapping path="/login"/> <mvc:exclude-mapping path="/css/**"/> <mvc:exclude-mapping path="/js/**"/> <mvc:exclude-mapping path="/images/**"/> <bean class="com.wanda.shop.interceptor.LoginInterceptor"/> </mvc:interceptor> </mvc:interceptors>拦截器代码里最基础也是最重要的逻辑是：静态资源一定要排除，否则登录页面都会因为加载CSS失败而显示不正常。这个问题我在第一次做项目时被坑了整整半天，后来养成习惯，每次配拦截器第一件事就是加静态资源排除。
再进一步，可以做数据范围权限。比如财务人员只能看自己负责楼层的账单，运营经理可以看全广场的数据。这时用AOP自定义注解配合ThreadLocal拿到当前登录用户ID，在SQL查询条件里动态拼接楼层或区域过滤条件。这一块是加分项，写进论文能明显提升技术深度。
3.4 可视化报表：MySQL聚合查询加上前端图表组件
报表模块是这类管理系统里最能体现"系统价值"的部分。管理层关心的核心指标就几个：月度租金收入、商铺空置率、到期合同数、欠费租户列表。
租金收入按月汇总的SQL大概是这样的：
SELECT DATE_FORMAT(pay_time, '%Y-%m') AS month, SUM(pay_amount) AS total_income FROM payment_record WHERE del_flag = 0 AND pay_time BETWEEN #{startDate} AND #{endDate} GROUP BY DATE_FORMAT(pay_time, '%Y-%m') ORDER BY month空置率计算需要结合商铺总数和当前空置数：
SELECT (SELECT COUNT(*) FROM shop WHERE status = 0 AND del_flag = 0) AS empty_shop_count, (SELECT COUNT(*) FROM shop WHERE del_flag = 0) AS total_shop_count前端我用的是ECharts，因为它的KPI大屏效果不错，而且对JSP页面友好，直接在页面上引入echarts.min.js，初始化一个div容器，把Controller通过AJAX或ModelAndView传过来的JSON数据塞进option里就行。这里有个实操技巧：Controller返回数据建议统一封装成Result对象，包含code、message、data三个字段，前端判断code是否为200再渲染图表，这样接口返回统一，调试也方便。
4. 真实开发中踩过的坑，以及答辩导师最爱追问的几个点
4.1 金额计算必须用BigDecimal，double是财务系统的天敌
前面建表时已经强调过金额字段用decimal，这里再补充Java侧的规范。Java里做租金、押金、物业费的计算，一律BigDecimal，禁止用double和float。很多同学会在租金计算里写double total = rent * area * 12，看似没问题，一旦涉及除法和乘法混合运算，精度误差累积到分位就会暴露。正确姿势：
BigDecimal totalRent = BigDecimal.valueOf(180.5) .multiply(BigDecimal.valueOf(62.3)) .multiply(BigDecimal.valueOf(12)) .setScale(2, RoundingMode.HALF_UP);顺带说一句，BigDecimal的构造方法要用valueOf或者new BigDecimal("180.5")，不要直接new BigDecimal(180.5)，因为后者传入的double本身已经有精度损失，结果依然不精确。这点无论是开发还是答辩，都是一个很值得讲的细节。
4.2 SimpleDateFormat线程安全问题与日期计算
在SSM项目里，SimpleDateFormat被很多人当成静态工具来用，这其实有线程安全隐患。SimpleDateFormat内部维护了Calendar对象，多线程共享时会相互覆盖状态，导致解析出错。正确做法是用DateTimeFormatter（Java 8开始推荐）或者每次使用时new SimpleDateFormat()。如果项目JDK版本是8以上，直接用java.time包下的LocalDate和DateTimeFormatter是最好的选择。
日期计算的核心场景包括：合同起止日期的天数差、每月账单周期计算、到期日提前N天提醒、跨月跨年的租金折算。
LocalDate startDate = contract.getStartDate(); LocalDate endDate = contract.getEndDate(); long days = ChronoUnit.DAYS.between(startDate, endDate);这里提醒一个小细节：between的结果不包括结束日期当天，如果计算"租赁多少天"，要+1。不同数据库和不同代码库的日期边界规则容易不一致，建议在项目里统一封装一个日期工具类，所有边界计算都走这一个类，避免各处算出的结果不一样。
4.3 逻辑删除和唯一索引的冲突，怎么解决
我给表都加了del_flag做逻辑删除，但这里有一个隐藏坑：如果某张表有唯一索引（比如shop_no），逻辑删除后这条记录还在表里，再次插入一个相同编号的商铺时会直接违反唯一索引约束。实际业务中商铺编号一般不会改写，但合同编号、租户编号就有可能出现"删除后重新录入"的场景。
解决办法有几个思路：一是唯一索引改为(shop_no, del_flag)这种复合唯一索引，删除时del_flag置为1，新插入时del_flag为0，组合起来不冲突；二是删除时把原编号改成带后缀的历史编号，比如HT20240001_DEL_20250614；三是干脆用物理删除+操作日志表记录变更痕迹。三种方案各有适用场景，我比较推荐第一种，简单直接，不需要额外维护历史编号字段。
4.4 事务边界：签约、改商铺状态、生成首期账单必须绑在一起
在3.1里我提过签约时要联动更新商铺状态，这里把事务边界完整展开。一次签约动作涉及三个写操作：插入合同记录、更新商铺表状态为已租并设置当前租户ID、生成第一期租金账单。这三个操作任何一个失败，其他两个都必须回滚。
用@Transactional标注Service方法时，要注意几个细节。第一，@Transactional只能作用于public方法，且通过Spring代理调用才生效，同类内部方法之间互相调用事务会失效。第二，事务默认只在抛出RuntimeException时回滚，如果代码里手动try-catch捕获了异常但没有重新抛出，事务不会回滚。这是很多项目里"数据怎么没回滚"的经典原因。第三，事务要放在Service层，不要放在Controller层，因为一个Controller方法可能调用多个Service方法，如果把事务放在Controller上，边界太粗，不利于精细控制。
4.5 答辩时导师最爱追问的几个问题
根据我带过的答辩经验，"万达商铺租赁管理系统"这类题目，导师的追问集中在这些点上：
- "两个运营人员同时签同一个商铺，怎么防止重复合同？"——答数据库唯一索引、原子校验SQL、事务回滚的三层保障。
- "租金递增是怎么实现的？第一年、第二年、第三年租金分别多少？"——把计算工具类的代码打开，现场演算一组数据。
- "商铺到期前怎么提醒？"——答定时扫描合同表、计算到期剩余天数、标记预警状态。
- "日志和删除怎么做的？"——答逻辑删除字段加操作日志表，删除不真删，保留审计线索。
- "数据库为什么用MySQL？为什么字段用decimal？"——答业务体量、精度要求、文档生态。
这些问题的答案其实都藏在项目细节里，你只要按照前面说的方式把业务逻辑真正实现了一遍，而不是照抄代跑通，答辩时就不会心虚。
5. 把代码变成论文：图表规范和测试部分的写法
5.1 论文结构怎么排，才算"像一篇管理系统论文"
管理系统类论文的结构在高校里已经形成了相对固定的范式，符合范式反而容易过盲审。我建议的章节排布是：绪论（背景、国内外现状、研究内容）、需求分析（可行性分析、功能需求、非功能需求、用例图）、系统设计（总体架构、功能模块划分、数据库设计、类设计）、系统实现（每个核心模块的实现思路、核心代码片段、界面截图）、系统测试（测试环境、测试用例表、测试结果分析）、总结与展望。
这里重点说下需求和实现的对应关系。很多学生论文里需求分析和系统实现各说各话，需求分析里写了"支持租金自动计算"，实现部分却只有一张列表页面截图。正确做法是：需求分析的每个功能点，在系统设计里都要有对应的模块，在系统实现里都要有对应的代码和截图，在测试里都要有对应的用例。这个对应关系是论文质量的重要评判维度。
5.2 架构图、ER图、时序图，画图比写代码更考功夫
论文里的图主要有三类，画法各有讲究：
架构图强调分层。SSM项目的架构图通常分四层：表现层（JSP、Controller）、业务层（Service接口与实现）、持久层（Mapper接口、Mapper XML）、数据层（MySQL）。层与层之间用箭头标注调用方向和依赖关系。画图时注意：箭头方向从Controller指向Service，再从Service指向Mapper，不要画反。
ER图强调实体关系。把商铺、租户、合同、账单四张核心表画出来，标注主键外键和一对多关系。这里可以结合的技巧是：ER图里只画实体、属性和关系，表结构细节留给数据库设计章节的文字描述。
时序图强调核心流程。建议画两到三张关键的时序图，比如"签约流程时序图""租金账单生成时序图"。时序图能直观展示方法调用顺序，大片文字说不清的内容，一张图就能搞定。
画图工具方面，PowerDesigner、Visio、draw.io、ProcessOn都可以。我个人的建议是draw.io，免费且导出的矢量图清晰度高，插入Word时不会失真。
5.3 测试部分怎么写才有说服力
很多学生的测试部分只有一张表格，写"登录功能测试通过"就完了。这是远远不够的。一份有说服力的测试报告至少要包含：
- 功能测试用例表：每个模块至少3到5条用例，要覆盖正常路径和异常路径。拿合同录入举例，正常用例是"录入一份有效合同，提示成功并生成首期账单"；异常用例是"起租日期晚于到期日期，系统拦截报错""同一商铺时间重叠，系统提示该商铺已被占用"。通过和失败的结果都要记录。
- 边界值测试：租金递增满一年、跨年账单、2月29日这种日期边界，都是可以写进测试用例的点。
- 兼容性和安全性测试简要说明：不同浏览器页面是否正常、密码是否加密存储、Session超时是否跳转登录页。这些表格写出来，论文的测试章节会充实很多。
5.4 写作时的几个注意事项
写论文时最需要避免的是大段贴代码。代码是论文的补充材料，不是正文。正确做法是贴关键代码片段加解释，解释要围绕"为什么这样设计"，而不是逐行翻译代码。比如贴租金计算工具类代码时，重点写清楚：为什么用BigDecimal、为什么年份差用ChronoUnit.YEARS、递增基数为什么是合同生效日而不是自然年。
另外一个容易踩的坑是术语混用。比如"Spring"和"SpringMVC"、"MyBatis"和"MyBatis-Plus"，这些概念必须区分清楚。你用的是SSM三件套还是加入了MyBatis-Plus扩展，论文里要明确说明。很多学生项目里其实已经用了MyBatis-Plus的BaseMapper，但论文里还只写MyBatis，这就是明显的技术术语不严谨。
数据方面也要严谨。系统里的测试数据建议多造一些有业务意义的商铺名和租户名，楼层分布合理、租金有梯度。答辩演示时，随便几条"测试1""测试2"数据会让系统显得很假，而一套看起来像真实商场的模拟数据会明显提升演示效果。
写在最后：做这类系统最值得投入的地方
我自己做这类项目的体会是：商铺租赁管理系统的技术难点并不在于某个框架的高阶用法，而在于你能不能把业务规则真正想清楚、做闭环。合同、账单、商铺状态、租户信息之间是彼此咬合的，一处状态不同步，后面查问题就是连锁的。所以花在建表设计、状态联动、事务边界上的时间，永远是这个项目性价比最高的投入。
如果在做好基础功能后还有余力，建议往两个方向扩展：一是引入工作流概念，把合同的审批、退租流程做得更像真实业务；二是做一个基于ECharts的运营驾驶舱，把租金收入和空置率做成可视化大屏。这两个方向都不难，但对论文深度的提升非常明显。
希望这篇经验梳理对正在做这个题目的同学有帮助。做系统是这样，认认真真把每一个业务闭环跑通，答辩时自然有话讲，论文自然有内容写。
