范围：CPU可以识别的代码和数据。 所有代码的总和。 要求：根据定义进行设计。 完整性，从头开始彻底定义整个设计。 这是因为软件的柔软性和硬件平台的多样性和特殊性。 完整的把握和从头开始设计是第一原则。 因为软件世界本身无法统一，而且有持续分化的趋势。 没有根本一致的基础可能是软件的本质。 回到无状态是处理软件问题的基础。 从这个角度来说，操作系统只是一个部分，一个模块，你可以选择不同的操作系统； 语言的选择就是运行环境的选择（每种语言都有自己的运行时布局）； 所谓框架只是一个“类”“库+运行环境”的结构。 这些东西（操作系统、语言、框架）在没有评估其负载能力和运行强度之前是不能纳入设计规范的。 性能：运行过程的收敛性（长时间运行的同质性）。 运算强度设计（串行处理速度）、负载能力设计（并发处理量）。 专为可靠性而设计。 软件问题三个方面： 1. 硬件、软件运行对象和运行软件的数字系统（CPU系统和数字加速硬件） 2. 交互（界面）、专业的界面设计 3. 软件调度性能、实时自动化流程（设备控制和自动测量）和用户交互过程（请求服务过程和干预过程；本地交互和远程交互）、程序控制和网络访问（服务器）的调度。 软件项目的三个部分：（纵向和横向翻译三个阶段以实现整体协调）分解文档、集成平台和可维护性需求。
软件设计必须是自文档化的。 不能依赖文档。 在软件代码中适当的情况下，需要适当地记录文档。 原则是每一段代码、每一个需要理解的地方，如果与整体架构相关，就必须解释清楚。 软件世界需要简化。 需要恢复软件原来的外观。 EDA有溢出的倾向，软件的各个方面都需要简化。 软件形态、需求分析、文档、开发工具等。过分强调适应生命周期变化的需求分析与没有需求分析是一样的。 不切实际的面向未来的需求架构的直接结果是软件复杂且错误丛生。 只有一种软件，却有多种观察视角。 使用最合适的视角，让软件一目了然。 软件生成过程和观察过程是两个不同的概念。 生成过程可分为：研究过程和工程过程。 研究过程可以通过结果和研究报告来体现； 工程过程必须按过程来描述。 软件规范所使用的语言必须具有通用语义，但描述本身是特定的； 不能强迫它具有全球唯一性。 你必须放眼全局才能选择正确的立足点，这需要了解当前的软件技术； 为了考虑纳入新的发展，规范应分层以区分一般和特定的挥发性成分； 具有具体的指导意义。 越具体，指导意义越大，但普遍性越差。 所谓的架构可能是一个非常具体的应用的代表； 不同类型的应用程序必须有不同的架构。 软件架构本身就是“应用程序架构”。
因此无法指定具体的架构。 可以做到：应用架构规范的规范。 逻辑架构的特殊性。 可以判断，任何实际软件所采用的软件逻辑抽象都是不同的、特例逻辑。 不然软件不可能这么轻巧实用。 软件逻辑是一个幽灵。 需求分析必须是现实的、实用的，而不是同构/模拟——这似乎是反对象分析。 因为这里强调的是与软件的交互界面，这个界面远远不能反映现实世界的结构。 需要注意的是，该软件强调数据处理和输入输出。 否则，就无法实现最低限度的简化。 也许最适合现实世界结构映射的方式是数据库——使用纯数据结构进行映射。 另外，有没有更合适的技术？ 是面向对象建模吗？ 那么对象如何与现实世界的对象联系起来呢？ 这再次说明软件技术与需求分析之间存在差距。 软件技术作为一门特殊技术为企业设计软件问题，有其局限性。 这也反映了包括软件应用在内的真实架构已经固定。 如果软件是数据处理和输入输出，那么软件结构就可以确定了！ 可视化和用户界面解锁了另一个软件世界，因为可视化可以为用户代表更抽象的逻辑。 用户希望像操作真实物体一样操作视觉对象。 软件从模拟现实生活对象的过程中继承了其结构。 工业控制也开辟了软件的新天地，因为软件需要从单独的输入中构建“集成感知”，感知设备的状态，然后做出响应。
软件具有固有的物理属性，即计算量。 在算法领域，无论算法的论证多么曲折，得到的结果总是“已经熟悉”的软件。 这种区别是定义软件规范的基石。 算法构建领域与软件领域完全不同。 算法不是软件。 算法类似于数学系统。 也像数学系统一样多样化。 软件建设。 算法总是要转化为软件，这是一个软件构建问题。 寻址系统，数组。 软件将自己的一代视为问题，为算法开辟了新的领域。 软件生成是一个“构造-编译”问题。 手动构建，自动编译。 语言的发展是一段由软件产生的历史。 所谓统一建模、所谓设计模式，其实都是软件产生的问题。 需求分析。 需求分析本质上是独立的。 所谓的OOA，即面向对象建模，将程序构建的概念提升到需求分析领域可能是错误的。 先验的、复杂的、难以掌握的限制只会阻碍人们进行需求分析； 即使勉强掌握，也很难在需求分析中实现创造性的发展。 需求分析要聚焦于需求分析本身，独立开发，都是为了分析准确、快速。 需求分析层次更高、更抽象、更自由，从而能够充分表达需求的本质。 相反，它可以促进更高级别程序的自动生成。 软件生成历史记录。 软件的产生是为了解决人机交流，让“计算机语言”更接近普通人的思维逻辑。 将这种“高级计算机语言”翻译成可执行代码就是软件生成（代码生成）的任务。
软件编译是专业人士的事情，所以语言问题的本质其实并不那么重要。 请注意，通过训练，莫尔斯电码的发送速度可以比语音速度更快！ 因此，计算机语言的未来是迷茫的； 事实上，确实很困惑。 历史上层出不穷的语言本身就说明了这个问题，今天仍然如此。 今天，有必要树立这样一个观点：语言因人而异； 面对一门语言，我们必须头脑清醒，首先明确“这门语言是为谁而设计的”； 也就是说，需求分析之前的需求是确定谁将设计软件，然后为他们选择合适的语言。 除了代码生成之外，软件生成还包括另一个含义：软件构建。 这已经在前面讨论过。 然而，这里的软件构造机制已经在语言中建立起来了。 手工软件构建只是语言给出的构建机制的应用。 手工软件构建是对语言构建机制的复制，产生大量代码来应对大量的实际问题。 三维结构。 这里还存在一个三维问题。 实际问题的结构可能会产生三维结构，就像一座建筑物，基本构件组装起来形成复杂的三维结构。 这是建筑师的作品。 也许我们目前在语言层面上混乱的关键也在这里，没有责任区分语言和三维构造。 一种趋势是语言本身试图压倒架构师。 隔离三维结构的问题是结构本身必须能够证明它是正确的。 1）能制作软件 2）结构逻辑正确，确实能解决应用问题。
该构造本身具有通用的属性。 基本原则是普遍适用的； 整体结构本身是笼统的，即抽象的、与实际问题无关的； 本地组件是通用的。 也就是说集装箱和容量是有区别的。 结构是容器，实际问题是容器中所装的数量。 一个好的容器必须能够承受容量的压力； 一个好的建筑结构必须能够满足荷载和抗振要求。 架构本身的承受能力是客观的，只与架构本身有关。 也就是说，建筑本身构成了它自己，因此也是科学。 也许软件建设本身就是一项澄清问题的工作，明确“能力”的特征，为软件建设的选择提供准确的依据。 不要以靶心杀鸡。 实际问题的“容量”很容易测量，因为它将流程的流程反映为应用程序的大小。 （什么是架构？架构存在吗？如果我们说的不是虚拟的，那么架构怎么定义——一定是具体业务流程和模式支撑的架构） 软件（算法）的结构。 一是数据的复杂性（内在的相互关系），二是计算方法（步骤和缓冲区）。 从宏观角度来看，数据关系更为基础。 目前的高级语言主要研究变量和过程（序列、分支步骤、循环缓冲区和迭代），但对数据复杂性的构建还不够。 同构现象。 CPU指令集可以说是由硬件直接实现的软件。 软件帝国从这里提取软件精神并升华。 从硬件角度来看，寄存器和指令执行流程体现的是变量和迭代（顺序改变、来回循环）。
（迭代过程）基于固定的寻址变量，可以通过寻址接口处理任何数据，从而将迭代过程变成通用过程。 CPU的基本过程是产生指令和数据。 指令天生带有子程序（一般过程）的基因，数据天生带有数据结构（寻址能力）的基因。 高级结构一般都类似于这种结构：设计一套类似CPU的机制来支持程序和数据； 独特的“寻址机制”和“CPU处理能力”是实现该结构的核心机制； 迭代就是所有这样的机制动力学和结构。 数据化是“寻址机制”的基础。 抽象是数据的工厂，所以必须研究抽象技术。 抽象技术。 所谓抽象，就是具体化，就是范围的定义和比较（两个具体对象之间的比较）。 如果范围定义完整，那么通过比较建立的联系就是普遍联系，而普遍联系就是所谓的抽象原理。 评价标准。 需要评估软件架构。 这种评价就像是“生意谈资”的评价。 评估的基础是软件架构的具体化。 当掌握了建筑的构建方法后，每一个建筑本身就变得具体，是一个具体的建筑。 可以识别混凝土结构； 如果可以识别，就可以客观评价。 可以根据三维结构的“压力”和“流量”的概念来进行评价。 把握需求——需求的变化。 我们想要不变的需求、核心需求和需求模式（表达和满足它们的步骤）； 但事实上需求总是在变化的。 软件必须无条件地促进需求的表达并最大程度地满足需求。
软件可能永远只是皮肤。 需求来自于现实的核心。 软件是一件衣服。 从这个角度来看，软件是一个没有中心的架构。 软件架构和需求之间联系的定量评估。 软件和算法的分离 软件的构建是软件一般属性要求的独立推论：算法是应用算法。 例如，数学公式的计算、图形图像的处理、谱分析、词法和句法分析。 因此该算法不是通用的软件算法。 因此，软件构建是软件规范的一部分，因为它是一种通用的软件构建技术。 计算技术和应用程序之间有明显的区别，它们是两个不同的组成部分。 软件规范是纯粹的，只涉及计算技术。 不关心应用程序建模。 计算方法本身已经被发现了（即如何自动计算，或者什么是可计算的），剩下的问题只是应用问题。 将应用程序问题解决集成到软件计算模型中。 汇编指令集中说明了自动计算技术。 所谓软件设计就是要推广这种计算方法。 所谓算法就是把问题弄清楚，然后找到一种自动计算的方法来解决问题。 从这个意义上说，软件是面向应用问题的。 因此，这意味着以以问题为中心的方式谈论软件。 不同类型的问题需要对解决方案有不同的重视。 这也体现在所谓的软件技术不同上。 因此，区分软件计算技术和应用问题的组成部分是软件规范首先需要识别的事情。 解决这个问题。 本质上就是一个将问题加载到变量中的过程，也是一个CPU寄存器放大的过程。
表现层：（需要在一个世界中定义情境、环境、起点和终点）并组织起来。 计算层（展开层）：基于表示，定义解决问题的步骤（定义运动和过程）。 需求分析。 用于描述问题的方法可能应该与软件算法完全分开。 否则，就找不到创造性的方法来描述问题，也无法表达问题的本质。 我们有一定的解释问题和写文章的布局方法； 我们有严格的逻辑方法来进行哲学研究。 需求分析，我们当然可以创建我们自己的方法。 这是什么方法呢？ 满足使用要求和使用流程。 离散/隔离个人需求。 事实上，外部导向的分析理解和内部导向的分析理解之间存在着鸿沟。 因为这是两个不同的世界。 在如此不同的两个世界之间，建造的建筑必然是多种多样的，奇怪的就是平凡的。 嗯，建立联系的媒介很少。 也许问题本身就出在这个连接的分析和设计上。 软件的数量是静态的。 强调这部分就忽略了活跃的、奇怪的、动态的部分。 软件的出现不仅被动地适应了显示需求，而且本身也改变了实际需求。 这种与实际需求相结合的状态是软件的活跃部分。 过去，仅仅提及“应用软件”是不够的。 （操作系统、编译软件、应用软件）从范围上分为三个层次，或者说三类： 1、活跃和粘性动态层次。 应用层。 它与现实之间的接口是设备逻辑。 需求简化，解决方案单一； 应用算法的专业性。
这是软件映像中最活跃的部分。 这里采用的是抽象（业务流程）与具体（设备能力）统一的思维方法。 同时可以具体描述逻辑软件流程； 动态和物理分析方法（物理量）。 业务流程的设计几乎就像艺术设计一样。 2.中间层。 程序构建层。 语言、编译技术、数据结构、设计方法（过程、数据、对象）和其他可以形式化的计算机科学任务。 抽象程序能力并设计自动程序生成系统：语言、计算系统和编译系统。 这是静态部分和活动部分之间的电平。 这里的概念：设计方法、主程序、程序流程（与应用层流程不是一一对应的）。 3.静态层。 软件体积、测量层。 程序构建过程中的所有差异都消失了。 这是软件的静态视图。 每个层都有自己的软件哲学、概念、流程和模型。 两层之间的对比凸显了不可调和的差异。 这也是所有关于软件的不成熟印象和抽象产生的地方。 在应用层，流程的抽象性和逻辑性更强。 虚部占据主要部分。 现实的服务需要根据设备的具体能力来构建。 3 个类别定义了“软件”和“程序”之间的区别。 第 1 层和第 3 层讨论“软件”，第 2 层讨论“程序”。 软件和程序的研究方式不同。 程序研究方法完备，但软件不完备。 程序开发应体现软件特性。
1）它是一个逻辑过程，是对整个过程和子过程的观察和验证程序。 2）在软件体量层面，软件规模、运行强度、稳定性指标均为自测程序。 第二阶段一定要有一个标准。 软件就像衣服，软件交付文档应该显示衣服是如何编织的。 （相对于需求，软件是衣服，不是核心；相对于硬件，软件是衣服，是一个包）要有理论解释。 建筑也是衣服的一个组成部分，类似于衣服的连接方式和模块集合的重心比较。 衣服是一种没有核心的结构。 软件也必须表现出这种特性。 无论如何，我们需要有观察软件的视角，无论一套软件基于什么理论。 什么是软件？ 描述是软件存在的形式（文本格式）。 软件必须是可执行的（这就是软件的严肃性，精确、定量）。 软件是异化的，一般异化为具体的和特殊的情况（概括抽象力量的最好方式）（没有完美满足需求的软件。与需求相比，软件只能满足固定的需求，而不能满足需求的变化，即一个软件总是具体的；从普遍中产生具体的思维方式，即构造方法；或者是通过磁力创造出来的。一个好的理论必须对人们有吸引力。真实的材料，就像磁铁一样；这也是建立在矛盾之中的现实方法，只要具体，一定能分析出潜在的矛盾和不完美。问题不仅在于分析和理解现实，而且在于能够构建现实；没有完美的现实，只有完美的理论科学研究。方法就是化繁为简。
工程的方法是“相似”，复制事物被发现时的状态，然后再现事物的性能。 本实施例中，软件和硬件工作方法的结果是一致的。 只是方向不同而已。 软件从一般到特殊； 硬件从具体入手，逐层构建系统。 硬件设计显然具有以技术和器件为核心的特点。 根据设备的特点进行外围设计。 在硬件领域，“具体”为上； 在软件领域，“具体”是最底层的。 ）具体说明：构成所有物质的电子、质子、中子都是圆形的，都是一样的，但由这些相同的东西组成的原子却有上百种不同。 数量和规模的每一次增加都会导致特异性的增加。 软件也是如此。 以下概念受到穆勇的质疑。 软件就像一座山，沟壑清晰。 （这个巨大的特殊性必然对应着需求的巨大特殊性）。 “软件以文本形式存在；软件以执行方式存在；软件以实例形式存在”，归根结底就是“软件是具体的”。 更底层的定义：软件与数据和逻辑相关（数据和逻辑是软件的基本语义）。 软件与流程（集成（数据的存储、数字化）和步骤（逻辑）相关；流程是步骤的遍历和数据的增减）。 执行的异化。 区分独立执行和整体执行的概念。 独立执行的代码称为模块，否则它只是一个“片段”。 独立性与数据完整性相关。 数据越大，非独立的代码片段越多，模块也越大。
模块独立性比整体执行所需的自由度更大，这意味着整体只使用部分模块的执行能力。 模块独立执行所获得的自由度应该是可测量的； 模块的执行设计应该获得更大的自由度； 自由度是模块可执行质量的评价指标。 对于设计的整体执行来说，自由度设计可能是设计过程中的主导方法。 它关系到对需求的全面、完整的理解以及需求的变化； 因此，自由度设计也是一种需求定位的设计。 软件的数量就是软件的能力。 这是理解软件如何解决问题的基础。 比如逻辑能力、计算能力、存储能力、成像能力等。软件是运行的，软件是自组织的，整个软件的每个环节都有自己的品质。 编译、操作系统、文件管理等方面都是由不同分工的软件来实现的。 需要构建功能级别的交互来考虑这种完整性。 显然各个部分都具有独立的完整性； 诚信与诚信的合作构成了一个整体系统。 因此，系统的完整性、长期性、稳定性不一定是必需的。 反过来，系统满足需求的快速性、对快速变化的适应能力、随实际变化的能力、潮起潮落特性、瞬态响应特性等可能更接近系统的本质。 这就像太极拳一样，需要在完美的氛围中练习。 软件功能是比代码更高层次的抽象。 也是构成软件内涵的基本语义。 “设备能力”的概念更为基础，可以统一所有其他能力； 它还可以作为以硬件为中心的概念的基础。
能力的获得在于“两点”。 就在于相互支持的接口，相互支持的两方具有相互的能力。 1. 在需求分析方面，我们总是在创造一套新的方法和语言。 最有效的需求分析是自然语言分析。 通过描述的形式，所有的理解都通过描述的形式在人们的头脑中被知晓。 也就是说，进入实际需求去了解需求、分析需求。 由于领域、术语和行业呈现习惯的不同，这个阶段差异很大。 2、第二是计算机的使用方式——计算机技术（外设、通讯以及计算机本身的硬件形式），试图设计合适的使用方法和硬件解决方案。 有使用环境、专业技术、成本、时间、个人习惯等原因。 这也是一个美妙的过程。 对本领域工作方法的熟悉、与外围设备相关的专业技术背景以及不拘一格的技术决定了这是一项体验型活动。 这就是计算机的使用方式。 3． 接下来，确定用户角色。 用户和位置是关联的。 使用地点是计算机使用方式的一部分。 这是一个沟通的过程，也是一个通过计算机辅助参与来改变相关领域习惯的问题。 4、然后，进入二元分析阶段：用户管理视角、目标函数视角、分析函数，完成两者之间的映射。 在此阶段，功能被量化。 功能量化。 职能与职能之间会出现模糊，并且会出现权力的转移。 这个阶段就是要充分考虑这些问题。 5、然后，进入传统的需求分析阶段。 计算架构和功能描述的规范分析。
用户界面规划（详细、规范级别）。 界面规划、功能、架构构成了具体的交互过程。 最后，将生成系统级文档。 运行实体和接口； 系统运行状态以及实体接口的输入输出规范。 6.然后，实体级程序构建阶段。 算法构建和程序构建。 宏观算法主要是从资源占用的角度来确定的。 这个阶段是程序文档阶段。 文档是现阶段的一个工具。 最终结果是程序模块的严格文档记录。 所有这些文件组合起来形成一个正在运行的流程。 这些记录在案的程序本身就是逻辑程序。 7、最后在编码阶段，根据模块文档的接口、资源、算法要求为企业设计软件问题，使用特定的语言编译代码。
