简介一份适用于UML课程设计与软件工程实践的停车场管理系统分析与设计文档面向软件工程、计算机相关专业学生以及需要完成课程设计或毕业设计的初学者。内容围绕系统分析展开首先给出功能性需求与非功能性需求分析并结合参与者绘制用例图随后从静态模型切入依次介绍分析包、分析类图和分析对象图再延伸到顺序图、协作图、状态图、活动图等动态模型最后覆盖部署图、构件图与数据库设计帮助读者快速建立从需求到建模的完整UML思路。资源为单个doc文档大小249KB属于课程设计说明书类型文件内部目录清晰涵盖需求分析、模型构建、数据库设计等完整章节既可直接参考说明书排版也可对照学习各UML图的绘制方法。已有3474人学习下载适合作为UML课程设计模板、软件系统分析设计练习或答辩资料。1. 从一套停车管理系统课程设计说明书看UML建模链路翻旧文档时翻到一份《软件系统分析与设计》课程设计说明书题目是停车管理系统。这份文档没有写运行截图却把UML建模链路完整走了一遍先从需求分析画出参与者与用例图再搭包图、类图、对象图、部署图、构件图之后用顺序图、协作图、状态图、活动图推演动态行为最后落到数据库表。做课程设计的人常把UML图当成交差用的示意图画完用例图就不知道类图怎么推状态图跟业务对不上。这套资料恰好能说明一条完整闭环参与者决定用例边界用例决定候选类类的关联决定表结构顺序图决定控制类方法。对正在写软件系统分析与设计报告的人照着这条链路走比抄模板实用得多。2. 用例图驱动的需求分析参与者识别与用例边界2.1 先识别参与者再谈用例三种角色的权限边界停车管理系统最关键的建模工作不是画界面而是把系统边界画清楚。原设计说明书里明确的参与者有三个普通用户、业务操作员、系统管理员。普通用户对应有车一族能注册、登录、查询停车空位、查询停车历史记录、查询收费标准、预定车位业务操作员负责登录后管理顾客档案、车辆入场、车辆出场、收费管理系统管理员负责操作员档案管理、统计报表、系统维护。三者之间不是平级关系而是权限层级系统管理员管理操作员操作员直接服务普通用户普通用户只能访问自己的数据。参与者为什么必须在用例之前确定因为用例图要回答的是“谁在系统外面系统为他做什么”。如果先把功能列表填进去画图时很容易把“数据库连接”“界面跳转”这类系统内部动作也扩成用例。我在评审课程设计时看到最多的错误就是用例图里有“保存用户信息”这种内部操作却没有标出触发它的外部角色导致整个用例图变成菜单树。识别参与者时建议圈出系统边界只有边界外的角色才画成actor系统内部的对象一律不准出现在参与者位置。可以直接用Visio的新建“软件和数据库”-“UML模型图”来画UML用例图也可以在你的建模工具里先标注三个参与者再为每个参与者挂用例。注意Visio画用例图时Actor和用例之间用实线关联这条线不要画成箭头UML用例图中参与者与用例的关系是无向关联。2.2 用例图不是功能菜单include和extend该用在哪儿从需求分析规格说明可以整理出系统管理员有操作员档案管理、统计报表、系统维护业务操作员有登录、顾客档案管理、入场管理、出场管理、收费管理普通用户有注册、登录、查询停车空位、查询停车历史记录、查询收费标准、预定车位。把这些用例放进一个矩形“停车管理系统”边界内再连上三个参与者就得到基础用例图。需要注意登录这个用例被三个参与者共用但如果每个参与者下面都画一个“登录”图会重复。常见做法是把登录作为公共用例操作员和系统管理员的“进入后台管理”通过include指向登录普通用户可以单独保留注册用例。入场管理和出场管理都必然触发收费计算这一层用include关系表达不是用extend。include表示被包含的用例一定会执行extend表示在特定条件或扩展点才插入额外行为。实际操作中如果收费类型有“按小时”和“按次数”可以把“选择收费类型”作为收费用例的扩展点用extend表达。课程设计的用例图不需要把所有扩展都画出来但至少要保证用例名是动词短语且每个用例对角色都有可观察的结果。2.3 用用例表把验收口径定下来比纯图更抗辩用例图只解决看关系没法写清楚前置条件和异常分支。课程设计答辩时老师问“入场失败怎么办”如果文档里没有用例描述场面会很尴尬。建议每张用例图配套一张用例表表头固定为用例名、参与者、前置条件、主成功场景、异常分支、后置条件、优先级。停车管理系统最核心的两个用例是车辆入场和车辆收费。车辆入场的主流程是操作员登录后进入入场管理录入车牌号选择空闲车位保存入场记录车位状态变为占用。车辆收费的流程是操作员录入车辆入场时间系统按停车时长或停车次数计算费用展示收费金额操作员收费后生成收费记录车位状态释放为空闲。异常分支要覆盖“车牌号已存在”和“临时卡余额不足”。优先级建议按P0/P1/P2排P0是登录、入场管理、出场管理、收费管理P1是查询空位、预定车位、顾客档案管理P2是统计报表与系统维护。画UML用例图时把P0用例放到页面左侧或上方突出核心业务流程答辩大纲也按P0优先级组织避免在次要功能上卡时间。下面给一个可以直接修改的PlantUML用例图脚本方便生成与正文一致的图startuml left to right direction actor 普通用户 as customer actor 业务操作员 as operator actor 系统管理员 as admin rectangle 停车管理系统 { usecase 注册 as UC1 usecase 登录 as UC2 usecase 查询停车空位 as UC3 usecase 查询停车历史记录 as UC4 usecase 查询收费标准 as UC5 usecase 预定车位 as UC6 usecase 顾客档案管理 as UC7 usecase 停车场入场管理 as UC8 usecase 停车场出场管理 as UC9 usecase 收费管理 as UC10 usecase 操作员档案管理 as UC11 usecase 统计报表 as UC12 usecase 系统维护 as UC13 } customer -- UC1 customer -- UC2 customer -- UC3 customer -- UC4 customer -- UC5 customer -- UC6 operator -- UC2 operator -- UC7 operator -- UC8 operator -- UC9 operator -- UC10 admin -- UC2 admin -- UC11 admin -- UC12 admin -- UC13 UC8 .. UC10 : include UC9 .. UC10 : include enduml这段脚本里left to right direction控制整个图的布局方向适合参与者多、用例多的场景actor与usecase是PlantUML的关键字rectangle 停车管理系统表示系统边界。..是虚线依赖用于include关系方向从基础用例指向被包含用例也就是入场管理指向收费管理。这里要注意如果收费不是每次入场后必须执行的就不要用include而是用带extend的扩展关系否则会误导评审。用例名参与者优先级关键场景登录全部P0账号密码校验车辆入场业务操作员P0记录车牌、分配车位车辆出场收费业务操作员P0计费、生成收费记录查询停车空位普通用户P1展示空闲车位预定车位普通用户P1锁定车位统计报表系统管理员P2汇总收费金额3. 静态模型搭建包图、类图、对象图与部署图构件图的取舍3.1 包图按功能模块切而不是按图层切静态模型的第一步是画包图。原设计说明书里的包结构是车辆入场管理、车辆出场管理、收费管理、用户档案管理、查询管理、系统管理。这个划分思路是“业务功能模块”不是三层架构。我见过不少课程设计把包图画成Controller、Service、DAO三层那叫架构部署说明不叫UML包图。UML包图的作用是管理依赖包与包之间只能有一个方向的依赖关系否则将来改动会互相传染。收费管理在入场和出场两个包之间被共用它的正确依赖方向是“入场管理依赖收费管理”而不是反过来。如果画包图时发现两个包互相指向对方说明边界切错了需要把公共部分抽出来。用Visio画UML包图时可以使用“包”形状右键添加子包并在包内简要列出关键类名这样答辩时能看出包的粒度是否合理。3.2 类图推导从用例中找候选类再处理继承和关联类图是软件系统分析与设计报告里最容易丢分的静态模型因为很多人的类图是从数据库表反向抄出来的缺少对象关系。正确的方式是从用例描述中提取名词用户、业务操作员、普通用户、系统管理员、车、停车卡、停车场、车位、收费标准、收费、入场管理、出场管理、交班。把“用户”作为基类业务操作员、普通用户、系统管理员作为子类收费作为抽象父类按小时收费和按次数收费作为子类。这就是原始类图的核心骨架。类图里的属性不要全都堆成字符串。原设计里用户有用户编号、姓名、密码、性别、年龄、联系地址普通用户还有用户名、卡号、车牌号车辆有编号、车牌号、车类型停车卡有卡编号、卡号、卡类型、余额、发卡时间、有效时间、挂失状态车位有车位编号、车牌号、车位状态。属性类型要标对性别用boolean或枚举金额用float或BigDecimal时间是Date而不是String。这类细节能直接看出建模能力。停车卡和车辆是绑定关系一辆车对应一张停车卡车位与停车场之间是聚合关系停车场包含多个车位但车位可以独立存在。收费由业务操作员生成一次收费对应一条收费记录。为了控制篇幅这里给出一份可运行的PlantUML类图脚本画的是核心实体类startuml class User { - userId : int - name : String - password : String - sex : boolean - age : int - address : String } class Customer { - userName : String - cardNo : String - plateNo : String queryFreeSpace() : void reserveSpace() : void queryHistory() : void } class Operator { - title : String - department : String entryManage() : void exitManage() : void charge() : void } class Admin { - techLevel : String report() : void archiveManage() : void } class Car { - carId : int - plateNo : String - carType : String } class ParkingCard { - cardId : int - cardNo : String - cardType : String - balance : float - validTime : Date - lost : boolean } class ParkingSpace { - spaceNo : int - plateNo : String - status : boolean } class Charge { - chargeId : int - cardNo : String - amount : float } class HourlyCharge { - startTime : Date - endTime : Date } class CountCharge { - totalCount : int } User |-- Customer User |-- Operator User |-- Admin Customer 1 -- 0..* Car : 持有 Car 1 -- 1 ParkingCard : 绑定 Operator 1 -- 0..* Charge : 生成 ParkingSpace --o ParkingCard : 分配 Charge |-- HourlyCharge Charge |-- CountCharge enduml这段脚本里的|--是UML继承关系的PlantUML写法空心三角指向父类。1 -- 0..*表示一个用户持有零到多辆车多重性标注在关系线两端。--o表示聚合。关系线只画必要的实体关联不要把所有类都互相连线否则类图会变成蜘蛛网。用Visio画UML类图时同样在“UML 类图”形状库中拖入类形状再使用“关联”工具连线双击连线后可以在“类别”中切换聚合、组合、依赖等关系类型。3.3 对象图、部署图和构件图哪些该细画哪些可以带过对象图是类图在某一时刻的实例快照。停车管理系统的对象图可以画一个“业务操作员-停车卡-车辆”的实例组合对象名写成“马师傅:Operator”呼应类图里的Operator类。对象图在课程设计中不必每张类图都配建议只对“车辆入场”这个核心场景画一张用来证明你理解类与实例的差别。部署图描述物理节点。原资料里的部署节点包括数据库服务器、停车场服务器、操作员处理设备、停车场出入设备、摄像头、对讲机、PC机、互联网MySQL数据库作为数据存储节点。画部署图时每个节点下面要注明实际运行组件例如数据库服务器节点标注“MySQL 数据库服务”操作员处理设备节点标注“浏览器终端”。不用纠结每个节点是否都有独立IP课程设计可以把局域网内的一组设备合并成一个节点。构件图在停车管理系统里相对简单原资料给出了电脑主服务器、停车卡、摄像头。构件图标明物理构件之间的依赖即可不必展开内部实现。如果答辩时间紧部署图和构件图各一页带过把时间留给类图和顺序图这两个图才是软件系统分析与设计课程设计的重点。3.4 类图关系速查表画图前对照一遍为了减少把泛化、实现、聚合、组合混用的低级错误我一般会放一张关系速查表在正文里。老师的评分视角是关系线比属性值更重要。关系类型UML表示停车场系统示例数据库映射泛化继承实线空心三角指向父类User与Operator不直接映射靠角色字段或子表实现虚线空心三角指向接口Charge接口与HourlyCharge接口不建表聚合实线空心菱形指向整体ParkingLot与ParkingSpace整体表主键出现在部分表外键组合实线实心菱形指向整体ParkingCard与CardRecord部分表外键非空且级联删除依赖虚线箭头指向被依赖方收费管理依赖收费标准运行时调用关系不建表注意Visio的“关联”连线默认是普通关联要表达聚合或组合必须双击连线后在“类别”中修改泛化关系也要使用专门的“泛化”工具不能随手画一条实线。看到这里你基本可以回答“用visio怎么画uml类图”的大半问题不是形状不会找而是关系线的类型没有对应到正确业务语义。4. 动态模型推演顺序图、协作图、状态图与活动图的联动4.1 顺序图用消息把查询空位和收费的调用链跑通动态模型里最值得花时间的是顺序图。停车管理系统的关键用例是查询空位和收费。查询空位涉及普通用户和业务操作员收费只涉及业务操作员。顺序图的三类对象边界类、控制类、实体类正好对应JSPServletBean模式里的JSP页面、Servlet控制器、JavaBean实体。画顺序图时如果发现边界类直接访问数据库说明控制类被跳过了分层有问题。原资料里查询空位的顺序图从用户登录开始用户提交登录信息边界类把信息传给控制类控制类查询数据库返回停车空位信息。这里的消息链不要省略。后面收费顺序图更典型操作员先录入车辆入场时间再录入出场时间录入收费类型控制类计算收费金额保存数据库最后显示收费成功。每一个消息都要有返回值线不能只有请求没有响应。给出查询空位的PlantUML顺序图脚本startuml actor 用户 as user boundary 查询界面 as ui control 查询控制 as ctrl entity 车位表 as db user - ui : 登录 ui - ctrl : 提交登录信息 ctrl - db : 按用户编号查询 db -- ctrl : 返回用户记录 ctrl -- ui : 登录成功 user - ui : 请求查询空位 ui - ctrl : 查询空闲车位 ctrl - db : 查询status空闲 db -- ctrl : 返回空位列表 ctrl -- ui : 封装展示数据 ui -- user : 显示空位信息 endumlboundary、control、entity是PlantUML里对UML分析类原型的支持分别对应界面类、控制类和实体类。actor关键字用于参与者。消息从上到下按时间排序--表示返回消息不带的箭头表示同步调用。判断一条顺序图是否成立可以沿着最右列从下往上读一遍看是否每一个数据库操作都有对应的控制请求和界面返回。4.2 协作图不重复建模只换视角协作图又称通信图它和顺序图描述的是同一次交互只是侧重点不同顺序图强调消息的时间顺序协作图强调对象之间的结构连接。原资料里给出了业务操作员、普通用户、系统管理员三类协作图本质是把登录、查询、收费等交互重新摆成网状。如果课程设计已经画了顺序图可以直接用工具转换导出协作图不需要手工重画一遍。注意协作图里的消息编号要连续例如操作员登录的协作图1为选择登录2为输入信息3为验证信息4为返回成功。编号顺序就是顺序图中消息顺序二者挂不上会在答辩时被发现。打印版报告不建议同时放顺序图和协作图选一张放正文另一张放附录即可。4.3 状态图针对对象的状态迁移而不是页面流转状态图强调的是某个对象在不同时刻的状态不是用户点了几下页面。停车管理系统里最好画的三个状态图是车位状态、停车卡状态、收费标准状态。车位状态可以定义为“空闲-占用-空闲”事件是入场分配和出场结算如果有预定车位功能还要加入“保留”状态。这样状态图才和用例里的预定车位对得上。原资料中的业务操作员、普通用户、系统管理员“使用状态图”严格来说更像角色活动状态不是对象状态图。如果想让报告更专业建议给车位和停车卡各画一张状态图替代角色状态图。下面是车位状态图脚本startuml [*] -- 空闲 空闲 -- 占用 : 车辆入场/分配车位 空闲 -- 保留 : 普通用户预定 保留 -- 占用 : 车辆入场 保留 -- 空闲 : 取消预定/超时释放 占用 -- 空闲 : 出场结算/释放车位 enduml状态图里的每个箭头都必须是一个事件比如“车辆入场”“出场结算”不能是“操作员点击按钮”这种界面动作。状态尽量控制在三到五个太多说明你没有找到对象的核心生命周期。状态图完成后检查是否漏掉了异常路径例如“保留”状态超时后应回到“空闲”。4.4 活动图把收费流程的分支和并行写清楚活动图适合表达业务流程尤其是收费过程。原始资料里的操作员活动图覆盖了登录、入场管理、出场管理、收费管理、查询停车使用状况其中“有空位/无空位”的判断很典型。活动图的价值在于能把“按小时收费”和“按次数收费”两个分支放到同一张图里表达。常见问题是把“网页登录”和“系统登录”两种方式画成并行分支实际上它们是同一条流程的两个入口不应该fork。活动图里条件判断用菱形判断节点并行操作才用分叉和汇合二者不要混用。收费流程可以这样建模登录后先判断车辆是入场还是出场入场时记录车牌、入场时间并分配车位出场时记录出场时间再判断收费类型按小时计算停车时长费用或按停车次数计费最后生成收费记录并释放车位。模型核心检查点常见错误顺序图消息从外部进入边界控制类调用实体边界类直接连数据库协作图消息编号与顺序图一致漏编号或编号不连续状态图每个状态有进入事件和离开事件把页面状态当作业务状态活动图判断节点覆盖是/否两个出口把入口方式画成并行5. 数据库表设计与UML类图的映射落库5.1 从类图到表结构哪些类落表哪些关系拆外键UML类图到关系数据库没有一对一映射尤其是有继承关系时。原类图中用户是父类业务操作员、普通用户、系统管理员是子类常见做法是单表继承一张user表加user_type字段区分角色。停车管理系统用户量不大单表继承的查询最简单也方便登录时一次性查出角色。缺点是操作员、普通用户各自的扩展字段会稀疏但课程设计规模下完全可以接受。如果指导老师要求体现类图继承关系可以拆成user主表加operator_profile、customer_profile扩展表主表存账号、密码、姓名等公共字段扩展表按角色存放职称、部门或车牌号。优缺点要写明白单表继承开发快、联查少类表继承更贴近面向对象但登录后还要根据角色二次查表。下面给出单表继承的建表SQLCREATE TABLE user ( user_id INT PRIMARY KEY AUTO_INCREMENT, user_type TINYINT NOT NULL COMMENT 1系统管理员,2操作员,3普通用户, name VARCHAR(20) NOT NULL, password VARCHAR(64) NOT NULL, sex TINYINT DEFAULT 0, age INT, address VARCHAR(255), tech_level VARCHAR(10), title VARCHAR(20), department VARCHAR(50) );这段SQL里user_type是关键字段对应类图中的三个子类tech_level、title、department是子类属性单表继承时将子类字段全部放到主表允许为空。这样虽然存在冗余但避免了为每个角色建一张表的关联成本。实际开发中我会保留这种设计并在Service层根据user_type决定能调用哪些功能。车位表同样可以从类图直接映射CREATE TABLE parking_space ( space_no INT PRIMARY KEY, park_id INT NOT NULL, plate_no VARCHAR(20) COMMENT 当前占用车牌空则为NULL, status TINYINT DEFAULT 0 COMMENT 0空闲,1占用,2保留, CONSTRAINT fk_space_park FOREIGN KEY (park_id) REFERENCES parking_lot(park_id) );status字段对应状态图中的“空闲/占用/保留”plate_no允许为空表示空闲车位没有绑定车辆。这里有个常见错误有人把“空闲”也用一个冗余车牌记录表示结果统计空闲数量时只能用IS NULL还会产生大量脏数据。用状态字段加可空车牌是更直接的处理。5.2 收费规则用一张规则表摊平两个子类原类图把收费拆成“按小时收费”和“按次数收费”但在数据库里照搬两张表并不明智。业务代码每次计费都要判断先用哪张表查询收费记录还要合并结果。常见做法是用一张billing_rule表通过bill_type字段区分计费方式这样扩展月卡、年卡时只需要增加bill_type不需要新增数据表。CREATE TABLE billing_rule ( rule_id INT PRIMARY KEY, card_type VARCHAR(10) COMMENT 固定卡或临时卡, car_type VARCHAR(10), bill_type TINYINT COMMENT 1按小时,2按次数, unit_time INT COMMENT 单位时间(分钟), unit_amount DECIMAL(8,2), max_amount DECIMAL(10,2) );这里的unit_time只对按小时收费有效max_amount表示单次停车封顶金额按次收费时这两个字段可以为空。类图里的HourlyCharge和CountCharge仍然保留它们的差异被规则表中的bill_type吸收。这样做的好处是收费逻辑只有一个查询入口根据卡类型和车辆类型匹配规则再按bill_type分支计算。5.3 入场记录和收费记录拆分交班报表不算错入场记录和收费记录如果合在一张表还没出场的车辆会产生大量空字段操作员交班统计也会变得复杂。原资料里有入场管理和出场管理两个类落地时对应两张记录表。入场记录记录车辆进入停车场的事实收费记录只记录出场结算时生成的费用。CREATE TABLE parking_record ( record_id INT PRIMARY KEY, plate_no VARCHAR(20) NOT NULL, space_no INT, operator_id INT, entry_time DATETIME, entry_lane VARCHAR(10) ); CREATE TABLE charge_record ( charge_id INT PRIMARY KEY, record_id INT, card_no VARCHAR(20), charge_type VARCHAR(10), amount DECIMAL(8,2), exit_time DATETIME, exit_lane VARCHAR(10), FOREIGN KEY (record_id) REFERENCES parking_record(record_id) );拆分之后查询停车历史时用record_id关联两张表统计收费金额时只查charge_record交班表需要的“进场次数、出场次数、金额总计”分别从两张记录表聚合不互相干扰。建议在parking_record的plate_no、entry_time上建联合索引在charge_record的operator_id、exit_time上建索引这样报表查询不会扫描全表。课程设计的数据库规模不需要分表但索引设计能体现你对sql执行路径的理解。6. 用Visio把UML类图从“能看”改到“能答辩”6.1 用Visio画UML类图的四个关键步骤很多人搜“用visio怎么画uml类图”卡在第一步找不到合适的形状。打开Visio后在“新建”里选“软件和数据库”分类再选“UML模型图”左侧会自动出现两个形状库UML用例图、UML类图。如果只看到“基本流程图”形状说明模板选错了。拖出“类”形状后双击形状输入类名然后右键选择“形状显示选项”勾选“属性”“操作”和“可见性”类图才会出现- userId : int这类标准写法。属性区的每一行要按“可见性 属性名 : 类型”的格式例如- password : String操作区写 queryFreeSpace() : void。接着用左侧的“关联”工具在两个类之间画关系线双击关系线会弹出“UML关联属性”对话框在“类别”里可以选择泛化、聚合、组合、依赖多重性在“结束点”标签页里设置。6.2 类图答辩前的自检清单以下是我每次提交前会用的一张检查表按顺序过一遍能避免大部分扣分项检查项说明可见性符号private显示为-public显示为所有属性都要有继承线方向泛化线空心三角指向父类不能反依赖线样式虚线箭头只用于依赖不要和实现线混用多重性一对多必须写1和0..*不要留空类命名类名是单数名词不是表名也不是页面名关系数量每个实体类至少参与一条关系不能孤立最后一个技巧把核心类加粗用图层给不同包设置不同颜色导出图片前把画布背景改为白色并统一字体为宋体或微软雅黑。答辩时这类细节会直接影响老师对“软件工程素养”的第一印象。把多重性标完整再用“形状显示选项”把可见性符号全部打开这张类图就能作为数据模型论证的一页。本文还有配套的精品资源点击获取
简介一份适用于UML课程设计与软件工程实践的停车场管理系统分析与设计文档面向软件工程、计算机相关专业学生以及需要完成课程设计或毕业设计的初学者。内容围绕系统分析展开首先给出功能性需求与非功能性需求分析并结合参与者绘制用例图随后从静态模型切入依次介绍分析包、分析类图和分析对象图再延伸到顺序图、协作图、状态图、活动图等动态模型最后覆盖部署图、构件图与数据库设计帮助读者快速建立从需求到建模的完整UML思路。资源为单个doc文档大小249KB属于课程设计说明书类型文件内部目录清晰涵盖需求分析、模型构建、数据库设计等完整章节既可直接参考说明书排版也可对照学习各UML图的绘制方法。已有3474人学习下载适合作为UML课程设计模板、软件系统分析设计练习或答辩资料。1. 从一套停车管理系统课程设计说明书看UML建模链路翻旧文档时翻到一份《软件系统分析与设计》课程设计说明书题目是停车管理系统。这份文档没有写运行截图却把UML建模链路完整走了一遍先从需求分析画出参与者与用例图再搭包图、类图、对象图、部署图、构件图之后用顺序图、协作图、状态图、活动图推演动态行为最后落到数据库表。做课程设计的人常把UML图当成交差用的示意图画完用例图就不知道类图怎么推状态图跟业务对不上。这套资料恰好能说明一条完整闭环参与者决定用例边界用例决定候选类类的关联决定表结构顺序图决定控制类方法。对正在写软件系统分析与设计报告的人照着这条链路走比抄模板实用得多。2. 用例图驱动的需求分析参与者识别与用例边界2.1 先识别参与者再谈用例三种角色的权限边界停车管理系统最关键的建模工作不是画界面而是把系统边界画清楚。原设计说明书里明确的参与者有三个普通用户、业务操作员、系统管理员。普通用户对应有车一族能注册、登录、查询停车空位、查询停车历史记录、查询收费标准、预定车位业务操作员负责登录后管理顾客档案、车辆入场、车辆出场、收费管理系统管理员负责操作员档案管理、统计报表、系统维护。三者之间不是平级关系而是权限层级系统管理员管理操作员操作员直接服务普通用户普通用户只能访问自己的数据。参与者为什么必须在用例之前确定因为用例图要回答的是“谁在系统外面系统为他做什么”。如果先把功能列表填进去画图时很容易把“数据库连接”“界面跳转”这类系统内部动作也扩成用例。我在评审课程设计时看到最多的错误就是用例图里有“保存用户信息”这种内部操作却没有标出触发它的外部角色导致整个用例图变成菜单树。识别参与者时建议圈出系统边界只有边界外的角色才画成actor系统内部的对象一律不准出现在参与者位置。可以直接用Visio的新建“软件和数据库”-“UML模型图”来画UML用例图也可以在你的建模工具里先标注三个参与者再为每个参与者挂用例。注意Visio画用例图时Actor和用例之间用实线关联这条线不要画成箭头UML用例图中参与者与用例的关系是无向关联。2.2 用例图不是功能菜单include和extend该用在哪儿从需求分析规格说明可以整理出系统管理员有操作员档案管理、统计报表、系统维护业务操作员有登录、顾客档案管理、入场管理、出场管理、收费管理普通用户有注册、登录、查询停车空位、查询停车历史记录、查询收费标准、预定车位。把这些用例放进一个矩形“停车管理系统”边界内再连上三个参与者就得到基础用例图。需要注意登录这个用例被三个参与者共用但如果每个参与者下面都画一个“登录”图会重复。常见做法是把登录作为公共用例操作员和系统管理员的“进入后台管理”通过include指向登录普通用户可以单独保留注册用例。入场管理和出场管理都必然触发收费计算这一层用include关系表达不是用extend。include表示被包含的用例一定会执行extend表示在特定条件或扩展点才插入额外行为。实际操作中如果收费类型有“按小时”和“按次数”可以把“选择收费类型”作为收费用例的扩展点用extend表达。课程设计的用例图不需要把所有扩展都画出来但至少要保证用例名是动词短语且每个用例对角色都有可观察的结果。2.3 用用例表把验收口径定下来比纯图更抗辩用例图只解决看关系没法写清楚前置条件和异常分支。课程设计答辩时老师问“入场失败怎么办”如果文档里没有用例描述场面会很尴尬。建议每张用例图配套一张用例表表头固定为用例名、参与者、前置条件、主成功场景、异常分支、后置条件、优先级。停车管理系统最核心的两个用例是车辆入场和车辆收费。车辆入场的主流程是操作员登录后进入入场管理录入车牌号选择空闲车位保存入场记录车位状态变为占用。车辆收费的流程是操作员录入车辆入场时间系统按停车时长或停车次数计算费用展示收费金额操作员收费后生成收费记录车位状态释放为空闲。异常分支要覆盖“车牌号已存在”和“临时卡余额不足”。优先级建议按P0/P1/P2排P0是登录、入场管理、出场管理、收费管理P1是查询空位、预定车位、顾客档案管理P2是统计报表与系统维护。画UML用例图时把P0用例放到页面左侧或上方突出核心业务流程答辩大纲也按P0优先级组织避免在次要功能上卡时间。下面给一个可以直接修改的PlantUML用例图脚本方便生成与正文一致的图startuml left to right direction actor 普通用户 as customer actor 业务操作员 as operator actor 系统管理员 as admin rectangle 停车管理系统 { usecase 注册 as UC1 usecase 登录 as UC2 usecase 查询停车空位 as UC3 usecase 查询停车历史记录 as UC4 usecase 查询收费标准 as UC5 usecase 预定车位 as UC6 usecase 顾客档案管理 as UC7 usecase 停车场入场管理 as UC8 usecase 停车场出场管理 as UC9 usecase 收费管理 as UC10 usecase 操作员档案管理 as UC11 usecase 统计报表 as UC12 usecase 系统维护 as UC13 } customer -- UC1 customer -- UC2 customer -- UC3 customer -- UC4 customer -- UC5 customer -- UC6 operator -- UC2 operator -- UC7 operator -- UC8 operator -- UC9 operator -- UC10 admin -- UC2 admin -- UC11 admin -- UC12 admin -- UC13 UC8 .. UC10 : include UC9 .. UC10 : include enduml这段脚本里left to right direction控制整个图的布局方向适合参与者多、用例多的场景actor与usecase是PlantUML的关键字rectangle 停车管理系统表示系统边界。..是虚线依赖用于include关系方向从基础用例指向被包含用例也就是入场管理指向收费管理。这里要注意如果收费不是每次入场后必须执行的就不要用include而是用带extend的扩展关系否则会误导评审。用例名参与者优先级关键场景登录全部P0账号密码校验车辆入场业务操作员P0记录车牌、分配车位车辆出场收费业务操作员P0计费、生成收费记录查询停车空位普通用户P1展示空闲车位预定车位普通用户P1锁定车位统计报表系统管理员P2汇总收费金额3. 静态模型搭建包图、类图、对象图与部署图构件图的取舍3.1 包图按功能模块切而不是按图层切静态模型的第一步是画包图。原设计说明书里的包结构是车辆入场管理、车辆出场管理、收费管理、用户档案管理、查询管理、系统管理。这个划分思路是“业务功能模块”不是三层架构。我见过不少课程设计把包图画成Controller、Service、DAO三层那叫架构部署说明不叫UML包图。UML包图的作用是管理依赖包与包之间只能有一个方向的依赖关系否则将来改动会互相传染。收费管理在入场和出场两个包之间被共用它的正确依赖方向是“入场管理依赖收费管理”而不是反过来。如果画包图时发现两个包互相指向对方说明边界切错了需要把公共部分抽出来。用Visio画UML包图时可以使用“包”形状右键添加子包并在包内简要列出关键类名这样答辩时能看出包的粒度是否合理。3.2 类图推导从用例中找候选类再处理继承和关联类图是软件系统分析与设计报告里最容易丢分的静态模型因为很多人的类图是从数据库表反向抄出来的缺少对象关系。正确的方式是从用例描述中提取名词用户、业务操作员、普通用户、系统管理员、车、停车卡、停车场、车位、收费标准、收费、入场管理、出场管理、交班。把“用户”作为基类业务操作员、普通用户、系统管理员作为子类收费作为抽象父类按小时收费和按次数收费作为子类。这就是原始类图的核心骨架。类图里的属性不要全都堆成字符串。原设计里用户有用户编号、姓名、密码、性别、年龄、联系地址普通用户还有用户名、卡号、车牌号车辆有编号、车牌号、车类型停车卡有卡编号、卡号、卡类型、余额、发卡时间、有效时间、挂失状态车位有车位编号、车牌号、车位状态。属性类型要标对性别用boolean或枚举金额用float或BigDecimal时间是Date而不是String。这类细节能直接看出建模能力。停车卡和车辆是绑定关系一辆车对应一张停车卡车位与停车场之间是聚合关系停车场包含多个车位但车位可以独立存在。收费由业务操作员生成一次收费对应一条收费记录。为了控制篇幅这里给出一份可运行的PlantUML类图脚本画的是核心实体类startuml class User { - userId : int - name : String - password : String - sex : boolean - age : int - address : String } class Customer { - userName : String - cardNo : String - plateNo : String queryFreeSpace() : void reserveSpace() : void queryHistory() : void } class Operator { - title : String - department : String entryManage() : void exitManage() : void charge() : void } class Admin { - techLevel : String report() : void archiveManage() : void } class Car { - carId : int - plateNo : String - carType : String } class ParkingCard { - cardId : int - cardNo : String - cardType : String - balance : float - validTime : Date - lost : boolean } class ParkingSpace { - spaceNo : int - plateNo : String - status : boolean } class Charge { - chargeId : int - cardNo : String - amount : float } class HourlyCharge { - startTime : Date - endTime : Date } class CountCharge { - totalCount : int } User |-- Customer User |-- Operator User |-- Admin Customer 1 -- 0..* Car : 持有 Car 1 -- 1 ParkingCard : 绑定 Operator 1 -- 0..* Charge : 生成 ParkingSpace --o ParkingCard : 分配 Charge |-- HourlyCharge Charge |-- CountCharge enduml这段脚本里的|--是UML继承关系的PlantUML写法空心三角指向父类。1 -- 0..*表示一个用户持有零到多辆车多重性标注在关系线两端。--o表示聚合。关系线只画必要的实体关联不要把所有类都互相连线否则类图会变成蜘蛛网。用Visio画UML类图时同样在“UML 类图”形状库中拖入类形状再使用“关联”工具连线双击连线后可以在“类别”中切换聚合、组合、依赖等关系类型。3.3 对象图、部署图和构件图哪些该细画哪些可以带过对象图是类图在某一时刻的实例快照。停车管理系统的对象图可以画一个“业务操作员-停车卡-车辆”的实例组合对象名写成“马师傅:Operator”呼应类图里的Operator类。对象图在课程设计中不必每张类图都配建议只对“车辆入场”这个核心场景画一张用来证明你理解类与实例的差别。部署图描述物理节点。原资料里的部署节点包括数据库服务器、停车场服务器、操作员处理设备、停车场出入设备、摄像头、对讲机、PC机、互联网MySQL数据库作为数据存储节点。画部署图时每个节点下面要注明实际运行组件例如数据库服务器节点标注“MySQL 数据库服务”操作员处理设备节点标注“浏览器终端”。不用纠结每个节点是否都有独立IP课程设计可以把局域网内的一组设备合并成一个节点。构件图在停车管理系统里相对简单原资料给出了电脑主服务器、停车卡、摄像头。构件图标明物理构件之间的依赖即可不必展开内部实现。如果答辩时间紧部署图和构件图各一页带过把时间留给类图和顺序图这两个图才是软件系统分析与设计课程设计的重点。3.4 类图关系速查表画图前对照一遍为了减少把泛化、实现、聚合、组合混用的低级错误我一般会放一张关系速查表在正文里。老师的评分视角是关系线比属性值更重要。关系类型UML表示停车场系统示例数据库映射泛化继承实线空心三角指向父类User与Operator不直接映射靠角色字段或子表实现虚线空心三角指向接口Charge接口与HourlyCharge接口不建表聚合实线空心菱形指向整体ParkingLot与ParkingSpace整体表主键出现在部分表外键组合实线实心菱形指向整体ParkingCard与CardRecord部分表外键非空且级联删除依赖虚线箭头指向被依赖方收费管理依赖收费标准运行时调用关系不建表注意Visio的“关联”连线默认是普通关联要表达聚合或组合必须双击连线后在“类别”中修改泛化关系也要使用专门的“泛化”工具不能随手画一条实线。看到这里你基本可以回答“用visio怎么画uml类图”的大半问题不是形状不会找而是关系线的类型没有对应到正确业务语义。4. 动态模型推演顺序图、协作图、状态图与活动图的联动4.1 顺序图用消息把查询空位和收费的调用链跑通动态模型里最值得花时间的是顺序图。停车管理系统的关键用例是查询空位和收费。查询空位涉及普通用户和业务操作员收费只涉及业务操作员。顺序图的三类对象边界类、控制类、实体类正好对应JSPServletBean模式里的JSP页面、Servlet控制器、JavaBean实体。画顺序图时如果发现边界类直接访问数据库说明控制类被跳过了分层有问题。原资料里查询空位的顺序图从用户登录开始用户提交登录信息边界类把信息传给控制类控制类查询数据库返回停车空位信息。这里的消息链不要省略。后面收费顺序图更典型操作员先录入车辆入场时间再录入出场时间录入收费类型控制类计算收费金额保存数据库最后显示收费成功。每一个消息都要有返回值线不能只有请求没有响应。给出查询空位的PlantUML顺序图脚本startuml actor 用户 as user boundary 查询界面 as ui control 查询控制 as ctrl entity 车位表 as db user - ui : 登录 ui - ctrl : 提交登录信息 ctrl - db : 按用户编号查询 db -- ctrl : 返回用户记录 ctrl -- ui : 登录成功 user - ui : 请求查询空位 ui - ctrl : 查询空闲车位 ctrl - db : 查询status空闲 db -- ctrl : 返回空位列表 ctrl -- ui : 封装展示数据 ui -- user : 显示空位信息 endumlboundary、control、entity是PlantUML里对UML分析类原型的支持分别对应界面类、控制类和实体类。actor关键字用于参与者。消息从上到下按时间排序--表示返回消息不带的箭头表示同步调用。判断一条顺序图是否成立可以沿着最右列从下往上读一遍看是否每一个数据库操作都有对应的控制请求和界面返回。4.2 协作图不重复建模只换视角协作图又称通信图它和顺序图描述的是同一次交互只是侧重点不同顺序图强调消息的时间顺序协作图强调对象之间的结构连接。原资料里给出了业务操作员、普通用户、系统管理员三类协作图本质是把登录、查询、收费等交互重新摆成网状。如果课程设计已经画了顺序图可以直接用工具转换导出协作图不需要手工重画一遍。注意协作图里的消息编号要连续例如操作员登录的协作图1为选择登录2为输入信息3为验证信息4为返回成功。编号顺序就是顺序图中消息顺序二者挂不上会在答辩时被发现。打印版报告不建议同时放顺序图和协作图选一张放正文另一张放附录即可。4.3 状态图针对对象的状态迁移而不是页面流转状态图强调的是某个对象在不同时刻的状态不是用户点了几下页面。停车管理系统里最好画的三个状态图是车位状态、停车卡状态、收费标准状态。车位状态可以定义为“空闲-占用-空闲”事件是入场分配和出场结算如果有预定车位功能还要加入“保留”状态。这样状态图才和用例里的预定车位对得上。原资料中的业务操作员、普通用户、系统管理员“使用状态图”严格来说更像角色活动状态不是对象状态图。如果想让报告更专业建议给车位和停车卡各画一张状态图替代角色状态图。下面是车位状态图脚本startuml [*] -- 空闲 空闲 -- 占用 : 车辆入场/分配车位 空闲 -- 保留 : 普通用户预定 保留 -- 占用 : 车辆入场 保留 -- 空闲 : 取消预定/超时释放 占用 -- 空闲 : 出场结算/释放车位 enduml状态图里的每个箭头都必须是一个事件比如“车辆入场”“出场结算”不能是“操作员点击按钮”这种界面动作。状态尽量控制在三到五个太多说明你没有找到对象的核心生命周期。状态图完成后检查是否漏掉了异常路径例如“保留”状态超时后应回到“空闲”。4.4 活动图把收费流程的分支和并行写清楚活动图适合表达业务流程尤其是收费过程。原始资料里的操作员活动图覆盖了登录、入场管理、出场管理、收费管理、查询停车使用状况其中“有空位/无空位”的判断很典型。活动图的价值在于能把“按小时收费”和“按次数收费”两个分支放到同一张图里表达。常见问题是把“网页登录”和“系统登录”两种方式画成并行分支实际上它们是同一条流程的两个入口不应该fork。活动图里条件判断用菱形判断节点并行操作才用分叉和汇合二者不要混用。收费流程可以这样建模登录后先判断车辆是入场还是出场入场时记录车牌、入场时间并分配车位出场时记录出场时间再判断收费类型按小时计算停车时长费用或按停车次数计费最后生成收费记录并释放车位。模型核心检查点常见错误顺序图消息从外部进入边界控制类调用实体边界类直接连数据库协作图消息编号与顺序图一致漏编号或编号不连续状态图每个状态有进入事件和离开事件把页面状态当作业务状态活动图判断节点覆盖是/否两个出口把入口方式画成并行5. 数据库表设计与UML类图的映射落库5.1 从类图到表结构哪些类落表哪些关系拆外键UML类图到关系数据库没有一对一映射尤其是有继承关系时。原类图中用户是父类业务操作员、普通用户、系统管理员是子类常见做法是单表继承一张user表加user_type字段区分角色。停车管理系统用户量不大单表继承的查询最简单也方便登录时一次性查出角色。缺点是操作员、普通用户各自的扩展字段会稀疏但课程设计规模下完全可以接受。如果指导老师要求体现类图继承关系可以拆成user主表加operator_profile、customer_profile扩展表主表存账号、密码、姓名等公共字段扩展表按角色存放职称、部门或车牌号。优缺点要写明白单表继承开发快、联查少类表继承更贴近面向对象但登录后还要根据角色二次查表。下面给出单表继承的建表SQLCREATE TABLE user ( user_id INT PRIMARY KEY AUTO_INCREMENT, user_type TINYINT NOT NULL COMMENT 1系统管理员,2操作员,3普通用户, name VARCHAR(20) NOT NULL, password VARCHAR(64) NOT NULL, sex TINYINT DEFAULT 0, age INT, address VARCHAR(255), tech_level VARCHAR(10), title VARCHAR(20), department VARCHAR(50) );这段SQL里user_type是关键字段对应类图中的三个子类tech_level、title、department是子类属性单表继承时将子类字段全部放到主表允许为空。这样虽然存在冗余但避免了为每个角色建一张表的关联成本。实际开发中我会保留这种设计并在Service层根据user_type决定能调用哪些功能。车位表同样可以从类图直接映射CREATE TABLE parking_space ( space_no INT PRIMARY KEY, park_id INT NOT NULL, plate_no VARCHAR(20) COMMENT 当前占用车牌空则为NULL, status TINYINT DEFAULT 0 COMMENT 0空闲,1占用,2保留, CONSTRAINT fk_space_park FOREIGN KEY (park_id) REFERENCES parking_lot(park_id) );status字段对应状态图中的“空闲/占用/保留”plate_no允许为空表示空闲车位没有绑定车辆。这里有个常见错误有人把“空闲”也用一个冗余车牌记录表示结果统计空闲数量时只能用IS NULL还会产生大量脏数据。用状态字段加可空车牌是更直接的处理。5.2 收费规则用一张规则表摊平两个子类原类图把收费拆成“按小时收费”和“按次数收费”但在数据库里照搬两张表并不明智。业务代码每次计费都要判断先用哪张表查询收费记录还要合并结果。常见做法是用一张billing_rule表通过bill_type字段区分计费方式这样扩展月卡、年卡时只需要增加bill_type不需要新增数据表。CREATE TABLE billing_rule ( rule_id INT PRIMARY KEY, card_type VARCHAR(10) COMMENT 固定卡或临时卡, car_type VARCHAR(10), bill_type TINYINT COMMENT 1按小时,2按次数, unit_time INT COMMENT 单位时间(分钟), unit_amount DECIMAL(8,2), max_amount DECIMAL(10,2) );这里的unit_time只对按小时收费有效max_amount表示单次停车封顶金额按次收费时这两个字段可以为空。类图里的HourlyCharge和CountCharge仍然保留它们的差异被规则表中的bill_type吸收。这样做的好处是收费逻辑只有一个查询入口根据卡类型和车辆类型匹配规则再按bill_type分支计算。5.3 入场记录和收费记录拆分交班报表不算错入场记录和收费记录如果合在一张表还没出场的车辆会产生大量空字段操作员交班统计也会变得复杂。原资料里有入场管理和出场管理两个类落地时对应两张记录表。入场记录记录车辆进入停车场的事实收费记录只记录出场结算时生成的费用。CREATE TABLE parking_record ( record_id INT PRIMARY KEY, plate_no VARCHAR(20) NOT NULL, space_no INT, operator_id INT, entry_time DATETIME, entry_lane VARCHAR(10) ); CREATE TABLE charge_record ( charge_id INT PRIMARY KEY, record_id INT, card_no VARCHAR(20), charge_type VARCHAR(10), amount DECIMAL(8,2), exit_time DATETIME, exit_lane VARCHAR(10), FOREIGN KEY (record_id) REFERENCES parking_record(record_id) );拆分之后查询停车历史时用record_id关联两张表统计收费金额时只查charge_record交班表需要的“进场次数、出场次数、金额总计”分别从两张记录表聚合不互相干扰。建议在parking_record的plate_no、entry_time上建联合索引在charge_record的operator_id、exit_time上建索引这样报表查询不会扫描全表。课程设计的数据库规模不需要分表但索引设计能体现你对sql执行路径的理解。6. 用Visio把UML类图从“能看”改到“能答辩”6.1 用Visio画UML类图的四个关键步骤很多人搜“用visio怎么画uml类图”卡在第一步找不到合适的形状。打开Visio后在“新建”里选“软件和数据库”分类再选“UML模型图”左侧会自动出现两个形状库UML用例图、UML类图。如果只看到“基本流程图”形状说明模板选错了。拖出“类”形状后双击形状输入类名然后右键选择“形状显示选项”勾选“属性”“操作”和“可见性”类图才会出现- userId : int这类标准写法。属性区的每一行要按“可见性 属性名 : 类型”的格式例如- password : String操作区写 queryFreeSpace() : void。接着用左侧的“关联”工具在两个类之间画关系线双击关系线会弹出“UML关联属性”对话框在“类别”里可以选择泛化、聚合、组合、依赖多重性在“结束点”标签页里设置。6.2 类图答辩前的自检清单以下是我每次提交前会用的一张检查表按顺序过一遍能避免大部分扣分项检查项说明可见性符号private显示为-public显示为所有属性都要有继承线方向泛化线空心三角指向父类不能反依赖线样式虚线箭头只用于依赖不要和实现线混用多重性一对多必须写1和0..*不要留空类命名类名是单数名词不是表名也不是页面名关系数量每个实体类至少参与一条关系不能孤立最后一个技巧把核心类加粗用图层给不同包设置不同颜色导出图片前把画布背景改为白色并统一字体为宋体或微软雅黑。答辩时这类细节会直接影响老师对“软件工程素养”的第一印象。把多重性标完整再用“形状显示选项”把可见性符号全部打开这张类图就能作为数据模型论证的一页。本文还有配套的精品资源点击获取
