简介：这份停车场管理系统软件工程课程设计报告书面向软件工程、计算机及相关专业课程设计阶段的学生，围绕车辆信息记录、车位动态分配、停车费用结算、车位使用状况查询与退出登录等核心功能，给出从需求分析到编码测试的完整文档范例。压缩包内仅含1个doc文件，体积约1.7MB，正文按引言、需求分析、概要设计、详细设计、测试分析、总结与参考文献组织，并附课程设计任务书与目录，便于对照章节结构整理报告。已有4750人学习下载，说明该选题在同类课程设计中具有较高参考热度。内容还交代了Windows XP平台、Microsoft VC++6.0开发、Visio 2007建模与红蜻蜓抓图等工具链，以及结构体、菜单函数、车辆进入与离开、初始化、计费模块的设计思路和测试用例，可帮助读者理解如何把软件工程方法落实到一个小型管理系统，并借鉴其文档表述、模块划分与调试记录。

1. 一份停车场管理系统课程设计报告书，为什么还值得拆

很多人的硬盘里都躺着几份当年交上去的文档，名字类似「停车场管理系统软件工程课程设计报告书.doc」，打开是需求分析、概要设计、详细设计、测试截图加附录源码的老结构。多数人扫两眼就关掉，觉得平台老、代码短、没什么可看。可把这份报告书当成「软件工程文档的最小可用样例」来读，价值反而清楚：它完整走了一遍从任务书约束、需求条目化、概要结构图、详细函数设计，到测试用例截图、源码附录的链路，配套实现只用结构体加数组，没有任何框架依赖，二十分钟就能在自己的机器上跑起来。适合三类人：正在赶课程设计、需要一份能照着填的文档骨架的在校生；想给学生讲清栈和队列到底解决什么业务问题的讲师；以及手上有个小工具要写却懒得重新搭结构的开发者。下面按「文档骨架、数据建模、函数落地、踩坑、验证」逐层拆。

2. 报告书骨架：从需求分析到测试分析的六段式链路

这套文档的章节顺序本身就是一份可复用的模板：引言、需求分析、概要设计、详细设计、测试分析、总结，最后挂源码附录。现在查资料靠互联网一搜一大把，但多数是片段，缺的恰恰是这种「一节接一节、每节都有交付物」的连续性。真按它填一遍，你会发现卡人的不是打字，而是每一节该写到什么粒度。

2.1 任务书与技术参数：先锁定平台与边界

报告书开头的任务书里有一张技术参数表，看着像走过场，实际上它决定了后面所有代码能写成什么样：

最容易翻车的是第二行。VC++6.0 的编译器不接受 C99 的「变量随用随声明」，你在for里写for (int i = 0; ...)直接编译报错。所以代码统一按块首声明来写：

/* 按 C89 约束：所有局部变量在函数体开头集中声明 */ void jinru(void) { int i; /* 循环变量，扫描车位 */ int a; /* 车辆次序号，用户输入 */ int h = 0; /* 已占用车位计数 */ int slot = -1; /* 第一个空闲车位下标，-1 表示没有 */ printf("请输入该车次序号(从 0 开始): "); scanf("%d", &a); /* 后续逻辑见 4.1 节 */ }

这里h和slot两个变量必须分开：h只回答「满没满」，slot回答「停哪」。报告书原代码把两者合成一个h用，是后面一系列错位的源头，第 5 章会细说。参数说明也顺带定死：N是停车场容量、M是便道容量、D是小时费率、CIXUHAO是车辆次序号上限，四个宏在文件头部集中定义，改配置只改这四行。

2.2 需求分析的写法：把「停车难」翻译成可测条目

引言和需求分析这两章，最容易写成空话。报告书里的「随着经济发展、买车的人越来越多」属于背景铺垫，占半页就够，真正要交付的是 2.3 节那几条功能。合格的写法是每条功能都能对应一个可执行的验收动作：

把「解决车辆停放难、乱收费」这种目标句，落到「3 小时收 3.6 元」这种能截图的结果上，需求分析这一章才算写完。顺带说一句，功能清单里的「查看车位使用状况」在原代码里其实没有独立函数，是散在进入函数里的计数打印，补文档的时候要么补一个show()，要么在需求里改成「进入时回显剩余车位数」，别让需求和实现对不上。

2.3 概要设计与详细设计的分界线

这两章最常被写重。判断标准只有一条：概要设计只画「有什么、怎么连」，详细设计才写「函数叫什么、参数是什么、内部怎么走」。

