东西二王 / 系统科学 / 基于模型系统的系统设计

分享

   

基于模型系统的系统设计

2019-05-04  东西二王

基于模型的系统工程(MBSE)在系统设计实践中不仅要重视具体模型(例如用例图、活动图、顺序图等)的使用,更需要重视构建合适的模型系统和模型架构。模型系统的完整性和模型架构的完善性直接影响系统工程在系统设计实践中的效果。

基于模型系统的系统设计

中国对系统工程的研究和应用起步很早。早在1954年,当兰德公司提出“系统工程”术语的时候,钱学森就发表了《工程控制论》。但是,随着世界及中国工业化的不断深入发展,系统工程本身的发展和应用也不断迎来新的挑战,需要从业人员不断思考新的问题。一个突出的现象是,工业系统的复杂性呈现类似指数规律的增长,工业企业自身的复杂性、工业体系的复杂性也迅速增长。这要求系统工程理论随之发展,对工程实践提供必要的指导。

近年来,中国对系统工程的学习、研究和实践迅速发展。但同时,在实践中也遇到了诸多挫折,甚至由此引起对当前系统工程理论和方法本身的怀疑。其中的原因之一是片面关注对部分具体模型和工具软件的应用,而忽视对模型系统的构建,非常容易陷入“见云不见雨”的困境,在项目实践或企业转型中难以解决“干旱问题”。应该将模型系统作为企业的战略性资产看待,通过构建合适的模型系统提升企业研发能力,提高系统工程应用效果。

主要术语

系统

系统是一个复杂的整体(whole),其功能取决于它的组成部分以及这些部分之间的相互联系。

非自然系统是以提供产品或服务为目的而人为定义并构造的相互关联的元素的集合。

系统思维(system thinking)就是把某个疑问、某种状况或某个难题明确视为一个系统的思维方式。

当把与某种关切相关的一系列问题视为一个系统时,就是一个“问题系统”;当把描述问题系统或描述产品的一个或多个模型视为一个系统时,就是一个“模型系统”。

模型

(美国)国防部体系结构框架(Department of Defense Architecture Framework,DoDAF)对模型的定义是“模型作为一种模板,以易于理解的格式来组织和显示数据”。并进一步定义:“当以此方式收集和呈现数据的时候,其结果就称为视图”。按照这个定义,可以将视图理解为数据实体或实例。

综合定义方法(integration definition method,IDEF)对模型的定义是:“不管以何种形式,只要 M 能回答有关实际对象A的所要研究的问题,就可以说M是A的模型。”这个定义揭示了模型的本质,尤其是打破了对模型的狭隘理解,模型是不限于形式的。IDEF对模型的定义可以理解为等同于DoDAF 所说的“视图”,是“数据”而不是“组织和显示数据的模板”。正如以上对模型的两种阐述,“作为模板的模型”与“作为数据实体的模型”非常容易混淆。为讨论方便,本文采纳DoDAF对模型和视图的定义。

架构

对“架构”(architecture)的内涵有不同认识和描述,以下是3种有代表性的阐述:

1)系统架构是更加抽象的、面向概念化的、全局的、聚焦于达成系统的任务和运行概念,并聚焦于系统和系统元素中的高层级结构。

2)架构就是对系统中的实体以及实体之间的关系所进行的抽象描述。

3)系统架构是概念的体现,是对物理的/信息的功能与形式元素之间的对应情况所做的分配,是对元素之间的关系,以及元素同周边环境之间的关系所做的定义。

这些阐述中出现的一些关键词有助于对架构内涵的理解——抽象、功能、形式和关系。

功能是可以用动宾短语描述的行为,相当于语法中的“谓语 宾语”。

形式是承载功能的主体,相当于语法中的主语。形式可以是实物系统、人员角色、组织或机制等。

架构是系统形式元素集合与系统功能元素集合之间的对应关系,是对系统主要元素及主要功能之间关系的概要描述,而忽略其中的细节。

模型系统与模型架构

模型系统的复杂性与问题系统的复杂性

模型的形式是否合适,取决于模型所要描述的事物的特征,以及人的思维特征。对于不同类别的事物,往往需要利用不同形式的模型描述,以利于人的准确理解。既然模型用于描述和回答问题,针对不同类别的对象,往往需要采用不同形式的模型。尤其是针对不同层级的问题,往往需要采用不同的模型。

基于模型的系统工程(MBSE)强调模型在系统工程的作用。需要重视的是,当要创新式研制某个复杂系统时,需要构建足够完整的模型系统。因为问题系统常常是不同的,所以没有通用的模型系统。适用于特定组织、特定项目的模型系统需要按照业务特点组织开发。开发的模型系统需要有良好的模型架构。如果使用的模型不完整,或者模型架构不合理,势必会直接影响对问题描述的完整性和准确性。

