SysML实践指南第二版（中文翻译：刘亚龙）第17章 OOSEM方法学

1. 使用OOSEM方法的住宅安全系统实例

本章介绍使用SysML语言和面向对象的系统工程方法(OOSEM)应用到住宅安全系统开发的过程。演示场景驱动过程进行系统分析、规范、设计、和验证的过程，和如何使用SysML自顶向下建模。方法的简化版本介绍在第3.4节,和应用一组典型的建模构件集生成汽车模型的例子介绍在第4.3节。

OOSEM的应用和第16章功能分析方法的使用,是SysML如何被应用作为一种基于模型的系统工程方法的例子；但SysML可以被应用于其它方法。本章的目的是来提供一种健壮性的基于模型的系统规范和设计方法，读者可以应用到满足他们需要的应用领域。

本章开始对方法和它如何满足一个整体开发过程简短进行介绍,并随后演示OOSEM方法应用到住宅安全系统建模的例子，在学习这个例子过程中，读者应首先阅读本书第二部分的语言描述，理解建模的基础概念。

1. 1. 方法概述

本节介绍了OOSEM方法的动机和背景、及系统开发过程的一个抽象层面的的总结，为OOSEM建模提供语境,并对OOSEM系统规范和设计过程作为系统开发过程部分进行总结。

1. 1. 1. 动机和背景

OOSEM是一种自顶向下、场景驱动建模过程的方程，使用SysML来支持系统分析、规范、设计、和验证。过程利用面向对象的概念和其它建模技术帮助架构更灵活和可扩展的系统，适应不断变化的技术和需求。OOSEM也试图简化与面向对象的软件开发、硬件开发、和测试过程的集成。

在OOSEM和其它基于模型的系统工程方法中,系统模型是系统规范和设计过程的主要输出。模型包含表示系统的多个方面构件，诸如，系统的行为、结构、和属性。一个模型必需是完整的，各方面构建的模型必须协调一致的表示系统,正如描述在第2.1.2节。

OOSEM 包含基础的系统工程活动诸如，需要分析、需求分析、架构设计、权衡分析和分析、和验证。同其它方法类似，诸如，Harmony SE过程[6,7]和Rational RUP SE[9,10],它们都采用自顶向下、场景驱动和使用SysML语言的建模方法。OOSEM利用面向对象的概念，诸如，封装和特定化，但这些概念应用在系统层级与应用在软件设计层级有些不同。特别是,OOSEM集成结构分析概念，诸如，数据流及面向对象概念的选择。OOSEM也包含一些其它建模技术,诸如，因果分析、逻辑分解、划分准则、节点分布、控制策略、和参数,来处理系统工程关注的广泛领域。

OOSEM是洛克希德·马丁公司和系统和软件联盟（SSCI）共同努力的结果，开始开发于1998[49, 50]，SSCI现在是软件生产力联盟[8]。经过进一步完善，OOSEM试点过程验证了方法的可行性 [51], INCOSE OOSEM 工作组从2002年进一步完善和发展OOSEM方法。INCOSE 工作组在OOSEM的原始形式中，扩展了许多UML表示的非标准的建模构件。2006年OMG采纳了SysML标准，由于很多商业工具的支持，使OOSEM方法的使用大幅提高，同时也加速了MBSE 方法学实践工作。

1. 1. 1. 系统开发过程概述

完整的系统工程生命周期过程包含系统开发过程、生产、部署、操作、支持、和退役。开发过程成功输出一个可验证的和可确认的系统模型，其满足系统的操作和功能需求，和其它生命周期需求，对应生产、部署、支持、和退役。

OOSEM是开发过程的一部分，OOSEM的原始形式是集成系统和软件工程过程(ISSEP)[52]。这个过程的一个修定版本是OOSEM,显示在系统开发过程图17.1中，并突出显示过程包含管理过程、系统规范和设计过程、下一层级的开发过程、系统集成和验证过程。在图中下一层级开发过程包含硬件、软件、数据库、和操作过程的开发,更一般的讲,这个过程可以被递归应用到系统层级的多个子层级，也即类似Vee开发过程 [53],其中开发过程被应用到系统层级的底层级。这个开发过程与一个典型的Vee过程的区别是：它应用管理过程和技术过程在每个Vee层级,典型的Vee过程仅应用技术过程在Vee的每个层级。

应用这个过程到系统层级的每个层级导致下一更低层级的元素规范形成。例如,应用过程在体系(SoS)层级导致一个或多个系统的规范和验证形成。应用过程在系统层级，导致系统的元素规范和验证形成,和应用过程在元素层级,导致组件的规范和验证形成。应用在硬件和软件层级，软件和硬件的开发过程进行分析对应组件的需求、设计、实现、和测试。

过程的叶子层级是一个元素层级或组件层级被采购或实施。在第4章的汽车设计例子中,如果汽车设计团队采购发动机, 团队指定发动机需求正如说明在图4.16,并验证发动机满足需求。另一方面,如果发动机需要设计,过程被应用到发动机设计的下一层级指定发动机组件和验证这些组件满足它们需求。开发团队必须确定，规范层级是适当的对应特定的应用。

下面的子节包含每个过程的高层级的总结，显示在系统开发过程图17.1。

图17.1系统开发过程.

1. 1. 1. 1. 管理系统开发

管理过程包含项目计划,和根据计划控制工作的执行。项目控制包含监控成本、计划、和性能测量来评估过程对应的计划、风险管理、并控制变更到技术基线。基于模型的测量描述在第2.2.4节可以被使用支持管理过程。

管理过程也包含选择生命周期过程模型,诸如，瀑布型、增量型、或敏捷型。用例被定义在模型中提供功能单元，可以服务作为一个有效的组织原则对应计划和控制工作将被完成的范围对应一个敏捷型或增量的特定开发。

管理过程也包含裁剪的定义，通过裁剪系统工程方法的活动和构件来满足项目的需要。裁剪依赖于许多因素，可以包含系统的扩展是一个新的设计(即,前所未有的)、系统的规模和复杂性、可用的时间和资源、和开发团队的经验级别。例如, 系统设计基于现有的设计，一般是约束包括已有的历史遗产或商业现成组件（COTS）。这些明显影响开发活动的构成和活动执行的顺序。活动可以包含已有的COTS组件，特定的功能需求并行使用其它系统规范和设计活动。设计重点放在COTS组件如何实现系统的要求，和组件与COTS组件之间需要增加的接口。

过程剪裁和对应的构件可能需要附加在特定领域系统的每个级别的层次结构中。在汽车设计的例子中，每个元素的设计方法可能需要定制的过程和构件。例如,应用方法来开发传动系统，车体、驾驶装备可能都包含需要执行的唯一的分析类型，涉及特定的技术和构件。

1. 1. 1. 1. 规范和设计系统

OOSEM执行这个过程，汇总在第17.1.3节。系统规范和设计过程包含活动来分析系统需求、定义系统架构、和指定下一层次设计的需求。下一层级的设计执行规范、和验证设计满足需求、和/或请求变更到需要的需求。对于简单系统，下一层级的系统设计可以是组件层级,其中，硬件、软件、数据库、和操作过程被开发。然而,正如先前描述的, 可能有中间的“元素”层次的系统层次结构。

1. 1. 1. 1. 开发硬件、软件、数据库、和操作过程

这些过程包含规范的完善、设计、实施和组件的验证、分析的支持。对于硬件组件, 通过制造和/或构建组件实施完成，对于软件组件，实施包括编码软件。如果系统层次中有多个中间层次优先于组件层级,开发过程在图17.1被递归应用到每个中间层次。

1. 1. 1. 1. 集成和验证系统

这个过程集成系统元素和/或组件并验证，集成的设计满足它的需求。过程包含开发验证计划、过程、和方法(例，观测、演示、分析、测试),进行集成和验证、分析结果、和生成验证报告。通过指定测试用例在每个设计层级，OOSEM支持Vee模型右侧的过程。测试用例随后使用来开发验证计划和过程,验证系统的需求描述在第17.3.8节。

产品集成和验证作为Vee右侧的过程执行,其中在每个层级集成物理的硬件和软件，并执行测试用例来验证，在组件、元素、和系统层级满足需求。在基于模型的方法中，集成和验证过程也可早期执行，更早的获得系统、元素、组件满足需求的确定性。这有时被引用到设计集成和验证过程，被完成通过集成一个更低层级的设计模型，诸如，组件设计模型到更高层级的设计模型，诸如，元素设计模型和随后的验证，集成模型在每个层级满足它上一层级的需求。在第4章介绍的汽车设计示例中,作为集成和验证过程的部分，发动机组件设计模型集成进发动机模型,发动机模型集成到汽车系统设计模型。集成的模型用来验证发动机组件的设计满足发动机的需求,发动机设计满足汽车的需求,和汽车设计模型满足用户需求。

1. 1. 1. OOSEM系统规范和设计过程

图17.2是一个抽象的OOSEM规范和设计系统过程的总结。过程的一个简化版本被介绍在第3.4节。动作的编号对应章节编号，章节中具体描述动作。引用的章节包含一个活动图，描述动作如何分解并表示在下一层级。为了简化过程描述,活动图不包含迭代循环过程，没有执行它包含的每个活动的输入和输出构件。然而,构件描述在子小节，被引用在动作在图17.2中。动作名称采用小写、活动名称在引用的章节使用大写。

Set-up Model（设置模型）活动设置建模需要的语境和条件，包括建立模型的向导和组织模型(参考第17.3.1节)。Analyze Stakeholder Needs（分析涉众需求）活动描绘目前的系统，及现有系统的限制和潜在的可以提高的方面,并指定系统未来必须支持的任务需求(参考第17.3.2节)。Analyze System Requirements（分析系统需求）活动指定支持任务的要求的系统需求，根据它的输入和输出响应和其它黑盒所需的特点(参考第17.3.3节)。Define Logical Architecture（定义逻辑架构）活动进行系统分解形成逻辑组件，并定义逻辑组件如何相互交互实现系统需求(参考第17.3.4节)。Synthesize Candidate Physical Architectures（综合备选的物理架构）活动分配逻辑组件到物理组件，具体实施在硬件、软件、数据、和过程(参考第17.3.5节)。在整个过程中，Optimize and Evaluate Alternatives（优化和评估备选方案）活动被调用进行工程分析、系统设计的权衡分析和设计优化(参考第17.3.6节)。Manage Requirements Traceability（管理需求可追溯性）活动使用来管理需求的可追溯性，从任务层级需求到组件需求(参考第17.3.7节)。在本章中，这些活动中的每个详细阐述了如何应用OOSEM方法开发住宅安全系统。注：简化的MBSE方法介绍在第3.4节,没有包含逻辑架构设计活动,仅包含其它活动的一个子集。

根据组织和项目的需要，对过程文档的详细程度进行定制。文档可以进一步阐述和描述每个建模的构件的创建，如用例的详细过程描述。诸如，一个用例。此外,这个过程可以被进一步完善反映设计迭代及迭代过程的输入和输出。为了简化流程描述，这个级别的信息不包含在这个示例中的任何过程中。该过程可以被记录在一个过程建模和/或过程创作工具中，并发布到Web环境中。这种方式对于过程的维护、剪裁和使用是有帮助的。在下面的示例中，包含OOSEM过程的模型在包中称为。

1. 1. 住宅安全例子概述

本节提供一个住宅安全例子的概述,包含问题背景和项目启动活动。

图17.2 OOSEM指定设计系统过程，动作编号对应子小节编号

1. 1. 1. 问题背景

一个公司称为Security Systems Inc，多年来一直为当地提供住宅安全系统。他们的监控系统安装在当地的住宅中，并由一个中央监控站(CMS)监控。系统的目的是监测潜在的入侵者。当安全系统监测到一个入侵者时，CMS列表中的操作者判断并联系当地的紧急调度，请求警察响应并到居住地点拦截入侵者。

Security Systems Inc这个业务持续了许多年。在过去的许多年它们一直处于市场领导地位, 然而，近几年它们的销售额已经明显降低，它们已有的许多客户已经终止合同并选择更有竞争力的合作伙伴。Security Systems Inc当前的系统是其功能管理方面明显变得过时，因此他们需要重建他们的市场地位。特别是, 他们已经决定启动开发增强型安全系统（ESS），目的是帮助他们恢复市场份额。

1. 1. 1. 项目启动

系统工程集成团队(SEIT)的职责是为图17.1的管理系统开发过程（manage system development）部分提供技术管理，包含技术计划、风险管理、管理技术基线、和进行技术审查。此外,SEIT包含团队成员，他们的职责是执行系统需求分析、系统架构设计、工程分析、和ESS集成和验证,描述在第1.4节。实施团队职责是执行分析需求，SEIT成员被分配到ESS组件、和设计和执行组件,并验证组件满足它们的需求。

SEIT选择增量开发过程作为它的生命周期模型。在第一个增量过程中,SEIT建立增量的项目计划和项目框架。第二个增量包含涉众需求分析、指定黑盒系统需求、评价和选择优选的系统体系结构并为建议的ESS解决方案的指定初步的组件需求。后续增量集中在架构的细化和实施需要实现，增加功能对应的选择ESS的用例。

作为建立项目计划和框架的部分在第一个增量步中,建模工作初始的活动包含定义建模目标；定义模型范围来满足目标；选择和裁剪MBSE方法；选择、采购、和安装工具；定义建模活动的详细计划；参与人员工作；并提供必要的培训。

