豆豆的Python生活 20 GTD任务管理(二) 需求确认与系统设计

一、缘起

又是一个周末的下午，阳光懒洋洋地铺在书桌上。豆豆背着书包敲响了马老师家的门，进门的时候脸上带着一股跃跃欲试的劲儿。

“马老师，我把剩下的用例都写完了！” 豆豆把一张纸放到桌上，”我回去想了好久，感觉越想越清楚。”

“哦？那我看看。” 马老师拿起来仔细看了一遍，嘴角慢慢浮出一丝笑意，”不错，比上次进步了不少。来，我们一起过一遍。”

二、豆豆的完整用例说明

上一节课，豆豆和马老师已经一起分析了用例一：分类查看任务列表和用例二：新建任务。回家之后，豆豆根据自己的理解，把剩下的用例也都补充完整了。

2.1 用例三：编辑任务

操作描述：

 用户在主界面的任务列表中，点击某条任务后面的【编辑】按钮，弹出编辑任务对话框。对话框中预先填入该任务的现有信息，用户可以修改任务标题、截止日期、分类、描述、进度、是否重要、是否紧急等属性，也可以添加或删除提醒时间。修改完成后点击【保存】，将更新后的数据保存到数据库，关闭对话框，主界面的任务列表同步刷新。约束与限制： 与新建任务相同，标题不能为空，截止日期不能早于今天，进度必须是0-100之间的整数。

2.2 用例四：删除任务

操作描述：

 用户在主界面的任务列表中，点击某条任务后面的【删除】按钮，弹出确认对话框，提示”您确定要删除该任务吗？”，用户点击【是】则将该任务从数据库中删除，主界面任务列表同步刷新；用户点击【否】则关闭对话框，不做任何操作。

2.3 用例五：标记任务完成

操作描述：

 用户在主界面的任务列表中，勾选某条任务前面的复选框，系统将该任务的完成状态设置为”已完成”，同时记录完成时间，将进度设为100%，并将该任务从当前象限的列表中移除。主界面统计信息同步更新。

2.4 用例六：任务回顾

操作描述：

 用户在主界面点击【任务回顾】按钮，弹出任务回顾对话框，显示所有已完成的任务列表。列表中每行显示任务标题、分类、描述、完成时间。用户可以输入关键字进行搜索，也可以选择排序方式（按完成时间升序或降序）。任务数量较多时，列表按每页10条分页显示，支持首页、上一页、下一页、尾页和跳转页码操作。用户还可以在回顾界面中删除已完成的任务记录。

2.5 用例七：任务提醒

操作描述：

 程序启动后，后台自动运行提醒检查服务，每隔一段时间检查一次数据库中的提醒记录。当某条提醒的时间到达时，系统自动弹出桌面通知，显示任务标题、截止日期、进度和描述信息。每条提醒只触发一次，触发后标记为已发送，不再重复提醒。

2.6 用例八：查看统计信息

操作描述：

 主界面顶部始终显示任务统计信息，包括：总任务数、待办任务数、已完成任务数，以及四个象限各自的待办任务数量。每次新建、编辑、删除或完成任务后，统计信息自动刷新。

三、马老师的审核意见

马老师把用例从头到尾看了一遍，放下纸，点了点头。

“整体来说写得不错，逻辑比较清晰，约束条件也考虑到了。不过我有几个问题想问你。”

“您说。”

“用例五里，你说勾选复选框就把任务标记完成——那如果用户不小心勾上了怎么办？能不能取消勾选？”

豆豆愣了一下：”这……我没想到。”

“这就是需求分析中容易忽略的地方——异常流程和边界情况。” 马老师说，”正常流程你描述得很清楚，但用户的操作并不总是按预期走的。比如误操作、输入了不合法的数据、网络断了……这些情况都要考虑到。”

“那这里怎么处理呢？”

“对于这个程序，我们可以简化一下：一旦勾选就直接完成，不支持反向取消——因为GTD的理念里，任务完成就是完成了，想’反悔’的话可以重新建一个任务。这个设计决策要在用例里说清楚。”

“明白了，我去补充一句。”

“还有，” 马老师继续说，”用例七的提醒功能，你写的是’每隔一段时间检查一次’，这个’一段时间’具体是多久？”

“呃……10秒？”

“可以，这是个实现细节，需求文档里可以不写死，但要说明’定时检查’这个机制。” 马老师说，”还有一点：你在用例六里提到了’删除已完成任务’，但用例四里的删除是主界面上的，两个地方都能删，要保证逻辑是一致的。”

“嗯，我知道了，都是从数据库里删掉这条记录。”

