Packagesare the primary organizing and CM structure for UML Models. UML tools oftencooperate with standard CM tools to allow check-in, check-out, changemanagement, compare, baseline, and restore on Package boundaries.
Whenprojects are new and subject to many changes, Packages tend to be small,because if you have to check out a Package to start editing, you do not want tolock out other modelers from doing any work. On the other hand, when maintenancework is causing changes that tend to ripple through multiple Packages, smallPackages with repeated check-outs, and check-ins will cause delay to theworking process. Some projects will change their Package structure as theproject evolves, but it is best to pick Packages properly sized to captureclosely related Elements so typical changes would only affect one Package.
Another considerationis that Packages tend to be the review structure. Just as with code, your modelshould be reviewed, so at the lowest level of Packages, they should be sized tobe conveniently peer-reviewed models.
EveryElement in UML must be owned by exactly one other higher level Element, exceptthe top-level Packages .This requirement produces a chain of ownership thatmust end in a Package. This is the origin of the use of Packages as theorganizing Element.
One of thecommon stereotypes of Package allows the modeler to show that we are splittingthe model by organizing principles. The stereotype is «model» which indicatesthat the contents of the Package are intended to be a complete version of yoursystem based on a modeling aspect. If you remember our discussion at the end ofChapter 2, What is UML?, we talked about different types of a modeling: Such asconceptualization, requirements analysis, analysis, and design, If you have aPackage whose totality of contents follows one of these aspects, you would flagthe Package with the stereotype of «model».
How we usethese «models» depends mostly on project methodology. Each model can offer up acomplete view of the system at a particular level of abstraction. If not basedon the types of modeling, the models might be based on a metamodeling level(e.g., MO, M1, ...), or modeling phase. Many projects have formal officialreviews at a planned time, e.g., SRR (System Requirements Review), SDR (SystemDesign Review), PDR (Preliminary Design Review), or CDR (Critical DesignReview), or TRR (Test Readiness Review). The models produced at these times arekept in «model» Packages and baselined so that the project go back and reviewthem. Models as Packages, are also Namespaces, so there is no problem havingidentically named Elements in each model.
Depending on the methodology, the separate«models» may be connected by a chain of dependencies. There are special typesdependencies are, but are not required to be used in these circumstances. Anabstraction relates two NamedElements that represent the same concept atdifferent levels of abstraction or from different viewpoints. Any of theabstractions in Table 8.3 can be associated with a string that explains how themapping works.
8.4 包的构造型
8.4.1 封装和模型
包是 UML 模型的主要组织和 CM 结构。 UML 工具通常与标准 CM 工具合作，以允许在包边界上进行签入、签出、变更管理、比较、基线和恢复。
当项目是新的并且有很多变化时，包往往很小，因为如果您必须签出包才能开始编辑，您不想阻止其他建模者进行任何工作。另一方面，当维护工作引起的更改往往会波及多个包时，重复签出和签入的小包将导致工作过程延迟。有些项目会随着项目的发展而改变它们的包结构，但最好选择大小合适的包来捕获密切相关的元素，这样典型的变化只会影响一个包。
另一个考虑因素是包往往是审查结构。就像代码一样，你的模型应该被审查，所以在包的最低级别，它们应该被调整为方便同行审查的模型。
UML 中的每个 Element 都必须完全由另一个更高级别的 Element 拥有，除了顶级 Packages。此要求产生必须以 Package 结尾的所有权链。这就是使用包作为组织元素的起源。
Package 的常见构造型之一允许建模者表明我们正在通过组织原则拆分模型。构造型是 «model»，它表明包的内容旨在成为基于建模方面的系统的完整版本。如果您还记得我们在第 2 章“什么是 UML？”末尾的讨论，我们讨论了不同类型的建模：例如概念化、需求分析、分析和设计，如果您有一个包，其全部内容遵循以下之一在这些方面，您将使用 «model» 的构造型标记包。如何
我们如何使用这些“模型”主要取决于项目方法。每个模型都可以在特定抽象级别提供系统的完整视图。如果不是基于建模的类型，模型可能基于元建模级别（例如，MO、M1 等）或建模阶段。许多项目在计划的时间都有正式的官方审查，例如 SRR（系统需求审查）、SDR（系统设计审查）、PDR（初步设计审查）或 CDR（关键设计审查）或 TRR（测试准备审查）。在这些时间生成的模型保存在“模型”包中并建立基线，以便项目返回并审查它们。作为包的模型也是命名空间，因此在每个模型中具有相同命名的元素是没有问题的。
根据方法论，单独的“模型”可能通过依赖链连接。有一些特殊类型的依赖项，但不需要在这些情况下使用。抽象将两个 NamedElement 关联起来，它们在不同的抽象级别或从不同的角度表示相同的概念。表 8.3 中的任何抽象都可以与解释映射如何工作的字符串相关联。
Table 8.3Types of Abstractions AbstractionType 抽象类型
«abstraction»
Relates two Elements or sets of Elements that denote the same concept but atdifferent levels of abstraction or from different viewpoints. Adjacent to thestereotype may be a string that explains how the mapping works
将表示相同概念但处于不同抽象级别或来自不同观点的两个元素或元素集相关联。与构造型相邻，可能是解释映射如何工作的字符串
«derive»
A calculable relationship between levels
级别之间的可计算关系
«realize»
The arrowhead points to Elements that act as requirements to the Elements atthe tail that realize or implement target Elements. We often show thisrelationship as a dashed line with a hollow triangular arrowhead
箭头指向元素，这些元素充当对实现或实现目标元素的尾部元素的要求。我们经常将这种关系显示为带有空心三角形箭头的虚线
«refine» A relationshipbetween two different levels of abstraction
两个不同抽象层次之间的关系
«trace» A generic relationship between differentversions. May be bi-directional
不同版本之间的通用关系。 可能是双向的
As a typeof Package, models look like Package with the stereotype of «model». Theoptionally triangle adornment A in the upper right to indicate their modelstatus. Models may have a viewpoint field that uses a string to document theorganizing principle or perspective for that model, see Fig. 8.20.
Manymodelers make their top-level Packages (the ones not contained by other things)into «models». However, this is not required and would prevent models frombeing contained in other Packages or models (as shown in Fig. 8.20). As withmost use of models, the project methodology will determine your practice.
作为 Package 的一种类型，模型看起来像带有«model» 构造型的 Package。 右上角的可选三角形装饰 A 表示其模型状态。 模型可能有一个视点字段，它使用一个字符串来记录该模型的组织原则或视角，见图 8.20。
许多建模者将他们的顶级包（不包含在其他东西中的包）制作成“模型”。 但是，这不是必需的，并且会阻止模型包含在其他包或模型中（如图 8.20 所示）。 与大多数模型的使用一样，项目方法将决定您的实践。
8.4.2 Miscellaneous Stereotypes of Packages 包的各种构造型
8.4.2.1 ModelLibrary 模型库
Thestereotype «MODELLIBRARY» indicates that the majority of its contents are usedby other Packages or models. Typically, we use a «modelLibrary» to containcommon types, units, utilities, or parts that other Packages in the system canuse. The «modelLibrary» will be marked a publicly visible and potentially«imported» into the top-level Package-Ensuring visibility and accessibility byall of the system's Packages.
构造型 «MODELLIBRARY» 表明它的大部分内容被其他包或模型使用。 通常，我们使用 «modelLibrary» 来包含系统中其他包可以使用的常见类型、单元、实用程序或部件。 «modelLibrary» 将被标记为公开可见并可能“导入”到顶级包中 - 确保所有系统包的可见性和可访问性。
8.4.2.2 Framework 框架
Similar to a «modelLibrary», a «FRAMEWORK»contains the infrastructure and architectural Elements shared my many of theother system Packages. A «framework» usually includes event and error handlers,message passing, logging, self-check, built-in-test, diagnostics, and securityenforcement.
类似于 «modelLibrary»，一个 «FRAMEWORK» 包含共享我的许多其他系统包的基础设施和架构元素。 “框架”通常包括事件和错误处理程序、消息传递、日志记录、自检、内置测试、诊断和安全实施。
8.4.2.3 Profiles
AlthoughPROFILES (and their associated PROFILE DIAGRAMS) are not included theFoundational level of the OCUP-2 examinations, you need to know their purposeand use. Profiles are similar to the standard Package except for the Profilestereotype. Profiles typically contain «metaclasses» (see Chapter 4: TheOrganization of UML) that are tailored to aid in enforcing the project's methodologyor reporting and status regime. You can use it to create or metaclasses orstereotypes, though typically only one person on a project is allowed. Ofcourse, these Profiles must be available to everyone on the project, and aredifficult to create, potentially introducing portability problems.
虽然配置文件（及其相关的配置文件图表）不包括在 OCUP-2 考试的基础级别，但您需要了解它们的目的和用途。 除了 Profile 构造型之外，配置文件类似于标准包。概要文件通常包含“元类”（参见第 4 章：UML 的组织），它们被裁剪以帮助执行项目的方法或报告和状态机制。 您可以使用它来创建元类或构造型，但通常只允许一个人参与一个项目。 当然，这些配置文件必须可供项目中的每个人使用，并且难以创建，可能会引入可移植性问题。
8.4.2.4 Diagrams
Diagrams ofthe contents of «model, «modelLibrarys», «frameworks», and «profiles» all havea field of pkg or package and the name of the Namespace in thediagram header. In many cases, the field can be omitted as it canbe determined by the contents. If the diagram primarily shows Packages andtheir relationships (eg. imports, accesses, dependencies, or abstractions), thediagram would be considered a Package Diagram. If the diagram primarily showsClasses, generalization, and associations, the diagram would be considered aClass Diagram, despite the header. If the diagram primarily shows instances, itwould be considered an Instance Diagram. A Profile Diagram looks like a PackageDiagram but supports a slightly different notation that allows the extension ofor restriction of existing meta- classes and the definition of stereotypes. Wewill not cover the details in this book nor are they on the OCUP-2 Foundationalexam.
«modelLibrarys», «frameworks» 和 «profiles» 的内容图表都有一个<kind > 字段 pkg 或 package 以及图表标题中的命名空间名称。 在很多情况下，<kind>字段可以省略，因为它可以由内容决定。 如果该图主要显示包及其关系（例如，导入、访问、依赖或抽象），则该图将被视为包图。 如果该图主要显示类、泛化和关联，则该图将被视为类图，尽管有标题。 如果图表主要显示实例，则将其视为实例图。 概要图看起来像包图，但支持稍微不同的表示法，允许扩展或限制现有元类和构造型的定义。
POINTS TO REMEMBER
A<> is a type of Package that represents a model of thesystem for a particular aspect, which may be declared in the model.
Separate«model» Packagesare often connected by a type of «abstraction» relationship.
Both «modellibrarys» and «frameworks» are used to contain reusable Elementstypes, parts, units, and architectural infrastructure.
A Profile is a type of Package and an associated diagram that allows the modelerto tailor project.
• <<model>> 是一种包，表示特定方面的系统模型，可以在模型中声明。
• 单独的“模型”包通常通过一种“抽象”关系来连接。
«modellibrarys»和 «frameworks» 都用于包含可重用的元素类型、部件、单元和架构基础设施。
• 配置文件是一种包和相关图表，允许建模者定制项目。