概要设计交付两张图。第一张是基本处理流程图，主干就四步：初始化 → 车辆到达 → 判断场内是否已满 → 满则进便道、不满则进场；离开分支则是判断场内是否有车、有则计时计费、该车之后的车辆退出让路、离开后便道首车进场。第二张是总体结构图，把系统拆成五个模块：车辆到达信息、车位使用状况、车辆离开信息、费用计算、退出，每个模块下面挂它维护的数据项。

详细设计才落到函数。这份报告书的详细设计章列了四个函数：menu()菜单、chushi()初始化、jinru()进入、likai()离开，加上main()只调menu()。这个拆法是合理的，因为四个函数各自对应一个菜单项，职责边界清楚。写详细设计时每个函数给三样东西：函数签名、局部变量表、处理步骤编号。比如likai()要写清「先定位目标车位、再把其后的车辆依次弹出到临时栈、弹出目标车、最后把临时栈压回」，这四步在概要设计里是不写的。

有个小技巧：详细设计写完，回头核对一遍每个函数是否只做一件事。原报告书的likai()同时干了计费、让路、便道进场三件事，测试的时候一旦数字不对，根本分不清是哪一段出的问题。拆成calc_fee()、pop_out()、queue_in()三个小函数，调试成本立刻降下来。

2.4 测试分析章节怎么留证据

测试章不是把程序跑一遍贴图，而是「输入 → 预期 → 实际」三列对得上。这份报告书列了五个用例：主菜单、初始化、车辆进入、车辆离开并收费、便道有车时的离开。每个用例配一张控制台截图，截图里要能看到输入值和输出值，不能只截一个菜单界面。

补两个它没覆盖但必须测的边界：停车场刚好停满第 N 辆车时再进一辆，看是否正确提示进便道；以及便道上有车等待时，场内车辆离开后便道首车是否按次序进场。这两个场景是课程设计答辩最常被追问的，提前截图存好，比临场解释省事得多。

3. 用栈和队列建模：结构体和宏定义怎么定

把业务场景翻译成数据结构，是这份报告书里最值钱的一段。它没有一上来写代码，而是先用一段文字把停车场的物理规则描述清楚，再顺势指出「单条序列、后进先出」对应栈、「门口排队、先进先出」对应队列。这个推导过程写进概要设计，比直接甩一句「用栈实现」有说服力得多。

3.1 为什么停车场是栈、便道是队列

报告书 1.2 节把规则写得很细：停车场只有一个大门，车辆按到达早晚从最里面向门口依次停放；某辆车要开走时，在它之后进场的车必须先退出来让路，等它开出后再按原次序进场。这句话翻译过来就是「最后进来的最先出去」，标准 LIFO，栈。

便道的规则是另一句：停车场满了，后来的车在门外便道等待，一旦场内有车开走，便道上的第一辆车进场；便道上的车如果没进场就要走，允许直接离开且不收费，等待次序保持不变。这是标准 FIFO，队列。

拿三辆车走一遍最直观。0 号车先进，停在最里；1 号车其次；2 号车最后进，停在最靠近大门的位置。此时 0 号车要走，它前面压着 1 号和 2 号，必须先把 2 号、1 号依次退到临时栈，0 号开出、结算，再把 1 号、2 号按原次序压回。如果这时便道上排着 3 号车，0 号一走空出一个位，3 号车进场。整个过程用两个数组加一个临时数组就能模拟，不需要任何动态内存。

3.2 三个结构体与四个宏：字段与容量的取舍

#include <stdio.h> #include <stdlib.h> #define N 100 /* 停车场车位数，可改 */ #define M 100 /* 便道车位数，可改 */ #define D 1.2 /* 每小时停车费(元)，可改 */ #define CIXUHAO 1000 /* 车辆次序号上限，可改 */ /* 车辆信息：一辆车一条记录 */ struct car { int car_num; /* 次序号，同时作是否有效的标记 */ int car_arr; /* 进场时刻，24 小时整点 */ int car_lef; /* 离场时刻，24 小时整点 */ int car_stay; /* 当前所在车位下标 */ } car[CIXUHAO]; /* 场内车位：1 有车，0 空 */ struct changnei { int neikong; } chn[N]; /* 便道车位：1 有车等待，0 空 */ struct changwai { int waikong; } chw[M];

三个结构体各有分工。struct car按次序号索引，回答「这辆车什么时候来的、停哪」；chn按车位下标索引，回答「这个位子上有没有车」；chw按便道位置索引，回答「门口排到第几个了」。两套索引必须能互相查到，所以car[i].car_stay存车位号，chn[k].neikong存占用状态，缺一不可。

