这是一个使用C#编写的数独生成求解器项目，包含了需求分析、概要设计、详细设计和核心代码实现。项目采用瀑布模型开发，实现了数独终局生成、求解算法、随机数生成及输入输出功能。通过GitHub进行版本控制，包括对数独类的设计和单元测试。此外，还涉及性能分析和代码质量改进。
最近更新时间2018.12.29（百忙之中实现了UI界面，另开了一篇）
GitHub连接：https://github.com/blingopen/sudoku
部分参考资料链接（有些参考之后忘记贴出来了）：
内容目录
此软件会用C#语言编写。
首先我对这个数独项目完成的时间做了一个大致的估计。
| PSP2.1 | Personal Software Process Stages |
预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 60 | |
| ·Estimate | ·估计这个任务需要多少时间 | 60 | |
| Development | 开发 | 1170 | |
| · Analysis | · 需求分析（包括学习新技术） | 300 | |
| · Design Spec | · 生成设计文档 | 30 | |
| · Design Review | · 设计复审（和同事审核设计文档） | 0 | |
| · Coding Standard | · 代码规范（为目前的开发制定合适的规范） | 60 | |
| · Design | · 具体设计 | 180 | |
| · Coding | · 具体编码 | 300 | |
| · Coding Review | · 代码复审 | 120 | |
| · Test | · 测试（自我测试，修改代码，提交修改） | 180 | |
| Reporting | 报告 | 360 | |
| · Test Reporting | · 测试报告 | 120 | |
| · Size Measurement | · 计算工作量 | 60 | |
| · Postmortem & Process Improvement Plan | · 事后总结，并提出过程改进计划 | 180 | |
| 合计 | 1590 |
本项目为个人项目，所以设计复审为本人自行复审（算在需求分析中），故和同行设计复审一栏时间花费为0.
需求分析
拿到题目之后我读了好几遍，终于把这个数独的需求摸索清楚了：
- 在控制台输入指令“sudoku.exe -c 有效数字”可以输出改有效数字数量的数独终局到txt文件中。
- 在控制台输入“sudoku.exe -s 绝对路径”可以读取绝对路径中txt文本中的数独，求解并输出结果到txt文件中。
首先计划了一番，计划的大致时间如上表，因为需求比较明确，并且功能没有很复杂，所以准备用瀑布模型来开发。
接着，我思考了一下，程序结构很简单，主要可分为以下几个板块，区分指令板块（包括不同的有效指令和无效指令），生成多个数独终局板块，求解数独板块，第一个板块直接在主函数中写一个判断就可以，后面两个板块要分别设计一些算法。
当然设计算法是后话，“工欲善其事，必先利其器”，要先把准备工作做好。所以先按照文档要求，创建一个优快云博客和GitHub工程文件夹，在这里寻求百度的帮助，查找了一些使用GitHub和Git的方法，配置好了相关环境，建立了相应的文件夹和博客。（前三次commit是试验自己是否创建成功）
然后按照正常的瀑布模型开发流程，计划了大致时间后，写了一个需求分析，参考了网上的模板和教材的流程，存入了GitHub中（文件 Analysis.docx），其中建模结果大致如下。
数据建模
本软件数据较为简单，抽象出来的实体只有一个完整的9×9的数独，和对应的每个3×3的小矩阵（共9个）。
功能建模
数据源即用户，数据终点为本地计算机，主要数据流即用户在控制台应用输入的各种指令和输出结果，主要处理过程即生成终局和求解数独。（详细设计回来发现此处图有些不恰当）
继续划分，系统主要分为数独生成终局部分和数度求解部分，无法进一步精细化，故画到一层即可。
行为建模
主要状态分为等待指令的主界面状态，生成终局状态，求解数独状态和错误信息状态，其行为关系如下：（详细设计回来发现此处图有些不恰当）
最低0.47元/天 解锁文章
扫一扫
863
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
