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 包的構(gòu)造型

8.4.1 封裝和模型

包是 UML 模型的主要組織和 CM 結(jié)構(gòu)愉老。 UML 工具通常與標(biāo)準(zhǔn) CM 工具合作，以允許在包邊界上進行簽入、簽出忱辅、變更管理榆芦、比較、基線和恢復(fù)粥惧。

當(dāng)項目是新的并且有很多變化時键畴，包往往很小，因為如果您必須簽出包才能開始編輯突雪，您不想阻止其他建模者進行任何工作起惕。另一方面，當(dāng)維護工作引起的更改往往會波及多個包時咏删，重復(fù)簽出和簽入的小包將導(dǎo)致工作過程延遲惹想。有些項目會隨著項目的發(fā)展而改變它們的包結(jié)構(gòu)，但最好選擇大小合適的包來捕獲密切相關(guān)的元素督函，這樣典型的變化只會影響一個包嘀粱。

另一個考慮因素是包往往是審查結(jié)構(gòu)激挪。就像代碼一樣，你的模型應(yīng)該被審查锋叨，所以在包的最低級別垄分，它們應(yīng)該被調(diào)整為方便同行審查的模型。

UML 中的每個 Element 都必須完全由另一個更高級別的 Element 擁有娃磺，除了頂級 Packages薄湿。此要求產(chǎn)生必須以 Package 結(jié)尾的所有權(quán)鏈。這就是使用包作為組織元素的起源豌鸡。

Package 的常見構(gòu)造型之一允許建模者表明我們正在通過組織原則拆分模型嘿般。構(gòu)造型是 ?model?，它表明包的內(nèi)容旨在成為基于建模方面的系統(tǒng)的完整版本涯冠。如果您還記得我們在第 2 章“什么是 UML炉奴？”末尾的討論，我們討論了不同類型的建模：例如概念化蛇更、需求分析瞻赶、分析和設(shè)計，如果您有一個包派任，其全部內(nèi)容遵循以下之一在這些方面砸逊，您將使用 ?model? 的構(gòu)造型標(biāo)記包。如何

我們?nèi)绾问褂眠@些“模型”主要取決于項目方法掌逛。每個模型都可以在特定抽象級別提供系統(tǒng)的完整視圖师逸。如果不是基于建模的類型，模型可能基于元建模級別（例如豆混，MO篓像、M1 等）或建模階段。許多項目在計劃的時間都有正式的官方審查皿伺，例如 SRR（系統(tǒng)需求審查）员辩、SDR（系統(tǒng)設(shè)計審查）、PDR（初步設(shè)計審查）或 CDR（關(guān)鍵設(shè)計審查）或 TRR（測試準(zhǔn)備審查）鸵鸥。在這些時間生成的模型保存在“模型”包中并建立基線奠滑，以便項目返回并審查它們。作為包的模型也是命名空間妒穴，因此在每個模型中具有相同命名的元素是沒有問題的宋税。

根據(jù)方法論，單獨的“模型”可能通過依賴鏈連接宰翅。有一些特殊類型的依賴項弃甥，但不需要在這些情況下使用。抽象將兩個 NamedElement 關(guān)聯(lián)起來汁讼，它們在不同的抽象級別或從不同的角度表示相同的概念淆攻。表 8.3 中的任何抽象都可以與解釋映射如何工作的字符串相關(guān)聯(lián)阔墩。

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

將表示相同概念但處于不同抽象級別或來自不同觀點的兩個元素或元素集相關(guān)聯(lián)。與構(gòu)造型相鄰瓶珊，可能是解釋映射如何工作的字符串

?derive?

A calculable relationship between levels

級別之間的可計算關(guān)系

?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

箭頭指向元素啸箫，這些元素充當(dāng)對實現(xiàn)或?qū)崿F(xiàn)目標(biāo)元素的尾部元素的要求。我們經(jīng)常將這種關(guān)系顯示為帶有空心三角形箭頭的虛線

?refine??A relationshipbetween two different levels of abstraction

兩個不同抽象層次之間的關(guān)系

?trace??A generic relationship between differentversions. May be bi-directional

不同版本之間的通用關(guān)系伞芹。 可能是雙向的

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? 構(gòu)造型的 Package。 右上角的可選三角形裝飾 A 表示其模型狀態(tài)唱较。 模型可能有一個視點字段扎唾，它使用一個字符串來記錄該模型的組織原則或視角，見圖 8.20南缓。

許多建模者將他們的頂級包（不包含在其他東西中的包）制作成“模型”胸遇。 但是，這不是必需的汉形，并且會阻止模型包含在其他包或模型中（如圖 8.20 所示）纸镊。 與大多數(shù)模型的使用一樣，項目方法將決定您的實踐概疆。

8.4.2 Miscellaneous Stereotypes of Packages????包的各種構(gòu)造型

?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.

構(gòu)造型 ?MODELLIBRARY? 表明它的大部分內(nèi)容被其他包或模型使用逗威。 通常，我們使用 ?modelLibrary? 來包含系統(tǒng)中其他包可以使用的常見類型岔冀、單元凯旭、實用程序或部件。 ?modelLibrary? 將被標(biāo)記為公開可見并可能“導(dǎo)入”到頂級包中 - 確保所有系統(tǒng)包的可見性和可訪問性使套。

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? 包含共享我的許多其他系統(tǒng)包的基礎(chǔ)設(shè)施和架構(gòu)元素。 “框架”通常包括事件和錯誤處理程序童漩、消息傳遞、日志記錄春锋、自檢矫膨、內(nèi)置測試、診斷和安全實施期奔。

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.

雖然配置文件（及其相關(guān)的配置文件圖表）不包括在 OCUP-2 考試的基礎(chǔ)級別侧馅，但您需要了解它們的目的和用途。 除了 Profile 構(gòu)造型之外呐萌，配置文件類似于標(biāo)準(zhǔn)包馁痴。概要文件通常包含“元類”（參見第 4 章：UML 的組織），它們被裁剪以幫助執(zhí)行項目的方法或報告和狀態(tài)機制肺孤。 您可以使用它來創(chuàng)建元類或構(gòu)造型罗晕，但通常只允許一個人參與一個項目济欢。 當(dāng)然，這些配置文件必須可供項目中的每個人使用小渊，并且難以創(chuàng)建法褥，可能會引入可移植性問題。

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? 的內(nèi)容圖表都有一個<kind > 字段 pkg 或 package 以及圖表標(biāo)題中的命名空間名稱酬屉。 在很多情況下半等，<kind>字段可以省略，因為它可以由內(nèi)容決定呐萨。 如果該圖主要顯示包及其關(guān)系（例如杀饵，導(dǎo)入、訪問谬擦、依賴或抽象）切距，則該圖將被視為包圖。 如果該圖主要顯示類怯屉、泛化和關(guān)聯(lián)蔚舀，則該圖將被視為類圖，盡管有標(biāo)題锨络。 如果圖表主要顯示實例赌躺，則將其視為實例圖。 概要圖看起來像包圖羡儿，但支持稍微不同的表示法礼患，允許擴展或限制現(xiàn)有元類和構(gòu)造型的定義。

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>> 是一種包掠归，表示特定方面的系統(tǒng)模型缅叠，可以在模型中聲明。

? 單獨的“模型”包通常通過一種“抽象”關(guān)系來連接虏冻。

?modellibrarys?和 ?frameworks? 都用于包含可重用的元素類型肤粱、部件、單元和架構(gòu)基礎(chǔ)設(shè)施厨相。

? 配置文件是一種包和相關(guān)圖表领曼，允許建模者定制項目。