SEIT选择OOSEM作为它们的基于模型的系统工程方法，使用SysML作为它们的图形化建模语言。这是基于一个早期的试点项目的结果，以评估该方法如何与工具很好的支持它们的需要(参考讨论关于试点项目在第19.1.4节)。他们选择工具基于工具选择准则（描述在第18.6节）。系统开发环境包含SysML建模工具、基于UML的软件开发环境、硬件设计工具、性能分析工具、测试工具、配置管理工具、需求管理工具、和其它对应计划的项目管理工具包含日程安排和风险管理。SEIT和选择的其它实施团队成员接受有关SysML、OOSEM和使用它们选择的工具的知识培训。

1. 1. 应用OOSEM来指定和设计住宅安全性系统

本章的例子试图描述建模活动对应第二个增量。在这个增量过程中,ESS建模被初始化和使用来指定和确认系统需求、架构解决方案、并分配需求到ESS硬件、软件、和数据组件。组件或被开发通过实施团队、或采购作为COTS产品。可以预见会除了硬件组件开发外将有明显的软件和数据库开发需要,诸如，传感器、摄像头、处理器、和网络设备,主要的COTS。建模工作也被使用来开发新的操作过程对应客户和中央监控站操作者，定义如何与系统交互。

下面的子节详细说明规范和设计系统过程和构件被汇总在第17.1.3节。子节编号对应编号引用动作在图17.2中。活动-管理需求可追溯性（Manage Requirements Traceability）和优化和评估可选方案（Optimize and Evaluate Alternatives）-被包含在本节的结束，即使它们在整个过程中作为支持活动发生。这个例子的模型目标和范围的目的是说明方法聚焦在入侵者监控线程，并没有详细阐述系统的其他详细功能。

1. 1. 1. 设置模型

在任何建模工作中，设置模型是关键的第一步。包含建立建模约定和标准和组织模型显示在图17.3。

图17.3 设置模型过程

1. 1. 1. 1. 建立建模约定和标准

建模约定和标准被需要来确保整个模型的表示和样式是一致的。这包含建立命名约定对应图和模型元素,诸如，包名称。约定和标准也标识语言的文体层面,诸如，何时来使用大写与小写和何时使用空格在名称中。约定和标准也应该考虑工具强加的限制，诸如，字母数字和特殊字符的使用限制。建议建立一个模板对应每种图的类型，强调图的布局约定。常常,这些约定和标准可以被定义在组织的层次中,如此，每个个体项目能使用它们作为它们的起始点。

在这个示例中使用的一些示例指导包括以下部分:

• 大写和小写的使用：

所有定义/类型词的第一个字符使用大写,诸如，模块和数值类型，和包和需求使用一个空格在有超过一个词组合名称之间。

例子：Video Camcorder

对应所有字符在组成部分、属性、 项属性、动作的名称使用小写，和使用一个空格在组合名称之间（超过一个词）。

例子：record data(这是一个动作名称)

• 动词/名词格式: 动词/名词格式被使用来命名活动、动作、和用例。

例子：Monitor Intruder(这是一个活动名称)

• 端口类型名称—命名端口类型典型的包含词‘IF’对应接口。

例子：Video IF

• 工具特定的符号—本章中生成的图，直接来自一个建模工具使用后期编辑，一些符号可能与SysML标准中有区别，其被描述在第二部分由于工具特定的规则。然而,指导应该备注任何工具特定符号与标准符号的区别。
• 模型元素描述—一个建模指导的另外一个例子将包含一个文本描述对应每个模型元素。大多数工具提供一个标准文本描述可以包含模型元素的一个简洁定义,并可以被捕捉作为一个备注或在文档中对应模型元素。如果这被正确的执行,它可以极大的增强模型的可理解性和维护性。这个信息也可被用来支持从模型自动生成文档,可以包含图和文本描述。第18.5.3节描述如何从模型生成文档。
• 客户化的构造类型和模型库—项目常常被需要来客户化语言使用特定的构造类型，它们可以应用到它们的领域和/或方法学。表17.1包含使用在这个例子中的用户定义的构造类型列表对应一个OOSEM-特定的SysML配置文件,。此外对于这些构造类型,一个项目使用 OOSEM可以选择来定义附加的构造类型和模型库，它是唯一的在它们的领域。方法对应定义一个配置文件被描述在第15章。

一些术语使用在这个例子中是唯一的到这个方法和包含的:

• 领域（Domain）：这个术语被使用来表示模型的范围。

例子：操作领域是指模型的部分，包含操作系统、用户、和环境。术语操作语境是一个操作域的同义词。

• 企业（Enterprise）：表示系统和用户工作在一起来完成一个目标的一个聚合。在OOSEM中,术语体系可以被考虑作为一个潜在的词对应企业。

例子：安全性企业是指安全性系统、紧急服务和通讯系统，其协同来响应紧急事件的逻辑的聚合。

• 逻辑的（Logical）：一个物理实体的一个抽象，其试图来表示它的功能，但没有约束使用的特定技术或实施。

例子：一个入口传感器是一个逻辑组件也即是一个物理组件的一个抽象，诸如，一个光传感器或接触传感器。

• 子系统（Subsystem）：组件的一个逻辑的聚合 a)执行一个或多个系统功能，或b)在组成部分之间有一个通用的特征。

例子 a：一个能量管理子系统是一个组成部分的聚合，其管理和分布能量

例子 b：电力子系统，是一个电力的组成部分的聚合

• 节点（Node）：基于一些准则，实体的一个划分。一个节点在OOSEM中通常被用来描述一个分布的系统，其中每个节点表示组件的划分基于它们的物理位置。节点也可被定义基于其它准则诸如，组织的职责(例，人员和资源赋值到一个特定的部门)。

例子：安装站点节点和中央监控站节点表示不同的物理位置，其中系统组件处于其中。

• 使命任务（Mission）：一个主要的任务分配给系统来支持。

例子：增强的安全系统和紧急服务支持任务来“生命和属性的安全性增强通过提供紧急响应盗窃、入室盗窃、火警、和健康和安全性。

表17-1 OOSEM-特定的配置文件的构造类型对应SysML中的类型

OOSEM的构造类型	基础类
«configuration item»	Block, Property
«data»	Block, Part Property
«document»	Block
«file»	Block, Part Property
«hardware»	Block, Part Property
«logical»	Block, Part Property
«mop»	Property
«moe»	Property
node physical	Block, Part Property
«operator»	Block, Part Property
«procedure»	Block, Part Property
«software»	Block, Part Property
«status»	Property
«store»«status»	Property Property
«system of interest»«store»	Block, Part Property
test component«system of interest»	Block, Part Property Block, Part Property
test component	Block, Part Property

1. 1. 1. 1. 组织模型

组织模型被标识作为开发一个有效的系统模型的关键方面。系统模型的复杂性，可以迅速击垮模型的用户，并成为棘手的，特别是对于大型分布式团队。这反过来又会影响模型开发人员保持模型一致的能力，和保持对模型的配置管理控制的能力。参考第6章的考虑如何组织模型使用包。

OOSEM过程包含标准方法对应组织模型通过包结构定义。作为SysML-Lite部分的概念第一次介绍在第3.3节，模型组织的构建包含附加的包结构来处理更复杂的模型。

模型组织典型的包含一个递归的包结构，镜像系统层次。一个包可以被定义对应一个模块的进一步分解。包可以包含模块对应顶层的领域、系统、元素、和组件层级。一个模块对应包在一个给定的层级，包含对应模块的下一层级的分解的模型元素,包含它的结构和行为。

模型组织也包含其它包，没有内嵌在系统层级包的内部。这些包包含模型元素可以被重用在系统层次的多个层次,诸如，数值类型包和视点包。这些包可以包含它们自己的层次组成内嵌的包，可以不直接与系统层次对应。

图17.4 ESS模型组织

这个例子的模型组织被强调通过在包图中的包结构和浏览器视图在图17.4。显示在图中的包图名称为Model Organization，镜像表示在浏览器视图中模型组织。

OOSEM Profile Extensions是一个包,Model是另外一个包。Model包包含顶层包对应Process Guidance（过程指导）、Security Domain as-is（安全领域现状）、Security Domain to-be（安全领域未来）、Value Types和Viewpoints。

Process Guidance（过程指导）包提供一种便利的机制捕捉过程定义、工具问题，其它过程信息被捕捉通过系统工程团队在整个建模过程中。如果信息在项目中是相关的,应该被反映并更新到组织的标准过程。对于这个例子,包包含描述OOSEM的活动图，包含活动图在图17.2和更底层的活动，被包含在第17.3.1节到第17.3.7节。可选的是,其它过程建模工具可以被用来捕捉过程信息,可以从这个包引用。

Security Domain as-is包包含模型信息，有关领域的当前信息来辅助理解当前系统和企业的限制,并来表示当前模型的部分可以被重用在未来的模型中。

Value Types包包含带有单位制和数量类型的数值类型应用在整个模型中。这个包导入SI Definitions包(没显示)，包含一个标准单位制和数量类型的库。数值类型和SI Definitions模型库描述在第7.3.4节。

Viewpoints包包含视点和相关的视图对应不同的ESS利益相关者。视点和视图描述在第6.9节。

Security Domain to-be（未来的安全领域）包包含与系统生命周期的不同部分相关的包。特别是,它包含Installation（安装）包和Operational（操作）包，也可以包含对应系统生命周期的其它部分的包,诸如，制造、支持、和退役。每个包包含定义系统支持系统生命周期的特定阶段的模型元素。例如, Installation包包含模型的安装程序和安装系统，包含安装卡车和安装工具。Installation领域描述在第17.3.9节。

这个模型的大多数操作包含Operational包内部，由于这个例子的聚焦是有关操作系统的设计。Operational包包含内嵌的包对应Requirements、Structure、Use Cases、 Behavior、Parametrics、Interface Definitions和ESS。一些包的名称开始使用一个数字来建立它们出现的层次中期望的顺序。然而,这些数字没有包含,当它们被引用使用下面的文本。其它生命周期包被组织类似于Operational包。

Operational包包含模型元素，其描述操作领域的不同方面。Requirements包包含对应ESS的任务需求。Structure包定义ESS和它的外部系统和用户。Use Cases包包含ESS必须支持的企业用例。Behavior包包含任务场景对应每个用例。Parametrics包包含顶层工程分析，支持权衡分析和设计优化。

Interface Definitions（接口定义）包包含定义的输入和输出和端口规范，使用在整个模型中。这些定义不限于单一层级的层次,和因此被包含在它们应用的最高层。ESS包包含表示ESS的模型元素。正如显示在图17.4，ESS包含内嵌的包对应它的Black Box Specification（黑盒规格）、 Logical Design（逻辑设计）、Node Logical Design（节点逻辑设计）、Node Physical Design（节点物理设计）和Verification（验证）。Node Physical Design包含内嵌的包对应硬件、软件、数据、和操作过程(没显示)。

每个预先包含的包被生成通过应用OOSEM到系统的规范和设计的模型元素。每个包的内容被描述在本章中的章节，对应于应用的OOSEM活动，其中的内容被生成。

图包含在特别的包被强调在浏览器使用特定的标志，其是唯一的对于每种工具。例如,有一个标志在图17.4向下到浏览器的底部，其是Model Organization包图显示在工具的绘图区域。

正如描述在第5.3.1节,图框架实际表示一个模型元素。模型元素也即表示通过图框架指令，其中图出现在浏览器层级中。在这种情况下,图框架表示Model正如指示在标题中。

模型元素包含在一个包中，可以关联到包含在另外一个包中的模型元素。当一个模型元素来自另外一个包出现在一个图上时,完整的限定名称标识该包，它被包含在里面。这使每个模型元素在一个图上将被唯一标识，即使2个模型元素在不同的包中有相同的名称。完整的限定名称可以被显示使用双-冒号符号描述在第6.6节。完整的限定名称被忽略在图中，贯穿本章来减少图混乱。

为了使模型的向导容易,定义一个模块定义图包含超链接到感兴趣的图有时很有用,并促进导航选择建模工作，模块定义图命名为Navigation图显示在浏览器中。这个图包含超链接到其它图包含整个模型来是容易获取到图，不需要详细了解包结构。一个图超链接图标的一个例子被显示在模型组织包图在图17.4。点击鼠标在这个图标上提供一个超链接到向导模块定义图。

1. 1. 1. 分析涉众需求

Analyze Stakeholder Needs（分析涉众需求）活动，首次介绍在图17.2中，图17.5显示详细内容。正如先前提及的,这个简化过程不包含输入、输出和过程的迭代。执行这个活动对利益相关者需要解决的问题进行分析，帮助理解利益相关者关注的问题，并指定的任务层级的需求。

分析包括评估当前系统的局限性，描述当前的系统和企业，通过执行因果分析，从每个利益相关者的视角确定系统的限制和潜在的提高领域。分析结果使用来衍生任务需求和整体目标对应未来的系统和企业，解决当前系统和企业的限制。未来的领域模型、企业用例、和有效性测量被使用来规范任务需求。进行任务需求审查确认任务需求解决涉众需求。

图17.5 分析涉众需求活动来指定任务需求

对于这个例子,OOSEM被应用来设计一个单一层级的系统称为ESS。作为一个结果,没有强调在体系或企业层级架构中的定位。如果需要,随后可以添加对应体系架构活动[54]应用在过程中。特别在OOSEM活动中，对应define SoS logical architecture（定义体系逻辑框架）和synthesize candidate SoS physical architectures（综合备选的体系物理架构）被插入在图17.2的analyze stakeholder needs（分析涉众需求）和analyze system requirements（分析系统需求）之间。