四个宏的取值也有讲究。N和M给 100，是为了让数组开在静态区、不碰栈空间，同时演示时不用等太久就能填满；D用1.2浮点，是因为计费要出小数，用int会把 0.6 元抹掉；CIXUHAO给 1000，是给次序号留足余量，实际一天进不了这么多车，但数组开小了，测试时随手输个 200 就越界。

提示：N、M改成 3 和 2 再跑一遍，几分钟就能把「满场」「便道排队」两个分支全触发出来，比用 100 跑半天高效。

3.3 初始化：数组边界和清零方式

void chushi(void) { int i, j; for (i = 0; i < N; i++) { /* 注意是 < N，不是 <= N-1 */ chn[i].neikong = 0; } for (j = 0; j < M; j++) { /* 便道用 j，不要写成 i */ chw[j].waikong = 0; } printf("\n\t\t已初始化，场内 %d 位、便道 %d 位全部清空\n", N, M); menu(); /* 处理完回菜单 */ }

三个细节决定这段能不能用。第一，循环上界写< N，因为chn定义时就是chn[N]，合法下标 0 到 N-1，写成i <= N-1虽然结果一样，但和chn[N-1]这种「数组开小一位」的写法混在一起时极易出错，第 5 章会展开。第二，两个循环的变量必须分开，chw的下标用j而不是i。第三，清零只清状态位，不清car数组，因为车辆记录按次序号累积，初始化指的是「新的一天，车位重来」，不是「历史记录抹掉」。

如果你想让初始化更彻底，可以顺手把car[i].car_stay置 -1，表示「未分配车位」。这样后面判断某辆车是否在场内，只看car_stay >= 0就够了，不用再反查chn。

3.4 菜单驱动的主控结构

void menu(void) { int n, w; do { printf("\n\t\t************** MENU **************\n"); printf("\t\t\t 1. 初始化\n"); printf("\t\t\t 2. 有车进入\n"); printf("\t\t\t 3. 有车离开\n"); printf("\t\t\t 4. 退出\n"); printf("\t\t**********************************\n"); printf("请选择(1-4): "); scanf("%d", &n); if (n < 1 || n > 4) { /* 非法输入，重来 */ w = 1; getchar(); /* 吃掉换行，防止死循环 */ } else { w = 0; } } while (w == 1); switch (n) { case 1: chushi(); break; case 2: jinru(); break; case 3: likai(); break; case 4: exit(0); break; } }

主控只有main()里一行menu();，所有功能函数执行完再回调menu()，形成闭环。do-while负责输入校验，switch负责分发，两者职责不重叠。getchar()那一行别省，输入字母时scanf会失败并把字符留在缓冲区，不清理就会反复弹菜单，看起来像死循环。

4. 车辆进入、离开与计费：四个函数的逐段落地

这一章是整份报告书的实现主体。四个函数里，chushi()最简单，menu()只是分发，真正有逻辑的是jinru()和likai()。原报告书的这两段代码思路对，但细节上有几处会直接导致结果错误，下面按「能跑通」的标准重写一遍，并说明每一处为什么这么改。

4.1 jinru()：车位分配与满场判断

void jinru(void) { int i, a, h = 0, slot = -1; printf("请输入该车次序号(从 0 开始): "); scanf("%d", &a); if (a < 0 || a >= CIXUHAO) { printf("次序号越界，请重新输入\n"); menu(); return; } /* 一趟扫描同时算出「占了多少」和「第一个空位在哪」 */ for (i = 0; i < N; i++) { if (chn[i].neikong == 1) { h++; } else if (slot == -1) { slot = i; } } if (h == N) { /* 场内满，进便道排队 */ printf("停车场已满，请停在便道\n"); chw[h - N].waikong = 1; /* 简化：便道位置按顺序取 */ car[a].car_stay = -1; } else { car[a].car_num = 1; car[a].car_stay = slot; chn[slot].neikong = 1; printf("该车停在停车场第 %d 号位(从 0 开始)\n", slot); printf("请输入进场时刻(24 小时整点): "); scanf("%d", &car[a].car_arr); } menu(); }

关键改动在slot。原代码直接拿「已占用数量」当中位号，在车位连续、没有车离开过的前提下碰巧成立；一旦中间有车开走，出现空洞，h就不再等于第一个空位的下标，车会被分配到已经被占的位置上，后面计费、让路全乱。改成扫描时顺手记录第一个neikong == 0的下标，逻辑才稳。

