软件工程第一次实验指南：用例图、流程图与需求分析实操

看到“软件工程第一次实验”这个标题的时候我猜你脑海里浮现的八成是“终于要写代码了”。我当年第一次走进软件工程实验室也是这么想的结果老师发下来的实验任务书连一行代码都没有——要我们给一个“图书管理系统”画用例图、画流程图、写需求说明。那一刻我才明白软件工程这门课讲的是“如何组织一次规范的软件开发”而你接到的第一次实验往往不是练代码而是练思维、练工程化表达。这篇文章我就围绕“软件工程第一次实验”这个几乎所有高校都会安排的入门训练把实验目标拆解、工具准备、完整实操流程和常见翻车点一次讲清楚。不管你是正在上软件工程导论、准备软工课设还是刚接触需求建模概念、担心软件工程毕业设计选题无从下手这篇内容都能给你一条可以直接照着走的路线。第一次实验看着简单但它是后续几次实验的“地基”地基歪了后面画架构图、写详细设计的时候会加倍痛苦。1. 第一次实验到底在考什么不是写代码是建立“工程感”1.1 课程定位决定了实验的“画风”软件工程导论这类课程跟数据结构、算法分析不一样。数据结构的实验核心是让你跑通一个算法比如用代码实现floyed算法类似的路径求解跑通就有成就感。软件工程实验则相反它训练的是你“在动手写代码之前”那套分析、建模、设计的能力。所以第一次实验几乎不会要求你交付一个程序而是要求你完成一个“从需求到模型”的推导链条。说得直白点老师是想看你能不能像真正的软件工程师那样拿到一个业务场景能理出用户、功能、规则、数据流这几样东西。你是在练习“怎么定义一个值得做的软件系统”而不是“怎么实现它”。我第一次做这个实验的时候最大的误区就是嫌麻烦画几幅图不是很快吗结果交上去被老师批得明明白白——用例没有边界流程图跑不通需求描述模棱两可。后来才意识到软工的图和代码一样是要经得起“推敲”的。第一次实验真正的分数差距不是谁画得好看而是谁“考虑得完整”。1.2 第一次实验最常见的三种形态不同学校、不同老师出的“第一次实验”形态会有些差别但大体逃不出下面这三种。你先判断自己拿到的是哪一种再分配精力方向才不会跑偏。实验形态典型任务核心产出物常用工具需求分析类给一个业务题目识别用户角色与功能需求用例图、功能清单、需求规格说明书片段draw.io、StarUML、Visio计划管理类制定项目计划安排迭代里程碑甘特图、WBS任务分解表、风险清单Excel、Project、在线看板环境协作类配置开发环境建立远程仓库并完成协作提交仓库截图、提交日志、冲突解决记录Git、GitHub/Gitee这三种不是互斥的很多老师的第一次实验是“需求分析为主 项目启动为辅”比如我这次拿到的就是给图书管理系统做需求建模同时要求用Git做版本管理。你拿到任务书后先花十分钟判断它属于哪一种再去想“我要用什么工具”“有哪些参考案例”效率会高很多。1.3 报告评分的隐形标准完整性大于正确性正确性大于美观性软工实验报告很多同学第一个念头是“我要画得漂亮”于是花大量时间调色、换图标。但以我后来当助教看别人实验报告的经验老师的评分维度其实是有优先级的。第一优先级是“完整”功能有没有漏、角色有没有漏、异常分支有没有处理。比如图书管理系统你画了读者借书但忘记画“读者还书”和“管理员处理逾期”就算图画得再精致也要扣分。第二优先级是“一致”需求描述里说到的功能用例图里有没有体现用例图里的操作流程图里能不能跑通。第三才是美观度。所以这篇文章后面所有的实操我都围绕“完整”“一致”这两个目标来写。美观这件事把图命名规范、字体统一、连线对齐就够了不用在样式上死磕。2. 工具选型与安装配置真正劝退人的环节2.1 一套够用的最小工具链我第一次做软工实验的时候差点把电脑装成了“全家桶”装了三个绘图软件还有一堆项目管理工具结果一半没用上。后来我总结出一套“最小工具链”应付第一次实验绰绰有余。绘图工具draw.io桌面版或网页版都行或者 StarUML。如果你需要严格意义的UML建模StarUML更正统如果你主要画流程图、思维导图draw.io 上手最快。文档工具Word 或 WPS。实验报告最后都是要提交文档的别在文档工具上搞花活排版规范比好看更重要。版本管理Git 一个远程平台GitHub、Gitee 都可以。很多学校第一次实验就要求交Git截图哪怕你是单人完成也要把仓库建起来。原型验证工具可选如果你做的是需求分析类实验可以顺手用 Python 的 Flask 写一个几行代码的假接口原型帮自己验证流程是否合理。这个不是必须但做了会让报告更有说服力。工具选型的核心原则是“够用就好”。别一上来就研究一堆企业级平台第一次实验撑不起那么复杂的重量级工具反而会在配置上浪费大量时间。2.2 绘图工具选择背后的一点思考我先说结论如果你不是被老师点名要求用某个特定工具我建议你优先用 draw.io。理由很简单第一它支持纯本地保存不需要账号也能用杜绝了“在线平台崩了导致进度丢失”的情况第二它导出PNG、SVG都极其方便实验报告里插图清晰度很高第三它跟Git配合很好很多项目的文档图都直接存成 .drawio 后缀进仓库方便diff对比版本。相比之下StarUML 虽然UML规范更严格但它的许可证验证和界面中文设置我见过不少同学当场卡住。顺带一提还有同学想用在线白板或PPT画图不是不能用但白板导出的图分辨率太低PPT画出的用例图连线没有自动吸附功能调整起来非常痛苦。你在画图工具上省下的时间最后都会在报告排版里还回去。2.3 第一次配置环境最容易踩的4个坑环境配置是第一次实验里最没技术含量、但最耗时间的环节。我把高频问题列成一个速查表你遇到的时候直接对照。现象常见原因解决建议Git中文文件名乱码或提交信息乱码Windows下Git默认编码与UTF-8不兼容执行git config --global core.quotepath false并把终端编码改为UTF-8draw.io网页版卡顿或文件保存丢失浏览器缓存不足、未开启本地自动保存优先用桌面版或者下载后再编辑养成“编辑一步就保存一次”的习惯StarUML许可证或校验页面打不开StarUML需要许可证验证教育邮箱有时收不到邮件换成 draw.io 或 PlantUML 写代码生成图避免在工具授权上耗时间图片在Word里模糊不清截图分辨率太低或直接拖入压缩后的PNG导出时选择SVG或高倍率PNG再插入Word2.4 一个人也要用的版本管理这是实验报告里的加分项很多同学觉得“团队协作才用Git我一个人做实验用不上”这个想法会直接让你在实验报告的“过程管理”一栏丢分数。软件工程的第一次实验哪怕所有内容都一个人完成也应该建一个仓库把实验题目、需求文档、绘图源文件、报告草稿全部按目录放进去并且用规范的方式提交。我自己的实操习惯是在仓库根目录建这几个子目录——docs放需求规格说明diagrams放绘图源文件screenshots放运行或截图证据report放最终实验报告。每次完成一个完整阶段就提交一次提交信息写成中文短语比如“添加借书流程数据流图”。老师看Git提交记录扫一眼就能看出你是不是认真做过这种工程化习惯在第一次实验里就养成后面软工课设、毕业设计会省心很多。3. 核心实操用“图书管理系统”走通完整流程下面我用一个经典的“图书管理系统”实验题目带你把第一次实验从头到尾走一遍。这个题目几乎是软工实验里的“原子题”选它有两个原因一是信息完全公开不会涉及任何保密或边界争议二是每所高校的软工课程里几乎都出现过类似变体你的实验题大概率能从这套流程里找到对应关系。3.1 需求收集先列功能清单再谈画图很多同学拿到题目第一件事就是打开绘图软件画用例图这是一个典型错误。画用例图之前你手里必须有一份“功能清单”这是你推导模型的原材料。以图书管理系统为例先别画图先在文档里列出所有你能想到的用户和功能读者注册/登录、图书检索、借书、还书、续借、预约、查看个人借阅记录图书管理员图书信息录入、图书信息维护、借书处理、还书处理、逾期催还系统管理员读者账户管理、管理员账户管理、系统参数配置、数据统计报表列清单的时候要注意一件事宁可多列也不要漏列。第一次实验被老师指出“需求遗漏”是非常常见的事情。你可以把自己假想成一个“挑剔的用户”反复问自己“那我还书的时候发现卡里欠费怎么办”“预约的图书到馆了系统怎么通知我”这些就是你需求的“异常分支”写进清单里能直接拉高报告的完整性评分。列完清单之后做一次“过滤”把那些明显超出实验范围的功能标注出来比如“对接支付宝缴纳逾期费”这类实在要做就放在“未来扩展”里。这样既显得你需求分析做得到位又不会把自己拖进过于复杂的建模泥潭。3.2 用例图识别角色和边界功能清单有了用例图就是把这些信息“图形化”。画用例图的重点是三个Actor识别准、用例边界清、关系想明白。图书管理系统的Actor至少有三个读者、图书管理员、系统管理员。有的同学会把“借书”“还书”都画成读者和图书管理员之间的连线其实区分的关键是“谁发起谁执行”。借书这个行为从系统的角度操作者是图书管理员读者是申请者但用例图通常站在“目标用户”的视角去表达。所以我的习惯是借书、还书放在“图书管理员”的Actor下而“提交借书请求”放在“读者”Actor下两个用例用依赖关系连接。用例之间的关系重点掌握两种include 和 extend。Include表示“这个用例一定包含另一个用例的行为”比如“借书处理”包含“验证读者身份”你画成带箭头的虚线指向被包含的用例。Extend表示“在某种条件下会触发扩展行为”比如“借书处理”在库存为零时扩展到“创建预约记录”。我见过很多同学把这两个关系画反你可以用一句话记include是“每次必做”extend是“偶尔触发”。3.3 流程图与数据流图什么时候画什么第一次实验最容易混淆的两个图一个是业务流程图一个是数据流图DFD。业务流程图强调的是“业务顺序”和“判断分支”。比如借书流程从读者提交请求开始系统依次进行身份检查、库存检查、库存扣减、生成借阅记录最后完成借出。这种图适合用简单的“开始—处理—判断—结束”结构来表达。画的时候特别要注意“判断节点”的每个分支都必须有出口不能有走到了死胡同的情况。数据流图强调的是“数据在系统里怎么流动、存到哪”。顶层DFD通常画外部实体、加工过程、数据存储、数据流四种元素。图书管理系统顶层图大概是读者把“借书请求”数据流进“借阅处理”加工加工过程访问“图书信息库”并生成“借阅记录”存入“借阅记录文件”。画DFD的时候有一条铁律叫“数据守恒”流出加工的每个数据项必须是流入或存储中已有的不能凭空多出字段。有的同学在加一个数据流时顺手加了一个“库存数量”字段但前面的数据源里根本没有这个字段这就是数据不平衡会被单独拎出来批评。至于“软件工程流程图”这个词很多场景下只是泛泛地指流程类图表。只要你能分清自己画的是业务流程图还是数据流图命名就无所谓了。如果实验手册没明确要求我的建议是两种都画业务流程图讲清楚“业务怎么走”DFD讲清楚“数据怎么流”两者结合就是一份很扎实的建模作业。3.4 实验报告组织与SRS片段示例报告是第一次实验的最终交付物很多同学前期图画得很好报告却写得东一句西一句非常吃亏。我习惯沿用一个固定结构实验目的与要求实验环境列出工具版本号比如 draw.io 24.x、Git 2.4x实验内容与步骤贴关键图 每张图配两三句解释实验结果与分析对照需求清单逐项说明是否覆盖遇到的问题与解决办法小结这里特别提醒每一张图下面一定不要空着图就完事至少要写两句话解释这个图表达了什么、为什么这样设计。老师看报告图是“证据”文字是“论证”光有证据没有论证分数高不了。如果你的实验要求写一部分需求规格说明书SRS可以用这种片段式的写法功能需求 F01读者登录 - 输入读者证号、密码 - 处理系统校验读者证号与密码是否匹配校验读者状态是否正常 - 输出登录成功/失败提示 - 异常连续输错5次账户锁定15分钟这种写法的好处是需求可验证、可测试老师一眼就能看出你理解“需求必须落地到具体规则”这件事。软件工程第一次实验的训练目标说到底就是这点——把一句笼统的“要能登录”拆成可执行的规则。4. 常见问题与评分雷区能救一个是一个4.1 模型与需求“两张皮”我在当助教的时候看过太多实验报告需求清单写了一堆功能结果用例图只有三个用例用例图画了“预约”功能流程图的判断条件里又完全没提预约。这种“需求是需求、图是图”的问题是软工实验最大的扣分项叫模型与需求不一致。要避免这个问题最土但最有效的办法是“对照检查”你每画完一张图就拿着功能清单逐项去打勾。功能清单里有的图里必须有图里出现的功能清单里必须能找到出处。我在自己实验的时候甚至会把功能清单打印出来画完一版图就勾一次有对不上的立刻补或删。第一次实验不用追求建模多复杂但“对得上”这条底线一定别破。4.2 流程图跑不通循环、断头路与发散箭头流程图最容易犯的三个毛病我一个个说。第一个毛病是判断分支没有出口。比如“库存是否充足”的判断你画了“是”的分支却忘记画“否”的分支图就成了一根断头路。正确画法是“否”分支回到修改数量或跳转到“提示库存不足并结束”。第二个毛病是非法循环。借书流程图里如果“验证身份失败”之后直接箭头连回“请求借书”中间没有任何计数器或退出条件从流程结构上就陷进了死循环。流程图的循环一般只允许出现在“重新输入数据”这种场景其他循环要尽量用异常出口。第三个毛病是从一个处理节点拉出好多条没有标注的箭头。处理节点如果有多个出口必须说明每个出口的触发条件不然老师根本不知道图上的菱形判断条件是用来干什么的。我自己的实操技巧是画完图之后用手指沿着每条箭头从“开始”走到“结束”如果走到哪一步你嘴上说不清楚下一步为什么要走这里那这个图一定有问题。4.3 版本管理混乱push冲突与提交信息失控第一次实验用Git最常见的翻车就是多人协作时push冲突。其实单人实验也会遇到“我明明提交了怎么仓库里没有”这种困惑。我的建议是如果第一次实验的题目支持独立完成就别为了“看起来像团队合作”硬跟室友拆工作量。与其把时间花在解决Git冲突上不如一个人把一套完整流程跑顺。如果你确实是多人分组实验记住一个原则每次编辑前先git pull改完提交前再git pull --rebase有冲突就先在本地解决再用git push。提交信息也要写得像样别出现“asdf”“final”“最终版2”这种消息一条提交信息最好能说清楚“这版做了什么”比如“完成借书流程DFD”。4.4 报告格式与评分雷区最后是报告部分。格式问题虽然看起来“低级”但扣分非常痛。我整理了一张我在批改报告时经常会打叉的情况你交作业前可以对照自查。雷区典型表现整改建议图片无编号、无题注图插进去就完事了统一使用“图1 借书业务流程图”这种格式正文中要引用需求描述含混“系统要支持借书”一句话带过拆成输入、处理、输出、异常四要素模型元素命名不统一用例图叫“用户”DFD里却叫“读者”全程统一用“读者”“管理员”等角色名不要混用没有任何截图证据交了报告但没看到实验过程把Git日志、绘图源文件列表等截图附到附录结论写成“我学会了”心得体会只有空话改成“我在借书流程图里学到判断分支必须补全出口条件”这类具体收获结尾想多说两句第一次实验做完我的体会是它看起来不起眼却能逼着你从“凭感觉开发”切换到“按流程做事”。这个过程不会太舒服你会觉得画图比写代码还烦但等你到了软工课设和毕业设计阶段就会发现当初那些“烦人”的用例、流程图、需求条目其实给你省掉了大量返工的力气。最后分享一个小技巧从第一次实验开始就固定用同一个案例、同一套命名去贯穿后面每次实验。比如第一次做了图书管理系统的需求分析第二次实验的数据库设计、第三次实验的详细设计全部在这套系统上继续扩展。这样每轮实验你只需要新增内容不用重新熟悉题目背景材料积累到毕业设计阶段甚至可以整理成一份完整的软件工程文档集。如果第一次实验拿到的题目跟我这里讲的图书管理系统不太一样也没关系你只要抓住“列需求清单→画用例图→画流程图/DFD→写报告”这条主线换成外卖点单、宿舍报修、课程选课这些题目步骤完全通用。祝你第一次实验顺利过关也欢迎做完之后回来交流你的案例和踩坑记录。