1 引言
OOSEM（Estefan，2008）将面向对象的概念与基于模型的传统SE方法相结合，以帮助构建灵活且可扩展的系统，适应不断发展的技术和变化的需求。OOSEM支持系统的规范、分析、设计和验证。OOSEM还可以促进与面向对象软件开发、硬件开发以及验证和确认方法的集成。
面向对象的系统工程（OOSEM）起源于1990年代中期在软件生产力联盟与洛克希德·马丁公司合作的工作。该方法部分应用于洛克希德·马丁公司的大型分布式信息系统开发，包括硬件、软件、数据库和手动程序元素。2000年11月，国际系统工程学会切萨皮克分会成立了OOSEM工作组，以帮助进一步发展该方法。OOSEM在国际系统工程学会和行业论文中有所描述（Friedenthal，1998；Lykins等人，2000），并在Friedenthal等人（2012）的《SysML实用指南：系统建模语言》一书中进行了介绍。
OOSEM的目标如下：
- 在整个生命周期中捕获足够的信息，以指定、分析、设计、验证和确认系统
- 将MBSE方法与面向对象的软件、硬件和其他工程方法相结合
- 支持系统级的重用和设计演进
图9.5展示了构成OOSEM的技术和概念。OOSEM融合了基础的SE实践、面向对象的概念以及其他独特的技术来处理系统复杂性。被公认为对SE至关重要的实践是OOSEM的核心原则。这些包括需求分析、权衡研究以及集成产品和过程开发（IPPD）。有关IPPD的更多信息，请参阅第9.7节，它强调了在开发过程中多学科团队合作的重要性。
在OOSEM中利用的面向对象概念包括块（即UML中的类）和对象，以及封装和继承的概念。这些概念直接由SysML支持。OOSEM独有的技术包括参数流下、系统/逻辑分解、需求变化分析以及其他一些技术。
2 方法概述
OOSEM支持如图9.6所示的开发过程。
这个开发过程包括以下子过程：
- 管理系统开发——规划和控制技术工作，包括规划、风险管理 1、配置管理和测量。
- 定义系统需求和设计，包括指定系统需求、开发系统架构以及将系统需求分配给系统元素
- 开发系统元素——设计、实施和测试满足分配要求的元素
- 集成和测试系统——集成系统元素并验证它们是否单独和共同满足系统要求
这个过程与第三章中描述的典型“Vee”过程一致。它可以在系统层次结构的每个级别上递归和迭代地应用。例如，如果系统层次结构包括多个系统元素级别，则该过程可以应用在系统级别上，指定系统元素的第一级要求。然后，可以对第一级的每个系统元素再次应用该过程，以指定第二级系统元素的要求，依此类推。
为了有效，OOSEM开发活动必须得到应用SE基本原理的系统工程师的支持，包括使用多学科团队以及有纪律的管理流程，如规划、风险管理、配置管理和测量。OOSEM开发活动和伴随的过程流在面向对象系统工程方法(OOSEM)教程(LMCO, 2008)和教程材料——使用OOSEM的基于模型的系统工程(JHUAPL, 2011)中有更详细的描述。
系统需求和设计过程被分解为以下OOSEM高级活动，如图9.7所示。
2.1 分析利益相关者需求
这项活动支持对“现状”和“未来”企业的分析。在OOSEM中，企业将系统与其他外部系统聚合在一起，共同完成任务。“现状”系统和企业被详细记录下来，以了解其局限性和需要的改进。“现状”企业的局限性，通过因果分析技术确定，是推导“未来”企业任务需求的基础。
OOSEM规定了“未来”企业的任务需求，以反映客户和其他利益相关者 2的需求。任务需求包括定义新的和改进的能力，以解决因果分析中确定的限制。 “未来”企业的能力被表示为具有相应MOE的用例。“未来”企业为要开发的系统或系统集定了上下文。
支持分析的建模工件，包括用例、场景分析、因果分析和上下文图，可以在客户的“现状”和/或“未来状态”概念文档中进行捕捉。
2.2 分析系统需求
这项活动规定了支持任务需求的系统需求。系统被建模为一个与外部系统和用户交互的黑盒。用例和场景反映了系统如何用于支持任务的操作概念。这些场景使用泳道表示黑盒系统、用户和外部系统的活动图进行建模。每个用例的场景用于推导黑盒系统的功能、接口、数据和性能需求。需求管理 3数据库被更新以追踪系统需求到用例和相关的任务需求。
随着开发的进行，需求可能会发生变化。例如，系统的外部接口可能会改变，或者其性能要求可能会增加。需求变化是根据需求可能发生变化的概率以及这种变化对任务的影响来评估的。这些因素被纳入风险评估，并在稍后用于确定如何设计系统以适应潜在的需求变化。
2.3 定义逻辑架构
这项活动包括将系统分解和划分为逻辑元素，例如，一个用户界面可以通过网络浏览器或环境监测器来实现，而环境监测器将通过红外传感器来实现。这些元素相互作用以满足系统需求并捕获系统功能。拥有逻辑架构/设计可以减轻需求和技术变化对系统设计的影响。
OOSEM提供了将系统分解为其逻辑元素的指南。逻辑元素的功能源自逻辑场景，以支持黑盒系统功能。逻辑元素的功能和数据可以根据其他标准重新划分，例如内聚性、耦合性、设计变更、可靠性和性能。
2.4 合成候选物理架构
物理架构描述了物理系统元素之间的关系，包括硬件、软件、数据、人员和程序。逻辑元素被分配到物理元素。对于分布式系统，OOSEM 包括指导，用于将物理元素分布在系统节点上以解决性能、可靠性和安全性 4等问题。系统架构继续完善，以解决与软件、硬件和数据架构相关的问题。每个物理元素的要求都追溯到系统要求，并在需求管理数据库中维护。
3 优化和评估备选方案
这项活动在整个其他OOSEM活动中被调用，以优化候选架构并进行权衡研究来选择一个架构。用于建模性能、可靠性、可用性、生命周期成本、人类和其他专业工程问题的参数模型被用来分析和优化候选架构到比较备选方案所需的水平。用于执行权衡研究的标准和加权因素可以追溯到系统需求和MOEs。TPMs被监控，并且潜在的风险被识别。
3.1 管理需求可追溯性
这项活动在整个其他OOSEM活动中进行，以确保需求、架构、设计、分析和验证元素之间的可追溯性。需求关系被建立并维护。系统模型中的需求被同步。随着需求管理数据库的更新，可追溯性持续被分析以评估和填补差距或不足。当需求发生变化时，可追溯性用于评估需求变化对系统设计、分析和验证元素的影响。
3.2 验证和确认系统
这项活动验证系统设计是否满足其要求，并确认这些要求是否符合利益相关者的需求。开发了验证计划、程序和方法（例如，检查、演示、分析和测试）。开发测试用例和相关验证程序的主要输入是系统级用例、场景和相关需求。可以使用与之前描述的用于建模操作系统的相同活动和工件来建模验证系统。在此活动中，需求管理数据库将被更新，以跟踪系统需求和设计信息到系统验证方法、测试用例和结果。
4 应用OOSEM
OOSEM是一种用于指定和设计系统的MBSE方法。这些系统不仅包括操作性系统，如飞机或汽车，还包括在整个生命周期中支持操作性系统的系统，如制造、支持和验证系统。该方法还可以应用于架构系统中的系统或企业，以及架构单个系统，甚至系统元素。
OOSEM 应根据特定应用、项目需求和约束进行定制。定制可能包括调整对特定活动及其相关建模工件的重视程度，以及/或根据特定生命周期模型对活动进行排序。
建模工件也可以在其他应用程序中进行细化和重用，以支持产品线和进化开发方法。产品线建模关注的是可变性的建模。为了确保所谓的“基于模型的产品线SE”，需要考虑三个方面的改进：
- 对每种工件类型的变化性和这些变化性之间的约束进行建模：需求、要求、架构、测试等。
- 每种SysML图的变异性建模：活动图、用例和其他。
- 这些工件之间的依赖关系和这些可变性之间的约束的建模，以解释它们之间的关系：例如，对于热水器产品线，电阻元件功率的可变性取决于或不取决于热水器容量的可变性。
OOSEM可以与各种学派的原则和实践相结合，例如敏捷软件开发。同样，这需要调整和定制如何应用OOSEM以与其他方法集成。
本文同步发表在 软件需求探索的https://srs.pub/specification/object-oriented-systems-engineering.html
作者: