本文的主要论点：软件开发应被视为通过将思维模型转换为程序代码来实现思想。
本文介绍了软件工程中实现思想的范式（英语：RPSE：作为软件工程范式的形式化）。
文章的英文版：
RPSE：作为软件工程范式的“形式化” 。 缩写词RPSE在下文中用于表示所描述的范例。
关键定义
在讨论本文的要点之前，您需要先同意本文中使用的基本术语的含义。
软件工程
对于
软件工程，我们指的是IEEE词典[1]中对软件工程学科的经典定义：软件工程是“对软件的开发，操作和维护应用系统，规范，可量化的方法”。
范式
本文中使用的
范式一词是基于托马斯·库恩范式[2]的经典定义：范式是一个问题圈子，一系列概念，普遍接受的规则和法则，解决特定科学领域问题的方法。
有关范式的更多信息为了更准确地确定下面使用的范式的概念，引用库恩书中的两个众所周知的引语很有用：
范式是指公认的科学成就，这些成就在一段时间内为科学界提供了提出问题及其解决方案的模型...
介绍这个术语，我的意思是说，一些科学研究实践的普遍接受的例子-包括法律，理论，其实际应用和必要的设备的例子-一起为我们提供了具体科学研究传统的模型。
这一概念的二重性在于，一方面，范式的特征是通过认识它的专家群体来表征的。 确定，创建和开发零件的是特定领域的专家。 另一方面，对某种范例的认可意味着专家加入了这样的社区。
托马斯·库恩（Thomas Kuhn）在他的书中考虑了科学范式。 但是，在本书的第一版发行后不久，这种概念在技术和社会生活各个领域中的实用性就变得显而易见。 在这方面，许多关于范式及其在汽车工业，城市规划，某些疾病的治疗等方面的出版物开始出现在特殊和流行的文献中。
软件工程，尤其是其重要组成部分-编程也不例外。 当前有许多竞争的编程范例。 Wikipedia上的另一篇文章[3]以及诸如[4]这样有趣的评论都专门针对它们的枚举。
关于编程范例的局限性[3]和[4]中描述的范例的作者集中于软件工程的一个狭窄子领域，即以特定的编程语言编写程序。 我认为许多专业人士都同意，不能仅在这些范例之一（例如功能编程）的框架内完成实际的软件项目。
相比之下，本文描述的范例适用于软件开发的各个主题领域和阶段。
关于软件项目管理范例的局限性例如，在评论[5]中，一些作者将组织和执行软件项目的各种方法或模型命名为范例。 例如，比较瀑布模型，V模型或敏捷模型。 与上述编程范例相反，这些方法不太可能因其相对的理论简单性和缺乏广泛的理论基础而在库恩定义的精神下被称为范例。
本文提出的范式还没有自己的理论基础，但是今天它的发展道路已经可见。
思想的实现
本文中
使用的概念的 物化 （engl：
reification ）是计算机科学中对物化的经典定义的扩展：“物化是将有关计算机程序的抽象概念转变为显式数据模型或以编程语言创建的其他对象的过程” [6]。
关于思想世界，事物世界和物化的更多信息本文中使用的对物化概念的经典定义的扩展实质可以定义如下。
在最早出现在我们身上的哲学领域中，已经决定将理想（思想世界）与物质（事物世界）进行对比。
我们充其量只能感觉到理想（或者认为我们感觉得到了）。 这种理想感的指标可以是在听了一段音乐，一本书的阅读片段等之后情绪或思维方式的变化。 当然，我的意思是对音乐的间接影响，例如音乐对我们的意识的影响，而不是身体对摇滚音乐会的轰鸣或迪斯科节奏的原始生理从属。
试图将我们对理想的理解表达为规则并不会成功。
伟大的俄罗斯诗人费多尔·伊万诺维奇·蒂奇切夫（Fedor Ivanovich Tyutchev）对此进行了出色的评论：
心脏如何表达自己？
还怎么理解你？
他会明白你的生活吗？
说出的是谎言... [7]
刚开始时，甚至很难提出一些实用的想法，例如房屋周围的小修或准备新的熟悉的菜肴。 只有经过深思熟虑或试图向他人解释后，这种想法才呈现出越来越清晰的“轮廓”。
现在，我们从理想概念的考虑转向对物质的考虑。 我们可以感知并记录我们周围的物质对象，以定性地区分它们的属性。 可以客观地测量许多对象的属性。 我们还可以客观地确定实体对象的层次结构和其他结构。
进行评估或测量（以获得定量特征）时，不需要有物品。 拥有他的模型就足够了。 此外，在许多实际有趣的情况下，可以在没有对象的情况下使用该模型。 模型可以与其他人讨论。 可以协商模型。 模型可以标准化（形式化）。
在人类活动的某些领域，模型的标准化程度如此之高，以至于从技术的角度来看，由不同的人或机枪根据标准化模型（例如，图纸）制成的零件（例如，螺栓）将无法区分。
意识到所提出定义的相对不准确性，在本文的后面，我将内在世界和外在世界的现象世界分为两部分：
U = M +我其中集合
M包含可以客观记录或测量的现象（物质世界），而
我 -其他所有事物。
这个公式是否适用于我们周围世界的绝对所有现象，这是一个开放的哲学问题。 在本文的后面，我们将公式的范围缩小到软件工程领域中的现象领域。
或者，将其表述为论文：与软件工程相关的全部现象可以分为理想的子集和材料的子集。 此外，根据现象的模型记录或测量物质现象。
在大多数情况下，创建或修改软件系统的过程以创建一个或另一个代码为结束，该代码使用计算机在物理过程中显示（现实现象）。
此过程始于在客户或开发人员心中出现的有关未来系统的某些想法。 我们将这些思想称为思想
模型 。
关于中间模型在简单的系统或对大型系统进行简单的添加/更改的情况下，开发人员会立即根据其思维模型编写代码或配置系统。 但是，在大多数情况下，会创建具有不同复杂度和形式化级别的中间模型-从简单的需求列表到广泛的形式模型（例如UML或BPMN模型）
与软件工程相邻的地区实现思想
显然，上述定义并不是全新的，而是在与编程相邻的智力工作领域中广泛使用（有意识或无意识地）。 例如，考虑两个这样的领域-机械工程和数学。
这两个领域已经长期有效地使用了思想的实现。 在这方面，他们有很多关于编程的知识。
在机械工程中，我们看到了一个完整的想法实现过程-从设计师脑海中出现一个想法到其思想，再到细节，将其映射到模型，最后从某种材料制造出来。
在数学上情况是不同的。
论数学思想的具体化关于数学思想具体化的有趣事实和考虑可以在本书[8]的第7.3段中找到。
数学的“最终产品”是具有经过严格验证的属性的形式模型。
从这个角度来看，编程处于中间。 可以用图形表示如下：
因此，数学使用了大量更多的抽象模型，并且几乎不适用于诸如工程图等极其特殊的模型领域。
相反，机械工程使用相对较少的抽象模型，但使用许多特定模型。 例如，可以明确制造物理对象的对象。
从这个角度来看，编程处于中间。
为什么在中间编程？最终的编程产品是软件代码。 而且，尽管它在硬件上执行时被映射到特定的物理对象（电信号和各种物理性质的场），但是这些对象很难与螺母，齿轮和车身进行比较。 另一方面，程序代码接近数学公式，有时是它们的直接反映。 但是，在任何实际的软件系统中，您都需要考虑环境的许多特定方面以及与用户或其他系统的交互。 这使得程序代码比数学公式更具体。
在模型使用方面，软件工程可以从邻近地区学到什么首先考虑数学。
世界多模型
在其发展的几千年中，数学学会了用非常不同的术语描述真实世界或虚构世界的相同现象。 古希腊人学会了用几何图形代替纯粹的口头描述来完成任务，并借助他们的帮助解决了实际上很重要的问题。 后来，出现了关于平面和数字上的线段互换性的理解。 然后，一个代数变量的概念以及将几何问题简化为代数方程组的概念就得以实现。
如今，高中生已经知道可以以不同的方式（例如几何或代数）解决相同的问题，并且相同的数学模型（例如代数方程式）可以描述许多不同的物理，化学等。 现象。
模型的形态以及概念和符号的一致性
数学不仅学会了很好的学习，而且使用非常不同的数学性质的模型描述了相同的真实或虚构的对象和过程。 数学的一项重要成就是能够确定来自不同数学分支的模型的相似度，以及将它们相互转化的能力。 近年来，对于最重要的数学问题，许多突破性的解决方案本质上都是独立的证据链，每个证据链都使用了特殊数学领域的专用仪器。 在这一高度专业化的证据的交界处，数学熟练地将一个数学部分的模型转换为另一部分的模型。 在编程中，当编译程序的源代码以及从DSL（特定于域的语言）或元数据生成代码时，现在会发生类似的情况。 但是软件工程领域中使用模型的文化远远落后于数学。
机械工程模型
从工程的物化中可以学到什么软件工程？
在许多行业中，甚至在人们非常关注的情况下，也存在着协调的正式和半正式模型链。 这些链以模型结尾，基于模型来制造和安装物理对象-设备和机器。 通常，对于大多数类型的中间模型，都有检查其正确性的正式方法（技术标准）。 模型是设计和制造工程产品过程中各种配置文件专家的主要交流语言。
在这种背景下，IT形势似乎要糟糕得多。 近年来，仅在非常大的IT问题中，才尝试建立可比较的模型和流程集。 通常，小公司和IT初创公司不仅没有开发正式的模型和流程，甚至都不怀疑它们的存在。 当前，这种情况取决于以下因素：
- 现有模型和流程缺乏效率
- 这些模型的知名度不足
- 对开发人员尤其是管理人员的教育不足
- 大学教育的积压来自软件工程的实际需求。
理念的物化（RPSE）范式的定义和轮廓
我们已经确定了所有必要的概念，可以对所提出的范例进行基本定义。 这是：
软件开发是通过将心理模型转换为计算机上执行的代码来实现思想。
在拟议范式的框架中：
- 所有主要软件开发过程都是构建心理模型和材料模型链的过程的特定变体（实现）。 通常，此链中最具体的模型是程序代码。
- 软件开发的本质是创建这样的链。
- 开发优化，降低成本和提高质量的所有主要问题都可以减少到优化相应模型链的构建。
为什么要实现而不是建模？请注意，尽管RPSE的定义指的是模型链的构建，但仍建议将范式化具体化而不是建模。 因此，试图强调模型链的特殊性，这些模型链变得越来越抽象/理想，越来越具体/材料化。
上面的定义在软件工程的不同领域有其自身的特点和变化。 仅在极少数情况下，在程序员的脑海中会发生一个清晰的想法，即如何在他完全成熟之前解决问题，然后在短时间内将其转换为编程语言代码。 在大多数现实世界项目中，寻找解决方案及其实现的过程共存，并行发展并相互影响。 即 心理模型，代码和通常的中间模型（以测试，图像，UML等形式模型的形式）并行增长和变化，相互影响。
定义选项很多时候，几个人同时处理一个问题。 他们每个人都有自己的思维模型，并可能有中间模型和代码片段。
通常，实际上缺少某种编程语言的代码，因为创建新解决方案归结于管理配置程序或生成器的掩码，例如，在诸如SAP或WebSphere的系统中使用开发工具时。
如今，用于将手动编写或自动生成的代码转换为可执行代码的选项也变得非常多样化。
最后，近年来，在其上执行代码的处理器的概念也得到了显着扩展。 如果以前是板上的处理器，然后又将它们插入台式机，笔记本电脑和服务器机架的外壳中，那么现在这套系统已经被内置在手机，游戏机，监控摄像头中的各种尺寸的各种芯片所扩展。智能“家电等 更不用说量子计算机。
但是，由于RPSE的一般性，它适用于上面列出的所有领域。
关于某种范例，今天还能说些什么，是否可以以某种方式更准确地勾勒出其轮廓？
在试图给出范式的主要定义之后，下一步的改进是尝试列出其影响的现象的主要类别。 回顾Kuhn的定义，我们需要尝试列出RPSE引入和使用的模型的类型。
RPSE模型可以分为三个主要类别：
- 心理模型
- 用程序设计语言或其等效代码作为可执行代码的模型。
- 中间模型。
在这个三合会中，最少探讨的是心理模型。 它们到底是什么意思？
心智模型是指在过程中的客户，程序员和其他参与者的脑海中存在的思想的术语，在此基础上最终出现了可执行代码。 这样的模型的存在是无可争辩的，并且可以例如由程序员本人在心理层面上进行注册。 .
. , . , «», .
. :
:
:
«» ?
«» , :
。
, [2], , , . . 这里是主要的：
- .
- / vs. / .
- .
- , .
- .
:
- : ) . ) . )
- .
结论
. ( ) . - , , .
, , . , , .
. .
文学作品
1. IEEE Standard Glossary of Software Engineering Terminology, IEEE std 610.12-1990, 1990.
2. Kuhn, Thomas S. The Structure of Scientific Revolutions. 3rd ed. Chicago, IL: University of Chicago Press, 1996.
3. Programming paradigm:
en.wikipedia.org/wiki/Programming_paradigm (state — 27.08.2018)
4. Peter A. Henning, Holger Vogelsang Taschenbuch Programmiersprachen. Carl Hanser Verlag GmbH & Co. KG; Auflage: 2., neu bearbeitete (5. September 2007). ISBN-13: 978-3446407442.
5. Software Engineering Paradigms And Models Information Technology Essay
www.uniassignment.com/essay-samples/information-technology/software-engineering-paradigms-and-models-information-technology-essay.php (state — 27.08.2018)
6. Reification (computer science)
en.wikipedia.org/wiki/Reification_ (computer_science) (state — 27.08.2018)
7. . Silentium! ( (.), 1829 .
8. Borovik, Alexandre. Mathematics under the microscope: notes on cognitive aspects of mathematical practice. American Mathematical Society. ISBN-13: 978-0821847619.
:
geralt