企业官网建设流程全解析

这张是一张标准UML包图（Package Diagram），用来描述一个购物系统中各个模块（包）之间的依赖关系。

一、核心元素：包（Package）

图里的每个矩形（带小标签）都是一个包（模块），代表系统中一个独立的功能单元：

• Web Shopping/Mobile Shopping/Phone Shopping/Mail Shopping：不同渠道的购物入口模块
• Payment：支付模块
• Shopping Cart：购物车模块
• Customer：客户模块
• Inventory：库存模块

二、包图里的标准关系（逐个解释）

1. «use»（使用依赖 / Usage Dependency）

• 含义：表示一个包的元素需要用到另一个包的元素，是最常见的包依赖关系。
• 例子：
  • Web Shopping→ «use» →Payment：Web购物模块需要调用支付模块的功能。
  • Mail Shopping→ «use» →Shopping Cart：邮件购物模块需要使用购物车模块。

2. «merge»（包合并 / Package Merge）

• 含义：表示将多个包的定义合并到一个公共的命名空间，常用于复用和扩展模型。
• 例子：
  所有渠道模块（Web/Mobile/Phone/Mail）都 «merge» 到一起，表示它们共享相同的基础定义，形成一个统一的“购物渠道”概念。

3. «access»（私有导入 / Private Import）

• 含义：表示一个包私有地导入另一个包的元素，导入的元素不会暴露给外部。
• 例子：
  Payment→ «access» →Shopping Cart：支付模块内部使用购物车模块的元素，但不会把这些元素暴露给其他包。

4. «import»（公共导入 / Public Import）

• 含义：表示一个包公共地导入另一个包的元素，导入的元素会成为当前包的公共元素，外部包可以直接访问。
• 例子：
  • Payment→ «import» →Customer：支付模块公开导入客户模块的元素，外部包可以直接使用这些元素。
  • Shopping Cart→ «import» →Inventory：购物车模块公开导入库存模块的元素。

三、整体逻辑（这个系统的模块关系）

1. 渠道层（Web/Mobile/Phone/Mail Shopping）：所有购物入口，它们都依赖支付和购物车模块，并且共享基础定义（通过«merge»）。
2. 业务模块层（Payment、Shopping Cart）：核心业务模块，依赖底层的客户和库存模块。
3. 基础模块层（Customer、Inventory）：提供客户和库存的基础数据，被上层模块导入和使用。

四、一句话总结

这张包图的核心目的是：

• 清晰展示系统模块的划分
• 明确模块间的依赖、导入、复用关系
• 让你一眼看懂哪个模块依赖哪个模块、依赖的方式是什么

1. «use» 使用（最常见）

UML 含义

A 包使用B 包，但不导入B 包，只是调用功能。

代码示例

// 包A：WebShoppingpackagecom.shopping.web;// 注意：这里【没有 import 支付包】publicclassWebOrder{publicvoidpay(){// 直接调用，但不导入com.payment.PaymentService.process();}}

特点

• 没有 import 语句
• 只是依赖、调用、使用
• 不把对方类引入自己命名空间

2. «import» 公共导入（公共导包）

UML 含义

A 包公开导入B 包，外部能通过 A 访问 B。

代码示例

// 包A：Paymentpackagecom.payment;// 公共导入 Customer 包importcom.customer.*;publicclassPaymentService{publicvoidpay(){// 直接用，不用写全路径Customercustomer=newCustomer();}}

特点

• 有 import
• 导入的类对外可见
• 别人可以通过 Payment 包看到 Customer 类

3. «access» 私有导入（内部导包）

UML 含义

A 包私有导入B 包，只有自己能用，外部看不见。

代码示例

// 包A：Paymentpackagecom.payment;// 私有导入（access 语义）importcom.inventory.Inventory;publicclassPaymentService{// 只能在内部用 InventoryprivatevoidcheckStock(){Inventory.check();}}

特点

• 导包了，但对外隐藏
• 外部包不能通过 Payment 访问 Inventory
• 相当于私有依赖

4. «merge» 合并（扩展/复用）