当面对某个较为具体的、影响范围不大的问题时,所需要的模型类型常常比较单一。例如描述系统的某个简单功能时,可以使用用例模型、活动图、顺序图、内部块图、状态机等模型。这几个模型组成了一个简单的模型系统。当面对的问题范围扩大到构建一个实物系统时,就要在此基础上增加描述系统形式的模型,还要建立功能与形式之间的关系,这些关系也需要相应的模型描述,例如功能与形式映射矩阵。可见,这样的模型系统就显得复杂些了。

如果作为主承包商负责研制一个完整的、复杂的系统时,所面对的问题将更为复杂。从模型深度方面看,往往需要从用户对系统能力需求的开发开始,向下一直到系统元素的具体实现;从生命周期方面看,需要从概念阶段到退役阶段。此时所面对的问题系统将是庞大复杂的系统。对于这样的问题系统,期望使用简单的模型、使用简单的模型架构完成描述任务是不可能的。

学习和使用诸如用例模型、活动图、顺序图、内部块图等“元素级”的模型并不难,但是要开发一个适用于复杂系统研制的模型系统,就是一项富于挑战的任务了。

美国国防部体系结构框架从利益攸关者视角将模型分为 8类(即 8个视角),共 52个模型。这 8个视角中的 52个模型就构成了一个模型系统框架,可以用于指导开发复杂的模型系统。甚至对于非常庞大的问题系统,例如描述某个大型组织的形式、业务和数据,或描述某个复杂系统研制流程和系统本身的描述数据,都可以参考 DoDAF 开发适用的模型系统。事实上,DoDAF中的模型系统框架更侧重于用户视角。如果作为开发者,往往需要比DoDAF模型更加细致的、适用于多学科问题描述的模型描述问题、描述系统。

模型架构的基础

问题系统的复杂性千差万别。是否存在一种搭建模型系统架构的通用方法?除了DoDAF这样的框架指导,在系统设计中有是否有规律可循?要回答这个问题,就需要考察是否存在通用的核心问题架构。

扎克曼框架(Zachman framework for enterprise architecture and information systems architecture)是DoDAF 的重要理论基础之一,原理上是以问题系统为核心建立体系结构框架。对于系统设计活动所面对的问题系统,图1描述了通用的核心问题架构。这个问题架构有重要的现实意义。

1)目的(Why)是必须首先考虑的问题,该问题属于业务和任务层。如果目的不明确或不合适,会直接影响决策。在系统研发早期需要对研发目的作明确的描述。

2)如何做(How)对应系统的功能,该问题处于问题的核心,属于概念层。考虑这个问题的过程是孕育有益创新最重要的环节。对于“跟踪式”研发来说,经常将“是什么”(What)当作问题的核心,从而失去重要的创新机会。

3)是什么(What)对应系统的形式,该问题属于系统层(物理层)。

4)性能(收益How well)和代价(How much)对应系统的度量,该问题也属于系统层。这是系统的验证、确认和采购需要考虑的重要问题。

5)问题架构是设计活动架构的基础,也是主体系统架构的基础。

核心问题架构是工程设计项目中描述一切问题的基础,是构建完整的问题架构、构建完整的模型架构的基础。

模型架构的层级

1)工程设计步骤与模型层级

为了完成工程设计,通常有任务层、概念层和系统层这 3 个设计活动层级。任务层设计回答图 1 中的问题“Why”,描述目的和功能。任务层主要对应用户和客户视角,描述的问题处于问题空间(或称为“问题域”);概念层设计回答图 1中的问题“How”,描述功能与备选的形式或选定的形式之间的对应关系,也就是系统架构设计;系统层设计回答图1 中的问题“What”和“How much/well”,描述选定形式的细节,详细到足以据此实施系统、运行系统、维护系统直至系统退役。概念层和系统层主要对应工程师和供应商视角,描述的问题处于解决方案空间(或称为“方案域”)。

基于模型系统的系统设计

图1 系统设计的核心问题架构

事实上,在工程设计实践中还有另外一种设计活动层级划分方式。例如设计飞机时,可能分为飞机层设计、机载系统层设计和机载设备层设计。这种划分方式可以称之为“按照产品层级划分的层级”。按照产品层级划分设计活动层级的局限性在于,它侧重关注系统的形式,而容易对系统的功能关注不足。这与面向服务的理念相矛盾,常常使系统功能偏离用户需求。或者说解决方案空间偏离问题空间,两者之间的对应关系发生偏差。不仅如此,用户需求在产品层级之间分解和传递时,也容易产生阻力、衰减和畸变。

2)任务层