1. 1. 1. 1. 刻画当前的系统和企业

当前的系统、用户、和企业被刻画在一个层级理解利益相关者的关注是充分的。这涉及建模当前的系统和企业，仅作为提供洞察问题需要的,并避免过度建模。如果一个当前的解决方案不存在,很明显不要做任何描述,您只需要指定任务需求。然而,常常有一组用户集、系统、和企业、表示分析的一个起点。

显示在图17.6模块定义图中的Operational Domain as-is（操作领域现状）包含一个顶层模块称为Operational Domain as-is，为其它模块提供在域中的语境。这个模块被分解为Security Enterprise as-is（安全企业现状）和Site as-is（站点现状）, Site as-is有一个多重性，说明可以有一对多个站点。

在OOSEM中,一个企业模块被建立表示模块的一个聚合，协同来达到一组任务目标集。在这个例子中,当前的企业包含Security System as-is是构造类型«system of interest»；Emergency Services（紧急服务）包含Dispatcher（调度）和Police；和Communication Network（通讯网路）使能在当前的安全性系统和紧急服务之间通讯。这些模块协同来监控住宅，并响应潜在的入侵者。

Site As-is，其被保护在企业的外部。每个站点由一个Single Family Residence与一个或多个Occupant（住户）组成,对于许多Intruders（入侵者）为0。

域模型帮助建立感兴趣的系统与外部系统和用户之间的边界，系统或直接或不直接的与它交互。当前安全性系统包含多个站点安装,正如说明通过在相关终点的多重性,和一个单一的中央监控站。注：Site Installation As-is（安装站点现状）被拥有(即,黑色钻石)通过Security System as-is（安全系统现状）并被引用(即,白色钻石)通过Single-Family Residence as-is（单一家庭住宅现状）。引用提供一种机制来表示一个更复杂的系统边界，其中部分被占有通过一个模块并引用通过另外一个模块。

当前域一个可选描绘被显示在图17.7,其中系统和外部系统被显示采用图标形式。这提供一种方式来简化的描绘当前操作域通讯，可以被注释来非正式表示实体之间选择的交互关系和联系。实体之间的关系可以被表示作为关联，但对于这个例子的目的，假定它们仅是模块定义图的一个注释。关系被随后被表示作为连接器使用项流在一个内部模块图中。

1. 1. 1. 1. 执行因果分析

当前系统和企业被分析来评估它们的功能和限制,并且标识潜在的提高域。其它数据源可以被需要来支持这个分析,包含市场数据，诸如，客户调查和竞争性数据。

构建因果分析的一个有用的技术是来使用一个鱼骨图来表示因果关系的的树。一个鱼骨图显示Security Enterprise as-is的因果分析显示在图17.8。树的根应该表示一个测量的问题，从每个利益相关者的角度。树的节点表示依赖的属性，可以被关联或影响有效性测量(moe)。

图17.6 操作领域现状

图17.7 当前操作域 (图标表示)

图17.8  公司所有者视角Security Enterprise as-is的因果分析

对于企业所有者和对于安全性系统公司的投资者,商业销售额是一个非常重要的moe,因此Lack of Sales(缺少销量)是相应的树的根。因果依赖关系显示，销售被影响通过Customer Satisfaction（客户满意度）和Market Size（市场规模）。Customer Satisfaction被测量根据System Cost（系统成本）和Security Effectiveness（安全有效性）。System Cost被测量根据它的Installation Cost（安装成本）和持续的Service Cost（服务成本）。Security Effectiveness被测量，根据response time（响应时间）、false alarms（错误警报）、 missed detections（丢失监测）和其它参数。moe相关的值和对应其它ESS利益相关者—包含客户、警察部门、和内部利益相关者,诸如，中央监控站操作员和系统安装者,也应该被考虑。对应警察部门的利益相关者关注可以是假警报数,和相关的成本到城市的部署不相关的资源。因果关系对应每个利益相关者可以被重载在鱼骨图上来提供一个综合多个利益相关者问题的视图和它们潜在的贡献。利益相关者视点定义在第17.3.5节的后面应该反映这些关注。

尽管SysML不能表示鱼骨图, 使用参数图可以提供一种等效表示方式，捕捉鱼骨图中的每个节点作为一个参数,并捕捉参数作为约束属性之间的关系。这使能参数在鱼骨图上将被量化之间的关系的因果分析,诸如，在Customer Satisfaction（客户化规格）和Security Effectiveness（安全有效性）和 System Cost（系统成本）层级之间的关系。一个权重可以被分配到量化的影响，每一个原因的效果类似的风险分析或故障模式和影响分析。

附加的工程分析被执行来标识关于moe的根部原因和相关的影响。这个分析可以包含时间线分析、可靠性分析、和生命周期成本分析。分析可以被绘制在参数图正如随后讨论的。

在这个例子中，在因果分析中确定的一个主要缺陷是当前的安全系统相对于竞争系统的有限的功能。一个利益相关者需求被标识来，扩展功能除了入侵者监测功能外，能处理紧急保护对应火警和医疗紧急事故。同样除家庭住户外，有一个需求为多个家庭住宅和小的商业区提供安全保护的扩展，因此安全性系统的市场规模确定了。

1. 1. 1. 1. 指定任务需求

基于先前的分析,一个有限的任务需求集被定义，其解决当前域的限制。任务需求被捕捉作为文本需求, 正如显示在需求图在图17.9。ESS的顶层任务需求对应包含文本语句到“Enhance security of life and property by providing emergency response to theft,, burglary, fire, and health and safety.”任务需求被包含在Requirements包中。任务需求和底层的需求之间的可追溯性被讨论在第17.3.7节。

1. 1. 1. 1. 捕捉有效性测量（MOE）

moe是任务层级的性能需求，反映价值到客户和其它利益相关者。它们被衍生从涉众需求分析，包含因果分析和任务性能分析。ESS的有效性测量是紧急响应时间,入侵者定罪的概率,可用性,和操作成本。每个moe的目标值被建立来解决涉众需求和实现竞争优势。

moe被绘制在顶层的参数图在图17.10。«objective Function»定义设计解决方案的整体成本有效性根据与每个moe相关的效用的加权和。

工程分析被执行在整个开发过程中来支持评估、选择、和设计方案的优化根据moe。一个参数图可以被定义来支持每个moe的分析,并包含影响moe值的低层级的参数。这提供一种机制顶层的moe向下流动到系统的关键参数,也被称为技术性能测量或性能测量(即,mop)正如模型被详细阐述的。详细讨论在第17.3.6节。

图17.9 ESS 任务需求

图17.10 ESS顶层参数图显示操作的成本有效性和它的关系到有效性测量 (moe)

1. 1. 1. 1. 定义未来的域模型

基于先前的分析,我们可以建立未来的系统和企业的范围。未来的操作域模块定义图被显示在图17.11。图表示Operational Domain 作为顶层的模块结构。这个模块被包含在 Operational::Structure包中。未来的操作域包含明显的变更从当前的操作域在图17.6中，它反映了来自因果分析的更广泛的任务要求。

 Emergency Services除了当前域的Police和Dispatcher外包含Fire Fighter（火警）和Paramedic（急救）。Multi-Family Residence（多个家庭住址）和Small Business（小的商业区）是 Property的特定化，同Single-Family Residence（单一家庭住宅）来自当前域。由于系统现在必须监控环境的火警，Physical Environment（物理环境）被包含。此外,当前的安全性系统模块已经被替换使用ESS,是«system of interest»构造类型。

Security Enterprise包含ESS、Emergency Services和Communications Network（通讯网络），职责对应满足任务需求并提供保护服务到客户和住户。moe是Security Enterprise模块的一种特定类型的属性值(«moe») 连同它们的单位。特定目标值和/或值分布也可以被指定。此外,Investigator 被添加到Operational Domain 来支持moe被称为入侵者定罪的概率。这个moe显著的影响ESS规范和设计，提供请求ESS 来捕捉和存储信息关于急救事件，其可以被获取通过Investigator。 在这个例子中 Police、Firefighter和Paramedic 都是Responder的子类。随着复杂性增长, 可能是必要的，创建一个单独外部系统特定的层次结构的模块定义图，以减少一个图上显示的信息量。

图17.11  未来的操作领域

1. 1. 1. 1. 定义企业案例

Security Enterprise用例被定义来表示每个任务目标，对应到任务需求在图17.9中。目标是来提供响应到入侵者、火警和医疗紧急事故,正如显示在用例图17.12。每个用案是特别的从一个更通用的用例称为Provide Emergency Response。一个异常用例称为Mitigate Failure也被定义来帮助提供非正常条件下的容错解决方案件。

一个附加的用例称为Provide Investigative Data,支持应急响应行动,诸如，提供证据来定罪一个入侵者。这种用例包含Investigator作为一个参与者。

Security Enterprise是用例的主题图，并被使用通过参与者达到用例目标(即,任务目标)。参与者被分配到模块，其处于企业的外部在Operational Domain模块定义图17.11中。Physical Environment也被显示作为一个参与者，在Provide Fire Emergency Response用例来说明它的功能作为火警的来源。

图17.12 安全企业用例

这个例子中，用例通过细化任务需求使用refine关系。refine关系的一个例子被显示在图17.54，在第17.3.7节。用例也可以追溯到其它原始文档，诸如，操作的概念或市场数据。企业用例被进一步详细说明通过任务场景，表示参与者和企业的其它组成部分之间的交互。这个分析被使用来帮助指定ESS黑盒的需求,正如描述在下一节。

每个用例可以增被强使用一个用例描述，包含用例场景中的每个步骤的一个的文本描述，诸如，描述在第12.4.2节。有许多关于如何写模型用例的软件分析的书籍[47]。各个步骤可以被捕捉作为SysML需求，可以被追溯到其它模型元素,诸如，特定动作在一个活动图中。用例描述可以包含额外的信息，诸如，可选路径和前置和后置条件。

1. 1. 1. 分析系统需求

Analyze System Requirements活动显示在图17.13。这个活动指定系统需求采用黑盒方式，根据它的输入和输出行为和其它外部观测到的特征。场景分析对应每个企业用例，描述系统如何与外部系统交互并标识用户在域模型来达到任务目标。

场景被建模使用或带有活动分区活动图或序列图。系统语境图被描述使用一个操作领的内部模块图，定义系统和外部系统和用户之间的接口。可以影响有效性测量的系统的关键属性被标识。基于分析,黑盒系统需求可以被指定根据系统功能、接口、控制、存储、性能、和物理需求。使用系统的状态机增强系统的黑盒需求，通过指定触发功能或操作的条件和事件，系统执行支持多个用例场景。

图17.13 分析系统需求活动来指定系统的黑盒需求

除了黑盒需求、设计约束,诸如，COTS组件的请求使用也被标识并捕捉,和随后施加在架构上。需求变更分析也被执行来评估需求变更的概率，和结果被使用在架构过程中来确保，架构是充分健壮的来适应潜在的需求变更。

系统需求检查被执行来确认，需求解决利益相关者的需要和任务需求,并确保需求的质量。这个检查可以被执行增量的,诸如，在分析完成时对应每个企业用例。

1. 1. 1. 1. 定义任务场景

在这个活动中,一个或多个任务场景被定义对应每个企业用例来指定系统和外部系统和用户之间的交互，来达到用例的目标(即,任务目标)。任务场景提供指定系统行为需求的基础。完整的一组场景，对应于每个主要的和可选的路径的每个用例都需要来完整指定系统需求。这可以包含附加用例的重构来表示通用功能，可以被分享在不同的用例之间。下面的因素应该被解决通过场景分析：

• 可能性比较高的场景
• 强调性能的场景和明显影响moe的场景
• 失败和异常场景
• 关键系统功能
• 新的系统功能
• 交互包含所有外部系统和用户

任务场景被建模使用活动或序列图。在活动图分区的中(也被称为泳道),或生命线在序列图中,表示系统和外部系统和用户。对于这个例子,任务场景被表示使用活动图。动作在活动分区被执行通过实体也即通过活动分区。

一个代表性的企业用例场景称为Provide Intruder Emergency Response(提供入侵者的应急响应)显示在图17.14。这个场景包含在Operational::Behavior包中并对应Provide Intruder Emergency Response用例在图17.12。场景被表示通过一个活动图带有活动分区对应ESS、Emergency Services（应急响应）、Occupant（乘员）和Intruder（入侵者）。ESS和Emergency Services是Security Enterprise的子分区。动作在每个活动分区中指定相应的模块必须做什么。ESS必须激活和去激活系统在响应Occupant输入中和必须监控环境来监测一个Intruder。分配活动分区描述在第14.6.3节被使用,但没显示,来分配职责对应动作。

接收事件动作表示一个Intruder的到达。流引脚在monitor intruder（监控入侵者）动作上说明，动作持续来接收输入和/或提供输出，正如它监控环境来检测Intruder。Alert Status（警报状态）输出来自monitor intruder动作反映输出必须是处于validated状态对应警报消息将被发送到Emergency Service,实现有关ESS的附加需求。

图17.14 Provide Intruder Emergency Response场景实现一个企业用例

另外一种特征在这个活动图是三个流终点的使用(使用X标志在一个圆内)。一个例子显示输出控制流来自deactivate system终止在一个流终点。这使deactivate system动作来完成不需要终止整个活动。

为了完整指定动作的输入和输出,它们的引脚必须有类型。模块定义图在图17.15指定动作的输入和输出类型在提供Provide Intruder Emergency Response活动图中。工具执行类型检查来确定输入和输出类型之前的兼容性,并将提供一个确认错误，如果它们不确定匹配的规则。这些类型也用于在下一节中所描述的相应的内部方框图中键入项属性。

