功能分层级,系统功能、子系统功能、部件/零件功能。我觉得没必要使用机能这个词。
可以说,这种方法扩展了严格功能和严格程序的方法。初步的建模和设计可以通过以下方式利用此方法:定义功能和机能, 而不将其执行过程分配给特定的子系统或组件,并基于机能定义场景, 而不必将它们统称为功能。
OFUS这篇论文区分function和functionality,我觉得还是觉得有好处的
Function:a special activity or purpose of a person or thing
Functionality:the quality in sth of being very suitable for the purpose it was designed for
从英文释义上看,Functionality更偏向于设计的目的是满足相关方的需要
我在之前的工程实践中,很难理解的一个问题就是一个功能的子功能是不是必须仅是这个功能的子功能,不能是别的功能的子功能,我们一般做功能树都是不允许一个子功能即在A功能下,又在B功能下的。
但是【基于模型的任务系统运行功能统一规范】论文里面的这句话【功能是机能的集合, 集合中的机能共同提供某些系统能力。机能可以是多个功能的成员】启发了我。
我是这么理解的,机能是系统实际运行时的展现出来的能力,而功能是这些能力按照特定逻辑和时序组合运行时“涌现”出来的,能够满足利益攸关方需要的能力。
功能是依靠机能和关系涌现出来的。机能是功能的“手段”(工具)。
我不赞同用包含关系符号描述功能与机能之间的关系。
涌现这个语义在OPM里面好像无法表达
勉强用“手段链接”。但opm不允许用手段链接符号连接两个过程。
赵老师,我个人理解,不一定对啊,【涌现】实际上有两层意思,一是指功能是机能的集合,二是功能不仅仅是机能的集合,二是功能需要机能在【系统依赖的场景下】按照一定的逻辑进行【活动】的运行才能达到【涌现】的目的,即通过改变客体的状态让相关方获益
所以【包含关系】仅仅指的是第一层的意思,第二层的意思需要通过机能持续的运行的建模,比如过程与状态的交互来表达
涌现是可能的关系被激活后变成现实的关系后,系统表现出来的特征和效应。
可能的关系变成现实的关系的现象和过程。
把涌现视为“可能的关系变成现实的关系的现象”,涌现就不再是不可捉摸的了。因为“可能的关系”是可以被认识、描述、控制并利用的。
@赵献民 赵老师,回到论文里面这张图,您认为哪个部分表现了【涌现】的含义
场景对机能的“调用”(触发、激活)。
不管是什么原因,只要是使可能的关系变为现实的关系,均会发生涌现现象。诱因可能是外部事件,也可能是内部事件。