| 
                             
                              | 
                                   
                                    | 编辑推荐: |   
                                    | 本文介绍如何用基于模型的系统工程(MBSE)支持吃烧烤:SysML支持架构建模,将功能映射到逻辑架构,希望对您的学习有所帮助。 来自于系斯模科技,由火龙果软件Alice推荐。
 |  |  什么是模型?模型提供认知杠杆 –“对特定系统、情况或过程的简化或理想化描述或概念,通常用数学术语表示,作为理论或经验理解或计算、预测等的基础,某事物的概念或心理表征。经常有修饰词。” 
                           ——牛津英语词典 为什么工程师喜欢模型?  – 现实往往过于复杂,无法直接“处理”;抽象隐藏了复杂性并促进了分析。 SysML:系统建模语言 • 2001 年,国际系统工程委员会建立了一个模型驱动系统设计工作组,为系统工程定制 UML。 • 到2006 年,OMG 采用了OMG SysML。 • SysML 提供以下图表类型,以及模型元素之间的众多可用关系:  – 行为图:用例图、活动图、序列图、状态机图  
                            – 结构图:块定义图、内部块图、参数图  
                            – 其他图:需求图、包图 
                            系统模型 •存在其他系统建模语言,但SysML是最广泛采用的,并且有一个欣欣向荣的工具生态系统。 •构建良好的系统模型明确地表示系统的行为、结构和元素之间的相互关系。 •它还促进了问题表述的“清晰性”。 •此外,当前的SysML工具允许将模型内容表示为表、矩阵和其他衍生工作产品。 行为是设计的核心 • 系统可能具有以下特征:  – 组成它们的元素  
                            – 这些元素之间的关系和相互作用  
                            – 系统表现出的行为  
                            • 请注意,系统通常表现出的功能/行为比组件单独提供的更多(否则,没有理由将它们组装到系统中)。 • 设计的核心是期望的行为(以及展示行为的条件)。 • 所有需求都是衍生产品,旨在表征和传达所需的行为和相关参数。 严格定义行为 • 为了有效地设计一个系统,人们必须充分理解它必须表现出的期望行为。 • 行为被理解后,必须清楚无误地加以描述。 • 此描述随后可作为创建/推导功能和性能要求的基础。 基于属性的需求 •基于模型的系统工程:基础与方法(ISBN:978-1-84821-469-9),Patrice 
                            Micouin提出所有需求要么是: 结构的:与系统的组成和结构相关的; 
                            行为的:与系统的行为/功能相关的; 
                            混合的:上述类型的组合的; 
                            还提出了一个基于属性的需求模型,消除了与基于文本的需求模型相关的模糊(包括用于捕获系统必须显示其功能的条件的语法)。 功能分解 •功能分解是系统工程过程的基石。 •使用了许多方法,包括功能流程框图(FFBDs)和IDEF0。 •SysML活动图可用于完成此角色,并具有易于分配给逻辑体系结构变体的附加优势。 •这通过促进重用和端到端可追溯性增强了系统模型的实用性。 用例:理解行为的基础 •SysML用例图是行为建模的有用起点。 •它们简单易懂,允许定义系统行为的个人或团队描绘相关行为、参与者和交互系统。 用例图: 烧烤BBQ 
 • 该图描述了烧烤架必须表现出的基本行为  • 包括几个相邻的系统(燃料、环境、食物)  • 它还包括“坏参与者”:不请自来的人 作为方法的活动图 
 •活动图可以作为“方法”附加到用例中 •这使建模工具中的直接深入行为成为可能  
 •此图是“cook food”的方法 •它包括各种活动,输入/输出参数被捕获并表示为进出PIN的对象流. 操作Operations (Input/Output/Return) 在SysML中,功能由一个操作表示 •操作必须由一个块拥有 •操作可以有一个或多个输入和输出参数 •操作也可以只有一个返回参数  
 
 烧烤架功能块 
 每个活动都是一个调用操作 •在这种方法中,活动图上的每个活动节点都是一个调用操作节点。 •如果需要进一步分解,可将方法附加到给定操作。 •这反映了典型的功能分解表,具有可能的丰富表达(和/或、时间事件、中断、逻辑分支等)的额外好处。 调用操作示例 
 燃烧燃料归“烹饪功能”所有 –它的输入是氧气和燃料 
                            –它的输出是烟、热和灰 
                            输入/输出表Input/Output Table 
 逻辑块Logical Block • 逻辑元素使用<<logical>> 构造型键入。 • 然后通过泛化关系将它们与功能块相关联。 • 这允许他们从功能块继承操作(以及操作满足的功能要求和链接到功能块的任何其他要求或模型元素)。 烧烤员逻辑块The User Logical Block 
 物理块 Physical Block •物理块与逻辑块相似;他们有<<physical>>的构造型。 •它们还可能包含属性,例如: –质量 
                            –长度/宽度/高度 
                            –其他物理属性 
                            •请注意,它们还可能继承其他块的属性和关系。 烧烤员物理块Physical Operator Block 
 泛化/专门化的优势Advantages of Generalization/Specialization •无分配:块“拥有”其功能和属性。 •关系继承: -操作满足功能需求;如果一个块继承一个功能,它也会继承这个关系 
                            -其他关系(如满足性能要求的值属性)也会继承 
                            •不需要分配关系…简化建模工作。 逻辑架构示例 
 Pellet烧烤架逻辑架构 
 衍生工作产品:示例矩阵 
 结论 • 使用操作是完成功能分解的一种灵活而直接的方式。 • 泛化关系可用于从每个架构到下一个架构(功能到逻辑到物理)继承功能、需求和其他关系。 • 衍生的工作产品,例如表格和矩阵,可用于管理这些关系并确保覆盖率和可追溯性。    |