案例示范：自己设计MyZip_myzip的写法-优快云博客

本文详细阐述了如何以质疑驱动的思路设计MyZip的逻辑架构，包括结构和行为设计，通过分层细化、分区引入和机制提取等手段进行子系统划分，以及如何运用序列图和灰盒包图进行行为设计。最后，通过贯穿案例PASS系统，展示如何在实际项目中应用这些设计原则。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

13.3.3 案例示范：自己设计MyZip

图13-18所示为MyZip的概念架构设计。它将和需求一起，影响MyZip的细化架构设计。

下面，主要演示如何以质疑驱动的思路，设计MyZip的逻辑架构视图。

首先，考虑结构方面的切分，如图13-19所示。不难看出，3种划分子系统的手段都运用了：

分层的细化。压缩实现层从原来的压缩控制层中分离出来。回忆本章所讲的"子系统划分策略背后的4大原则"。无论是从职责不同的角度，还是从所需技能的角度考虑，两者都应该分离成为单独的"子系统"。

分区的引入。界面交互层必须进一步分区，例如：支持右键菜单的"Windows外壳扩展"部分被独立。

机制的提取。例子是智能缓冲机制，它应该成为一个通用性的基础子系统。同时，为了使它可重用，缓冲区不负责"缓冲区已满"时的具体处理而是回调外部单元进行。再者，为了提高使用友好性，缓冲区具有一定"智能"，它会自动保存溢出的部分，从而简化使用缓冲区的接口。

然后，让切分出的职责协作起来，验证能否完成功能。图13-20所示的序列图即为一例，初步回答"能协作以支持压缩吗"的问题。请读者看图13-19，回忆本书提倡的"增量建模"技巧--不要急于"一口吃个胖子"。

如此循环，早晚要定义子系统的接口。图13-21是包-接口图，帮助架构师明确需要哪些接口（还没有到接口内方法定义一级）。

再次从结构设计跳到行为设计。现在该更明确地考虑压缩了，图13-22演示了ZipOneFile的设计。同样，遵循"先大局，后局部"的设计原则。具体设计决策是，让"控制"担负ZipOneFile的职责，而不是让"压缩实现"来担负--原因是希望"压缩实现"不须感知File的概念而能够更大程度上被重用（例如对数据包而非文件进行压缩）。

图13-23所示的行为设计，离明确接口的方法级定义的目标就不远了……

------------------------------------------------------------------------------------------------------------------------------------------------

13.4 更多经验总结

13.4.1 逻辑架构设计的10条经验要点

图13-24归纳了ADMEMS方法推荐的逻辑架构设计的10条经验要点，其中：如何划分子系统，如何定义接口，如何运用质疑驱动的思维套路等已介绍，其他几点仅在后续小节进行简述。

------------------------------------------------------------------------------------------------------------------------------------------------------

13.4.2 简述：逻辑架构设计中设计模式应用

设计模式是Class Level的设计，它如何用于架构一级的设计呢？

基本观点是：让Class和SubSystem搭上关系。不难理解，设计模式用于架构设计主要有两种方式：

明确子系统内的结构。

明确包间的协作关系。

如何做呢？答案是灰盒包图。图13-25说明了灰盒包图的意义，它打破了"子系统黑盒"，关心子系统中的关键类，从而可以更到位地说明子系统之间的协作关系，并成为设计模式应用的基础。

例如，对比图13-26和图13-27--背景是项目管理系统甘特图展现的问题。后者明确了子系统之间的交互机制，还显式地说明了Adapter设计模式的应用--这就是灰盒包图的价值。

-------------------------------------------------------------------------------------------------------------------------------------------------------

13.4.3 简述：逻辑架构设计的建模支持

工欲善其事，必先利其器。在实践中必须选择最合适的模型，甚至做一些改造工作使UML更适合特定的实践目的。例如，灰盒包图就是一种"专门说明重要子系统设计"的UML图的应用。

另外，包-接口图是类图的一种特定形式，它包含"包（package）"和"接口（interface）"两种主要元素。这种图（可参考图13-20）的作用很专一：说明包之间的协作需要哪些接口。逻辑架构设计中，包-接口图式是从结构设计到行为设计的思维桥梁。

最后，本章讲"逻辑架构设计的整体思维套路"时已亮明了观点：逻辑架构的设计，应该使结构设计和行为设计相分离。这样才利于更有效地思维。不信？请看图13-28所示的"设计图"（这是很多设计者习惯的思维方式）。思维清楚吗？思维混乱的原因：将结构和行为过多地混在了一起。

本书推荐用序列图（它较专注于行为设计）辅助逻辑架构设计，尽量不要用协作图（虽然在UML 1.4中，它和序列图等价，但从形式上它的"结构气"太重）。

-------------------------------------------------------------------------------------------------------------------------------

13.5 贯穿案例

下面，继续本书的贯穿案例：PASS系统的架构设计。首先应注意两点：

第一，细化架构设计的重要"输入"之一是概念架构设计，不应忽视，毕竟细化架构设计是整个架构设计过程中的一个阶段。例如，在第9章进行的"基于鲁棒图的初步设计"，以及第9章进行的高层分割考虑（如图13-29所示）。

第二，5视图方法的运用，总体而言是5个视图的设计穿插进行的，对复杂系统而言，根本不可能将逻辑视图设计完全之后再考虑其他视图。而本例的PASS系统具有很强的分布特点，所以必然较早地考虑到物理视图对逻辑设计的影响。例如，PASS服务器作为一个物理架构元素的"节点（Node）"，它之上"跑"的逻辑架构元素"逻辑层（Layer）"有哪些呢？如图13-30所示，它包含了业务层、集成层、数据访问层，但未包括展现层程序。