图17.15 输入和输出定义对应Provide Intruder Emergency Response场景

1. 1. 1. 1. 定义系统语境

System Context图被显示作为一个内部模块图在图17.16。这个图描绘ESS和它的接口到外部系统和参与在任务场景中用户。内部模块图的框架表示Operational Domain模块。Operational Domain的组成部分对应Security Enterprise和来自图17.11的模块定义图中的企业参与者。组成部分键入ESS和Emergency Services内嵌在seo:Security Enterprise内部,和组成部分键入Occupant、Property、Intruder和Physical Environment内嵌在s:Site内。输入和输出流(即,对象流)来自Provide Intruder Emergency Response活动图在图17.14分配到项流，流过组成部分之间的连接器(参考第14.7节),和项属性被键入使用输入和输出引脚类型来自活动图。

端口被使用来指定接口，描述组成部分如何被连接到另外一个。详细的被指定通过端口的类型和在一些情形下通过连接器的类型。对于这个例子,端口类型被键入接口模块，其可以指定详细的接口规范对应逻辑的和物理的接口，正如描述在第7.6节。接口模块可以包含流属性来指定项，其可以流动通过端口。项流动说明事物的类型，流动贯穿连接器,包含Electrical Power（电功率）、Occupant Input（住户输入）、Site Status（站点状态）、Target Signatures（目标特征）和Alert Status（警报状态）。项流在连接器和流属性包含在端口中必须符合定义的兼容性规则。

图17.16 System Context显示ESS和顶层外部系统、用户、和物理环境之间

1. 1. 1. 1. 捕捉关键的系统属性和约束

关键的性能需求可以被捕捉作为ESS模块的数值属性或作为它的输入和输出的约束。性能需求被衍生基于工程分析。

一个性能分析的一个例子是一个时间线分析。时间图在图17.17指定任务时间线对应Provide Intruder Emergency Response场景在图17.14。动作来自活动图被显示在y轴上并请求时间来执行动作被显示在x轴上。时间线被使用来分配时间到每个动作在场景中，为了满足任务响应时间，其被标识作为一个moe。在这个例子中,入侵者监测响应时间是时间从入侵者进入房产，直到ESS报告警报到紧急服务。这被视作为一个关键系统属性, 被称为性能的衡量并被表示作为«mop»在模型中。这个属性对应的值可以是预算的基于它的影响在整个安全性有效性上。 图17.17是一个UML时序图，也即不是SysML的部分。然而, 时间线是一个可视化的工程分析的结果的许多重要的可视化方式之一。

其它关键的系统属性，需要分析来满足需求包含监测的概率和误警的概率。这些属性上的约束被绘制在参数图作为工程分析的部分描述在第17.3.6节,并贡献到图17.10的moe在。

图17.17 入侵者紧急响应时间线

1. 1. 1. 1. 指定黑盒系统需求

OOSEM 的应用结果在基于场景分析和其它执行的工程分析, 正如先前描述在本节中的。规范通常被称为黑盒规格（black-box specification），它定义了系统的外部可观察的行为和物理特性。黑盒规格要求不详细说明系统如何达到外部可观测的行为,其被定义通过系统设计。设计约束可能会增加黑盒规格，以限制如何实现黑盒要求。。

一个例子是使用一个特定的COTS组件或设计特定的算法设计约束。。

黑盒的规格要求被表示通过一个模块，具有下面的特征:

• 它必须执行的所需的功能和相关的输入和输出。所需的功能被建模作为动作，被分配到块或块的操作。相关的输入和输出是该动作的输入和输出的和相应的操作签名。
• 所需的外部接口，使其能够与其他外部系统和用户进行交互。该接口由模块上的端口和相关的端口类型指定。
• 所需的性能、物理的、和质量特性，影响功能如何很好的必须被执行,或一个物理特征，诸如，它的重量和尺寸。这些特征被指定作为数值属性带有单位制和数量类型。数值属性可以有确定的值或概率分布与它们的值相关。约束在数值属性上被捕捉使用参数约束。OOSEM应用«mop»构造类型到属性，其被标识作为关键的(例，可以明显影响任务性能)。
• 在输入事件和确定何时执行功能的前处理条件方面所需的控制。所需的控制可以表示由一个状态机的模块，指定哪些活动是在响应于不同的触发事件，以及它们的关联的保护条件。
• 所需的项，系统不许存储包含数据、能量、和质量。需要存储的可以被建模作为模块的引用属性。OOSEM的构造类型的这些属性作为«store»。

ESS模块的规范特征被显示在图17.18。在这个例子中, ESS模块的一个操作被定义对应到每个动作在ESS活动分区中，在图17.14。附加的操作被定义对应每个动作在其它任务场景中被分析。动作在活动图中是调用操作动作（call operation action），其调用操作在模块中，也即是表示通过活动划分。可选的是,在模块上调用行为动作（call behavior action）在ESS活动分区中可以调用一个活动，其被分配到ESS模块。

性能属性,诸如，probability of intruder detection、probability of intruder false alarm、intruder detection response time和mean time between failures是构造类型作为性能的测量«mop»。参数约束在这些属性上可以支持多种工程分析。端口和它们的类型指定系统接口。项被存储,诸如，:Event Log、:Sensor data和 aux pwr:Electrical Power 是引用属性，其是构造类型作为«store»。

黑盒规格要求可以被追溯到任务需求，正如描述在第17.3.7节,使用适当的需求关系。可追溯性可以被定义在一个细粒度的特征层级或在一个更细粒度的层级依赖于需要。

黑盒规格要求可以被应用在任何层级的设计,包含系统、元素、和组件层级。作为一个结果, 这个方法来指定一个模块的特征随后被使用在章节来指定组件需求。

1. 1. 1. 1. 定义系统状态机

活动图对应每个任务场景定义ESS必须执行的动作。ESS状态机指定组合行为，ESS必须执行基于来自ESS参与的所有场景动作。状态机指定何时ESS执行特定的动作。这被进行通过指定何时进入和退出一个状态并使能特定的动作在特定的状态。状态之间的转变被触发通过提交事件到看门狗条件，和事件相关联的输入的收据(即,信号或调用事件),一个变更事件,或时间事件。状态机的详细信息被讨论在第11章。

图17.18 ESS 黑盒规格要求

ESS响应一个输入事件评估看门狗条件，来确定是否来转变到下一个状态。看门狗的条件可以指定输入值、当前状态和资源可用性的条件。如果转变被触发,模块执行当前的状态退出动作,执行转变行为 (即,影响),并进入下一个状态。随后执行下一个状态的进入动作紧随通过它的do/行为,其被定义通过一个活动。(注：从初始伪状态到内嵌状态的转变)。转变行为可以包含一个发送信号动作，可以触发外部系统的状态机的一个转变。entry、exit、do和转变行为可以对应动作在ESS活动分区中。该系统的逻辑和物理设计必须实现由系统状态机所施加的控制要求。

一个简化的状态机指定控制需求作为一个系列的语句如下。如果在当前状态中发生输入事件，并且满足看门狗条件，则系统转变到下一个状态，并在指定的性能约束中执行指定的操作。转变逻辑也可被反映在活动图使用构件，诸如，动作上的前置和后置条件、控制节点上的看门狗条件、可中断区域、接收事件动作和发送信号动作。

ESS 状态机的一个部分被显示在图17.19。状态机包含power off、power up、power on和power down状态。power on状态是一个多个区域的复合状态对应activation-deactivation、intruder monitoring、fire monitoring、fault monitoring和power source management。系统有一个激活状态在它的每个正交区域在任何给定的时间。

图17.19 ESS 状态机

系统转变从deactivated到activated基于Activate Select。正如显示在intruder monitoring区域，ESS 初始的转变到intruder nonalert状态。如果一个入侵者被检测并且ESS处于激活状态,它设置警报并转变到intruder alert状态。在intruder alert状态,警报初始是unvalidated。一旦警报已经被确认,系统转变到validated状态并发送确认入侵者警报到Emergency Services。

1. 1. 1. 1. 分析系统需求变化

需求变化分析（Requirements variation analysis）试图来定义潜在的变更在需求中，这可能会导致从不同的来源，如一个可能的变化到外部接口，系统用户的数量可能增加，或可能的新功能。识别潜在需求变化的系统方法是评估在图17.18中的系统模块的每个功能，对应系统功能、接口、和性能需求,伴随每个项流和外部实体在图17.16中。这个评估可以标识系统黑盒规格要求和它的语境如何可能会变更。对应ESS, 一些潜在的需求变更可能会导致评估在图17.16中所示的预期站点设施的数量的潜在增加，通过多重性在Site Installation上, 或评估潜在的附加的ESS 功能来监控一氧化碳或灭火，会被包含作为附加的操作在图17.18中。

需求变化被评估根据一个需求将变更的概率,和它的潜在的影响,其可以被量化作为如高、中、或低。分析的结果是风险分析的输入，来评估技术、成本、和变更的计划影响,并来开发风险缓解策略。缓解策略被反映在架构和设计方法中,诸如，隔离设计变更需求的来源。类似的方法可以应用到评估潜在的技术变化。

1. 1. 1. 1. 标识系统设计约束

设计约束的约束，限制解决方案空间，在本例中是指ESS设计。这些约束典型由客户,开发组织,或外部法规强加的。约束可以被强加在硬件、软件、数据、操作过程、接口、或系统的任何其它其它组成部分。例子可以包含一个约束，系统必须使用预先定义的 COTS硬件或软件、或一个特定的接口协议。对于ESS系统,设计被约束包含遗留的中央监控站硬件,以及中央监控站和和历史点安装之间的通讯网络。

设计约束可以有一个明显的影响在设计上，并应该被确认之前施加它们在解决方案中。一个直接的方法来解决设计约束是来分类约束(例，硬件、软件、过程、算法),标识特定的约束对应每个分类,并捕捉它们作为系统需求在Requirements包中伴随对应的原理。设计约束随后被强加在物理架构上,正如讨论在第17.3.5节。

1. 1. 1. 定义逻辑架构

定义逻辑架构（Define Logical Architecture）活动显示在图17.20。这个活动是系统架构设计的部分，包含分解系统到的逻辑组件，并通过它们之间的交互满足系统需求。逻辑的组件是物理组件的抽象，执行系统功能不需要施加约束。一个逻辑的组件的一个例子是一个用户界面，其可以被实现通过一个 Web浏览器或显示控制台,或可以被实现通过一个光学传感器或接触传感器的一个entry/exit传感器。逻辑架构服务作为一个中间层次的抽象处于黑盒系统需求和物理架构之间。它可以帮助设计团队管理需求的影响和技术变更。例如, 如果 ESS性能需求对应监测一个入侵者的变化,entry/exit传感器将存在作为逻辑设计的部分,但特定的技术选型可以变化, 此外,逻辑架构可以作为一个系列的产品、支持不同的物理实现、以满足任务要求的范围内的参考架构。

图17.20 定义逻辑架构活动，分解系统到逻辑的组件,并描述它们间的交互和互联来满足系统需求.

逻辑架构定义活动包含分解系统到逻辑组件, 正如先前描述的。逻辑的场景被生成来描述系统模块的逻辑组件之间如何交互实现每个操作(例，功能)。系统的内部模块图定义这些逻辑组件之间的互联。逻辑组件标识从初始的逻辑分解可以进一步分解和完善再分配功能、存储、和属性的分解。每个逻辑的组件被随后指定以一种相似的方式，正如描述对应ESS黑盒规格要求。一个逻辑的组件可以包含一个状态机作为它的规范的部分，如果它有明显的基于状态的行为。系统层级需求和逻辑的组件之间的可追溯性被维护正如讨论在第17.3.7节。逻辑组件被分配到物理组件来开发物理架构,正如描述在第17.3.5节。

1. 1. 1. 1. 定义逻辑分解

ESS 模块被指定作为系统需求分析的部分描述在第17.3.3节。OOSEM包含系统模块对应的逻辑和物理设计分离的分解。为了达到这一点,一个系统模块的分离子类被生成对应逻辑的和物理分解, ESS Logical（ESS逻辑）模块是ESS模块的一个子类，其继承ESS模块的所有特征,包含它的操作、存储、属性、和端口。ESS Logical模块表示系统黑盒，其被分解到逻辑的组件。一个ESS物理模块被生成以一种相似的方式来表示系统黑盒，被分解到物理组件,正如描述在第17.3.5节。

OOSEM包含特定的技术来分解ESS Logical模块到逻辑组件,正如显示在ESS Logical模块定义图在图17.21。逻辑组件有«logical»构造类型的应用。系统被分解到逻辑组件的三个类,包含:

• External Interface Components（外部接口组件）来管理接口到每个外部系统或用户(参考系统和用户外部到ESS在图17.16)；
• Application Components负责提供业务逻辑和每个外部项流处理 (参考项流在ESS语境图在图17.16)；
• Infrastructure Components, 其提供内部系统支持服务或互联框架，诸如，布线、管道, 等。

在ESS逻辑分解中,一个Occupant IF Mgr是一个External Interface Component的一个例子,Site Configuration Mgr是一个Infrastructure Component的一个例子,和Event Detection Mgr和Alert Validation Mgr是一个Application Component的例子。这种方法确保了系统的逻辑架构包括组件与功能的通信和与外部系统的接口，输入和输出的处理，并提供内部支持服务。