参数上，a是用户输入的次序号，同时充当car数组下标，所以必须先做范围校验再使用。h只用于判断满场，slot只用于分配，两个变量各管一件事。便道那段用了h - N作为便道下标，属于极简写法，只在场内满、便道从 0 开始排队时成立；要支持多辆车排队，得换成 4.4 节的 head/tail 版本。

4.2 likai()：让路逻辑必须用临时栈

void likai(void) { int i, k, idx, time; int temp[N], top = -1; /* 临时栈：存被请出场的车位号 */ double fee; printf("请输入离开车辆次序号: "); scanf("%d", &i); if (i < 0 || i >= CIXUHAO || car[i].car_num != 1 || car[i].car_stay < 0) { printf("该车不在场内，请核对次序号\n"); menu(); return; } idx = car[i].car_stay; /* 第一步：把 idx 之后的车辆依次弹出，压入临时栈 */ for (k = idx + 1; k < N; k++) { if (chn[k].neikong == 1) { temp[++top] = k; chn[k].neikong = 0; } } /* 第二步：目标车离场，结算 */ chn[idx].neikong = 0; car[i].car_stay = -1; printf("请输入离场时刻(24 小时整点): "); scanf("%d", &car[i].car_lef); time = car[i].car_lef - car[i].car_arr; if (time < 0) time += 24; /* 跨零点补一天 */ fee = D * time; printf("次序号 %d 的车停留 %d 小时，应收费 %.2f 元\n", i, time, fee); /* 第三步：临时栈里的车按原次序压回 */ while (top >= 0) { k = temp[top--]; chn[k].neikong = 1; } /* 第四步：便道首车进场 */ printf("便道上现在有车吗？(1 有 / 2 没有): "); scanf("%d", &k); if (k == 1) { printf("请输入便道首车的次序号: "); scanf("%d", &k); printf("请输入该车进场时刻: "); scanf("%d", &car[k].car_arr); car[k].car_num = 1; car[k].car_stay = idx; /* 占用刚空出的位 */ chn[idx].neikong = 1; } menu(); }

这段的骨架就是栈的弹出与压回，临时数组temp加栈顶指针top，不涉及任何库函数。三处要留意：top初始为-1表示空栈；压入用temp[++top]、弹出用temp[top--]，顺序别反；while (top >= 0)而不是> 0，否则栈底那辆车永远回不去。

计费部分写成time < 0就+24，处理的是「晚上 22 点进场、次日 6 点离场」这种情况，不补这一天会算出负数和负费用。输出用%.2f，把1.2 × 3 = 3.5999...收成3.60，截图里好看也好核对。

4.3 计费公式与时间口径

计费本身只有一行fee = D * (lef - arr)，真正容易出问题的是时间口径。报告书在参数里写的是「24 小时整点计时」，意味着进场和离场都只精确到小时，不做分钟。这带来两个必须提前约定的规则：

第四行是血泪经验。只按「小于零就加 24」处理，用户把进场 6 点、离场 5 点误输成进场 6 点、离场 23 点，程序会算成 17 小时，费用翻几倍还查不出原因。加一条绝对值判断，把明显不合理的输入挡在计费之前，比事后对账省事得多。

4.4 便道车辆进场与次序保持

原代码处理便道用的是「问一句有没有车、再让用户手输次序号」，这在演示时够用，但回答不了「便道上排了三辆车，谁先走」这个问题。要让次序真正成立，得给便道加两个游标：

int head = 0; /* 便道队首，下一个进场的位置 */ int tail = 0; /* 便道队尾，下一个排队的位置 */ /* 入场排队 */ if (head == tail) { /* 队列空 */ chw[tail].waikong = 1; } else { chw[tail].waikong = 1; } tail = (tail + 1) % M; /* 循环队列，防越界 */ /* 有车离场后，队首进场 */ if (head != tail) { chw[head].waikong = 0; head = (head + 1) % M; }

head和tail相等表示队空，tail前进一位表示入队，head前进一位表示出队，% M让下标在 0 到 M-1 之间循环，便道排满时不会把数组撑爆。判断队满的条件是(tail + 1) % M == head，留一个空位区分空和满，这是循环队列的标准做法。

把这段接进jinru()的满场分支和likai()的第四步，便道就从「用户口头报数」变成了真正的队列。测试时连续让 5 辆车在满场状态下排队，再依次放 3 辆车离场，观察进场顺序是不是 1、2、3，一眼就能看出队列有没有写对。

