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 工具合作，以允許在包邊界上進(jìn)行簽入、簽出、變更管理、比較、基線和恢復(fù)。
當(dāng)項(xiàng)目是新的并且有很多變化時(shí)，包往往很小，因?yàn)槿绻仨毢灣霭拍荛_(kāi)始編輯，您不想阻止其他建模者進(jìn)行任何工作。另一方面，當(dāng)維護(hù)工作引起的更改往往會(huì)波及多個(gè)包時(shí)，重復(fù)簽出和簽入的小包將導(dǎo)致工作過(guò)程延遲。有些項(xiàng)目會(huì)隨著項(xiàng)目的發(fā)展而改變它們的包結(jié)構(gòu)，但最好選擇大小合適的包來(lái)捕獲密切相關(guān)的元素，這樣典型的變化只會(huì)影響一個(gè)包。
另一個(gè)考慮因素是包往往是審查結(jié)構(gòu)。就像代碼一樣，你的模型應(yīng)該被審查，所以在包的最低級(jí)別，它們應(yīng)該被調(diào)整為方便同行審查的模型。
UML 中的每個(gè) Element 都必須完全由另一個(gè)更高級(jí)別的 Element 擁有，除了頂級(jí) Packages。此要求產(chǎn)生必須以 Package 結(jié)尾的所有權(quán)鏈。這就是使用包作為組織元素的起源。
Package 的常見(jiàn)構(gòu)造型之一允許建模者表明我們正在通過(guò)組織原則拆分模型。構(gòu)造型是 ?model?，它表明包的內(nèi)容旨在成為基于建模方面的系統(tǒng)的完整版本。如果您還記得我們?cè)诘?2 章“什么是 UML？”末尾的討論，我們討論了不同類(lèi)型的建模：例如概念化、需求分析、分析和設(shè)計(jì)，如果您有一個(gè)包，其全部?jī)?nèi)容遵循以下之一在這些方面，您將使用 ?model? 的構(gòu)造型標(biāo)記包。如何
我們?nèi)绾问褂眠@些“模型”主要取決于項(xiàng)目方法。每個(gè)模型都可以在特定抽象級(jí)別提供系統(tǒng)的完整視圖。如果不是基于建模的類(lèi)型，模型可能基于元建模級(jí)別（例如，MO、M1 等）或建模階段。許多項(xiàng)目在計(jì)劃的時(shí)間都有正式的官方審查，例如 SRR（系統(tǒng)需求審查）、SDR（系統(tǒng)設(shè)計(jì)審查）、PDR（初步設(shè)計(jì)審查）或 CDR（關(guān)鍵設(shè)計(jì)審查）或 TRR（測(cè)試準(zhǔn)備審查）。在這些時(shí)間生成的模型保存在“模型”包中并建立基線，以便項(xiàng)目返回并審查它們。作為包的模型也是命名空間，因此在每個(gè)模型中具有相同命名的元素是沒(méi)有問(wèn)題的。
根據(jù)方法論，單獨(dú)的“模型”可能通過(guò)依賴(lài)鏈連接。有一些特殊類(lèi)型的依賴(lài)項(xiàng)，但不需要在這些情況下使用。抽象將兩個(gè) NamedElement 關(guān)聯(lián)起來(lái)，它們?cè)诓煌某橄蠹?jí)別或從不同的角度表示相同的概念。表 8.3 中的任何抽象都可以與解釋映射如何工作的字符串相關(guān)聯(lián)。
Table 8.3Types of Abstractions? ? ? ?AbstractionType??????????? 抽象類(lèi)型
?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
將表示相同概念但處于不同抽象級(jí)別或來(lái)自不同觀點(diǎn)的兩個(gè)元素或元素集相關(guān)聯(lián)。與構(gòu)造型相鄰，可能是解釋映射如何工作的字符串
?derive?
A calculable relationship between levels
級(jí)別之間的可計(jì)算關(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)對(duì)實(shí)現(xiàn)或?qū)崿F(xiàn)目標(biāo)元素的尾部元素的要求。我們經(jīng)常將這種關(guān)系顯示為帶有空心三角形箭頭的虛線
?refine??A relationshipbetween two different levels of abstraction
兩個(gè)不同抽象層次之間的關(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 的一種類(lèi)型，模型看起來(lái)像帶有?model? 構(gòu)造型的 Package。 右上角的可選三角形裝飾 A 表示其模型狀態(tài)。 模型可能有一個(gè)視點(diǎn)字段，它使用一個(gè)字符串來(lái)記錄該模型的組織原則或視角，見(jiàn)圖 8.20。
許多建模者將他們的頂級(jí)包（不包含在其他東西中的包）制作成“模型”。 但是，這不是必需的，并且會(huì)阻止模型包含在其他包或模型中（如圖 8.20 所示）。 與大多數(shù)模型的使用一樣，項(xiàng)目方法將決定您的實(shí)踐。
8.4.2 Miscellaneous Stereotypes of Packages????包的各種構(gòu)造型
?8.4.2.1 ModelLibrary????模型庫(kù)
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? 來(lái)包含系統(tǒng)中其他包可以使用的常見(jiàn)類(lèi)型、單元、實(shí)用程序或部件。 ?modelLibrary? 將被標(biāo)記為公開(kāi)可見(jiàn)并可能“導(dǎo)入”到頂級(jí)包中 - 確保所有系統(tǒng)包的可見(jiàn)性和可訪問(wèn)性。
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.
類(lèi)似于 ?modelLibrary?，一個(gè) ?FRAMEWORK? 包含共享我的許多其他系統(tǒng)包的基礎(chǔ)設(shè)施和架構(gòu)元素。 “框架”通常包括事件和錯(cuò)誤處理程序、消息傳遞、日志記錄、自檢、內(nèi)置測(cè)試、診斷和安全實(shí)施。
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ǔ)級(jí)別，但您需要了解它們的目的和用途。 除了 Profile 構(gòu)造型之外，配置文件類(lèi)似于標(biāo)準(zhǔn)包。概要文件通常包含“元類(lèi)”（參見(jiàn)第 4 章：UML 的組織），它們被裁剪以幫助執(zhí)行項(xiàng)目的方法或報(bào)告和狀態(tài)機(jī)制。 您可以使用它來(lái)創(chuàng)建元類(lèi)或構(gòu)造型，但通常只允許一個(gè)人參與一個(gè)項(xiàng)目。 當(dāng)然，這些配置文件必須可供項(xiàng)目中的每個(gè)人使用，并且難以創(chuàng)建，可能會(huì)引入可移植性問(wèn)題。
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)容圖表都有一個(gè)<kind > 字段 pkg 或 package 以及圖表標(biāo)題中的命名空間名稱(chēng)。 在很多情況下，<kind>字段可以省略，因?yàn)樗梢杂蓛?nèi)容決定。 如果該圖主要顯示包及其關(guān)系（例如，導(dǎo)入、訪問(wèn)、依賴(lài)或抽象），則該圖將被視為包圖。 如果該圖主要顯示類(lèi)、泛化和關(guān)聯(lián)，則該圖將被視為類(lèi)圖，盡管有標(biāo)題。 如果圖表主要顯示實(shí)例，則將其視為實(shí)例圖。 概要圖看起來(lái)像包圖，但支持稍微不同的表示法，允許擴(kuò)展或限制現(xiàn)有元類(lèi)和構(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)模型，可以在模型中聲明。
? 單獨(dú)的“模型”包通常通過(guò)一種“抽象”關(guān)系來(lái)連接。
?modellibrarys?和 ?frameworks? 都用于包含可重用的元素類(lèi)型、部件、單元和架構(gòu)基礎(chǔ)設(shè)施。
? 配置文件是一種包和相關(guān)圖表，允許建模者定制項(xiàng)目。