逻辑分解的一些基本原理包括以下内容：:

• 传感器被假设来处理他们的输出并生成一个监测。
• Event Detection Mgr和System Controller提供大多数业务逻辑来处理来自传感器的事件,并控制动作在响应事件中。这是一种典型的模式，其已经广泛应用。
• Auxiliary Power管理通过Power Manager引入支持对ESS的严格的可用性要求。
• Occupant Input Data Mgr确认用户当他们输入代码。

图17.21 模块定义图显示ESS逻辑模块作为ESS模块的一个子类,和它分解到逻辑的组件包含External Interface Components、Application Components和Infrastructure Components。

1. 1. 1. 1. 定义逻辑组件之间的交互实现每个系统操作或分配活动

ESS Logical模块的操作继承自ESS 模块和重定义来包含它们的方法。活动图被定义作为方法来实现ESS Logical模块的每个操作。这确保每个动作，ESS执行在任务场景的支持中,被实现通过一个活动在逻辑设计中。一个类似的方法被使用如果活动被分配到模块并且每个被调用通过一个调用行为动作在更高层级活动图中。

图17.22显示Monitor Intruder-ESS Logical活动图，实现ESS Logical模块的monitor intruder操作。活动的输入和输出匹配monitor intruder动作的引脚在图17.14的Provide Intruder Emergency Response场景中。活动分区表示逻辑组件来自ESS Logical Block Definition Diagram在图17.21。

External Sensor（外部传感器）、Entry Sensor（入口传感器）、Exit Sensor（出口传感器）和Internal Sensor（内部传感器）生成Detections，Event Detection Manager（事件监测管理）处理Detection来生成一个intruder:event并存储事件信息在event log中。System Controller随后控制系统动作响应Event。控制器动作请求Site Status Mgr来提供一个状态更新。如果系统已经被激活, System Controller发送一个信号来触发警报,来记录外部传感器数据在Sensor Data Recorder（传感器数据记录器）中，和来请求警报的确认。如果警报被确认,警报状态被通讯到Emergency Services。条件的逻辑可以被捕捉通过System Controller状态机或可以被表示使用后处理条件在控制器动作上。动作在活动图中包含流的输入和输出，但没有显示到简化的图上。

1. 1. 1. 1. 定义系统的逻辑内部模块图

ESS Logical内部模块图被显示在图17.23,并表示组成部分的互联，由逻辑组件键入。封闭的框架表示ESS Logical模块。ESS Logical模块的端口与ESS模块上的是协调一致的，ESS定义在图17.16, 允许将外部接口委派给系统的逻辑部分。

组成部分键入外部接口组件提供通讯和接口到ESS外部环境。组成部分键入application components提供业务逻辑。例如,传感器在图中表示外部接口组件和Event Detection Mgr和System Controller（系统控制器）表示application components（应用组件），其提供业务逻辑到监测过程来自传感器,并控制入侵者监测的响应。组成部分之间的连接器使控制器来发送请求到Alarm、Sensor Data Recorder、Site Status Mgr和Alert Validation Mgr。此外 Investigative Data Mgr有权限来调查数据包含Event Log（事件日志）和Sensor Data Recorder。为了简化图，项流没显示。

图17.22 Monitor Intruder-ESS Logical活动图是一个线程通过ESS逻辑的系统设计

实现ESS Logical模块的monitor intruder操作

图17.23 ESS Logical内部模块图显示系统逻辑组件之间的互联

当完成时, 逻辑设计的内部模块图包含系统的所有逻辑的组成部分。然而,有时,期望来仅显示组成部分的一个子集基于一个特定的需要。一个通用的例子是来生成这个内部模块图的一个版本，其仅显示一个特定子系统的逻辑的部分,其中一个子系统对应到那些组成部分，其执行一个特定的系统功能或交叉视图,诸如，表示动力子系统使用提供动力的组成部分。

1. 1. 1. 1. 指定明逻辑组件

每个逻辑组件的规范包含特征的规范，被绘制在各自的模块中采用同样的方式，被描述对应指定ESS系统模块的特征规范。动作来自活动图被捕捉作为操作；逻辑的接口被捕捉作为端口；持久存储被捕捉作为引用属性使用«store» 的构造类型应用；和性能和物理的属性被捕捉作为数值属性。

1. 1. 1. 1. 定义逻辑组件状态机

组件的规范可以包含一个状态机，如果它有状态行为，也即依赖于输入事件和前处理条件。一个简单的状态依赖行为对应一个组件可以包含一个等待状态,其中组件等待直到它接收一个输入事件。组件随后转变到另外一种状态来执行一个特定的do/行为，被定义通过一个活动。它随后转变返回大它的等待状态，当活动被完成和等待下一个触发事件。

对于这个例子Event Detection Mgr和System Controller是逻辑组件，有复杂的状态依赖行为。System Controller是一个逻辑组件，职责是控制动作响应事件来自Event Detection Mgr。由于控制器必须处理不同的事件给出不同的响应,和它的行为也依赖于系统的当前状态,它是合适的来表示控制器的行为使用一个状态机。控制器状态将镜像许多相同的状态，处于系统状态机中，在图17.19,但转变和行为将反映System Controller的输入和System Controller的动作而不是ESS系统输入和动作。

1. 1. 1. 综合备选的物理架构

Synthesize Candidate Physical Architectures（综合候选的物理架构）活动显示在图17.24。这个活动综合候选的物理架构来满足系统需求。架构被定义根据物理组件，它们的关系,及其在系统节点的分布。系统的物理组件包含硬件、软件、持久性数据、和操作过程。系统节点表示一个组件的划分基于它们的物理位置或其它分布的准则，诸如，组织的职责。一个系统不是一个分布式系统是一个退化的情形包含一个单一的节点。

划分准则被定义并用来划分物理组件和解决关注点，诸如，性能、可靠性、和安全性。逻辑的节点架构被定义如何来确定逻辑的组件,和它们相关的功能,储存数据、和控制、分布在系统节点上。一个物理节点架构被定义，其中每个逻辑的组件在每个节点上被分配到一个或多个物理组件，其可以包含硬件、软件、和持久的数据组件的一个组合,以及操作过程执行通过操作者。系统设计约束，被定义第17.3.3节被施加在物理架构上。

软件、硬件、和数据结构是物理架构的特定视图，其中只包括适用的软件，硬件和数据组件。例如,软件架构强调软件组件和它们的行为和结构关系。定义这些架构包含组件附加的划分基于特定关注的实现。需求被随后指定对应每个物理组件并追溯到系统需求。

图17.24 综合备选的物理架构活动来指定系统的物理组件

工程分析和权衡分析被执行来评估、选择、并改进首选的的物理架构正如描述在第17.3.6节。应该注意的是，权衡分析被执行贯穿整个OOSEM过程，开始于分析涉众需求。一个系统设计审查被执行增量的来确保物理架构满足系统需求和涉众需求。

1. 1. 1. 1. 定义划分准则

划分是系统架构的一个基础方面。划分准则被建立来划分功能、数据持久性、和逻辑的和物理的组件之间的控制,和来划分子系统、节点、和架构层级之间的划分。应用划分准则在整个设计过程可以导致在组件设计中，最大限度地提高凝聚力和最大限度地减少耦合，以减少界面的复杂性。应用准则也可以降低需求和技术变更的影响,并更有效的解决关键需求诸如，性能、可靠性、可维护性、和安全性。设计实践,诸如，装配件的设计和设计的可维护性,包含定义和划分准则的应用作为实践的一个关键部分。划分的一些例子包含下面的:

• 重构通用的功能到共享的组件
• 划分组件和功能基于相同的更新速率,并划分组件使用高的更新速率对应那些带有底的更新速率
• 划分软件组件到架构层次基于功能的依赖性程度或它们提供的服务
• 划分数据到分离的存储其基于它们的安全性分类层次
• 物理划分，这样低的可靠性组件更容易获得，以减轻可维护性
• 组件的物理划分来减少装配和拆卸的移动部件的数量
• 划分组件来重用通用的模式
• 划分组件来减少变更在需求或技术上的传递影响。需求变化分析被执行，作为制定的黑盒系统需求的部分，可以被用来标识更可能的需求变更。
• 基于开发的考量，划分功能和组件，诸如，是否它们是一个特定的增量的发布的部分

划分考量应该增强通过其它设计策略，诸如，这些说明在下面，以确保一个强大的和可扩展的设计。

• 标准接口的使用
• 规定通过软件升级增加功能
• 模块化和可重新配置组件的使用
• 在退化模式中的操作能力(例，安全模型)
  1. 1. 1. 定义节点逻辑架构

到目前为止, 还没有讨论如何在系统节点上分布的功能。一个节点常常表示组件的一个划分和相关的功能、控制、并基于组件的物理位置保存数据。节点可以包含一个固定的设备或一个移动的平台，诸如，一架飞机。许多现代的系统被分布在多个系统节点上。节点也可以被定义基于其它准则，诸如，组织的职责(例，人员和资源赋值到一个特定的部门)。在OOSEM中，一个逻辑节点表示逻辑组件在特定位置的一个聚合(或集)。一个物理节点表示在一个特定位置的物理组件的一个聚合(或集)。逻辑组件在一个逻辑节点被分配到物理组件在一个物理节点上,正如随后描述在本节的。

功能、控制、和保存数据可以被分布以多种方式。一个系统可以是严重的分布的，这样每个节点有完整的功能、控制、和数据并可以自主操作。可选的是,分布也可以是中央集中的，其中大多数的功能、控制、和数据与一个中央节点相关,和本地节点主要提供一个接口到外部系统和用户在一个特定的位置。功能、控制、和数据可以被部分分布的贯穿区域和本地节点中,其中，每个节点执行总的功能的一个子集、控制、和数据。

一个分布的系统可以被刻画为完全分布的,部分分布的,或上面描述的中央集中分布的，分布的选项可以包含一个中央节点任何的组合,多个区域节点,和多个本地节点在每个区域中。权衡分析典型的被执行来优化分布方法基于考虑，诸如，性能、可靠性、安全性、和成本。许多类型的系统被分布包含信息系统与网络的通讯,电力分布系统，体系(SoS)的复杂系统，诸如，交通系统。

对于ESS,节点表示Central Monitoring Station (CMS)和Site Installations，其被安装在一个Single-Family Residence、Multifamily Residence或Small Business。尽管没有包含在这个例子中,一个CMS备份设备可以是一个附加的节点来提供灾难性护肤来满足系统可用性需求。

ESS Node Logica模块定义图显示在图17.25。ESS Node Logical是另外一个ESS模块的子类，其继承所有它的特征,类似于ESS Logical模块。每个子类有一个明显的分解。这个模块被分解到Site Installation和Central Monitoring Station节点，是构造类型«node logical»。

Site Installation和Central Monitoring Station由逻辑的组件组成，正如分别显示在图17.26和17.27。这种分解包含逻辑组件，被定义在逻辑设计在第17.3.4节。

一个特定的逻辑的组件可以被分布到超过1个节点。然而,逻辑组件可以有不同的需求在每个节点。一个逻辑组件的一个例子也即被分布到超过一个节点是Sensor Data Recorder分布到Site Installation（站点安装）和Central Monitoring Station（中央监控站）。这种分布被驱动需要集中管理大量的数据，并提供中央存取传感器数据。在这种情况下Sensor Data Recorder（传感器数据记录器）的一个子类的逻辑的组件被定义对应Site Installation和Central Monitoring Station节点使用它们特定的需求。Event Log也被分布到Site Installation和Central Monitoring Station,所以事件数据来自多个站点可以被获取在中心。这个实施需求来综合Site Installation和Central Monitoring Station的数据，数据库设计必须解决。正如显示在图中, Site Installation和Central Monitoring Station节点也包含组件称为Site to CMS IF和CMS to Site IF来支持节点之间的通讯。

图17.25 模块定义图显示ESS Node Logical模块正如ESS模块的一个子类,它分解到Site Installation和Central Monitoring Station的逻辑节点

图17.26安装站点节点分解到它的逻辑的组件

图17.27 中央监控站节点分解到它的逻辑的组件

类似的一组建模构件的集用来定义ESS Logical架构在先前的章节中，也可被开发来定义ESS Node Logical架构。这包含ESS Node Logical的活动图和内部模块图。每个活动图是ESS Logical架构创建的，阐述了ESS Node Logical架构指定的活动如何执行通过逻辑组件，被分布在节点上。

活动图显示组件的交互在每个节点内部和贯穿节点。活动图称为Monitor Intruder-ESS Node Logical Site到CMS Communications被显示在图17.28,为了适应页面,活动图仅包含整个Monitor Intruder行为的一个端口，其被指定在逻辑的活动中在图17.22。节点被表示正如作为划分,和逻辑组件内嵌在它们各自的节点。在这个例子中, process intruder detection（处理入侵者监测）和control intruder response（控制入侵者响应）动作被完成在Site Installation节点和validate intruder alert被完成在Central Monitoring Station节点。事件数据和传感器数据的存储被执行在两个节点上。Site to SMS IF和CMS to Site IF支持Site Installation节点和Central Monitoring Station节点之间的通讯。这个活动图的整体行为是一致的行为，最初被指定为在Monitor Intruder-ESS Logical活动图，图17.22中的逻辑设计部分。

图17.28 Monitor Intruder-ESS Node Logical Site to CMS Communications活动图显示

选择的组件和节点之间交互的通讯