工程设计是为了获取某种工具(实物工具或机制),利用这种工具对事物施加某种影响,以达到期望的目的。对于人类的理性活动,无论是复杂还是简单,总是由目的驱动的。确定目的并描述目的是第一个步骤,是属于任务层设计。任务层或可称为“业务层”或“业务和任务层”。任务层的工作主要是定义目标和任务范围。对应问题架构中的“Why”。

任务层定义为后续定义提供非常重要的基础。为用户提供的最有用的服务是帮助他决定什么是他真正想要的。需要重点关注的是对任务的描述应该完整且无冗余。为了完整地描述任务,就需要对任务作适当的分解。分解方式、分解深度和对分解的描述方式会影响描述的完整性和独立性。重叠描述任务不仅使后续定义和分析过程工作量剧增,更麻烦的是某些隐性的重叠描述如果未被发现,则很容易产生歧义,为研制质量控制和成本控制埋下深深的隐患。

分解任务时,常见的方式是按照任务过程分解,或按照任务客体对象类型分解。描述分解结果的常用形式是清单或树状图。

事实上,无论是按照过程分解,还是按照客体对象类型分解,都无法仅仅用清单或树状图描述任务之间的关系,并使所描述的任务之间相互独立。对任务分解得越深,越容易使子任务之间相互重叠。原因是过程之间和对象类型之间广泛存在着逻辑关系(典型的逻辑关系如泛化、依赖和关联),逻辑关系无法仅用清单和树状图描述。更本质的原因是,任务之间关系的拓扑是网状的,思维导图或清单的拓扑是树状的,两者之间不存在合理映射。为了弥补清单或树状图的不足,可以结合如图3所示的类图对任务作分解和定义。

树状的思维导图(图 2)、任务用例图和任务类图(图 3)是分解并描述任务层任务活动的适用模型。在任务层活动分解和描述时,还需要使用结构化文本模型对每项任务活动的内涵(目的、范围、执行者等)作详细描述。

基于模型系统的系统设计

图2 思维导图

基于模型系统的系统设计

图3 任务类图

完成任务分解后,可以针对任务逐一描述。描述时可以采用 SysML定义的用例图、活动图、顺序图、内部块图、状态图模型或接口描述表等其他模型。一组“用例图、活动图、顺序图、内部块图、接口描述表、状态图”的实例就像一片叶子,一棵树上的所有叶子结构都是相似的。任务分解定义了枝干,在枝干末梢长满叶子,一棵大树就被描述完整了。

任务分解模型(组)和任务定义模型(组)共同组成任务层模型系统。

3)概念层

概念层或可称为“逻辑层”。概念层要定义如何实现任务目标,对应问题架构中的“How”。概念层设计的目标是确定系统架构,也就是确定系统功能与系统形式之间的对应关系。

概念层处于任务层与系统层之间,是可选的而非必须的。如果任务层的活动与系统层的系统元素一一对应,则可以不定义概念层;如果任务层的活动与系统层的系统元素之间是复杂的多对多关系,则概念层就是必要的。这种映射关系越复杂,越需要作概念层定义。

概念层设计要针对任务层定义的每项任务,分析其资源需求。资源需求包括数据资源需求、实物资源需求和能源资源需求等。

概念层设计需要的模型类别通常包括以下8类。

■ 业务和任务行为描述模型。

■ 业务和任务环境(包括外部系统)接口描述模型。

■ 业务和任务与系统功能映射关系描述模型。

■ 业务和任务与所需资源流描述模型。

■ 资源描述模型。

■ 系统功能描述模型。

■ 系统形式描述模型。

■ 系统架构描述模型。

上述各类模型不拘泥于形式,此处仅强调其功能。这些模型组成概念层模型系统。

4)系统层

系统层或可称为“物理层”,对应问题架构中的“What”和“How much/well”。系统层要定义系统元素的形式细节和行为细节。系统层的描述要足以支持构造真实的物理系统。

对系统元素的描述涉及多物理域,适用的模型形式也非常多,不存在普遍适用的模型。系统层模型系统与学科领域强相关,而与系统功能和系统形式无关或弱相关。

对复杂系统的设计,往往需要将系统本身划分为多个层级。例如,在飞机设计时,将系统划分为飞机层、机载系统层、机载设备(部件)层、零件(模块)层等。针对每个层级,也可以按照任务层、概念层和系统层这 3层开展设计,这是递归过程,对各类模型也可以递归使用。

基于模型的系统工程(MBSE)在系统设计实践中不仅要重视具体模型(例如用例图、活动图、顺序图等)的使用,更需要重视构建合适的模型系统和模型架构。模型系统的完整性和模型架构的完善性直接影响系统工程在系统设计实践中的效果。(责任编辑 祝叶华)

参考文献(略)

基于模型系统的系统设计

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多
    喜欢该文的人也喜欢 更多

    ×
    ×

    ¥.00

    微信或支付宝扫码支付:

    开通即同意《个图VIP服务协议》

    全部>>