本章讨论模型组织的主题，并描述模型组织概念使用SysML构件:模型、包、和视图。在SysML中,模型组织的基础单元是包（package）。包和它的内容被显示在包图上。包是容器和命名空间,是SysML中两个基础概念。
复杂系统的SysML模型可以包含上千个或甚至上百万个模型元素。在SysML中,每个模型元素包含在一个单一的容器内，容器称为它的所有者或父。包含的元素常常称为子元素。当一个容器被删除或拷贝时,它的子元素也被删除或拷贝。一些子元素也可以是容器，其导致一个内嵌的模型元素层次树。
包是容器的一个例子，模型元素包含在一个包内被称为包元素,例，模块、用例、和活动。由于包也可以是包元素,因此支持包层次树。
此外为了有一个位置在容器层次中,每个模型元素有一个名称,称为命名元素,也必须是命名空间的一个成员。一个命名空间使它的元素在它内部被唯一标识。SysML也包含命名元素之间的一个关系称为一个依赖,其可以被专业化作为需要更多地反映特定的语义。一个包是一个命名空间对应它包含的包元素。
如果一个元素被使用在它的命名空间外部时，一个完整合格的名称可以被用来无歧义的在容器层次内部定位它。一个重要的关系是：允许包含在一个包中的元素将被导入到另外一个包中，所以它们可以被引用简单通过它们的名称。
模型是一个特定的包类型，其包含一组模型元素集描述一个感兴趣的领域。本书第二部分的其它章节描述不同类型的模型元素,和它们如何被使用来描述一个感兴趣的领域。本章描述这些元素如何被组织来增强建模的有效性。
有效的模型组织结构促进模型元素的重用,存取容易和模型元素之间的导航。它也可以支持模型的配置管理,和与其它工具之间的交换建模信息,正如描述在第18章。保持一个很好定义模型组织的重要性提高使用模型的规模,即使很小的模型也受益于协调一致的组织原则的应用。划分模型的特定的准则被满足来自于方法学,但一些模型组织原则的例子被包含在本章的后面。
由于重用非常重要在建模中,SysML包含一个模型库的概念,其是特别的试图来包含模型元素，其可以被共享在模型之间和模型内部。模型库被更完整的描述在第15章。
视图和视点可以被用来可视化模型根据多个组织原则。一个视图是一种类型的包用来关联模型的一个特定视角,诸如，性能或安全性。一个视点表示一个特定利益相关者的视角，其指定视图的内容。一个视图符合一个视点。
包含在一个包内的模型元素可以被显示在一个包图上。一个包图完整的标题如下:
pkg [model element typ]package name [diagram name]
- 图的类型是：pkg
- 模型元素类型可以是：模型、包、模型库、或视图。
包图的一个例子被显示在图6.1。它显示包层次的一些层次对应ACME Surveillance system Inc产品包的模型。包图符号表被包含在表A.1在附录中。
图6.1 包图的一个例子
SysML模型被组织在包层次树中，类似于Windows中的目录结构。包被用来划分模型元素到有凝聚性的单元，可以是与主题相关的访问控制、模型向导、配置管理、和其它考虑。在SysML中，模型组织最明显的类型是：模型、包、模型库、和视图。
包（package）是其它模型元素的容器。包含包中的任何模型元素，确切在一个容器中，当容器被删除或拷贝时,包含的模型元素也被删除和拷贝。容器的这种模式意味着，任何SysML模型是模型元素的一个层次树。
可以包含在包中的模型元素，称为包元素（packageable elements），包含模块、活动、和数值类型等。包允许嵌套它自身的模型元素。容器规则和其它相关特征,诸如，名称。其它类型的包元素被描述在相关的章节中。
在SysML中，一个模型在一个内嵌的包层次树中是包的顶层。在一个包层次次中,模型可以包含其它模型、包、和视图。模型内容和细节的选项依赖于使用的方法学，例如,是否有一个模型的层次树。典型的,一个模型被理解来表示一个系统或感兴趣的，对应一些目的的一个完整描述,正如描述在第2章。
一个模型有一个单一的主要层次包含所有元素,它的组织原则基于什么更适合满足项目需要。视图描述在第6.9节,可以被用来提供附加的视角关于模型使用可选的组织原则。
常常一个包被专业的构建，它的内容将被重用在许多模型中。SysML包含一个模型库的概念—一个包也即被设计来包含可重用的元素。一个模型库被描述作为一个包标志，使用关键字«modelLibrary»在包名称上，如图6.2所示的Components和Standard Definitions。参考第15.2节获取更多信息关于模型库。
图6.2监测系统模型的包图
一个包图的内容区，显示包和包元素，表示在包图框架内部。包的显示使用一个文件夹标志，其中包名称和关键字可以出现在标签或标志体上。
如果一个模型出现在一个包图上,其可以出现每当有一个模型层次,标准文件夹标志包含一个三角形在车体标志的右上角。
包图在图6.2显示顶层包ACME Surveillance Systems Inc的企业模型,正如指定在标题。用户定义的图名称对应这个图是顶层包,说明这个图的目的是来显示模型包的顶层结构。在这个例子中,模型包含独立的包层次对应：
- 现成的标准组件
- 标准工程定义诸如，SI单位制(也被称为国际单位制)
- 公司的产品
- 任何特定的扩展需要来支持 域特定符号和概念(扩展到SysML,称为配置文件,被详细描述在第15章)
每个包应该包含包元素，对应包的目的。这些元素可以随后被表示作为需要关于不同的SysML图包含结构、行为、参数、和需求图,正如随后描述在在本书的这个部分。
正如先前描述的,一个模型被管理在一个单一的包的结构中。包顶层是一个模型，其提供包含，其通常包含包的下一层级的模型层次,正如显示在图6.2。这些包依次常常包含子包，其进一步划分模型元素到逻辑分组。
对于建模者模型组织是一个关键选项，由于它影响重用、存取控制、模型向导、配置管理、数据交换、和开发过程的其它关键方面。例如,一个包可以是模型的单元，对于它的存取权限被赋予,授权仅选择用户能修改它的内容。此外,当一个特定的包被检出并修改它的内容时,其它用户可以被排除从标记变更，直到这个包被捡入。一个不好的模型组织也使用户的理解和在模型中的导航变得困难。
模型层次应该是基于一组组织原则。下面的是一些可能的方式来组织一个模型:
-
-
- 通过系统的层次(例，系统层次、元素层次、组件层次)
- 通过过程的生命周期，每个子包模型表示在过程中的一个阶段(例，需求分析、系统设计)
- 通过工作在模型上的团队(例，需求团队、集成产品团队(IPT)1,2)
- 通过模型元素的类型包含它内部(例，需求、行为、结构)
- 通过模型元素，可能一起变更
- 通过模型元素组织来支持重用(例，模型库)
- 通过其它逻辑或模型元素的黏着分组基于定义的模型划分准则
- 上述原则的一种组合
-
容器关联父到子在一个包层次内部。容器层次的一些级别可以被显示在包图上，使用容器在容器元素和它们的包含元素之间。容器被显示作为一条直线带有一个“十”字在容器内该（父）终点, 但终点没有任何修饰与包含的元素相关（子）。每个容器关系可以被显示正如一个独立的路径,但典型的它们被显示作为一个树用一个“十”字符号和从它发散的许多线。一个可选的容器的显示是来显示内嵌的模型元素包含在包的标志上。
图6.3显示四个包含在公司模型的Products包内：Surveillance Network、 Surveillance Systems, Cameras和Requirements。这个例子使用包容器的符号。不同的组织的原则被使用对应Products、Cameras和Surveillance Systems包。Products包被组织来包含包对应公司提供的三个主要产品线,和一个附加的包对应所有需求规范。Cameras包层次被组织通过建模构件类型和正如它包含包来捕捉相机的结构、行为、和参数方面。Surveillance Systems包层次被组织基于架构原则，其需要一个Logical Architectur包,一个Physical Architecture包,和一个Use Cases包。它也有一个Analysis包来持有多种分析类型和它们的产出。
图6.3 在包图上显示内嵌的包
在一个工具中，容器树（containment）常常是一个可视的浏览器视图。图6.4提供一个例子，对应图6.3的模型组织。容器层次通常展开演示模型的构成，包含其它内嵌的包，包含各种不同的模型元素。一个工具通常显示容器层次和相关内容以扩展的形式，使用浏览器的简约形式,类似Windows中的文件浏览器。
图6.4模型的包层次浏览器视图
此外对于包,包图被用来显示包元素。通过多个形状和大小不同的节点标志表示包元素,图标也可被使用。
图6.5的包图，对应图6.2中的Components包。该包是一个模型库，包含现成的组件用于构建摄像头和监控系统。Components模型库包含的组件模块说明通过«block»关键字,并显示在图框架内部。为了减少混乱，在图中仅显示了模型库内部的一些模型元素。正如解释在第2和第5章,图是底层模型的简化视图，并且图中所有可能出现的内容可以不显示。图名称被隐藏,但可以被包含强调图的目的。
图6.5 使用一个包图显示包的内容
除了作为一个包元素的容器外,一个包也是它内部元素的一个命名空间。大多数SysML模型元素有名称尽管一少部分没有,诸如，一个注释。任何类型的命名空间定义一个唯一性规则来区分包包含的不同命名元素。在包中，包元素的唯一性规则是每个元素必须有一个唯一的名称。
正如前面陈述的,一个包层次可以包含多个层级的内嵌包，意味着，包含在一个包中的模型元素，可以被包含在一个任意数量层次的高层次包中。容器在一个父和子之间是无歧义的，表示通过一个工具的模型的浏览器视图中。
出现在一个图上的模型元素，它的框架可以或不能表示它的父命名空间。然而,当一个模型元素显示在一个图上时，它不能表示它的父,简单的使用模型元素的名称是误导的，由于它给出一个容器的错误印象。解决方案是在标志中对应那个模型元素给出合格的名称。如果在容器层次包内的模型元素是内嵌,随后完整的名称显示来自那个包的相对路径到包含的元素。如果模型元素没有内嵌在包内部，完整的名称包含来自模型到元素的完整路径。
一个模型元素的限定名称总是最后是模型元素名称前面是路径，路径中的每个包含名称空间由双冒号分隔符号“::”,所以,当阅读限定名称时,路径时从左到右 例如,一个模型元素X包含包B,进而是B包含在包A,表示为A::B::X。
图6.6显示在一个包图中，使用限定名称的一些例子。描述显示在图6.2的Basic Definitions包。标志命名为Basic Definitions::Waypoint演示在一个称为Basic Definitions的包内有一个数值类型Waypoint的模型元素,Basic Definitions是Standard Definitions的模型元素。Waypoint被随后用来指定一个监控摄像头的扫描模式。图中的其它2个标志表示处于Basic Definitions包的外部的模型元素，因此有完整的名称，对应来自公司模型的路径ACME Surveillance Systems Inc。在一个包层次中,每个模型元素有一个唯一的名称在所有模型元素中，无论它是否被包含在命名空间中。
图 6.6使用限定名称来表示模型元素在一个容器层次内部
依赖于模型的组织,不同包的模型元素常常互相关联,这些联系中的一些需要表示在图上。在这种情况下, 需要显示来自许多包的模型元素在一个给定的图上,所以一个伸缩自如的替代方式是使用限定名称,避免图杂乱。
一个导入的关系被使用来表示一个命名空间（源命名空间）的元素或元素集导入到另外一种命名空间（目标命名空间）。当显示在一个图上时，导入元素的名称变成目标命名空间中的名称，并不需要目标命名空间的一个限定名称。注：许多SysML工具自动隐藏完整的名称，是否一个导入关系存在或不在。
一个包导入一个完整的包,其意味着，所有包中的模型元素被导入到目标命名空间。当它是必须的并且导入一个包的所有元素不可能可能引起混乱时，可以被使用，每个导入元素在目标明明空间由有一个对应的模型元素。
名称冲突作为导入的结果，发生在两个或两个以上的目标命名空间的模型元素会有相同的名称时。为了防止名称冲突在目标名称空间，导入的模型元素采用别名, 别名可用来为一个导入的模型元素提供一个替代名称。名称冲突的规则如下:
- 如果一个导入元素的名称与一目标命名空间的一个元素冲突，那个元素没导入,除非一个别名被使用来提供一个唯一的名称。
- 如果两个或更多的导入元素名称冲突时,它们都没有导入到目标命名空间.
命名元素标识在一个命名空间内部,是否是直接容器或被导入的一个结果,被称为成员。成员在它们的命名空间内部有一个可视性属性,或public或private。成员在一个命名空间内有一个默认的可视性public。成员的可视性确定，是否它可以被导入到另外一个命名空间。从源命名空间到目标命名空间一个包的导入仅导入名称带有public可视性的元素。更进一步, 在目标命名空间内部一个导入关系可以说明是否导入的元素是public或private。
当通过一个建模工具存取和控制一个模型时,一个导入的元素可以仅变更在源包中, 在任何表示目标包的包图中，任何相关元素的可视性会自动变更。
导入关系被显示使用一条虚线箭头,标签使用关键字«import»。箭头点指向源，尾部为目标命名空间，在其中名称将被导入。箭头点或到一个独立的模型元素(元素导入)或到一个完整的包(包导入)。关键字«access»被使用代替«import»，当元素将被导入作为目标命名空间的Private成员时。
图6.7 «import»和«access»的视图
图6.7图中表示的Parent包中，有三个包P1、P2和P3。名称为Model::P1包不包含在图的语境中，所以使用它的限定名称。Model::P1包含一个带有public可视性的模块A (SysML没有一个图形化符号对应可视性,因此这里添加注释到标志)，包P2私有导入P1。P2也包含带有公共可视性的B和C模块和私有可视性的模块F，P2也包含一个内嵌的Child of P2包,其包含一个单一的公共可视性模块E。包P3有一个公共可视性模块C,并被导入到包P2中,但也导入模块C作为一个独立的元素,带有别名D来避免名称冲突。注：别名D被注释在导入关系上。
图6.8演示导入关系对命名的影响。显示一个图表示包P3，来自图6.7多个模型元素导入后的名称变化。模块B、C和D(一个别名对应P2::C) 由于它们是P3的成员，显示使用简单名称，它的名称是可视的由于P3已经导入P2。模块E不得不使用限定名称Child of P2::E,。模块F不得不使用限定名称P2::F，由于它被定义为private和所以没有导入,但P2是可视的由于它处于相同的命名空间P3。模块A不得不通过它的完整的限定名称Model::P1::A,由于尽管它被定义带有公共的可视性。Model::P1被导入私有的到P2，由此在P2中不可见，并没有导入到P3。
图6.8 包P3中的命名
图6.9显示一些导入关系在Standard Item Definitions包内部。它包含一个可重用模型库的一个例子称为SI Definitions其被定义在SysML包内。(SI定义包被定义作为一个标准化的模型库在SysML v1.0的附录D。在SysML 1.3中，它已经被重命名为"SysML Quantity Kinds and Units for ISO 80000-1"，但为了简便，我们依然使用原始名称[1]。)，SI Definitions包提供单位制的公共集对应使用整个模型，被导入到SI Types包,。SI Types依次被导入对应使用在许多其它内部的包,其中之一是Standard Item Definitions包其包含信息、材料和能量流动的定义在整个监测系统中。
图6.9 导入‘SI ’单位制类型的模型库到‘Standard Item Definitions’包
一个依赖关系可以被应用在命名元素之间，用来说明在依赖关系的一端的一个元素的一个变更可以导致依赖关系另外一端的元素的变更。模型元素在依赖关系的两端，被称为客户端和供应端。客户端依赖供应端，因此供应端的一个变更可能引起客户端的变更。
当一个包的内容依赖于另外一个包的内容时，依赖关系通过依赖关系说明。例如, 在系统软件的应用层级的软件应用可能依赖于系统软件内部服务层级的软件组件。这可以表示在一个软件架构的模块通过包之间的依赖关系，表示应用层级的包(即,客户端)和表示服务层级的包(即,供应端)。
在建模过程的早期，依赖关系常常使用来指定一个依赖关系，随后被替换或扩展到确定的定义。有多种类型的依赖关系，可以使用在包图和选择的其它图中。下面的是一个通用依赖关系的列表:
- 使用（Use）：说明客户端使用供应端
- 细化（Refine）：说明客户端是供应端的一个更详细的说明,诸如，当物理和性能特性被包含在一个组件定义中时。这种关系常常用在需求分析中。正如描述在第13.13节。
- 实现（Realization）：说明客户端实现表示在供应端的描述,诸如，一个实施包来实现一个设计包。
- 追溯（Trace）：说明有一种追溯关系在客户端和供应端之间，不需要更精确的语义约束关系。这种联系被常常用来在需求分析中, 正如描述在第13.14节。
- 分配（Allocate）：说明一个模型元素被分配到另外一个。这种联系被描述在第14章。
图6.10 依赖关系例子在摄像头性能视图中
一种依赖被表示通过一条虚线带有一个开放的箭头，从客户端指向供应端。依赖关系被表示使用书名号中的一个关键字。
图6.10 Camera Performance视图中显示了一些类型的依赖关系, 摄像头性能的定义在图6.11。Video Stream Rate约束模块是一个Video Performance需求更精确的细化（refinement）。Video Stream Rate使用一个兆字节每秒定义(Mbps)作为它定义的部分。活动Generate Video Outputs被追溯到Video Stream Rate，如果约束发生变更，活动的性能可以需要来被重新评估。Generate Video Outputs被分配到Camera来说明，摄像头的职责是执行那个活动。这些模型元素的详细描述在本章的后面。
容器层次包提供一个模型的基础组织。然而,合并跨越多个命名空间一组模型元素时，它常常是有用的，支持一个特定的利益相关者的视角的一个视图。SysML引入视图和视点的概念来促进这一点。视图和视点术语在SysML中被常常认为与IEEE 1471标准协调,“Recommended Practice for Architectural Description of Software-Intensive”[18]。
图6.11 一个性能视点和一个视图用来断定它的定义
视点描述利益相关者感兴趣的一个视角，其被使用来指定一个模型的一个视图。一个视点包含一组属性集，其包含:
- 采用这个视角的原因和目的
- 利益相关者对这个视角有兴趣
- 利益相关者希望聚焦在它们的关注点
- 语言用来表示视图
- 方法用来建立视图(注: 建立视图的视点方法可以被看做产需模型库的定义准则)
视图是一种类型的包并被称为符合它的视点。视图导入一组模型元素集，根据它的视点方法和被表达在语言定义，通过视点表示它的利益相关者的相关的信息。一个视点的属性被常常正式指定,作为视图构建的指导,但可以被非常精确指定允许自动构建和评估一个视图。
视点被表示为一个矩形标志，使用关键字«viewpoint»和视点名称在名称舱段中。视点属性被表示在一个独立舱段标签为«viewpoint»。视图被表示作为一个包，使用关键字«view»带有视图的名称和一个依赖关系到它的视点。视图和视点之间有一个符合关系被表示，作为一条虚线箭头从视图指向视点,使用关键字«conform»修饰。
从一个系统的架构视角看一个视点也常常是重要的，其强调影响系统性能的模型某些方面。在图6.11中，Performance视点模型聚焦在性能特性。摄像头的Performance视图符合Performance视点。摄像头的性能视图包导入摄像头的结构和行为包，由于它们包含元素，它们的性能被评估。它也导入需求包并与性能需求对比。最后,导入Surveillance Systems::Physical包，系统架构师可以用来评估相机环境中可能影响相机性能的因素。
一个很好定义的模型组织结构是必须的，来确保模型被划分到模型元素、支持重用、存取控制、模型向导、配置管理、和数据交换。不同的组织原则可以被使用来建立带有嵌套包的协调的包层次，每个包包含逻辑分组的包元素。下面的汇总模型组织的重要原则。
- SysML模型组织构建的原则被称为一个包。包图被使用来描述这个模型组织根据包,它们的内容和联系。
- 一个模型是一种类型的包，对应一个给定的目的表示一个感兴趣的领域。模型是包层次的根。如果感兴趣的领域是相当复杂的，它可以有子模型。
- 包层次基于容器或包元素所有权的概念。包元素在一个包中是容器的一个必要方面，删除或拷贝它们使用容器。包元素的例子是模块、活动、和数值类型。在一个模型中，容器层次在一个建模工具中常常驱动主要的浏览器视图。
- 包也是命名空间，对应一组命名元素称为成员。命名空间定义一组规则唯一标识每个个体成员。在包内，对应包的命名空间规则是每个成员必须有一个唯一的名称。
- 包图的名称标志必须有一个查看，来明确理解其中表示的元素在模型容器层次中。如果一个标志表示包的成员，图框架表示,随后它的名称(和有时关键字)是所有被需要的。否则一个限定的名称被需要,其是一个连接的成员名称和一个成员和根模型或图语境之间的所有命名空间的路径。
- 包(和其它)图使用限定名称可能变得非常混乱。为了避免这一点,SysML提供一种机制来导入成员从一个包到一个命名空间,或作为一个整体包或作为个体模型元素。成员的可视性在它的源包中控制是否它是一个目标命名空间的成员。
- 模型元素相互依赖有多种方式。一个供应端和一个客户端元素的依赖关系，说明如果供应端元素发生变更客户端元素也变更。依赖关系的不同类型被标识使用一个关键字并被使用对应特定目的，诸如，refinement,allocate,和traceability。
- 一个模型有单一的容器层次,因此暴露一个有关模型的单一视角。一个视点是一种机制设计允许建模者来查看模型从一个特定的视角。一个给定的视图符合一个单一的视点，标识如何它应该被构建和它的目的。视图典型的不包含元素的，但替换导入模型元素为了收集他们到一个共同的命名空间来查看通过包和其它图。
- 包图的图的类型是什么?
- 那种类型的模型元素可以被表示在一个包图中?
- 包含进包中的模型元素的通用术语是什么?
- 模型出现在一个包层次的哪一个层次?
- 命名三种潜在的组织原则，其可以被用来构建一个模型的包层次。
- 您如何可以显示在一个包图上，其中一个包包含另外的一个?
- 那种准则一个包增强对应命名元素，其是它的成员?
- 通过查看包图，您如何告知，一个模型元素表示在图上是一个包的成员，也即是表示通过图框架?
- 写下完整的名称对应一个模块B1包含在一个包P1中,其依次被包含在一个模型M1中。
- 一个包P1包含三个元素—模块B1,模块B2,和模块B3，所有都是公共的可视性，和一个包P4带有私有可视性。另外一种包P2包含一个包称为B1和2个模块称为B2和B4。如果包P2导入包P1带有公共可视性，列举P2的所有成员。
- 如果一个空的包P9导入P2(正如定义在问题10)带有公共可视性,列举所有P9的成员。
- 什么是一个别名的使用?
- 三种通用类型依赖关系的名称。
- 依赖关系如何显示在一个包图?
- 一个视点的三个属性的名称
- 您如何表示一个视图V1,其符合一个视点VP1,在一个包图上?
对于一个模型，您正试图构建的,讨论模型组织的类型也即是适合它的。