“对。” 马老师满意地说，”总体上，你这次的用例写得比第一版需求规范多了。现在需求文字描述已经基本完整，下一步我们要用另一种方式来进一步确认需求——原型图。”

“原型图？”

“就是把程序的界面先画出来，让用户看到大概长什么样子，提前发现问题。” 马老师说，”文字描述有时候会有歧义，但一张图往往能说清楚很多东西。这叫做【一图胜千言】”

四、用原型图确认需求

“做原型图用什么工具呢？” 豆豆问。

“工具有很多，专业的有Axure、Figma，简单的用PowerPoint、甚至手绘都行——哪怕你拿铅笔在纸上把界面大概画出来，只要能把想法传递给对方，就达到目的了。” 马老师说，”工具只是手段，重要的是把需求说清楚。我这里用Axure画了几张原型图，我们来看一下。”

马老师打开电脑，逐一展示原型图。

4.1 原型一：主界面

“你看，主界面分成四个区域，对应四个象限。每个区域有一个标题，下面是任务列表，每一行显示任务的完成状态、标题、进度、截止日期，最右边是编辑和删除按钮。顶部有【新建任务】和【任务回顾】两个按钮，旁边显示统计信息。”

“和我想的差不多！” 豆豆说，”不过我之前没想到把统计信息放在顶部，这样一眼就能看到总体情况，挺好的。”

“是的，这就是原型的价值——让你在开始写代码之前，就能直观地感受到程序用起来是什么感觉，发现之前没有想到的细节。”

4.2 原型二：新建任务

“这是新建任务的对话框。你能对照用例二，看看有没有遗漏的字段吗？”

豆豆仔细对照了一下：”标题、截止日期、分类、描述、进度……重要和紧急的复选框……提醒列表……都有了。”

“分类的选项是什么？”

“下拉列表，有工作、学习、生活、其他四个选项。” 豆豆回答，”对了马老师，我在用例里写的是’学习、生活、其它’，这里多了一个’工作’。”

“好眼力！” 马老师说，”这就是原型确认需求的意义。你觉得加上’工作’合理吗？”

“合理，毕竟不只是学生用，大人也可以用嘛。”

“那就更新一下用例二，把分类选项改成工作、学习、生活、其他。”

4.3 原型三：任务回顾

“这是任务回顾界面。顶部有关键字搜索框和排序选择，中间是已完成任务的列表，底部是分页控制器。”

“分页控制器有首页、上一页、下一页、尾页，还有一个跳转到指定页的输入框。” 豆豆说，”这个我在用例六里写到了。”

“不错。你注意到列表里显示的列是哪些吗？”

“任务标题、分类、描述、完成时间，最后是删除按钮。”

“和用例六对得上吗？”

豆豆检查了一遍：”对得上！”

4.4 原型四：任务提醒

“这是系统弹出的桌面提醒通知，显示任务标题、截止时间和描述。这个是操作系统级别的通知，不是我们自己画的窗口，所以原型图只是示意一下样式。”

“明白了。” 豆豆点头，”那现在需求就算确认好了吧？”

“基本上是的。” 马老师说，”在真实的项目里，这个阶段还要让客户签字确认，防止后面扯皮。我们自己用的程序就不用这么正式了，但这个流程要记住。”

五、系统架构设计

“需求确认了，下一步要做设计了吧？” 豆豆问。

“是的，咱们在讲《万卷书库》时说过，做一个有一定规模的软件，在写代码之前，还有一件重要的事——系统设计。” 马老师说，”我们要把程序的整体结构想清楚，决定用什么架构、有哪些模块、数据怎么存储。这样写代码的时候才不会乱。你还记得我们在万卷书库里讲过的三层架构吗？”

“记得，表示层、业务逻辑层、数据访问层。” 豆豆说，”表示层负责界面，业务逻辑层处理规则，数据访问层操作数据库。”

“很好，记得这么清楚！” 马老师说，”这次的GTD任务管理系统，我们同样采用三层架构。来，你来说说，这三层分别应该做什么？”

豆豆想了想，开口说道：”表示层就是我们看到的那些窗口——主界面、新建任务的对话框、任务回顾的对话框……业务逻辑层负责检查规则，比如标题不能为空、截止日期不能早于今天……数据访问层就是真正去操作SQLite数据库的代码。”

“说得很准确！” 马老师说，“基于我们学过的三层架构和原型，你可以先推导出表示层的对象，比如主界面窗口、任务信息编辑对话框、任务回顾窗口和提醒窗口，相应地在业务逻辑层我们也要有对应的任务服务、提醒服务，数据访问层有任务数据访问对象和提醒数据访问对象，再向下就是数据库了，我们通过前面的用例描述、界面元素可以基本确定数据库里有任务表、提醒表。”