UML 含义

把 B 包的功能合并到 A 包，A 直接扩展 B。
最常用于：多个渠道共用一套基础购物逻辑

代码示例

// 基础包：BaseShoppingpackagecom.base;publicclassBaseCart{voidaddItem(){}}

// WebShopping 包 merge 合并 BaseShoppingpackagecom.web;// merge = 继承 + 全功能合并importcom.base.BaseCart;publicclassWebCartextendsBaseCart{// 直接拥有 BaseCart 的所有功能}

特点

• 合并 =完全继承 + 扩展

• 子包拥有父包全部能力

• 用于通用功能抽取、多渠道复用

• «use»：我用你，但不导入你（依赖调用）

• «import»：我公开导入你，大家都能看见

• «access»：我私有导入你，只有我自己能用

• «merge»：我合并你，把你的功能变成我的功能

«import»：公共导入，被导入的元素成为导入包的公共成员，外部可见。
«access»：私有导入，被导入的元素仅在导入包内部可见，外部不可见。
«import» = 我借用你（你还是你，我还是我）
«merge» = 我合并你（你变成我，我扩展你）

📐 UML 包图（Package Diagram）核心组成部分

结合你提供的 Servlet 2.5 包图，UML 包图的标准组成可分为核心元素、关系元素、辅助元素三大类，每类都有明确的定义和作用，下面是结构化拆解：

一、核心元素（包图的主体）

1. 包（Package）

包图最基础的容器，用于分组管理语义相关的UML元素（类、接口、子包等），是包图的核心单元。

• 图形表示：带标签的矩形，上方小矩形标注包名，下方大矩形展示包内元素（也可仅画小矩形，元素单独列出）。
• 示例：图中的javax.servlet、javax.servlet.http就是两个顶级包，分别封装了通用Servlet核心和HTTP协议扩展的所有元素。
• 作用：实现模块化、分层解耦，清晰划分系统的架构边界（如核心层、扩展层）。

2. 包内的模型元素

包的内容，是包图承载的业务/技术逻辑主体，常见类型包括：

• 类/接口/抽象类：如图中的Servlet（接口）、HttpServlet（抽象类）、Cookie（类）
• 异常类：如图中的ServletException、UnavailableException
• 子包：包内可嵌套子包，实现更细粒度的分层（本图未展示嵌套）
• 其他UML元素：枚举、协作、用例等（Servlet包图中未涉及）

二、关系元素（包与元素、元素与元素的连接）

用于描述包之间、包内元素之间的依赖、继承等逻辑关系，是包图的“骨架”。

1. 包之间的关系

2. 包内元素的关系（复用UML通用关系）

包图中包内元素的关系与类图完全一致，用于描述元素间的逻辑关联：

三、辅助元素（包图的标注与说明）

1. 构造型（Stereotype）

用于对元素/关系进行语义扩展，用<< >>标注，明确元素的类型。

• 示例：图中所有接口都标注了<<interface>>，明确其为接口类型，而非普通类。

2. 约束与标注

• 接口实现标注：如Serializable、Cloneable用空心圆标注，说明类实现了该接口。
• 依赖说明：部分依赖关系用<<use>>标注，明确“使用”依赖（如ServletContext被ServletRequest使用）。
• 包版本/命名空间：包图左上角可标注包的版本（如图中的《API》Java Servlet 2.5），明确规范版本。

3. 注释与说明

• 用于补充包图的额外信息，如图右上角的uml-diagrams.org是来源标注，不影响模型逻辑。

四、结合Servlet包图的完整组成对照

五、包图的核心设计原则（补充）

1. 高内聚、低耦合：包内元素语义高度相关，包间依赖尽可能少（如Servlet核心包与HTTP扩展包的分层）
2. 开闭原则：包的职责单一，扩展包依赖核心包，核心包不反向依赖扩展包
3. 无循环依赖：包之间不能出现双向依赖（如A依赖B，B又依赖A）
4. 分层清晰：按架构分层划分包（如核心层、业务层、视图层），符合系统架构逻辑

💡 延伸：包图与类图的区别