交互模型——聚焦'用户怎么用'
- 用例(Use Case)是需求捕获的主干,强调参与者与系统的协作目标;
- 顺序图(Sequence Diagram)刻画时序行为,适合验证操作流程合理性;
- 状态图(State Diagram)建模对象/页面/会话的状态生命周期(如登录态→浏览态→下单态→支付态);
- UI 原型是早期反馈载体,连接抽象模型与真实体验,降低后期返工成本。
功能模型——厘清'系统做什么 & 怎么做'
- 用户可见功能 = 外部契约(如'搜索商品''提交订单'),对应用例主事件流;
- 底层操作实现 = 内部职责分配(如 SearchController 调用 ProductService 查询 + 过滤 + 分页),宜用活动图(Activity Diagram)表达分支、并发与异常处理;
- 关键洞察:WebApp 的本质挑战常在于「信息组织方式」(如导航深度、链接语义、缓存策略)与「上下文敏感操作」(如权限动态控制、状态一致性维护),而非算法复杂度。
导航模型——解决'用户如何找到并抵达目标'
- 导航设计即信息架构(IA)+ 交互路径规划,需权衡效率(最短路径)、可预测性(一致的导航模式)与包容性(多入口、返回机制、面包屑、站点地图);
- 优先级设定应基于用户角色(如访客 vs 会员)、任务频次(高频操作置顶/快捷入口)及业务目标(如转化漏斗关键节点前置)。
结构化开发方法的价值锚点: 在需求稳定、领域清晰(如企业后台系统、政务服务平台)的 WebApp 中,其线性阶段划分(分析→设计→实现)能保障可追溯性、文档完备性与团队协同确定性,尤其利于合规审计与长期维护。
示例:用活动图思想伪代码表达'用户下单'底层操作流
def process_order(user, cart_items):
if not user.is_authenticated():
raise PermissionError("需登录")
if not validate_inventory(cart_items):
raise InventoryError("库存不足")
order = create_order(user, cart_items)
if charge_payment(order) == "success":
update_inventory(cart_items)
send_confirmation_email(order)
return redirect_to_success_page(order)
else:
rollback_order(order)
return redirect_to_payment_failure()
当用例中存在大量 «extend»(扩展)和 «include»(包含)关系时,直接为整个用例绘制单一顺序图极易导致消息泛滥、生命线冗长、控制流交织,丧失可读性与沟通价值。避免顺序图过度复杂化的关键在于分层建模、关注分离、按场景裁剪。以下是经过工程验证的实用技巧:
- 按主事件流 + 独立扩展流拆分顺序图
- 仅为主成功场景(Basic Flow)绘制核心顺序图,聚焦典型用户路径(如'正常下单');
- 将每个重要扩展点(如 «extend» 的'库存不足提示''优惠券失效校验')单独建模为轻量级扩展顺序图,标注其触发条件(如
[库存 check 返回 false])和切入位置(如 );