马老师一边说，一边给豆豆画了个示意图：

“这就是我们这个程序的分层结构。上层只调用下层，下层不知道上层的存在——表示层只和业务逻辑层打交道，不直接操作数据库；业务逻辑层只和数据访问层打交道，不管界面长什么样。这样各层的职责清晰，以后修改起来也方便。”

“那提醒功能放在哪里？” 豆豆问。

“问得好！” 马老师说，”提醒功能有点特殊——它不是由用户操作触发的，而是后台定时自动运行的。我们把它设计成一个独立的后台服务，程序启动的时候就开始运行，定时检查数据库里有没有到期的提醒，有的话就弹出通知。它属于业务逻辑层的一部分，但独立于用户界面之外。”

“原来如此。” 豆豆说，”马老师，我们是不是还象上次一样建立不同层的目录来存不同层次的代码文件？”

“是的，我们可以这样组织项目目录：” 马老师说。

gtd_task_manager/├── main.py              # 程序入口├── ui/                  # 表示层│   ├── main_window.py       # 主窗口│   ├── task_dialog.py       # 新建/编辑任务对话框│   ├── review_dialog.py     # 任务回顾对话框│   └── add_reminder_dialog.py  # 添加提醒对话框├── service/             # 业务逻辑层│   ├── task_service.py      # 任务业务逻辑│   └── reminder_service.py  # 提醒后台服务├── dao/                 # 数据访问层│   ├── task_dao.py          # 任务数据访问│   └── reminder_dao.py      # 提醒数据访问└── gtd.db               # SQLite数据库文件</pre>

“这样看起来清晰多了。” 豆豆说，”每个文件夹里放的都是同一层的代码，一眼就能看出来。”

“对。目录结构本身就是一种文档，让人一看就知道程序是怎么组织的。”

六、功能模块设计

“架构定好了，下面我们来细化一下每个模块的功能。” 马老师说，”先从表示层开始，你来说说主窗口要实现哪些功能？”

豆豆看着原型图想了想：”主窗口要显示四个象限的任务列表，每个象限是一个独立的区域，里面有一个表格。顶部有新建任务按钮、任务回顾按钮，还有统计信息标签。”

“对。那这四个象限的区域，是不是可以单独封装成一个组件？”

“什么意思？”

“就是把每个象限的代码单独写成一个类，而不是把四个象限的代码全部堆在主窗口里。” 马老师说，”你想想，四个象限的结构是不是完全一样？”

豆豆点点头：”对，都是一个标题加一个表格，显示的列也一样，操作也一样，只是显示的任务不同。”

“那就可以把象限封装成一个QuadrantWidget类，主窗口里创建四个这样的对象，分别对应四个象限。这样代码简洁，以后如果要修改象限的显示方式，改一处就够了，不用改四遍。”

“明白了，这就是代码复用！” 豆豆眼睛一亮。

“正是。” 马老师继续说，”我们把整个程序的功能模块梳理一下：

表示层模块：

• MainWindow

• QuadrantWidget 

• TaskDialog

• ReviewDialog

• AddReminderDialog

业务逻辑层模块：

• TaskService

• ReminderService

数据访问层模块：

• TaskDAO

• ReminderDAO

“我们还是用图表示更清晰一些。”马老师打开Axure画了个图：

豆豆认真看着马老师画图，突然问道：”马老师，为什么提醒的数据访问要单独一个ReminderDAO，而不是放在TaskDAO里？”

“好问题。” 马老师说，”你看，提醒记录和任务记录虽然存在同一个数据库里，但它们是不同的数据实体，有各自的操作。更重要的是，ReminderService需要单独访问提醒数据，如果把提醒的操作混在TaskDAO里，ReminderService就必须依赖TaskDAO，层次关系就乱了。单独拆出来，职责更清晰。”

“懂了。每个类只做一件事。”

“对，这就是软件设计中很重要的单一职责原则——一个类只负责一件事情。这样的代码更容易理解、修改和测试。现在已经有了模块，你能参考以前学的知识，设计出TaskService、TaskDAO、Task这几个对象的属性和方法吗？”

“我试试”，豆豆边想边在纸上画出了三个对象的具体设计：

“很不错！” 马老师说，“任务相关的对象是重点，只要你能把这个做出来，提醒对象也不是什么问题。”

七、数据库设计

