概要设计说明书怎么读：角色、流程与库表实战解析

简介面向社团宣传管理平台的概要设计说明书清晰定义了项目整体架构与核心功能为后续详细设计和编码提供明确指导。文档由程赵旭、王成龙、岳凤彬、胡苏齐、王文通合作完成覆盖2020年5月至7月从启动到结束的完整设计过程。内容从引言、任务概述切入重点给出前台展示与后台管理的处理流程包括操作流程及数据增加、修改、删除流程同时说明总体结构、功能分配含管理员、社长与社员角色、数据结构设计和Web框架、数据库、身份验证等软件插件选型建议适合正在规划社团管理类平台的高校项目组或开发者参考。资源为一份Word文档实际为docx格式大小仅511KB便于直接打开阅读或二次编辑。文档章节完整、条理清晰可作为社团管理类课程设计与毕业设计的起步模板已有八十人学习浏览。1. 概要设计说明书怎么读角色、流程与库表骨架拿到这份二十多页的概要设计说明书我先在浏览器里快速扫目录直接定位到“总体设计”和“数据结构设计”两节。社团宣传管理平台这类高校社团系统业务边界其实很清晰前台展示社团信息后台让管理员、社长、社员三类角色各自维护自己的数据。文档锁定的技术栈是 JSP 前台页面 DAO 层访问数据库 SQL Server 2008 Tomcat 本地服务器属于最经典也最好复现的 Java Web 分层路线没有中间件、没有微服务依赖少非常适合照着做课程设计或者毕业设计。这篇笔记我会把这份文档里能直接落地的模块划分、流程约束、接口参数和数据表定义逐一拆开最后给出从 ER 图到建表语句的实操路径让你拿到文档就能动手。2. 处理流程拆解从操作入口到增删改的三条路径处理流程是概要设计里最先体现系统玩法的地方。文档明确给出了操作、数据增加、数据修改、数据删除四段流程我按三段拆开讲。先解释一个关键点这套平台用的登录模型是“前台和后台分离”。普通社员和社长在前台右侧功能栏登录超级管理员走导航栏的后台超链接进入独立登录页。为什么要分因为管理员需要操作的界面和普通用户完全不一样强行混在一个登录入口里代码里就要多写一套角色路由反而增加出错面。2.1 操作流程一个前台、两种登录入口的设计意图流程细节是这样的用户打开社团网站前台展示界面右侧功能栏有登录框输入账号密码后身份按“社团成员”或“社长”处理。管理员则要点击导航栏的后台超链接进入后台登录界面输入管理员账号密码。密码经过 DAO 层与数据库比对匹配则跳转到后台管理界面不匹配就弹出一个 Alert 警告框提示“密码与账户不匹配”。从文档描述可以看到整套分层思路JSP 负责展示DAO 层负责 SQLServlet 或 Controller 负责调度数据库里存的是用户表和角色字段。这里有一个容易被新手忽略的设计点管理员登录入口独立意味着后台登录页不需要承载“记住我、验证码、找回密码”等前台功能可以单独控制安全策略比如后台登录失败三次就锁账号这是我在类似项目里的常见做法。针对“操作流程”的落地步骤整理为先建用户表 UserInfo包含登录账号、登录密码、用户类型字段。前台登录表单提交到 LoginServlet按普通用户流程处理。后台登录表单提交到 AdminLoginServlet单独处理管理员校验。DAO 层分别提供 findUserByAccount 和 findAdminByAccount 两个查询方法。密码错误时返回 JSON 或 request 属性JSP 端弹出 Alert。参数层面需要注意用户类型字段建议用 char(1) 或 tinyint例如 1管理员、2社长、3社员不要用字符串描述否则 SQL 查询和下拉框都要跟着写映射。2.2 数据增加流程自动编号与表单校验的职责边界增加流程的约束写得很清楚每条信息都有一个编号编号字段不可人为编写系统自动给出其他信息由用户填写填写的格式和正确性由系统判断输入通过表单校验后才保存到数据库非法输入会报错且无法提交。很多人看到这里会觉得“编号自动生成”是理所当然的但在 JSP 时代的项目里这恰恰是最容易翻车的地方。常见写法是页面表单里放一个编号输入框用户自己填或者 JS 里生成一串时间戳当编号导致数据库主键混乱。正确做法是数据库表设计时就给编号字段设置 identity(1,1)也就是自增主键JSP 页面完全不渲染这个字段。落地步骤可以这样建表时写明编号字段为 INT IDENTITY(1,1) PRIMARY KEY。增加数据的 JSP 表单只暴露需要用户填写的业务字段。前端 JS 负责第一层格式校验比如时间格式、数字范围。后端 DAO 层做第二层校验判断活动时间是否晚于当前时间、社团类型是否在枚举范围内。校验通过执行 INSERT失败则返回提示信息并保留用户已填内容。这里要特别说一句前端校验只保证体验后端校验才保证数据安全。文档里说的“系统进行判断”我一般会做成前后端双重判断避免有人绕过页面直接构造请求。2.3 数据修改与删除流程JSP 修改页和 confirm 确认框的配合修改流程管理员或社长在后台界面选中要修改的信息点击“修改”超链接跳转到另一个 JSP 界面修改后提交格式仍要与后台代码规定一致否则提示重新修改。删除流程点击“删除”超链接弹出 confirm 确认框显示“是否真的要删除”点击确定后删除并更新数据库。这里有一个值得记录的细节修改操作使用超链接跳转新 JSP说明当时的实现没有走 AJAX 弹窗而是最传统的“列表页带 ID 拼链接”方案。对应到代码上列表里每一行操作的 URL 大概是editInfo.jsp?id101 deleteInfo?id101这种方案的好处是简单直接、刷新后状态清晰缺点是如果编辑页被直接打开且 ID 不存在需要额外做空值判断。我在复现时会加一个判断逻辑JSP 页面顶部先查记录查不到就重定向回列表页并提示“记录已被删除或不存在”。删除流程里 confirm 只解决了“确认”这一步真正的删除动作要在点击“确定”后发起。我建议把删除做成逻辑删除而不是物理删除加一个 delete_flag 字段列表查询默认过滤 delete_flag0。原因很实际社团活动删错了没法恢复尤其是活动参与记录和日志可能关联了其他表。3. 总体结构与功能分配把三大角色映射成模块树总体设计这一章最难的地方不是画模块图而是把文档里散落的功能词条整理成可执行的模块清单。原文的模块树信息来自一张系统功能模块图和三段角色功能描述我按自己的习惯重新归类方便后续做数据库权限和菜单设计。3.1 总体结构从功能模块树到子系统划分文档将系统划分为多个模块模块再进一步细分。从功能描述里能明显看到几组模块系统管理用户、注册会员、社长注册、社团信息信息管理和信息查询、社团活动活动管理和活动审核、新闻制度、日程表、社团相册、社团成员、日志、个人资料、社团聚餐、收藏。这个模块划分基本等同于菜单树。复现时建议把菜单表 menu 和角色表关联动态渲染左侧导航而不是在 JSP 里写死。对应到概要设计我一般会先整理一张“模块清单表”列里写模块名、归属角色、是否涉及审核、对应数据表这样到详细设计阶段就不会漏。3.2 功能分配三类角色的权限矩阵管理员的核心职责是“管理平台”包括系统用户管理、注册会员管理、社长注册管理、社团信息查询、社团活动管理、社团活动审核、新闻和制度管理、日程表信息管理、社团相册管理、系统管理。社长负责“管自己的社团”包括个人资料、社团信息、社团相册、社团成员、日志、日程表、社团活动、社团聚餐。社员则是“查看和参与”包括个人资料、我的社团、社团相册、社团信息、社团聚餐的查询日志查询与管理以及收藏管理。把这段变成一个功能权限矩阵功能模块管理员社长社员系统用户管理可管理不可见不可见社长注册管理可管理不可见不可见注册会员管理可管理不可见不可见社团信息管理可管理可管理本社可查询社团活动管理可管理、可审核可发布、可管理可查看新闻和制度管理可管理可查看可查看日程表信息管理可管理可管理本社可查看社团相册管理可管理可管理本社可查询社团成员管理可管理可管理本社不可见日志管理可管理可管理本社可查询社团聚餐管理可管理可管理本社可查询收藏管理不可见不可见可管理自己这张矩阵的价值在于后续详细设计阶段每个 Controller 方法和 DAO 查询都能从这张表里反推出权限判断条件不需要再猜。3.3 分配原则数据归属决定谁能动、谁能看从矩阵能看出一个规律社长只能管理“本社”数据社员只能“查询”和“管理自己的收藏和个人资料”管理员拥有全部权限。这个“数据归属”概念直接决定了 SQL 怎么写。比如社长查询成员列表SQL 必须带 club_id 条件社员查询日志只能看到自己参与社团的日志或自己的日志收藏管理只操作自己的收藏记录。我在复现时会把归属字段统一命名为主表的 club_id 字段社长登录后 session 里存 club_id所有带归属的数据查询都拼上这个条件。如果不这么做就会出现“社长 A 删掉了社长 B 的社团活动”这种低级事故这在答辩演示时是非常尴尬的。4. 接口设计与运行环境Tomcat、JDBC、SQL Server 的取舍接口设计章节通常最枯燥但恰恰是复现时依赖最多的信息。文档把接口拆成外部接口和内部接口两大部分外部接口又分用户界面、软件接口、硬件接口内部接口直指数据库连接。4.1 内部接口JDBC 连接 SQL Server 的配置要点内部接口只有一句话与 SQL Server 数据库通过 JDBC 接口进行连接。这句话背后的配置细节值得展开。以 SQL Server 2008 为例JDBC 驱动类名、URL 格式、端口和认证方式都是可以确定的。配置项参数值说明驱动类名com.microsoft.sqlserver.jdbc.SQLServerDriver对应 sqljdbc4.jarJDBC URLjdbc:sqlserver://localhost:1433;DatabaseNameclub_platform数据库名称按实际建库名替换默认端口1433SQL Server 默认端口认证方式混合认证或 Windows 认证开发环境常用 sql 账号加密码连接池DBCP 或 C3P0避免每次操作新建连接如果项目里已经有 DAO 层最稳妥的连接获取方式是通过配置文件加载例如 db.properties。我一般在测试连接时会先用命令行验证服务器端口通不通再写 JDBC 代码否则容易把“写的代码有问题”和“SQL Server 服务没启动”混在一起排查。4.2 外部接口界面、软件与硬件边界的说明用户界面部分按 Windows 应用软件规范设计风格简约采用对话框交互。这个描述可以理解成系统面向的是纯浏览器使用场景页面布局参考桌面软件习惯所有操作窗口都用对话框完成。对应到前端技术上就是表单页和列表页分离弹窗提示用 alert、confirm。软件接口写明本软件采用 Tomcat 本地服务器运行于 Windows 2000 以上的操作系统。这说明部署形态是单机或实验室服务器而不是云部署。复现时我建议用 JDK 8 Tomcat 8.5 SQL Server 2008 的组合兼容性比 JDK 11 更高。硬件接口要求 Intel 或其他系列微型计算机内存 16G 以上硬盘 512G 以上这是在写需求说明书时定的下限实际跑这个项目 4G 内存也能跑但用 16G 内存机器做开发是合理的因为还要跑 IDE、数据库和 Tomcat。4.3 运行环境与部署边界Tomcat 本地服务器的定位把运行环境整理成一张可直接照做的参数表项目要求操作系统Windows 2000 以上Web 服务器Tomcat 本地服务器数据库SQL Server 2008连接方式JDBC内存16G 以上硬盘512G 以上一个容易被忽略的点是Tomcat 本地服务器还要考虑端口占用。默认 8080 端口如果被其他进程占用Tomcat 启动会报端口被占用错误。我在第一次部署时会先调整 server.xml 里的 Connector port或者用 netstat -ano 检查端口。这些在概要设计里不会写但属于实际环境里的必踩项。5. 数据结构设计与常见问题5 张核心表的字段定义和五个坑数据结构设计是这份文档里信息密度最高的部分它直接给出了逻辑模型和物理模型的骨架。我在这章先把关系模型讲清楚再补全 5 张核心表的字段建议最后给一份高频坑排查记录。5.1 逻辑结构关系模型的选择与查询代价文档提到系统采用分支关系模型以数学概率为基础。这里“分支关系模型”实际是指关系模型也就是以二维表、行、列来组织数据基于关系代数和集合论。关系模型最大的优点是概念简单、表达清晰存取路径对用户透明缺点是查询效率比不上专门优化的非关系模型尤其在多表关联的时候。在这个系统里关系模型要表达的实体关系很典型社团由社长建立一个社长对应一个或多个社团学生提交申请记录申请某个社团管理员管理所有社团和用户活动、新闻、留言、相册分别挂在社团或用户下。落到逻辑设计上关键是要把“登录账号”“社长”“管理员”“普通用户”统一在一个身份体系里通过用户类型区分而不是给每种身份单独建表。如果给管理员、社长、社员各建一张表光登录校验就要写三套 DAO后续扩展新角色也麻烦。5.2 物理结构5 张核心表的字段建议文档在物理结构设计里列出了 5 张表分别是社团申请信息applysid、网站新闻articleid、留言信息bbsid、社团信息cinfoid、活动信息activityid。括号内可以作为主键字段名延续使用我按这个命名给了每张表的建议字段。社团申请信息 applysid字段类型说明applysidint identity申请编号主键user_accountvarchar(30)申请人登录账号club_namevarchar(50)申请加入的社团名称apply_timedatetime申请时间audit_statustinyint0 待审核、1 通过、2 驳回remarkvarchar(200)备注网站新闻 articleid字段类型说明articleidint identity新闻编号主键titlevarchar(100)标题contenttext正文publishervarchar(30)发布人账号publish_timedatetime发布时间categoryvarchar(20)新闻或制度分类留言信息 bbsid字段类型说明bbsidint identity留言编号主键user_accountvarchar(30)留言人账号contentvarchar(500)留言内容replyvarchar(500)管理员回复create_timedatetime留言时间社团信息 cinfoid字段类型说明cinfoidint identity社团编号主键club_namevarchar(50)社团名称club_typevarchar(20)社团类型foundervarchar(30)社长账号establish_timedatetime建立时间descriptionvarchar(1000)社团简介活动信息 activityid字段类型说明activityidint identity活动编号主键club_namevarchar(50)所属社团名称activity_titlevarchar(100)活动标题locationvarchar(100)活动地点activity_timedatetime活动时间contenttext活动内容statustinyint0 待审核、1 已发布、2 已结束这些字段是对文档物理结构的补全考虑到文档只给了主键标识字段设计部分我按这类社团系统最常见的信息维度来补。实际建库时可以根据需求说明书再增删。5.3 高频坑排查记录现象、原因、解决三步走第一坑新增数据时编号字段被手动填写。现象是管理员在表单里看到“编号”输入框填了编号提交后报主键冲突或重复。原因是没有把编号设计成数据库自增主键页面渲染出来了本不该出现的字段。解决方法是建表时给编号字段加 identity(1,1)JSP 表单不渲染编号服务端忽略任何传入的编号参数。第二坑修改数据后前端显示的还是旧值。现象是后台修改社团信息成功前台页面没有更新。原因是浏览器缓存或查询没有重新查库也可能事务没提交就关闭了连接。解决方法是修改操作后用重定向跳回列表页而不是转发JSP 列表查询每次都从 DAO 取最新数据同时确认事务在 commit 后再 close。第三坑删除重要社团信息后无法恢复。现象是误删了活动记录连参与记录也没了。原因是删除用了物理 DELETE没有做逻辑删除。解决办法是给相关表增加 delete_flag 字段删除操作执行 UPDATE 而不是 DELETE列表查询默认过滤 delete_flag0。第四坑JDBC 连接报“不支持此服务器版本”。现象是启动 Tomcat 后第一次查询就抛 SQLServerException。原因是驱动版本与 SQL Server 2008 不匹配或者 JDBC URL 里端口和数据库名写错。解决方法是换用 sqljdbc4.jar确认 URL 为 jdbc:sqlserver://localhost:1433;DatabaseNameclub_platformSQL Server 的 TCP/IP 协议要在服务端开启。第五坑社长能删其他社团的活动。现象是两名社长登录后都能在活动列表里看到全部社团的记录。原因是列表查询没有按 club_id 过滤数据归属。解决方法是社长登录后把 club_id 存入 session所有业务查询都带上 club_id 条件删除和修改操作在 DAO 层再做一次归属校验。6. 从概要设计落地建表脚本三个值得保留的习惯把概要设计变成建表脚本是体力活靠的不是临场发挥而是几个固定习惯。第一个习惯是先把角色字段和归属字段定死用户表必须有用户类型业务表必须有 club_id否则权限判断一改再改。第二个习惯是编号字段全部用 identity 自增让数据库保证唯一应用层只做业务校验。第三个习惯是时间字段统一用 datetime状态字段用 tinyint并提前约定每一档数值的含义。以用户表为例按 SQL Server 2008 语法可以这样建USE club_platform; GO CREATE TABLE dbo.UserInfo ( userid INT IDENTITY(1,1) PRIMARY KEY, login_account VARCHAR(30) NOT NULL UNIQUE, login_password VARCHAR(64) NOT NULL, user_type TINYINT NOT NULL DEFAULT 3, -- 1管理员 2社长 3社员 real_name VARCHAR(30) NULL, club_id INT NULL, delete_flag TINYINT NOT NULL DEFAULT 0, create_time DATETIME NOT NULL DEFAULT GETDATE() ); GO这段脚本把三类角色统一在 user_type 字段里管理员不需要挂社团编号社长和社员用 club_id 绑定归属。login_account 加唯一约束防止重复注册delete_flag 为逻辑删除留了后路。社团表和活动表用同样的思路建外键关联 club_id 或 founder不要把业务归属全部压到一张表上。从那以后我每次拿到设计文档都会先做两张纸角色功能矩阵一页数据表清单一页。前者用来对权限方法后者用来对主键、外键和归属字段。两张纸填完再动工建库返工率低很多。希望帮到你。本文还有配套的精品资源点击获取