Get best of the week

OS Sivelkiriya：软件开发过程

哈Ha

这篇文章继续了有关Sivelkiriya OS项目的出版物发行周期。在该周期的第一篇文章中，对该概念进行了一般性描述，在第二篇文章中，解释了为什么有必要使用该概念，以及该产品以什么形式可以看到光线，在第三篇建筑解决方案中描述了论文。由于许多评论员提出了此OS开发便利性的问题，因此本文旨在重点介绍该主题。

软件开发过程


Sivelkiriya下的软件开发过程与其他OS（Windows，Linux，Android等）下的软件开发过程不同，因为开发人员在所有情况下都准备了通用组件，在开发时尚不知道其具体用例。换句话说，开发就像在所有情况下都开发了库而不开发应用程序一样。

任何模块都不能承担异常功能。任何模块都不能严格要求或隐含地假定它将与开发人员想要的模块或在开发过程中与他进行测试的模块完全交互。因此，该模块显然不依赖于任何其他模块的版本，从而避免了依赖地狱的问题。我们再次强调，在Sivelkiriya的框架内，应用程序的范式被拒绝，包括作为包含一组预定义模块的程序。

在这种情况下，模块可以确定通过哪个接口与其他模块进行交互。另外，它可能要求并建议通过交易对手模块的中央存储库中提供的特定测试。并非总是要求该模块使用每个接口的最新版本-它可以使用任何受支持的版本，并且操作系统负责提供这些版本。

在语言和环境方面，Sivelkiriya提供与其他操作系统相同的灵活性。一个模块可以同时包含机器代码和字节代码或解释代码。此外，对于不同类型的代码，使用了不同的执行程序，它们本身就是模块。他们的任务是确保模块代码的执行以及跨越其边界的调用和数据的传递，以及实现必要的维护（例如，垃圾回收）。由于采用了这种方法，因此计划支持多种语言（解释和编译）和环境。同时，由操作系统设置的限制适用于模块，而与加载的语言和方法无关，因为任何执行程序最终都会通过调用接口方法与操作系统进行交互，以通用方式控制其权限。

Sivelkiriya中的动态库的概念几乎完全被模块的概念所取代。如有必要，联合分发的模块可以将部分代码传输到共享库，但是，此包中未包含的其他模块将无法访问它。查找共享库的问题还可以通过以下事实解决：在所有情况下，都使用软件包中包含的确切库。与通用代码的任何其他交互都通过模块系统发生。

开发人员互动的组织


显然，操作系统的这种结构需要一种特殊的方法来组织模块开发人员与操作系统的开发人员之间的互动：最天真的是，相信操作系统的开发人员能够一次构成一组接口，涵盖了将来所有使用运行此OS的设备的方式。 。相反，通用兼容性的组织要求提供接口和原型的OS开发人员与使用它们的软件开发人员之间进行持续的双边合作。

每个接口的特征是由主要和次要部分组成的版本号。随着次要版本的增加，可以在相同的旧版本中用新的实体来补充接口，但是，不允许删除或更改现有的实体。当接口需要深度处理时，将发布新的较旧版本。

一个主要版本中的所有次要版本彼此兼容。在对象实际实现和调用上下文次要版本号预期一致的情况下，这种兼容性是显而易见的。如果实际使用的对象实现的接口版本低于调用上下文所期望的版本，则根本不使用该接口提供的某些数据和功能。如果对象实现的副版本低于预期的副版本，则在访问未实际实现的实体时，将调用默认处理程序，默认处理程序的工作基于接口的早期版本中已经提供的数据和算法。因此，如果“ Article”界面的较新版本在可通过该界面访问的数据中添加了“ Advertising text”字段，例如，在某些出版物中，在可以访问文章全文的横幅上，为了兼容起见，默认处理程序可以将全文的第一段或第一句用作此类文本。另一种方法是在访问不可访问的数据时返回``未实现''的特殊值（异常），这将处理此类限制的责任转移到了调用上下文中。

较旧版本的接口可以彼此兼容，也可以不兼容。例如，在从考虑屏幕上的点在笛卡尔坐标中的位置移动到使用极坐标的假设情况下，“点位置1.0”界面使用笛卡尔坐标，而“点位置2.0”界面包含极坐标表示。由于这两种表示形式之间存在一一对应的关系，因此当所使用的接口的实际版本与预期的不同时，操作系统始终可以重新计算坐标。

不幸的是，这种掩盖实际版本号并不总是可能的。例如，如果版本1.0中的“旋律”界面将乐曲描述为乐谱，而版本2.0中将其描述为录音，则它们之间就没有一对一的对应关系：同一旋律可以在不同的乐器上演奏，而录音可以包含无法在乐谱上表达的声音。同样，如果“注释”界面最初是为文本内容设计的，然后又适合手写，那么将其转换为另一种语言将很困难：手写注释可能包含图片，而隐藏字符（例如软字体）转移）。最后，传统上以二维方式描绘城市地图，但是，对于具有多层次交换的特大城市，这已变得越来越不够。如果将来要从二维卡过渡到三维卡，那么从一个卡转换到另一个卡将不是那么容易。

更改模块的原型版本时，适用类似的规则。由于模块的主要任务是实现数据接口，因此我们将不对其进行详细介绍。

接口的分发通过操作系统开发人员团队支持的存储库进行集中管理。更新操作系统时，将加载新版本。不允许存在其他用于分发接口的存储库，因为这将终止通用兼容性，这是创建Sivelkiriya OS的主要目标。唯一的例外可能是公司内部存储库，用于某些接口开发的事实是商业秘密的情况。但是，此类接口不能超出将其用于内部工作的公司。

既可以通过操作系统开发团队支持的存储库，也可以通过第三方（商业软件公司，开源社区，公司服务器等）支持的存储库来分发模块。同时，由OS开发团队支持的中央存储库被定位为主要存储库，因为它提供了一些独特的服务。

因此，在将新版本的模块加载到存储库中时，将使用补充的集成库，单元测试以及性能测试来测试它们。开发人员和用户均可获得通过此类测试的信息。添加新测试时，它们也适用于存储库中存在的模块的较旧版本。中央存储库提供的所有测试可供所有开发人员在其内部以及在其自己的基础结构上使用；唯一的例外是反对针对特定测试的模块优化，这不利于在一般情况下使用。

此外，中央存储库会收集有关其他打开的存储库中可用的所有模块的信息，并在可能的情况下进行测试，尽管仍然只能从托管它们的存储库中下载此类模块。这样一来，用户就可以将有关可用模块的所有信息集中在一个地方，而软件开发人员则可以进一步推广自己的存储库（商店）。

最后，中央存储库可帮助在有争议的情况下进行仲裁（例如，在将未经许可的软件分发给第三方时）。如果没有在中央存储库（包括公司内部存储库）中注册，则无法创建第三方存储库；中央存储库的支持团队有权阻止单个模块级别和整个第三方存储库级别的违反规则的用户（海盗，黑客，具有封闭式体系结构的软件开发人员）。

该系列中的先前文章可在此处找到：一，二，三。与以前一样，全文可在项目网站上找到。

More articles:


All Articles