UML中的包与实例建模

# UML 中的包与实例建模 ## 1. UML 包的标准元素与扩展机制 UML 的所有扩展机制都适用于包。通常，我们会使用标记值为包添加新属性（如指定包的作者），使用构造型来定义新的包类型（如封装操作系统服务的包）。 UML 定义了适用于包的五种标准构造型： | 构造型 | 说明 | | --- | --- | | facade | 表示仅作为其他包视图的包 | | framework | 表示主要由模式组成的包 | | stub | 作为另一个包公共内容代理的包 | | subsystem | 表示所建模的整个系统的独立部分的包 | | system | 表示所建模的整个系统的包 | 除了这五种包构造型外，还会使用通过标准构造型 `import` 指定的依赖关系。其中，`facade` 和 `stub` 这两种构造型有助于管理非常大的模型。 - **facade 的使用**：用于为复杂的包提供简化视图。例如，系统中有 `BusinessModel` 包，可定义不同的 `facade` 包，将其部分元素分别展示给不同用户群体。操作步骤如下： 1. 确定要展示给不同用户群体的元素子集。 2. 定义 `facade` 包，通过 `import` 依赖关系引入这些元素子集，且 `facade` 包不拥有这些元素。 - **stub 的使用**：当使用工具将系统拆分为多个包，且需要在不同时间和地点进行操作时使用。例如，开发团队分布在两个地点，一个地点的团队为另一个团队所需的包提供 `stub`。这样团队可以独立工作，`stub` 包能捕捉系统中需要谨慎管理的衔接点。 ## 2. 常见的建模技术 - 建模元素组 使用包的最常见目的是将建模元素组织成可以命名和作为一个集合进行操作的组。对于简单应用，可能不需要包，所有抽象都可放在一个包中。但对于其他系统，系统中的类、接口、组件、节点和图往往会自然地分组，可将这些组建模为包。 类和包有一个重要区别：类是问题或解决方案中事物的抽象；包是用于组织模型中事物的机制。包没有标识（即不能有包的实例，在运行系统中不可见），而类有标识（类有实例，是运行系统的元素）。 ### 2.1 包的分组方式 - **分组相同类型元素**：例如，将系统设计视图中的所有类及其关系分离到一系列包中，使用 UML 的 `import` 依赖关系控制这些包之间的访问。同样，可对系统实现视图中的所有组件进行类似组织。 - **分组不同类型元素**：对于地理上分布的团队开发的系统，可将包作为配置管理的单元，将每个团队可以单独签入和签出的所有类和图放入包中。通常，也会使用包来分组建模元素及其关联的图。 ### 2.2 建模元素组的步骤 1. 扫描特定架构视图中的建模元素，寻找概念或语义上彼此接近的元素组。 2. 将每个元素组用包包围。 3. 对于每个包，区分哪些元素应在包外部可访问，将其标记为公共元素，其他元素标记为受保护或私有元素。不确定时，隐藏元素。 4. 通过 `import` 依赖关系显式连接依赖其他包的包。 5. 对于包族，通过泛化将专用包连接到其更通用的部分。 例如，在信息系统的设计视图中，可将类组织成经典的三层架构包： - `User Services` 包：提供用于呈现信息和收集数据的可视化界面。 - `Data Services` 包：维护、访问和更新数据。 - `Business Services` 包：连接其他两个包的元素，包含管理用户执行业务任务请求的所有类和其他元素，包括规定数据操作策略的业务规则。 ```mermaid graph LR classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; A(User Services):::process --> C(Business Services):::process B(Data Services):::process --> C(Business Services):::process ``` 在渲染此类模型时，通常希望展示每个包的核心元素，还可展示每个包的文档标记值，以明确包的用途。 ## 3. 常见的建模技术 - 建模架构视图 使用包对相关元素进行分组很重要，对于开发复杂模型是必不可少的。当考虑软件系统架构的不同视图时，可使用包来建模架构视图。 视图是对系统组织和结构的投影，专注于系统的特定方面。这