交互模型——聚焦'用户怎么用'
- 用例（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]）和切入位置（如 ）；