ESS Node Logical内部模块图在图17.29和图17.30显示，逻辑组件如何互联在每个节点内部和贯穿节点。这包含组成部分的互联，支持通讯指定在Monitor Intruder-ESSNode Logical Site to CMS Communications活动图中。再一次,系统的外部接口被维护在封闭的模块的端口上。然而,节点在这个例子中没有端口。相反,外部连接器直接连接到节点的内嵌的组成部分的端口上。

图17.29 Site Installation内部模块图显示它的组成部分之间的互联

图17.30 Central Monitoring Station内部模块图显示它的组成部分之间的互联

1. 1. 1. 1. 定义节点物理架构

功能对应逻辑的组件在ESS逻辑架构被划分在逻辑节点中并绘制在ESS节点的逻辑架构中正如描述在先前的章节。这被完成通过分布逻辑的组件到每个逻辑节点基于划分考虑，有些独立的组件如何被实施。例如,划分Entry Sensor逻辑组件到Site Installation节点和不到Central Monitoring Station节点，无论什么技术被使用来实施Entry Sensor。

逻辑组件在每个节点上，被随后分配到物理组件在每一个节点构成的ESS节点物理架构中。支持权衡分析,解决技术和实施的考虑关联到性能、可靠性、安全性、和其它质量属性,被解决作为这个分配决策的部分。逻辑组件到硬件组件和逻辑的组件到软件组件的一部分分配在Site Installation节点和Central Monitoring Station分别被显示在分配表在图17.31和图17.32。

设计约束被标识在系统需求分析过程中在第17.3.3节，被施加在物理架构上作为逻辑-到-物理分配的部分。例如,一个逻辑的组件可以被分配到一个特定COTS组件，其已经实施作为一个设计约束。一个引用的物理架构也可以约束解决方案空间使用多个预先定义的或遗留的组件，诸如，通用服务的一组集。例如,引用的软件架构对应Central Monitoring Station软件是一个多层级的软件架构，包含特定类型的组件与每个架构层次关联—也即是,表示,任务应用框架,和操作系统层级。

图17.31逻辑的组件到硬件组件的分配在安装站点和中央监控站节点

图17.32逻辑组件到软件组件的分配在站点安装和中央监控站节点上

备选的物理架构被生成通过分配逻辑组件到可选的物理组件。例如, Entry Sensor包含备选的分配到一个Optical Sensor和一个Contact Sensor、Contact Sensor被选择作为备选项。逻辑-到-物理组件的分配也可以基于架构模式。模式可以表示与技术相关的通用解决方案。例如, Event Detection Mgr和System Controller构成一个设计模式在逻辑设计中，可以被实施使用一个通用的软件设计解决方案。

权衡分析被执行来基于选择准则选择首选的物理架构，其优化有效性测量和性能测量。在这个例子中,ESS入侵者监测的概率和误警概率可以驱动Site Installation性能需求,和被监控的Site Installations的数字和类型,和紧急响应时间,可以驱动Central Monitoring Station的性能需求。性能需求必须被提交到权衡使用可用性、成本、和其它关键需求达到一个平衡的系统解决方案。

当一个逻辑的组件被分配到软件，软件组件必须也被分配到执行它的一个相应的硬件组件。除了软件分配，保存数据被分配到存储数据的硬件组件，和操作过程被分配到执行过程的操作符。这些分配也可被反映到分配表类似于图17.31和17.32。

一种类似的方法，被使用来建模ESS节点逻辑架构可以被应用到ESS节点物理架构。ESS Node Physical模块被定义作为ESS模块的一个子类，并分解到物理节点如图17.33所示。除了Site Installation和Central Monitoring Station节点、Communication Network也是一个节点在节点物理架构中,而它是抽象的方式在节点逻辑架构中。

图17.33 模块定义图显示ESS节点物理模块作为ESS模块的一个子类,和它分解到安装站点和中央监控站物理节点

ESS Node Physical模块定义图对应Site Installation和Central Monitoring Station被分别显示在图17.34和图17.35。在这些模块定义图中,逻辑的组件来自逻辑节点在图17.26和图17.27已经被分配到物理组件基于在图17.31和17.32的分配表。物理组件组成Site Installation和Central Monitoring Station物理节点。物理组件有构造类型应用来表示组件的类型,诸如，«hardware»和«software»。

图17.34 安装站点-物理节点模块定义图显示物理组件的层次

图17.35 中央监控站-节点物理模块定义图显示物理组件的层次

Monitor Intruder-ESS Node Physical活动图对应Site Installation（安装站点）和Central Monitoring Station（中央监控站）被显示在图17.36。活动划分表示ESS节点物理架构的组件。活动图捕捉硬件和Site Software（站点软件），以及系统操作之间的交互。Site Software聚合所有软件组件，其被分配到Site Processor（站点处理器）并是构造类型作为一个configuration item(配置项)。这个软件执行在Site Processor上,尽管这没显示作为一个活动划分在活动图中。软件组件之间的详细交互必须保存交互，被指定在逻辑架构和节点逻辑架构。其它活动划分表示硬件组件和安全性操作。

活动图必须与图17.22中相应的逻辑和节点逻辑活动图的行为一致，如图17.28所示，并也支持初始的行为指定对应monitor intruder动作在图17.14中。包含它的输入、输出、和任何前置和后置条件。在同一时间,更详细的添加来显示物理组件如何交互在每个节点上。

图17.36 监控入侵者-节点物理活动图显示物理组件之间的交互

ESS Node Physical内部模块图对应Site Installation和Central Monitoring Station在图17.37和图17.38，显示物理部分如何被互联在每个节点内部和通过节点。ESS Node Physical模块是封闭的框架。

在每个组件上物理端口被指定作为物理接口。外部端口在Video Camcorder上是p2，并键入一个Optical Interface，其重定义External Sensor IF端口。在Video Camcorder上的其它端口包含一个端口p1键入Video IF和Power IF端口(没显示)。大多数端口在内部组成部分没有完整的定义在这个例子中,和因此不显示流的方向。

由于ESS Node Physical模块是ESS模块的一个子类,它继承它的特征包含它的端口来自ESS模块。然而,物理端口在ESS Node Physical模块上不共享一个通用类型使用端口在初始的ESS黑盒上,其已经被定义作为逻辑端口。当处理数据流,物理接口常常被指定通过一个通讯协议,和逻辑接口表示信息内容。因此,这些物理端口在ESS Node Physical模块上需要替换逻辑的端口从初始的ESS模块。这可以被完成通过定义一个多重性在初始的端口上作为0..1,这样ESS Node Physical模块不得不使用原始的端口定义。它执行这通过重定义多重性作为0,并随后添加它自己的端口作为需要的。一旦者被执行,逻辑端口来自ESS Node Logical模块可以被分配到ESS Node Physical模块的物理端口。一个可选的来替换端口，是来延迟端口的类型在初始的ESS黑盒上,和它们的类型在ESS Node Logical和ESS Node Physical模块上。

项流定义作为逻辑流动项在逻辑架构中,并分配到物理项流在物理架构中。端口的类型已经被延迟在这个例子中等待详细的接口规范在组成部分上。

ESS节点物理架构定义系统的物理组件,包含硬件、软件、数据存储、和其它存储项(例，流体,能量)和操作过程，被执行通过操作符。软件组件和持久的数据存储内嵌在它们分配到的硬件组件中。在图17.37例如,一些软件的组成部分已经被分配到Site Processor。软件到硬件的分配是一个软件组件到一个硬件处理器的UML部署的一个抽象。

ESS节点物理架构服务作为集成框架对应所有组件来一起工作。ESS Node Physical Design包在图17.4包含内嵌的包对应节点物理架构的Structure和Behavior。此外, Node Physical Design包也包含包对Site Installation和Central Monitoring Station,每个约束所有内嵌的包对应硬件、软件、持久性数据、和操作过程。系统的物理组件，是ESS节点物理架构的组成部分，被包含在这些内嵌的包中。下面的子节描述活动到架构并指定软件、数据、和硬件架构。此外,子节描述如何来定义架构的特别视图，诸如，安全性；并指定操作系统所需的操作程序。

图17.37 站点安装节点物理内部模块图

图17.38 中央监控站-节点物理内部模块图

1. 1. 1. 1. 定义软件架构

软件架构是一个系统架构的整体视图，其包含软件组件和和它们之间的相互关系。软件架构是有效的指定软件组件支持系统需求的关键。

ESS Software模块定义图被显示在图17.39。Site Software和CMS Software模块聚合通过引用软件，其被定义在ESS节点物理分解中对应Site Installation和Central Monitoring Station分别在图17.34和17.35。Site Software和CMS Software模块提供一种方式来聚合软件到一个«configuration item»。软件组件被包含在软件包,其依次被包含在Site Installation和Central Monitoring Station包。

图17.39 ESS软件模块定义图显示安装站点软件和中央监控站软件

建模组件对应系统层级软件架构包含类似的建模构件，正如先前描述的。相似的,软件行为可以被指定来确认使用活动图指定作为逻辑的部分,节点逻辑,和节点物理活动图。行为可以被指定作为活动图、序列图、和/或状态机图。这可以包含定义活动图、序列图、和/或状态机图来细化软件组件之间的交互，其初始的被指定在活动图对应逻辑组件和随后对应Site Software。内部模块图可以被生成从Site Software和CMS Software模块来详细定义软件互联。互联和相关端口类型应该通过一致使用ESS节点物理架构的内部模块图。接口可以包含端口，其被键入通过模块和/或接口模块，其指定需要和提供的接口。序列图和内部模块图都应该与行为和结构需求协调的，指定通过物理架构活动图和内部模块图。软件架构细化可以被表示在SysML中或UML中，随后描述在本节。

从逻辑-到-物理组件的初始分配可以不包含分配到所有框架和操作系统组件，其被需要来支持应用组件,所以这必须被解决作为定义软件架构的部分。此外, 此外，软件组件可能需要相当大的改进，以解决软件的具体问题，并充分指定软件的需求。软件结构的一些关注依赖应用领域。对于信息系统,软件架构常常是一个层级架构,其中每个层级包含软件组件，其可以依赖一个更低层的对应它提供的服务。这可以包含一个表示层级,任务应用层级,框架层级,操作系统层级,和数据层级,正如显示在包图对应CMS软件在图17.40。软件组件来自物理架构被进一步细化和划分到不同的层级。一个引用的架构可以被实施作为一个设计约束，其包含定义框架层级的可重用的组件,诸如，消息,存取控制服务,和数据库接口。对于嵌入式实时软件设计,架构也必须解决关联到日程算法和如何来解决并发、优先权、和总线的利用、内存、和处理器资源的关注。这些和其它的关注必须被解决来完整定义软件架构。

图17.40 包图显示软件层级之间的依赖性

1. 1. 1. 1. 定义数据架构

数据架构是一个物理架构的视图，其表示持久性数据,数据如何被使用,和数据被存储在那里。物理架构提供集成框架来确保数据架构与整体的系统设计是协调的。持久性数据需求可以是衍生自场景分析。持久性数据被存储通过一个组件(逻辑或物理的)和表示作为一个组件的引用属性使用«store»构造类型。作为逻辑设计的部分,持久性数据被封装在操作在它上面的逻辑组件上。逻辑组件被分配到物理架构的物理组件,其可以包含数据文件和内存存储设备，其存储数据,和软件应用，诸如，关系性数据库的应用，其管理数据。

持久的数据定义类型对应Site Installation和CMS被指定在一个ESS Persistent Data模块定义图正如显示在图 17.41。这包含Event Log、Video和Site Config Data，作为持久数据类型，其构造类型为«file»。数据定义可以是复杂的数据结构，其被表示通过模块或数值类型。例如, Event Log包含许多不同类型事件的记录，诸如，通电事件,系统激活事件,入侵者监测事件,和其它衍生自场景分析。持久数据被包含在内嵌的包Site Installation和Central Monitoring Station包的内部。

图17.41 模块定义图显示持久数据存储通过系统在安装站点和中央监控站

数据架构可以包含域特定构件来细化数据规范。数据关系可以被指定通过一个实体关系属性(ERA)图或直接在模块定义图上使用模块之间的关联，其定义数据。这种描述可以被视作为概念数据模型，其表示需求对应实施的数据库。概念数据模型的实施依赖于使用的技术,诸如，平面文件、关系型数据库、和/或一个面向对象的数据库。

有许多其他领域的特定方面的数据结构，必须考虑，诸如，数据的规范化、数据同步、数据备份和恢复、和数据迁移策略。数据同步的一个例子是需要同步事件日志来自每个Site Installation与Central Monitoring Station。数据架构的选择和特定的技术被确定通过权衡分析和分析,正如描述在第17.3.6节。

1. 1. 1. 1. 定义硬件架构

硬件架构是物理架构的一个视图,其表示硬件组件和它们之间的互相联系。ESS Hardware模块定义图被显示在图17.42,并包含Site Hardware和CMS Hardware模块。这些模块聚合硬件组件以一种相似的方式正如显示在图17.39对应ESS Software。

硬件组件被分配来自逻辑的组件在图17.31，正如先前描述的。ESS Node Physical内部模块图在图17.37和图17.38显示硬件组件之间的互相联系。这可以更充分地阐述了更详细的硬件接口，包括通信协议，信号特性，物理连接器和电缆。硬件框架和组件技术的特定选型来自工程分析和权衡分析,正如描述在第节17.3.6.这包含性能分析来支持规模和其它硬件组件需求、和可靠性、可维护性、和可用性分析来评估支持能力需求。

图17.42 ESS 硬件模块定义图显示对应安装站点和中央监控站的硬件

1. 1. 1. 1. 定义操作过程