5. 避坑与排查：原代码里五处会直接翻车的地方

这份报告书的附录源码，思路是对的，但有几处细节错误，直接编译运行会得到很奇怪的结果。下面五条都是照着原样敲进去必然踩到的，按「现象 → 原因 → 解决」列出来。

5.1 数组开小一位，循环却按满位跑

现象：程序偶尔崩溃，或者某个车位的状态莫名其妙变成别的值，重跑一次又不复现。

原因：结构体数组声明成chn[N-1]，合法下标是 0 到 N-2，但循环里写的是for (i = 0; i <= N - 1; i++)，最后一次访问chn[N-1]已经越界。越界写不保证立刻报错，它可能覆盖相邻变量，表现出来就是随机的。

解决：数组按容量开，循环按< 容量写，两边对齐：chn[N]配for (i = 0; i < N; i++)。改完把N调到 3，用调试器单步看i的每一次取值，确认最后一次是 2 而不是 3。

5.2 分号多一个，整条判断失效

现象：不管车位有没有被占，计数结果永远是 0，满场判断永远不成立。

原因：if (chn[i].neikong == 0);后面多了一个分号。这在语法上等于「如果条件成立，执行一个空语句」，后面的h++就变成了无条件执行或者根本不执行，判断形同虚设。这类错误编译器只给警告，不给错误，很容易漏掉。

解决：删掉分号，把if和它的语句体写成两行并保持缩进；编译时把警告级别调高，VC++6.0 里在 Project Settings 的 C/C++ 页把 Warning Level 设成 Level 3 以上，这类空语句会提示出来。

5.3 便道清零用错了循环变量

现象：初始化之后，便道状态没被清干净，或者场内状态被重复清了一遍。

原因：两个循环共用变量i，第二个循环本该写chw[j].waikong = 0，实际写成了chw[i].waikong = 0。i此时已经等于 N，chw[N]越界，而chw的合法范围是 0 到 M-1，真正的便道元素一个都没清到。

解决：两个循环各用各的变量，场内用i、便道用j，循环体里不要出现另一个循环的变量名。养成习惯：嵌套或并列循环，变量名必须不同，编译器不会替你检查这个。

5.4 「让后面的车先退出去」只写在注释里

现象：中间位置的车离场后，它后面的车状态没变，再想查询或让路时数据全乱；计费金额却是对的，所以测试时很容易放过。

原因：原代码的likai()里有一句 printf 提示「请让此车之后的车先全部退出停车场」，但只打印了这句话，没有任何实际的弹出与压回逻辑。等于把最核心的栈操作交给了用户脑补。

解决：按 4.2 节补上临时栈的弹出与压回两段循环，top指针从 -1 开始，压入++top、弹出top--，最后用while (top >= 0)全部压回。补完之后，让 2 号车离场，检查 1 号、2 号车位状态是否恢复为 1。

5.5 计费出现负数或小数点后一长串

现象：跨零点停车时费用是负的；同日停车时显示3.5999999这种数字。

原因：时间差直接相减，没处理离场时刻小于进场时刻的情况；输出用%f默认六位小数，浮点误差全暴露出来。

解决：差值为负时加 24，并加一条合理性判断挡住明显输错的输入；输出改成%.2f。如果业务上需要按半小时计费，把D拆成D / 2再乘半个小时数，别在最后一步做除法，否则误差会放大。

6. 从能跑改成能讲：给报告书补一套可验证的用例集

把上面五处修完，程序能跑通，但离「能拿去答辩、能给别人看」还差一步：缺一套能证明它对的小规模用例集。我一般会在文档最后加一张表，把N和M都调到 3，按固定顺序操作，记录每一步的预期和实际：

这张表的价值在序号 6 和 7：序号 6 同时验证了计费和让路，序号 7 验证了队列。测试章里把每一步的控制台截图按序号命名贴进去，答辩时被问到「中间的车走了怎么办」，直接翻到第 6 行，比口头解释快十倍。

顺带把源码里的四个宏集中到文件头，并在报告书的参数表里加一列「调小后的测试值」，写明N=3、M=3用来触发满场和排队分支，D=1.2保持不变方便心算。这样别人拿到这份报告书，不用问就知道该怎么复现。

从那以后我每次交这种小系统，都会先把容量调到个位数跑一遍全流程，再改回正式值，截图按用例编号存好，最后才补文档。吃过一次「代码能跑、但说不清哪一步验证了什么」的亏，这个顺序就再没变过。希望帮到你。

本文还有配套的精品资源，点击获取