“功能模块想清楚了，下面来设计数据库。” 马老师说，”根据我们的需求，程序需要需要两张表存储任务数据和提醒数据。先来设计任务表，你来想想任务需要存哪些字段？”

豆豆看着用例说明，一个个数出来：”任务标题、截止日期、分类、描述、进度、是否完成、是否重要、是否紧急……”

“还有呢？”

“还有……” 豆豆想了一下，”创建时间？”

“对，还有完成时间——任务完成的时候要记录完成时间，回顾的时候能看到。” 马老师说，”当然还有一个自动生成的主键id。整理一下，任务表的字段如下：

豆豆盯着表格看了一会儿：”马老师，is_important和is_urgent两个字段，是不是就决定了任务在哪个象限？”

“完全正确！” 马老师说，”不需要单独存一个’象限’字段，只要知道是否重要、是否紧急，就能推算出在哪个象限。这叫做避免冗余数据——能推算出来的数据就不要再单独存一份，否则两个地方的数据可能会不一致，造成混乱。”

“明白了！那提醒表呢？”

“提醒表相对简单。” 马老师说，”每条提醒记录对应一条任务，需要存储哪些信息？”

“提醒时间……还有对应的任务id……” 豆豆说，”还要知道这条提醒有没有发送过，避免重复提醒。”

“很好，你已经想得很完整了。提醒表的字段：

“task_id是外键？” 豆豆问，”外键是什么意思？”

“外键就是一张表里的字段，引用了另一张表的主键。” 马老师解释道，”这里reminders表里的task_id，引用的是tasks表里的id。通过这个关联，我们就能知道这条提醒属于哪个任务。就像图书馆里的借阅记录，每条借阅记录里都有一个’图书编号’，通过它可以找到对应的图书信息——这个’图书编号’就是外键。”

“噢！我明白了。” 豆豆说，”那一个任务可以有多条提醒记录，就是一对多的关系？”

“完全正确！一个任务对应多条提醒，这是典型的一对多关系。” 马老师点头，”你学得很快。”

“那删除任务的时候，对应的提醒记录也要一起删掉吧？”

马老师眼睛一亮：”豆豆，你现在想得越来越全面了！对，删除任务时，要先删除该任务关联的所有提醒记录，再删除任务本身。否则数据库里就会留下一堆孤立的提醒记录，找不到对应的任务，这种数据叫做’脏数据’。”

“我记住了。” 豆豆认真地在本子上写下：删除任务时，先删reminders，再删tasks。

八、总结

“好了，今天我们做了不少工作。” 马老师说，”我们来回顾一下。”

豆豆翻开自己的笔记，总结道：”我们先把完整的用例说明都写好了，然后马老师帮我审核，补充了边界情况和异常流程的考虑。之后用原型图把界面大概画出来，对照用例把需求再确认了一遍，还发现了分类选项需要补充’工作’这个细节。然后做了系统架构设计，决定用三层架构，把代码分成ui、service、dao三个目录。接着梳理了每个模块的功能，最后设计了两张数据库表——tasks和reminders。”

“总结得非常好！” 马老师说又在纸上开始画图，”从第一节课到现在，我们大概经历这些步骤。”

“你看，从’我要做一个任务管理程序’到’知道怎么做这个程序’，中间经历了这么多步骤。” 马老师说，”这就是软件工程的价值——让你在动手写代码之前，把问题想清楚。”

“明白，建狗窝和建大厦是不一样啊。” 豆豆笑着说。

“没错。当然，现实中需求分析和设计也不可能做到百分之百完美，总会有遗漏的地方，在开发过程中也会不断调整。你看我画这张图的时候，就没有把下一阶段的开始放到前一阶段结束之后，它们之间是有交叉的，也就是不用等到把需求全弄清楚了再进入设计，可以渐进式明确需求，提前做设计。但是前期工作做得越扎实，后期返工的代价就越小。”

“马老师，那下一步就是写代码了吗？” 豆豆有些跃跃欲试。

“对！” 马老师说，”有了这份设计，写代码就有了明确的目标，不会再迷茫了。下次我们就从数据访问层开始，一层一层地把程序搭起来。”

豆豆收拾好笔记本，站起来准备离开。窗外天色已经暗了下来，路灯一盏一盏地亮起，把街道照得温暖而明亮。

“马老师，我感觉这次学到的东西，比单纯写代码有意思多了。”

“那是因为你开始学会思考了，而不只是执行。” 马老师笑着说，”这是成为一名真正的程序员最重要的一步。”

豆豆背起书包，走进了夜色里，脑子里已经开始盘算着下次怎么写那个TaskDAO了。