操作者可以是系统外部的或系统内部的,依赖于系统边界如何被定义。对应ESS, Occupants的属性是外部到系统,正如定义在Operational Domain模块定义图在图17.11。另一方面, Central Monitoring Station Security Operator和Administrator在图17.35被考虑在ESS内部。一些逻辑组件被分配到内部操作者来执行选择的任务。内部和外部操作者/系统的用户都被表示在活动图上来描述它们如何与系统的剩余部分交互。它们也被包含在其它图中像任何其它外部系统或系统组件。

需求对应一种什么操作必须执行到操作系统可以被指定通过操作的过程，其定义每个Operator需要的任务。任务分析、时间线分析、认知分析、和其它支持分析被执行来确定任务性能的层级，其是协调的与特定的技巧级别。ESS操作过程被标识在ESS Procedures模块定义图在图17.43。每个过程应用«procedure»的构造类型。

图17.43 模块定义图显示操作过程对应 ESS外部用户和内部操作

1. 1. 1. 1. 指定组件需求

物理架构包含详细的软件架构、数据架构、硬件架构、和操作过程,导致系统架构的组件规范将被分别实施在软件、数据、硬件、和操作过程。组件规范是一个主要的输出来自系统规范和设计过程。组件规范典型的被捕捉作为模块带有合适的黑盒规格要求特征,以一种相似的方式正如描述在第17.3.3节的子节称为指定黑盒系统需求。软件组件规范和硬件组件规范的模型的一个例子被显示在图17.44。软件组件在图中是Controller也即是Site Software的部分,使用OOSEM 的«software»构造类型。一个构造类型属性称为status说明这是一个Development Item。控制器操作和端口被指定。如果需要的和提供的接口被使用,这些会被需要来反应在端口类型中。活动图可以被用来定义方法对应操作,如果这是软件规范考虑的部分，诸如，对应计算的和/或逻辑密集型算法。参数图可以被用来指定算法的性能需求根据期望的输入、输出响应。状态机对应控制器可以定义主要的行为根据事件，其触发操作。

图17.44软件和硬件组件规范的例子

develop software过程引用到在图17.1被使用来执行软件需求分析来驱动更详细的需求、进行软件设计、和实施和测试软件组件。统一建模语言[36]可以被使用来支持这个过程。SysML模型可以被引用作为一个规范模型通过软件设计团队。类可以被定义作为SysML软件组件规范的一个子类或分配来自SysML软件组件规范并表示在类图上。UML组合结构图可以被用来细化来自节点物理架构在图17.37和图17.38的SysML内部模块图来反应软件组件之间的互联和接口。软件设计实现软件组件接口、操作、和状态机行为指定在SysML模型中通过介绍更详细的结构和行为。软件序列图被进一步阐述来显示底层软件设计组件之间的交互。UML组件图和部署图也可以被使用对应软件设计来显示更明显的软件如何被部署除了软件到硬件的抽象分配在图17.37和图17.38。

硬件组件规范在图17.44是Video Camcorder也即是Site Hardware的部分,使用OOSEM的«hardware»构造类型。构造类型属性称为status说明这试图是一个商业现成的(COTS)项。黑盒组件规范包含功能需求衍生自场景分析,和性能属性使用«mop»构造类型，它的值被确定通过工程分析和权衡分析,正如描述在第17.3.6节。端口被使用来指定接口和显示流属性的方向。它也是明显的舱段，Video Camcorder有一个Memory Card（存储卡）和包含Image Processing（图像处理）。如果软件组件被分配到硬件,它们可以被表示在一个分配舱段中。此外,一个属性也可被添加到硬件组件，其引用一个组件的几何绘图。附加的规范特征可以是添加来解决需要。

组件模块表示组件的黑盒规格要求以一种相似的方式，ESS模块表示系统的一个黑盒。组件模块的规范特征类似于特征描述在第17.3.3节。特征可以被使用作为一个文本需求定义的基础对应每个组件。模块的每个特征可以包含一个文本描述，其所有或部分对应到一个shall语句,或可选的是,特征可以细化一个文本需求。例如,文本对应操作可以指定功能需求, 文本对应端口可以指定接口需求,和文本对应数值属性可以指定性能和物理需求。文本可以被绘制在描述场中对应相应的模型元素或它们可以被捕捉作为SysML需求，其被随后被关联到规范特征通过合适的需求关系(例，refine、satisfy)。文档生成工具可以被用来自动生成文本规范基于一个规范模板。

1. 1. 1. 1. 定义其它架构视图

从特定利益相关者的视角来看，可能会有系统的其它架构视图，诸如，一个安全性架构。安全性架构可以被表示作为节点物理框架的一个过滤子集,其包含硬件、软件、数据、和过程，其解决安全性需求。视图提供一个机制，可以帮助来指定、分析、并集成了关键的架构交叉方面。这可以包含交叉行为、结构、参数、和与特定的关注关联的需求。

一个视点表示一个利益相关者的视角，诸如，一个安全性架构试点。视点被使用来指定模型的一个子集，也即是利益相关者感兴趣的并解决了它们的关注。来自第17.3.2节的因果分析可以提供输入来标识利益相关者关注。

图17.45 ESS 视点指定利益相关者视角，其反映在模型的视图中

正如描述在第6.9节,一个视点包含规则，指定如何一个特定的视图被构建来反映利益相关者的视角。规则可以被定义根据查询模型准则。一个视图提供模型的一个过滤部分，其符合视点通过返回模型元素在响应模型查询中。一个视图可以被表示以许多不同的格式，诸如，图的一个组合、表格、矩阵、和树,并可以被表示通过构件衍生来自超过一个模型。

Viewpoints包被引入在模型组织的讨论中在第17.3.1节并显示在图17.4。选择ESS Stakeholder Viewpoints被显示在图17.45包含Emergency Services视点和System Security视点。System Security视点指定查询准则来返回所有组件，需要来满足系统安全性需求,诸如，机密性、完整性、和可用性需求,安全性视图表示查询的响应并包含模型元素，其满足安全性需求。其它利益相关者视点可以表示Company Owner、Customer和其它开发团队角色。

1. 1. 1. 优化和评估备选方案

Optimize and Evaluate Alternatives活动被显示在图17.46。这个活动被调用在整个所有其它OOSEM活动中，来支持工程分析和权衡分析。此活动包括确定所需的分析,定义分析语境,捕捉约束在一个参数图中对应每个分析,并执行工程分析。

图17.46 优化和评估备选活动来支持权衡分析和分析

第8章描述如何来建模约束使用参数。SysML使关键系统特征将被绘制在模型中，所以它们可以被分析。这提供一种机制来集成系统设计模型与许多工程分析模型,诸如，性能、可靠性、和质量属性分析。第18章包含进一步的讨论关于工程分析和仿真模型如何被集成使用SysML模型在系统开发环境中。

1. 1. 1. 1. 标识未来执行的分析

分析未来将被执行的，应该支持特定分析目标,可以包含下面的:

• 特征或预测系统的一些方面,诸如，它的性能、可靠性、质量属性、或成本
• 优化设计通过敏感性分析
• 评估和选择一个首选的解决方案在备选设计方法中
• 验证一个设计使用分析
• 支持技术计划,诸如，成本预估和风险分析

不同类型和工程分析的真实度被标识在整个设计过程中来满足分析目标。构造类型也可被定义来包含属性，其捕捉附加的分析元数据,诸如，分析假设,或有关分析工具或求解器的信息(参考仿真配置文件和模型库在第15章中)。

1. 1. 1. 1. 定义分析语境

一个模块定义图被使用来定义每个分析。图17.47显示一个模块图称为ESS Analysis Context。Analysis Context模块由表示每个分析将被执行的模块组成。在这个例子中,一个分析被标识对应的每个moe在第17.3.2节,包含：Availability Analysis、Emergency Response Time Analysis、Probability of Intruder Conviction Analysis、Operational Cost Analysis。此外Cost Effectiveness Analysis模块被使用来分析整个系统的价值。

每个分析模块标识在分析语境中,被使用来进一步指定分析。在图17.48中, Cost Effectiveness Analysis模块由一个约束模块称为Operational Cost Effectiveness Equation。该约束模块已经应用«objectiveFunction»构造类型,并指定一个等式，其关联操作成本有效性到参数，其对应于有效性测量的可用性、紧急响应时间、入侵者定制概率、和操作成本。在这个例子中,等式是一个应用函数的权重求和，其被与每个moe关联。

Cost Effectiveness Analysis模块也引用到Operational Domain模块，作为分析的主题。在这种情况下,分析的主题是顶部模块在系统层次中。通过引用这个模块,参数在分析等式中可以被关联到ESS属性和外部系统和用户,是分析的主题。Operational Domain或更一般的讲,分析的主题,可以是子类来表示设计的不同变体来支持权衡分析。(参考第8.11节)。

图17.47 ESS分析语境定义分析模块来支持有效性测量分析

使用与上面相同的模式,每种分析可以被定义通过分解分析模块到可应用的分析等式和引用分析的主题。

1. 1. 1. 1. 捕捉约束在参数图中

参数图使能设计和分析模型之间集成。它执行这一点通过绑定分析等式的参数，其被定义对应每个分析模块到分析主题的属性(例，系统)。

ESS的顶层参数图被讨论在第节17.3.2和显示在图17.10。参数图使用等式定义在Cost Effectiveness Analysis在图17.48中。参数图绑定目标函数参数到moe显示在图17.11的Security Enterprise中。

随着系统设计的深入，附加的工程分析被需要来评估系统设计属性的影响在moe上。availability属性在图17.10表示一个moe，它的值被确定通过Availability Analysis标识在图17.47中。图17.49显示模块定义图对应Availability Analysis,其包含可用性,可靠性,和维修时间的等式。相应的参数图，其绑定等式的参数到ESS的特定属性被显示在图17.50。参数图提供机制来维护显式的关系在moe和它们的流向下到关键系统、元素、和组件属性。

参数也可以被使用来约束输入、输出、和输入/输出与一个系统或组件行为的关联。从Monitor Intruder-ESS Node Physical活动图在图17.36,一个约束模块可以被定义来指定数学原理在监测概率的信号和信号输入的信噪比到到Video Camcorder。约束模块可以随后被使用在一个参数图来绑定到特定属性来分析监测性能。

图17.48 成本有效性分析模块组成一个目标函数，其每个参数的权重,和引用操作域作为分析的主题

图17.49 可用性分析组成约束模块和分析主题的应用

系统的状态也可被作为一个数值属性，其被使用在参数中，这个属性的值表示系统的状态在任何点在某个时刻并被确定通过ESS状态机行为。这个属性可以被使用在参数中通过绑定一个状态依赖约束到状态属性。对应一个弹力球的例子, 应用在球上的力的约束，取决于球的状态，无论它是否与地面接触。状态依赖的约束可以被调节在球的状态上。在这个例子中,状态依赖约束表示一组方程，当球的状态是“与地面接触（contact with ground）”,和另外一组方程当球的状态是“没有与地面接触（not in contact with the ground）”。

图17.50 可用性分析模型绘制在一个参数图

1. 1. 1. 1. 执行工程分析

一个可计算的功能被需要来执行等式在参数图中。这可以被执行使用辅助的工程分析工具,正如描述在第18章。分析结果确定满足约束条件的系统属性的特定值或值范围。值可以被合并返回到系统的SysML设计模型中。例如,可用性分析结果来自Availability Analysis在图17.50可以显示扩展到系统满足它的可用性需求。需要的值对应mean time between failures和mean time to repair可以指定值对应ESS模块在图17.18中。

1. 1. 1. 管理需求可追溯性

Manage Requirements Traceability活动被显示在图 17.51。这个活动被调用贯穿整个OOSEM活动来建立需求可追溯性在利益相关者需求和系统规范和设计模型之间。这包含定义规范树；捕捉基于文本需求在模型中；建立基于文本的修和模型原始之间的关系derive、satisfy、verify和refine关系；并生成可追溯性报告和规范文档。语言概念对应需求建模被描述在第13章。

图17.51 管理需求可追溯性活动，试图来维护利益相关者和系统规范和设计模型之间的可追溯性

1. 1. 1. 1. 定义规范树

ESS Specification Tree(ESS规范树)被显示在图17.52。规范树中显示了系统层次中的每个层次的规范。规范树包含ESS Mission requirements（ESS任务需求）、ESS System Specification（ESS系统规格）、Site Installation Specification（站点安装规格）、Central Monitoring Station Specification（中央监控站规格）和Site和Central Monitoring Station Hardware（中央监控站硬件）和Software Specifications（软件规格）。追溯关系显示可追溯性在每个层级规范之间。规范树也显示可追溯性从ESS Mission requirements（ESS任务需求） 到一个Stakeholder Needs Assessment（涉众需要评估）文档。

图17.52 ESS规范树在一个需求图上，显示规范的层次

追溯关系被使用对应粗粒度的可追溯性，其不包含细粒度的可追溯性在个体设计元素和个体需求之间。细粒度的可追溯性使用其它需求关系,正如描述在第13章和随后在本节。

1. 1. 1. 1. 捕捉基于文本需求到模型中

利益相关者需求常常被绘制在文本规范外部到建模环境。基于文本需求被绘制在模型中通过生成一个SysML需求对应每个文本需求。许多SysML建模工具提供一种机制来导入文本需求从文档或需求管理工具直接到建模工具,并来维护原始需求和需求在SysML建模工具中的同步。可选的是,文本需求可以被生成在SysML建模工具中, 其可以被导出到一个需求管理工具,或输出作为一个文档以文本或表格格式。

