M< MDA AN Agile Systems Engineering 敏捷系统工程 [美]Bruce Powel Douglass著 张新国谷炼 译 清华大学出版社
译 者序 复杂系统的构想、开发、实施和运行带来了技术和管理上的双重挑战，应对系统工程的 复杂性己经成为未来工业领域的核心竞争力之一。目前，架构引领、基于模型、数据驱动已 经成为解决复杂问题的基本能力要素。面对复杂系统生命周期中呈现出的不可预见性与不确 定性、外部背景环境剧烈变化以及新兴技术不断涌现，复杂系统的采办方提出了进化式、渐 进式的策略，利益攸关者的需要和需求以及系统需求将不断变化，这就要求复杂系统的开发 过程和系统架构应具备良好的敏捷性，即在不可预见性、不确定性和变化的态势下保持系统 开发有效开展的能力。 架构引领、基于模型、数据驱动的新的开发模式为敏捷方法在复杂系统工程中的实践和 应用提供了基础，使得复杂系统在开发过程中以增量式、迭代式的方式开展。这种新的开发 模式被称为基于模型的敏捷系统工程，即aMBSE(agile Model Based Systems Engineering). aMBSE方法由本书作者Bruce Powel Douglasst博士在MBSE方法上首创，广泛应用于复杂系统 的开发之中，并被证明是行之有效的。aMBSE方法从复杂系统的某一个或几个方面的需求入 手建立模型，并对建立的模型进行执行和分析，在系统开发的早期就进行相关需求和设计的 验证和确认，从而避免大量的工作和人力被投入之后产生的风险和费用。 架构方法是解决复杂性问题的有效方法，通过架构方法能够基于彼此逻辑相关且协调一 致的原则、概念和特性来创造一个全面的解决方案，进而满足系统需求集合（可追溯到业务 或使命以及利益攸关者需求)及生命周期概念（如实施、运行、支持）所表达的问题或机会，并 且可通过技术（如机械、电子、软件等）来实现。本书提出并定义了子系统/组件、可依赖性、 分布、部署、并发与资源5个视角，进而开发了候选架构的模型和视图，通过对复杂系统从 需求到功能架构、逻辑架构再到物理架构的连续传递和映射，实现从系统需求到架构实体再 到系统元素的划分、对准和分配，并建立系统设计与演进的指导原则。 传统的基于文本的系统工程已经难以满足复杂系统的开发要求，必须采用正规化的系统 建模语言对系统的需求、架构和设计进行表达，保证整个开发过程的正确性、一致性和完整 性。本书使用国际面向对象组织OMG制定的正规形式化图形建模语言SysML,对系统的需 求、功能、行为、结构进行建模。SysML遵循MOF的四层元模型框架，具备对“功能-行为 结构”逻辑关系的描述能力。功能表达了系统为满足使命将输入转化为输出的动作以及相应 的性能，行为表达了系统功能之间的交互关系以及系统状态随时间发生的转移，结构则表达 了如何实现这些功能和行为。本书通过使用SysML语言以及图形化的建模环境，从不同维度 展现复杂系统的需求、功能、行为和结构。 本书中的另一个亮点是如何对复杂系统中的各种数据进行正确的表述，这是复杂系统工 程人员较为棘手的问题。数据是物理世界在赛博空间的映射，可以表述系统与背景环境之间 以及系统元素之间物质、能量和信息的交互过程。数据驱动的复杂系统定义必须按照由抽象 到具体、由逻辑到物理的逐步细化过程。复杂系统首先被看作一个“黑盒”，识别并定义其 与外部交互的逻辑数据和接口。然后对系统架构的备选方案进行权衡和分析，选择架构中不
译 者 序 复杂系统的构想、开发、实施和运行带来了技术和管理上的双重挑战，应对系统工程的 复杂性已经成为未来工业领域的核心竞争力之一。目前，架构引领、基于模型、数据驱动已 经成为解决复杂问题的基本能力要素。面对复杂系统生命周期中呈现出的不可预见性与不确 定性、外部背景环境剧烈变化以及新兴技术不断涌现，复杂系统的采办方提出了进化式、渐 进式的策略，利益攸关者的需要和需求以及系统需求将不断变化，这就要求复杂系统的开发 过程和系统架构应具备良好的敏捷性，即在不可预见性、不确定性和变化的态势下保持系统 开发有效开展的能力。 架构引领、基于模型、数据驱动的新的开发模式为敏捷方法在复杂系统工程中的实践和 应用提供了基础，使得复杂系统在开发过程中以增量式、迭代式的方式开展。这种新的开发 模式被称为基于模型的敏捷系统工程，即aMBSE(agile Model Based Systems Engineering)。 aMBSE方法由本书作者Bruce Powel Douglass博士在MBSE方法上首创，广泛应用于复杂系统 的开发之中，并被证明是行之有效的。aMBSE方法从复杂系统的某一个或几个方面的需求入 手建立模型，并对建立的模型进行执行和分析，在系统开发的早期就进行相关需求和设计的 验证和确认，从而避免大量的工作和人力被投入之后产生的风险和费用。 架构方法是解决复杂性问题的有效方法，通过架构方法能够基于彼此逻辑相关且协调一 致的原则、概念和特性来创造一个全面的解决方案，进而满足系统需求集合(可追溯到业务 或使命以及利益攸关者需求)及生命周期概念(如实施、运行、支持)所表达的问题或机会，并 且可通过技术(如机械、电子、软件等)来实现。本书提出并定义了子系统/组件、可依赖性、 分布、部署、并发与资源5个视角，进而开发了候选架构的模型和视图，通过对复杂系统从 需求到功能架构、逻辑架构再到物理架构的连续传递和映射，实现从系统需求到架构实体再 到系统元素的划分、对准和分配，并建立系统设计与演进的指导原则。 传统的基于文本的系统工程已经难以满足复杂系统的开发要求，必须采用正规化的系统 建模语言对系统的需求、架构和设计进行表达，保证整个开发过程的正确性、一致性和完整 性。本书使用国际面向对象组织OMG制定的正规形式化图形建模语言SysML，对系统的需 求、功能、行为、结构进行建模。SysML遵循MOF的四层元模型框架，具备对“功能-行为- 结构”逻辑关系的描述能力。功能表达了系统为满足使命将输入转化为输出的动作以及相应 的性能，行为表达了系统功能之间的交互关系以及系统状态随时间发生的转移，结构则表达 了如何实现这些功能和行为。本书通过使用SysML语言以及图形化的建模环境，从不同维度 展现复杂系统的需求、功能、行为和结构。 本书中的另一个亮点是如何对复杂系统中的各种数据进行正确的表述，这是复杂系统工 程人员较为棘手的问题。数据是物理世界在赛博空间的映射，可以表述系统与背景环境之间 以及系统元素之间物质、能量和信息的交互过程。数据驱动的复杂系统定义必须按照由抽象 到具体、由逻辑到物理的逐步细化过程。复杂系统首先被看作一个“黑盒”，识别并定义其 与外部交互的逻辑数据和接口。然后对系统架构的备选方案进行权衡和分析，选择架构中不
I敏捷系统工程 同组件的实现方式，进而定义不同组件、不同学科之间的物理数据和接口，为基于模型的向 下游工程转交提供输入。本书提出了数据模式的概念，定义了复杂系统的逻辑数据模式和物 理数据模式，实现了机械、电子、软件等不同领域学科之间的互操作。正是由于系统模型的 建立和数据模式的定义，使得敏捷方法从软件领域被推广到多学科领域，引发了系统工程应 用模式的转型。 本书作者Bruce Powel Douglass博士是系统工程与嵌入式软件开发领域的知名专家，在该 领域拥有超过30年的工作经验。作为嵌入式系统开发的代表性人物，Buce在结构化和面向 对象方法、嵌入式系统开发、安全关键系统设计和复杂系统设计等方面都有很深的造诣。本 书以承载能力达1500千克的可穿戴式工业外骨骼机器人以及为人熟知的高端跑步机为示例， 使有大量实例阐明在应用MBSE方法中所涉及的工程流程步骤，使读者更容易掌握aMBSE 的精髓。因此，本书自出版之日起已成为Amazon网站上最畅销的科技书籍之一。 综上所述，MBSE是一种应对复杂系统的有效方法，它实现了从文本到模型、从预估到 敏捷、从软件到多学科领域的转变。通过本书的学习，可以为系统工程师提供详细的指导， 而使读者能够容易且有效地将MBSE方法应用到复杂产品开发中。 最后，感谢中国航空工业集团公司信息技术中心高星海、郄永军、常创业以及编译工作 小组在校对、版本控制等方面中付出的努力，在此表示衷心的感谢。 译者
IV 敏捷系统工程 同组件的实现方式，进而定义不同组件、不同学科之间的物理数据和接口，为基于模型的向 下游工程转交提供输入。本书提出了数据模式的概念，定义了复杂系统的逻辑数据模式和物 理数据模式，实现了机械、电子、软件等不同领域学科之间的互操作。正是由于系统模型的 建立和数据模式的定义，使得敏捷方法从软件领域被推广到多学科领域，引发了系统工程应 用模式的转型。 本书作者Bruce Powel Douglass博士是系统工程与嵌入式软件开发领域的知名专家，在该 领域拥有超过30年的工作经验。作为嵌入式系统开发的代表性人物，Bruce在结构化和面向 对象方法、嵌入式系统开发、安全关键系统设计和复杂系统设计等方面都有很深的造诣。本 书以承载能力达1500千克的可穿戴式工业外骨骼机器人以及为人熟知的高端跑步机为示例， 使有大量实例阐明在应用aMBSE方法中所涉及的工程流程步骤，使读者更容易掌握aMBSE 的精髓。因此，本书自出版之日起已成为Amazon网站上最畅销的科技书籍之一。 综上所述，aMBSE是一种应对复杂系统的有效方法，它实现了从文本到模型、从预估到 敏捷、从软件到多学科领域的转变。通过本书的学习，可以为系统工程师提供详细的指导， 而使读者能够容易且有效地将aMBSE方法应用到复杂产品开发中。 最后，感谢中国航空工业集团公司信息技术中心高星海、郄永军、常创业以及编译工作 小组在校对、版本控制等方面中付出的努力，在此表示衷心的感谢。 译者
作者简介 Bruce Powel Douglass3岁时开始自学读书，不到12岁就开始学习微积分。他14岁辍学游历 美国，几年后进入俄勒冈大学学习数学专业。他最终获得俄勒冈大学运动生理学科学硕士学位 以及USD医学院神经生理学博士学位。他在USD医学院期间提出了一个名为自相关因子分析 的数学分支，用于研究多细胞生物神经系统中的信息处理。 Buce作为软件开发人员和系统工程师在实时嵌入式系统领域己经工作超过30年，是实 时嵌入式系统领域著名的演说家、作者与顾问。他是嵌入式系统大会和UML世界大会的顾问 委员会的成员之一，并在会议上讲授过关于系统工程、项目估算和调度、项目管理、面向对 象的分析与设计、通信协议、有限状态机、设计模式以及安全性关键系统设计方面的课程。 Buce在实时系统、软件设计以及项目管理方面有多年的开发、授课与咨询经验。他还为很 多（特别是实时领域内的）杂志和期刊撰文。 Buce是IBM物联网IoT)业务部的首席布道师。作为首席布道师，除了披荆斩棘开拓道 路，他更像是一位首席科学家。Buce与UML合作伙伴在UML与SysML标准的规定方面密切 合作。他开发了用于Rhapsody建模工具的第一个DoDAF的UML概要以及其他概要，例如故 障树分析概要以及安保性分析概要。他是对象管理组组织的实时分析和设计工作组的副主 席。他还撰写了其他几本关于系统与软件开发方面的书籍，包括Doing Hard Time:Developing Real-Time Systems with UML,Objects,Frameworks and Patterns(Addison-Wesley,1999).Real- Time Design Patterns:Robust Scalable Architecture for Real-Time Systems(Addison-Wesley, 2002).Real-Time UML 3rd Edition:Advances in the UML for Real-Time Systems(Addison- Wesley,2004).Real-Time Agility(Addison-Wesley,2009)Design Patterns for Embedded Systems inC(Elsevier,,20ll)、Real-Time UML Workshop.for Embedded Systemst(Elsevier,,2014)等，以及 一本关于乒乓球方面的短篇教材。 Buce喜欢古典音乐，古典吉他弹奏水平达到专业水准。他参加过多场体育比赛，包括 乒乓球、自行车极限马拉松赛、赛跑以及全接触跆拳道，尽管目前还只是与打不还手的静物 交手。他最近重新回到三项全能运动比赛以及自行车极限马拉松赛，并在2014年首次参加了 铁人三项比赛。 Bruce在全世界进行广泛咨询与培训活动。如果你对此感兴趣，可以通过Bruce..Douglass@ us.ibm.com与他联系
作 者 简 介 Bruce Powel Douglass 3岁时开始自学读书，不到12岁就开始学习微积分。他14岁辍学游历 美国，几年后进入俄勒冈大学学习数学专业。他最终获得俄勒冈大学运动生理学科学硕士学位 以及USD医学院神经生理学博士学位。他在USD医学院期间提出了一个名为自相关因子分析 的数学分支，用于研究多细胞生物神经系统中的信息处理。 Bruce作为软件开发人员和系统工程师在实时嵌入式系统领域已经工作超过30年，是实 时嵌入式系统领域著名的演说家、作者与顾问。他是嵌入式系统大会和UML世界大会的顾问 委员会的成员之一，并在会议上讲授过关于系统工程、项目估算和调度、项目管理、面向对 象的分析与设计、通信协议、有限状态机、设计模式以及安全性关键系统设计方面的课程。 Bruce 在实时系统、软件设计以及项目管理方面有多年的开发、授课与咨询经验。他还为很 多(特别是实时领域内的)杂志和期刊撰文。 Bruce是IBM物联网(IoT)业务部的首席布道师。作为首席布道师，除了披荆斩棘开拓道 路，他更像是一位首席科学家。Bruce与UML合作伙伴在UML与SysML标准的规定方面密切 合作。他开发了用于Rhapsody建模工具的第一个DoDAF的UML概要以及其他概要，例如故 障树分析概要以及安保性分析概要。他是对象管理组组织的实时分析和设计工作组的副主 席。他还撰写了其他几本关于系统与软件开发方面的书籍，包括Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks and Patterns(Addison-Wesley, 1999)、RealTime Design Patterns: Robust Scalable Architecture for Real-Time Systems(Addison-Wesley, 2002)、 Real-Time UML 3rd Edition: Advances in the UML for Real-Time Systems(AddisonWesley, 2004)、Real-Time Agility(Addison-Wesley, 2009)、Design Patterns for Embedded Systems in C(Elsevier, 2011)、 Real-Time UML Workshop for Embedded Systems(Elsevier, 2014)等，以及 一本关于乒乓球方面的短篇教材。 Bruce喜欢古典音乐，古典吉他弹奏水平达到专业水准。他参加过多场体育比赛，包括 乒乓球、自行车极限马拉松赛、赛跑以及全接触跆拳道，尽管目前还只是与打不还手的静物 交手。他最近重新回到三项全能运动比赛以及自行车极限马拉松赛，并在2014年首次参加了 铁人三项比赛。 Bruce在全世界进行广泛咨询与培训活动。如果你对此感兴趣，可以通过Bruce.Douglass@ us.ibm.com与他联系
前 言 产品的功能和复杂性正在成倍地增加，而且对这些系统的安全性、可靠性以及安保性的 关注使得这样的系统对工程师而言更加困难。同时，产品开发周期正在萎缩。很显然，变革 是需要的。我们需要能够以更少的时间制造出更有能力且缺陷更少的系统。 针对此问题，一个受到高度评价的解决方案是避免以文本作为捕获工程数据的主要手 段。虽然文本具有极好的表现力，但是它是有歧义的，而且是极其不严谨的。使用更加正规 的定义语言（这里，显然是指UML和SysML)进行建模是要力求改善特定的工程数据。只要我 们能够想出改进的方式即可。 另一个所提供的解决方案是敏捷方法。尽管敏捷方法已经开始应用于嵌入式和实时系 统，但这些方法却是由软件IT行业开发的。然而，敏捷文献（几乎）完全关注在台式机或T软 件开发上。他们考虑的开发环境（几乎）全部都是同地域小型团队的合作，并不关注安全性、 可靠性或安保性问题：而且没有与电子或机械部件的联合开发。因此，系统工程师想要知道 的是“这种方法如何适用于‘我’和我的工作”。敏捷文献没有给出答案。 有一些关于系统工程的很好的书籍，也有一些关于SysML与基于模型的系统工程 (MB$E)的很好的书籍。有许多关于软件的敏捷方法的书籍（其中一些书籍也是很好的）。然 而，目前还没有书籍来尝试将这些概念综合为一种一致且可用的系统工程方法。本书的目的 就在于满足这种需要。 我们首先简单地介绍了系统工程学科，之后又简短讨论了敏捷方法，因为它们在大多 数系统文献中都有论述，包括其益处。除前言部分外，还有一章内容关于基本的SysML。接 着，我们就开始理解如何在现实生活中应用MBSE。 本书中的方法基于作者的Harmony敏捷系统工程流程。该流程有关软件开发方面的部分 在其他文献中有详细描述①：本书仅涉及系统工程的关注点。Harmony敏捷系统工程流程是 一种敏捷的、以模型为中心的实施途径，用于开发系统工程所需的工程数据：需求、架构、 接口以及可依赖性分析是其中最重要的内容。Harmony流程是依据作者在全球范围内所指 导完成、取得飞速进展并在其他方面发挥作用的实际项目上累积的数十年系统经验提出和 完善的。 在教育工作者中有这样一种说法一“我示你看。我讲你听。你做你懂”。为此，本书 中有大量示例用于阐明执行所涉及的工程步骤的细节。这些示例涉及工程学科的多个方面， 包括软件、电子和机械工程。这些示例中的第一个示例是高瑞跑步机。第二个更复杂的示例 是能够承载1500千克的可穿戴工业用机器人外骨骼（被称为waldo)。Harmony敏捷系统工程流 程的每个主要活动都是以这些和其他示例展开讨论和演示的。我们鼓励读者针对提出的问题 构建自己的解决方案并建立这些章节中所描述的模型。 ①例如，参见Real-Time Agility(Addison-Nesley,.2OO9)或Rea-Time UML Workshop for Embedded Systems(Elsevier, 2014)
前 言 产品的功能和复杂性正在成倍地增加，而且对这些系统的安全性、可靠性以及安保性的 关注使得这样的系统对工程师而言更加困难。同时，产品开发周期正在萎缩。很显然，变革 是需要的。我们需要能够以更少的时间制造出更有能力且缺陷更少的系统。 针对此问题，一个受到高度评价的解决方案是避免以文本作为捕获工程数据的主要手 段。虽然文本具有极好的表现力，但是它是有歧义的，而且是极其不严谨的。使用更加正规 的定义语言(这里，显然是指UML和SysML)进行建模是要力求改善特定的工程数据。只要我 们能够想出改进的方式即可。 另一个所提供的解决方案是敏捷方法。尽管敏捷方法已经开始应用于嵌入式和实时系 统，但这些方法却是由软件IT行业开发的。然而，敏捷文献(几乎)完全关注在台式机或IT软 件开发上。他们考虑的开发环境(几乎)全部都是同地域小型团队的合作，并不关注安全性、 可靠性或安保性问题；而且没有与电子或机械部件的联合开发。因此，系统工程师想要知道 的是“这种方法如何适用于‘我’和我的工作”。敏捷文献没有给出答案。 有一些关于系统工程的很好的书籍，也有一些关于SysML与基于模型的系统工程 (MBSE)的很好的书籍。有许多关于软件的敏捷方法的书籍(其中一些书籍也是很好的)。然 而，目前还没有书籍来尝试将这些概念综合为一种一致且可用的系统工程方法。本书的目的 就在于满足这种需要。 我们首先简单地介绍了系统工程学科，之后又简短讨论了敏捷方法，因为它们在大多 数系统文献中都有论述，包括其益处。除前言部分外，还有一章内容关于基本的SysML。接 着，我们就开始理解如何在现实生活中应用MBSE。 本书中的方法基于作者的Harmony敏捷系统工程流程。该流程有关软件开发方面的部分 在其他文献中有详细描述a；本书仅涉及系统工程的关注点。Harmony敏捷系统工程流程是 一种敏捷的、以模型为中心的实施途径，用于开发系统工程所需的工程数据；需求、架构、 接口以及可依赖性分析是其中最重要的内容。Harmony流程是依据作者在全球范围内所指 导完成、取得飞速进展并在其他方面发挥作用的实际项目上累积的数十年系统经验提出和 完善的。 在教育工作者中有这样一种说法——“我示你看。我讲你听。你做你懂”。为此，本书 中有大量示例用于阐明执行所涉及的工程步骤的细节。这些示例涉及工程学科的多个方面， 包括软件、电子和机械工程。这些示例中的第一个示例是高端跑步机。第二个更复杂的示例 是能够承载1500千克的可穿戴工业用机器人外骨骼(被称为waldo)。Harmony敏捷系统工程流 程的每个主要活动都是以这些和其他示例展开讨论和演示的。我们鼓励读者针对提出的问题 构建自己的解决方案并建立这些章节中所描述的模型。 a 例如，参见Real-Time Agility (Addison-Wesley, 2009)或Real-Time UML Workshop for Embedded Systems(Elsevier， 2014)
X敏捷系统工程 读者 本书的主要读者不言而喻是系统工程师。系统工程师的主要关注点集中在（通常）由多个 工程学科所实施的系统规范与设计上。系统工程师规定了产品的系统特性而将学科特有的细 节留给适当的下游工程团队。一些下游工程师也可能在本书中找到感兴趣的信息，特别是系 统工程数据如何被格式化并采纳以满足转交活动中他们需要的细节。 目标 在游历世界期间，我感受到系统工程师在应用MBSE方法时所遇到的困难。主要的语 言一一SysML一令人望而生畏。SysML包括800页左右的UML规范并且增加了数百页。它 是一种功能极为强大但是十分复杂的语言。 除了语言本身，随着产品复杂性成倍增加以及产品交付周期的不断缩减，亟须同时提高 系统工程工作的效率并改进质量。我们看到系统在安全关键的、高可靠性和安保性环境中正 日益取代人类，并且我们必须能够始终依靠这些系统的功能正常运转。 本书有一个简单目标一为系统工程师提供足够的指导，以便他们能方便有效地将敏捷 方法和MBSE应用到复杂系统的开发中，因为现实世界越来越依赖于这些系统的运行。 工具 本书中的所有建模示例都使用IBM RhapsodyTM工具进行建模。然而，关于标准的一个 好处是对不同工具的多种选择。如果你偏爱的其他工具支持SysML标准，那么你用你选择的 工具建立这些模型时应该不会遇到什么困难。这不是一本关于Rhapsody的书，也不是专用于 Rhapsody的书。 拓展 如果你对工具、培训或咨询感兴趣，参见www.ibm.com。我在世界范围内教授关于 UML、SysML、MDA、DoDAF、架构设计、设计模式、需求建模、用例、安全性关键开 发、行为建模、开发流程改进、项目管理与调度等多门高等课程并提供咨询。你可通过 Bruce.Douglass(@us.ibm.com就培训或咨询服务与我联系。我还开通了一个（免费的）yahoo群 组论坛，网址是htp:/∥groups..yahoo.com/group/RT-UML一快来参与吧！My IBM Thought Leader(http://www-01.ibm.com/software/rational/leadership/thought/brucedouglass.html) 含你可能感兴趣的白皮书，其涉及不同课题并可供下载。 Bruce Powel Douglass博士
X 敏捷系统工程 读者 本书的主要读者不言而喻是系统工程师。系统工程师的主要关注点集中在(通常)由多个 工程学科所实施的系统规范与设计上。系统工程师规定了产品的系统特性而将学科特有的细 节留给适当的下游工程团队。一些下游工程师也可能在本书中找到感兴趣的信息，特别是系 统工程数据如何被格式化并采纳以满足转交活动中他们需要的细节。 目标 在游历世界期间，我感受到系统工程师在应用MBSE方法时所遇到的困难。主要的语 言——SysML——令人望而生畏。SysML包括800页左右的UML规范并且增加了数百页。它 是一种功能极为强大但是十分复杂的语言。 除了语言本身，随着产品复杂性成倍增加以及产品交付周期的不断缩减，亟须同时提高 系统工程工作的效率并改进质量。我们看到系统在安全关键的、高可靠性和安保性环境中正 日益取代人类，并且我们必须能够始终依靠这些系统的功能正常运转。 本书有一个简单目标——为系统工程师提供足够的指导，以便他们能方便有效地将敏捷 方法和MBSE应用到复杂系统的开发中，因为现实世界越来越依赖于这些系统的运行。 工具 本书中的所有建模示例都使用IBM® Rhapsody™工具进行建模。然而，关于标准的一个 好处是对不同工具的多种选择。如果你偏爱的其他工具支持SysML标准，那么你用你选择的 工具建立这些模型时应该不会遇到什么困难。这不是一本关于Rhapsody的书，也不是专用于 Rhapsody的书。 拓展 如果你对工具、培训或咨询感兴趣，参见www.ibm.com。我在世界范围内教授关于 UML、SysML、MDA、DoDAF、架构设计、设计模式、需求建模、用例、安全性关键开 发、行为建模、开发流程改进、项目管理与调度等多门高等课程并提供咨询。你可通过 Bruce.Douglass@us.ibm.com就培训或咨询服务与我联系。我还开通了一个(免费的)yahoo群 组论坛，网址是http://groups.yahoo.com/group/RT-UML——快来参与吧！My IBM Thought Leader页面(http://www-01.ibm.com/software/rational/leadership/thought/brucedouglass.html)也包 含你可能感兴趣的白皮书，其涉及不同课题并可供下载。 Bruce Powel Douglass博士
目 录 第1章什么是基于模型的系统工程…1 1.3 系统工程的生命周期…13 1.3.1V模型生命周期…13 1.1关键的系统工程活动…1 1.32增量式…15 1.1.1识别客户需要…2 1.3.3混合式…16 1.1.2规定系统需求 2 1.4基于模型的系统工程MBSE)…17 1.1.3评估可依赖性…3 1.4.1建模的优势… …17 1.1.4评价备选架构和技术…3 1.4.2用UML和SysML进行高精度 1.1.5选择特定架构和技术 建模…20 1.1.6分配需求和接口到架构 0…4 1.4.3建模是敏捷系统工程的根本…20 1.1.7向下游工程转交…4 1.4.4在你的组织或项目中采纳 1.1.8将学科特定的设计综合至系统 建模…2 组成…5 1.4.5建模规则…25 1.1.9以整体验证系统…5 1.5总结…27 1.1.10系统确认…8 参考文献…27 12系统工程数据… 8 1.2.1系统开发规划…8 第2章 什么是敏捷方法 …29 12.2利益攸关者需求…9 2.1 敏捷宣言… …30 1.2.3系统需求 9 2.2敏捷方法的益处 32 1.2.4认证规划 9 2.2.1提高工程数据的品质……32 1.2.5子系统需求 9 2.2.2提高工程效率…32 12.6学科特定的需求…9 2.2.3尽早获得投资的回报(RO0…33 1.2.7安全性分析…10 2.2.4利益攸关者满意……33 1.2.8可靠性分析…10 2.2.5增强了项目控制… 1.2.9安保性分析…10 2.2.6响应变化…33 1.2.10系统架构 …10 2.2.7更早且更大幅度地降低项目 1.2.11综合测试规划 …11 风险…33 1.2.12综合测试…11 2.3 将敏捷宣言应用于系统工程…34 1.2.13验证规划 2.3.1增量式地工作…34 1.2.14验证试验 12 2.3.2动态地规划…34 1.2.15确认规划 12 2.3.3 主动降低项目风险 …35 12.16追溯矩阵…12 2.3.4持续地验证…36 1.2.17 综合测试结果…13 2.3.5连续地综合… 36 12.18验证结果…13 2.3.6用例1：在空域中发现轨迹…36 1.2.19确认结果…13
第1章 什么是基于模型的系统工程 ···1 1.1 关键的系统工程活动 ························· 1 1.1.1 识别客户需要 ································ 2 1.1.2 规定系统需求 ································ 2 1.1.3 评估可依赖性 ································ 3 1.1.4 评价备选架构和技术 ···················· 3 1.1.5 选择特定架构和技术 ···················· 4 1.1.6 分配需求和接口到架构 ················ 4 1.1.7 向下游工程转交 ···························· 4 1.1.8 将学科特定的设计综合至系统 组成 ················································ 5 1.1.9 以整体验证系统 ···························· 5 1.1.10 系统确认 ······································ 8 1.2 系统工程数据 ····································· 8 1.2.1 系统开发规划 ································ 8 1.2.2 利益攸关者需求 ···························· 9 1.2.3 系统需求 ········································ 9 1.2.4 认证规划 ········································ 9 1.2.5 子系统需求 ···································· 9 1.2.6 学科特定的需求 ···························· 9 1.2.7 安全性分析 ·································· 10 1.2.8 可靠性分析 ·································· 10 1.2.9 安保性分析 ·································· 10 1.2.10 系统架构 ···································· 10 1.2.11 综合测试规划 ·····························11 1.2.12 综合测试 ·····································11 1.2.13 验证规划 ·····································11 1.2.14 验证试验 ···································· 12 1.2.15 确认规划 ···································· 12 1.2.16 追溯矩阵 ···································· 12 1.2.17 综合测试结果 ···························· 13 1.2.18 验证结果 ···································· 13 1.2.19 确认结果 ···································· 13 目 录 1.3 系统工程的生命周期 ······················· 13 1.3.1 V模型生命周期 ··························· 13 1.3.2 增量式 ·········································· 15 1.3.3 混合式 ·········································· 16 1.4 基于模型的系统工程(MBSE) ········· 17 1.4.1 建模的优势 ·································· 17 1.4.2 用UML和SysML进行高精度 建模 ·············································· 20 1.4.3 建模是敏捷系统工程的根本 ······ 20 1.4.4 在你的组织或项目中采纳 建模 ·············································· 21 1.4.5 建模规则 ······································ 25 1.5 总结 ··················································· 27 参考文献 ···················································· 27 第2章 什么是敏捷方法 ···················29 2.1 敏捷宣言 ··········································· 30 2.2 敏捷方法的益处 ······························· 32 2.2.1 提高工程数据的品质 ·················· 32 2.2.2 提高工程效率 ······························ 32 2.2.3 尽早获得投资的回报(ROI) ········ 33 2.2.4 利益攸关者满意 ·························· 33 2.2.5 增强了项目控制 ·························· 33 2.2.6 响应变化 ······································ 33 2.2.7 更早且更大幅度地降低项目 风险 ·············································· 33 2.3 将敏捷宣言应用于系统工程 ··········· 34 2.3.1 增量式地工作 ······························ 34 2.3.2 动态地规划 ·································· 34 2.3.3 主动降低项目风险 ······················ 35 2.3.4 持续地验证 ·································· 36 2.3.5 连续地综合 ·································· 36 2.3.6 用例1：在空域中发现轨迹 ········ 36
第1章 什么是基于模型的系统工程 系统工程是跨学科的活动，它更多地关注系统特性而不是特定的技术，其总体目标是产 生优化的系统以满足潜在的复杂需要。该关注包括必要的系统特性规范（需求）、大规模系统 的组织原则（系统架构）、在其环境中系统和元素间以及构成该系统的大型架构元素间移动的 “流”和事件的定义（接口）以及通过优化分析对关键方法和技术的选择（权衡研究）。 简而言之，系统工程是构建复杂的技术多元化系统的跨学科方法。 贯穿于系统规范、开发和验证的活动中都涉及系统工程。系统工程提供关键的系统级项 目监管。在本书中，我们将关注规范活动，但系统工程所包括的远不止这些。 系统工程区别于学科特定工程，学科特定工程统称为“下游工程”。这些工程学科包括 机械、电子、化学、光学、核电和软件工程。因此，当系统工程可以定义分配到这些特定工 程学科的需求时，这些需求不应规定这些学科中所采用的设计或技术，除非是在高的层级上。 1.1关键的系统工程活动 图1.1指明系统工程的主要方面，它们连接成“传统的”或“经典的”流。 当然，系统工程比这要多很多，在本书中，我们会涵盖很多方面。当前，它提供 套有用的高层次的论点。关于更多的正式的系统工程定义，请读者参考INCOSE Systems Engineering Handbook (1]. 识别客户需要 规定系统需求 评价备选架 选择特定的 分配需求和 构和技术 架构和技术 接口到架构 评估可依赖性 确认系统 以整体验证 系统 综合架构组件 综合多样化的 向下游工程 技术解决方案 转交 图1.1基本系统工程活动
什么是基于模型的系统工程 系统工程是跨学科的活动，它更多地关注系统特性而不是特定的技术, 其总体目标是产 生优化的系统以满足潜在的复杂需要。该关注包括必要的系统特性规范(需求)、大规模系统 的组织原则(系统架构)、在其环境中系统和元素间以及构成该系统的大型架构元素间移动的 “流”和事件的定义(接口)以及通过优化分析对关键方法和技术的选择(权衡研究)。 简而言之，系统工程是构建复杂的技术多元化系统的跨学科方法。 贯穿于系统规范、开发和验证的活动中都涉及系统工程。系统工程提供关键的系统级项 目监管。在本书中，我们将关注规范活动，但系统工程所包括的远不止这些。 系统工程区别于学科特定工程，学科特定工程统称为“下游工程”。这些工程学科包括 机械、电子、化学、光学、核电和软件工程。因此，当系统工程可以定义分配到这些特定工 程学科的需求时，这些需求不应规定这些学科中所采用的设计或技术，除非是在高的层级上。 1.1 关键的系统工程活动 图1.1指明系统工程的主要方面，它们连接成“传统的”或“经典的”流。 当然，系统工程比这要多很多，在本书中，我们会涵盖很多方面。当前，它提供一 套有用的高层次的论点。关于更多的正式的系统工程定义，请读者参考 INCOSE Systems Engineering Handbook [1]。 䆚߿ᅶ᠋䳔㽕 㾘ᅮ㋏㒳䳔∖ 䆘Ӌ䗝ᶊ ᵘᡔᴃ 䗝ᢽ⡍ᅮⱘ ᶊᵘᡔᴃ 䆘Ԅৃձ䌪ᗻ ⹂䅸㋏㒳 ҹᭈԧ偠䆕 ㋏㒳 㓐ড়ᶊᵘ㒘ӊ 㓐ড়ḋ࣪ⱘ ᡔᴃ㾷އᮍḜ ϟ␌Ꮉ 䕀Ѹ ∖䜡䳔ߚ ষࠄᶊᵘ 图1.1 基本系统工程活动 第1章
2敏捷系统工程 下面将论述活动的目的和意图，但不会论述活动如何进行、何时进行（这些内容将在后 续章节中论述)。由于本书的焦点在于描述如何用敏捷的方式达到系统工程的目标，因此如 何执行这些任务将有别于这种简单化的论述。我们将在第2章中从总体上讨论敏捷方法，并 在后续章节中详细阐述敏捷方法的最佳实践。 1.1.1识别客户需要 我们创建系统最终是要满足客户的一整套需要。它通常作为利益攸关者需求或客户需 求集来捕获。我更喜欢这两个术语中的前者，因为利益攸关者的集合超出了采购方或甚至主 要用户的范围。我们必须满足广大利益攸关者的需要，例如： ·采购方 ·用户@ ●评价者 ●市场人员 ●卖方 ●培训人员 ●制造商 。采办方 。安装人员 ●维护人员 。支持服务 ·运行管理 。认证机构 客户支持 ●处置服务 表达利益攸关者需要的最常用方式是采用文本形式的利益攸关者需求规范②，但模型可 以单独使用或与文本需求相结合使用。利益攸关者需求必须是针对利益攸关者的需要是什么 的准确表述，理解这一点很重要。 1.1.2规定系统需求 利益攸关者需求是对利益攸关者需要的表述，系统需求则是对可观察到的系统特性的精 确的、可测试的表述。系统需求最常关注的是系统做什么，但也可包括其他种类的需求，如 服务品质(QoS)、安全性、可靠性、安保性、耐久性、可制造性、可维护性、可复用性、所 谓的“设计需求”和参数需求。第4章会更详细地论述这个主题。要点在于系统需求是关于 ①也可理解为，可能有很多不同类型的用户以不同的方式使用本系统以实现不同的目标。对于一辆汽车，乘客和 司机都是用户，但他们以不同的方式参与到系统中。 ②为清楚起见，在我使用“文本XXX规范”术语时，我所指的是自然语言规范，而不是以精确的文本语言方式表 述的规范，如数学、Z、SysML以及临时逻辑语言
2 敏捷系统工程 下面将论述活动的目的和意图，但不会论述活动如何进行、何时进行(这些内容将在后 续章节中论述)。由于本书的焦点在于描述如何用敏捷的方式达到系统工程的目标，因此如 何执行这些任务将有别于这种简单化的论述。我们将在第2章中从总体上讨论敏捷方法，并 在后续章节中详细阐述敏捷方法的最佳实践。 1.1.1 识别客户需要 我们创建系统最终是要满足客户的一整套需要。 它通常作为利益攸关者需求或客户需 求集来捕获。我更喜欢这两个术语中的前者，因为利益攸关者的集合超出了采购方或甚至主 要用户的范围。我们必须满足广大利益攸关者的需要，例如： ● 采购方 ● 用户a ● 评价者 ● 市场人员 ● 卖方 ● 培训人员 ● 制造商 ● 采办方 ● 安装人员 ● 维护人员 ● 支持服务 ● 运行管理 ● 认证机构 ● 客户支持 ● 处置服务 表达利益攸关者需要的最常用方式是采用文本形式的利益攸关者需求规范b，但模型可 以单独使用或与文本需求相结合使用。利益攸关者需求必须是针对利益攸关者的需要是什么 的准确表述，理解这一点很重要。 1.1.2 规定系统需求 利益攸关者需求是对利益攸关者需要的表述，系统需求则是对可观察到的系统特性的精 确的、可测试的表述。系统需求最常关注的是系统做什么，但也可包括其他种类的需求，如 服务品质(QoS)、安全性、可靠性、安保性、耐久性、可制造性、可维护性、可复用性、所 谓的“设计需求”和参数需求。第4章会更详细地论述这个主题。要点在于系统需求是关于 a 也可理解为，可能有很多不同类型的用户以不同的方式使用本系统以实现不同的目标。对于一辆汽车，乘客和 司机都是用户，但他们以不同的方式参与到系统中。 b 为清楚起见，在我使用“文本XXX规范”术语时，我所指的是自然语言规范，而不是以精确的文本语言方式表 述的规范，如数学、Z、SysML以及临时逻辑语言
第1章什么是基于模型的系统工程3 系统行为和特性的表述。很明显，为确保我们正在构建的系统满足于利益攸关者，我们需要 在这两种需求间建立相关的特定表述。 系统需求规范的主要工作关注于两种特定种类的需求：功能需求和QoS需求。功能需求 规定系统做什么一系统的行为、用户和其他系统如何交互、系统提供什么能力以及系统所 消耗和传递的信息。这些是系统的动词。与此相反，QoS需求规定行为达成得多好（副词）： 例如行为的性能、可靠性和安全性。除了QS需求外，还有其他非功能需求，包括可承受 性、成本、系统效能、可处置性、可维护性、包装和处理等[1]。 简而言之，功能需求规定系统执行的控制和数据转换，而Q0S需求是这些转换的非功能 方面。 系统需求不做的是规定内部架构、设计和实现技术③。常见的错误是，通过规定不必要 的约束过分地约束内部设计，导致架构师和下游工程师有效工作的灵活性受到限制。对所需 的数据或控制转换进行规定是完全恰当的，但在需求中规定该转换的设计或实现通常是不恰 当的。 1.1.3评估可依赖性 术语“可依赖性”指的是我们在预期的环境下以预期的使用方式以及在违反了这些假设 的情况下依赖于系统的能力。可依赖性有三个主要方面：安全性、可靠性和安保性。从图1.1 中可以注意到，该活动与所有其他工程活动并行完成。这是因为可依赖性关注既是内在的又是 外在的。内在的关注是从系统或其背景环境的基本本质属性中产生的。例如，汽车是很重的东 西，它的主要作用是移动，因此内在的关注是能够开始、控制和结束移动。这些关注点不管用 什么技术启动汽车都是存在的。可是，如果在设计中选择燃油发动机，那么这个决策引入了对 燃油可燃性和烟雾的关注：如果选择电动发动机，则引入了对触电和危险材料泄漏的关注。因 而，在做出技术决策时，必须评估这些关注对安全性、可靠性和安保性的影响。 1.1.4评价备选架构和技术 系统需求是从黑盒的视角不断细化的。这意味着不应规定设计内部的技术解决方案。系 统工程师的任务是识别要使用的系统架构和关键技术。这是因为系统工程师有整体的系统视 角并处在最佳位置做出可能影响多重学科（如电子和软件）的权衡。凭借他们的自由发挥④， 电子工程师可以以软件和机械设计对系统成本或性能产生负面影响为代价做出对他们的设计 的最优决策。但如果决策的后果完全特定于某个工程学科，那么这种决策最好留给特定学科 的专家去做。 换句话说，除非缺乏此类规范会对其他工程学科或系统整体产生负面影响，否则系统工 程师不应规定内部软件架构、电子组件或机械零件。 由于系统工程师具备这种整体视角，他们的职责之一是定义大规模系统架构。为此，他 们通常必须评价备选方法。这被称为进行权衡研究。在权衡研究中，为定义设计的某一方面 ③或至少不该做的！ ④双关语
第1章 什么是基于模型的系统工程 3 系统行为和特性的表述。很明显，为确保我们正在构建的系统满足于利益攸关者，我们需要 在这两种需求间建立相关的特定表述。 系统需求规范的主要工作关注于两种特定种类的需求：功能需求和QoS需求。功能需求 规定系统做什么——系统的行为、用户和其他系统如何交互、系统提供什么能力以及系统所 消耗和传递的信息。这些是系统的动词。与此相反，QoS需求规定行为达成得多好(副词)： 例如行为的性能、可靠性和安全性。除了QoS需求外，还有其他非功能需求，包括可承受 性、成本、系统效能、可处置性、可维护性、包装和处理等[1]。 简而言之，功能需求规定系统执行的控制和数据转换，而QoS需求是这些转换的非功能 方面。 系统需求不做的是规定内部架构、设计和实现技术c。常见的错误是，通过规定不必要 的约束过分地约束内部设计，导致架构师和下游工程师有效工作的灵活性受到限制。对所需 的数据或控制转换进行规定是完全恰当的，但在需求中规定该转换的设计或实现通常是不恰 当的。 1.1.3 评估可依赖性 术语“可依赖性”指的是我们在预期的环境下以预期的使用方式以及在违反了这些假设 的情况下依赖于系统的能力。可依赖性有三个主要方面：安全性、可靠性和安保性。从图1.1 中可以注意到，该活动与所有其他工程活动并行完成。这是因为可依赖性关注既是内在的又是 外在的。内在的关注是从系统或其背景环境的基本本质属性中产生的。例如，汽车是很重的东 西，它的主要作用是移动，因此内在的关注是能够开始、控制和结束移动。这些关注点不管用 什么技术启动汽车都是存在的。可是，如果在设计中选择燃油发动机，那么这个决策引入了对 燃油可燃性和烟雾的关注；如果选择电动发动机，则引入了对触电和危险材料泄漏的关注。因 而，在做出技术决策时，必须评估这些关注对安全性、可靠性和安保性的影响。 1.1.4 评价备选架构和技术 系统需求是从黑盒的视角不断细化的。这意味着不应规定设计内部的技术解决方案。系 统工程师的任务是识别要使用的系统架构和关键技术。这是因为系统工程师有整体的系统视 角并处在最佳位置做出可能影响多重学科(如电子和软件)的权衡。凭借他们的自由发挥d， 电子工程师可以以软件和机械设计对系统成本或性能产生负面影响为代价做出对他们的设计 的最优决策。但如果决策的后果完全特定于某个工程学科，那么这种决策最好留给特定学科 的专家去做。 换句话说，除非缺乏此类规范会对其他工程学科或系统整体产生负面影响，否则系统工 程师不应规定内部软件架构、电子组件或机械零件。 由于系统工程师具备这种整体视角，他们的职责之一是定义大规模系统架构。为此，他 们通常必须评价备选方法。这被称为进行权衡研究。在权衡研究中，为定义设计的某一方面 c 或至少不该做的！ d 双关语