Requirements包包含需求,简短讨论在第17.3.1节并显示在模型组织在图17.4中。一个内嵌的包被生成对应每个规范在ESS Specification Tree（ESS规范树）中。需求包包含需求对应规范。

例如, ESS Requirements被显示在需求图在图17.53中。顶层需求是ESS System Specification。正如前面提及的,这个需求服务作为一个容器对应其它需求在规范中。需求的容器层次在每个个体规范中通常对应到基于文本规范的文档的组织,如图中第一层需求所示。这些需求层次包含容器对应Interface（接口）、Functional and Performance（功能和性能）、 Reliability（可靠性）、Maintainability（维护性）和Availability（可用性）,和其它典型的需求的分类。每个需求有一个名称、一个id、和文本,也可以包含附加的需求属性,诸如，严重性、不确定、变更的概率、和验证方法,尽管这个信息没显示在图中。表格符号常常被使用作为需求一个更小型的表示，正如描述在第13.7.1节。

1. 1. 1. 1. 建立需求关系和原理

需求可追溯性被维护通过在模型中建立基于文本需求之间和其它模型元素对应于其它需求、设计元素、和测试用例之间的关系。原理对应的关系也可被绘制在模型中。

从一个任务需求到一个组件需求的需求可追溯性的一个例子可以被查看在需求图17.54中。图显示从Intruder Emergency Response（入侵者紧急响应）任务需求到Video Camcorder性能需求对应Field of view、Resolution和Sensitivity和到Capture Video功能性需求之间的可追溯性。

任务需求对应Intruder Emergency Response被细化通过用例称为Provide Intruder Emergency Response。ESS系统需求对应Intruder Detection and False Alarm Rate（入侵者监测和误报率）衍生自任务需求。Intruder Detection and False Alarm Rate需求包含需求对应Entry-Exit Detection和Perimeter Detection。需求包含在Video Camera Specification被衍生自Perimeter Detection需求。Video Camcorder（视频摄像机）被评估来满足Video Camera Specification（视频摄像机规格）。Verify Entry Detection（验证入口监测）测试案例Intruder Detection and False Alarm Rate需求被满足。原理对应衍生Video Camcorder性能需求来自Perimeter Detection需求被显示使用«rationale»构造类型。

保持可追溯性的粒度级别被确定作为过程剪裁的一部分。例如,它可以是充分的来评估一个特定的组件满足一个需求,诸如，Video Camcorder在图17.54.可选的是,它可能是必须的来显示一个组件的一个特定特征,诸如，它的数值属性之一,满足一个特定的性能需求。更细的粒度增加了可追溯性的精度,其可以辅助在变更影响评估中,例如；但它被执行增加了工作的代价来建立和维护可追溯性关系。

1. 1. 1. 1. 分析可追溯性差距

可追溯性报告被生成并用来分析可追溯性差距和评估系统设计如何满足系统需求。测量也可以被使用来确定需求覆盖率根据satisfy和verify关系。结果来自这种分析被使用来驱动更新到系统设计和验证和来更新可追溯性。矩阵和表格表示方式常常被使用来捕捉需求关系和差距报告正如描述在第13.7.2节。

视点和它们相应的视图可以辅助在需求可追溯性分析中，通过提供一种方式来查询模型对应模型元素，其满足一个特定的需求集。这被讨论在第17.3.5节的后面，在子节称为定义其它架构视图。如果选择的需求被使用作为定义查询准则对应一个视点的基础,视图符合视点可以是模型元素的一个报告，其满足选择的需求集。一个视图可以被表示以许多不同的格式，诸如，图的一个组合、表格、矩阵、和树。它也可被表示作为一个包含这些构件文档。

图17.53 ESS系统规范显示需求包含在系统规范中在一个需求图上

图17.54 需求图显示可追溯性从入侵者紧急响应需求到视频摄像机的组件需求和设计

1. 1. 1. 1. 管理需求更新

需求管理活动可能会导致建议的更新，以现有的需求和/或新的需求的产生。在一些情形下，新的文本需求被定义对应每个黑盒需求规格特征，诸如，那些显示在图17.18和17.44对应ESS和它的组件,模型帮助发现模棱两可的、不协调的、不完整的、或不可验证需求，其可以随后被细化通过建议的需求变更,和管理变更在项目的变更管理过程中。

在大型的项目上,一个需求管理工具通常被使用结合系统建模工具。两个工具之间的集成是重要的来确保需求和它们的关系被同步在两个工具之间。变更过程必须确定，需求的变更如何被处理。一种方法是在需求管理工具中对需求文本进行更改，并建立建模工具中的模型元素和文本要求之间的关系。第18章包含附加的讨论关于集成系统建模工具与需求管理工具。规范文档使用文本需求也可被直接输出从建模工具使用自动文档生成功能和标准需求模板。

1. 1. 1. OOSEM支持集成和验证系统

Integrate and Verify System过程是系统开发过程的部分显示在图17.1和描述在第17.1.2节。这个过程的目标被来验证系统满足它的需求。系统、元素、和组件验证典型的完成通过一个观测、分析、演示、和测试的组合。过程包含开发验证计划和过程,每个过程进行验证、分析验证结果、并生成验证报告。

OOSEM 支持这个过程以多种方式。系统模型可以被使用作为一个开发测试用例的基础并关联验证过程。模型也可被使用来支持其它建模构件，其支持验证计划,和验证环境的设计。此外, 操作系统的模型可以被使用来支持早期的需求确认和设计验证,特别是当耦合与一个执行环境来执行模型。

注：正如描述在第13.12节,SysML包含一个测试用例和验证关系,其可以被使用结合需求来显示需求如何可以被验证在系统、元素、和组件层级。从图17.54, Verify Entry Detection测试用例验证Intrusion Detection and False Alarm Rate需求。测试用例被表示作为一个活动图在图17.55使用«testCase»关键字显示在标题上。ESS Node Physical是一个单元处于测试中。在这个例子中,一个Video Source和Contact Sensor Emulator表示ESS外部环境，其生成激励到 ESS和Test Monitor对比ESS 响应与期望的响应。一个Tester初始测试。

测试案例规范定义激励、条件、和期望的响应。验证结果来自测试案例的执行与期望的响应对比。结果可以随后被记录来确定是否系统提供期望的响应。结果被称为判决,和可以包含pass、fail、undetermined或一些其它值集。需求验证状态被更新来反应验证结果来自测试案例执行。

正如上面提及的,验证的方法包含：观测、分析、演示、和测试。测试用例定义和执行以来与方法的验证。例如,对于一个系统的验证方法，其“The system shall weigh between 98 and 100 pounds”可以被执行通过测试或分析。来验证需求通过测试,一个测试用例被定义来称重系统, 并将所测得的重量与所需的重量进行比较。验证这个需求通过分析,每个组件的预估重量被汇总来预估系统重量。在随后情形中,参数图可以被使用来验证需求通过分析。

正如上面说明使用参数, 模型可以被使用来支持需求验证通过分析。一个可执行模型可以被用来表示处于测试中的单位代替实际的硬件或软件。结果来自执行测试案例使用系统模型可以被用来获得需要验证的早期指示优先于不得不构建硬件和软件。在系统规范和设计过程非常早的阶段，系统模型可以被用来验证，系统和组件需求满足任务需求。这可以包含一个分离事件的使用诸如fUML,正如描述在第9.14节。正如开发过程,更详细的组件设计模型可以被集成与系统模型来验证，组件设计满足系统需求。有许多考虑对应如何来有效利用一个系统模型来支持这个功能。第18章包含附加的讨论关于SysML如何被使用与一个更大范围的仿真和分析模型，其可以被使用来支持需求验证。

图17.55 验证进入监测测试案例

测试用例的执行需要一个验证环境来生成激励和评估响应,和一个处于测试中的单位来响应到激励。验证环境可以包含硬件、软件、设施、和人员。在下一节中,OOSEM应用到建模验证环境被讨论。

1. 1. 1. 开发使能系统

为了开发一个完整的功能，支持完整的系统生命周期,使能系统（enabling systems）可以需要来被开发和/或修改。使能系统包含制造系统来生成系统,支持系统，诸如，支持装备来维护系统,和维护系统来验证系统。这些生命周期考虑应该被早期解决来避免后续的不利影响。例如,如果制造系统功能没有早期考虑,生产系统的成本可以增加大幅度的征收更高的制造方法成本。作为一个结果,使能系统与操作系统被开发并发的，所以特定的关注,其可以影响生命周期的其它部分,被早期解决在开发过程中。

图17.56显示过程对应并发开发ESS操作系统与ESS使能系统对应验证和安装。更一般的讲, 过程可以包含其它使能系统，诸如，制造系统。OOSEM方法被应用来开发操作系统在这个例子中。然而,方法和相关的构件可以被裁剪和应用来指定和设计使能系统。对于非常复杂的使能系统,完整的方法可以被应用。对于简单的使能系统,仅选择的方法方面可以被应用。

图17.56 系统操作的并发开发过程和使能系统

例如,验证系统可以是非常复杂的,诸如，当精确的测量装备被需要来验证系统时。对测量设备的要求可能比试验中的操作系统的要求更严格。如果测量装备将被设计和开发,一个严格的OOSEM应用可以被需要,伴随UML测试配置文件[48]的应用来提供附加的建模构件，其可应用到测试域。在图17.57, Verification Domain（验证领域）包含Verification Context-Entry Detection 对应Verify Entry Detection测试案例，其被显示在图17.54。测试案例被查看作为Verification Context的一个操作，其方法是活动图在图17.55。Verification Context包含测试组件，其是验证系统的部分,并引用处于测试中的单元。Verification Domain模块定义图是类似于Operational Domain模块定义图在图17.11。OOSEM可以被应用来开发整个验证系统使用一种相似方法正如被应用到操作系统的规范和设计。

ESS Installation System（ESS安装系统）可以是复杂的和可以安排OOSEM的应用对应它的规范和设计。ESS Installation Domain（ESS安装领域）模块定义图显示在图17.58。Installation Enterprise包含ESS Installation System和外部Suppliers支持安装目标,正如定义通过安装用例。ESS Installation System（ESS安装系统）包含Installers(安装者)和他们的Installation Equipments(安装设备),诸如，Installation Trucks（安装卡车）和Installation Tools（安装工具）。这个服务作为一个起始点对应指定和设计ESS Installation System以一种相似的方式正如Operational Domain模块定义图(图17.11),其是一个ESS操作系统的一个规范和设计的起始点。Installation包在图17.4有一个类似的内嵌的结构包,并包含类似的建模构件,作为Operational包。

图17.57验证域的模块定义图来支持设计验证系统

图17.58 安装域模块定义图，一个起始点对应ESS安装系统的规范和设计

1. 1. 小结

例子描述在本章说明SysML如何被使用作为一个基于模型的系统工程方法部分,称为OOSEM,为了解决一个系统工程问题。自顶向下场景驱动的方法被使用来流动需求向下从涉众需求到组件-层级规范,包含硬件、软件、持久性数据、和操作过程。OOSEM方法包含涉众需求的分析、分析系统黑盒需求、定义逻辑架构、综合备选的物理架构、和支持活动来优化和评估可选的和管理需求的可追溯性。

方法也支持验证过程在Vee开发过程的上侧,和其它使能系统的开发，诸如，安装系统。方法说明系统的不同方面如何被分析来解决大量的关注关联到系统功能、接口、性能、分布、生命周期、和变更在需求和技术中,来开发一个强健的方案满足涉众需求。

OOSEM应该被裁剪到特定的项目目标和约束和关联建模目标、范围、和工具和资源约束。裁剪包含选择严格的层级，其被应用到每个OOSEM 活动,建模构件被生成,和到什么层次的细节。

1. 1. 问题
2. 开发下面的构件对应Provide Fire Emergency Response用例显示在图 17.12。
   1. 提供消防应急响应活动图(等效到图17.14)
   2. 监控Fire-ESS逻辑的活动图(等效到图17.22)
3. 客户已经引入下面新的的需求:“The ESS shall provide the ability to integrate with a fire-suppression system to extinguish fires when detected with minimal adverse impact to the property.”描述这种新的需求在系统设计上的影响通过标识下面的建模构件的变更。
   1. ESS 需求(图17.53)
   2. 企业安全性（Security Enterprise）用例(图17.12)
   3. 提供火灾应急响应（Provide Fire Emergency Response）活动图(参考响应到问题 1a)
   4. 系统语境（System Context）(图17.16)
   5. ESS 黑盒规范（ESS Black-Box Specification）(图17.18)
   6. ESS逻辑分解（ESS Logical decomposition）(图17.21)
   7. 监控火灾-ESS逻辑（Monitor Fire-ESS Logical）的活动图(参考响应到问题1b)
   8. ESS逻辑（ESS Logica）内部模块图(图17.23)
   9. ESS节点逻辑（ESS Node Logical）模块定义图(图17.26和图17.27)
   10. ESS逻辑节点（ESS Node Logical）内部模块图(图17.29和图17.30)
   11. 分配表对应逻辑组件到硬件和逻辑的组件到软件(图17.31和图17.32)
   12. 安装站点（Site Installation）内部模块图(图17.37)
4. 这个需求变更如何影响有效性测量?
5. 这个如何影响顶层参数图在图17.10?
6. 什么附件类型的分析被需要,和这如何可以被反映在参数图中?
7. 讨论预先的需求变更如何影响整个模型,和模型如何帮助来解决需求变更