Get best of the week

OS Sivelkiriya: proceso de desarrollo de software

Hola Habr

Esta publicación continúa el ciclo de publicaciones sobre el proyecto Sivelkiriya OS. En el primer artículo del ciclo, se dio una descripción general del concepto, en el segundo se explicó por qué era necesario y de qué forma el producto podía ver la luz, en la tercera tesis se describieron soluciones arquitectónicas. Dado que muchos comentaristas han planteado la cuestión de la conveniencia de desarrollo para este sistema operativo, este artículo pretende resaltar este tema.

Proceso de desarrollo de software


El proceso de desarrollo de software en Sivelkiriya difiere del de otros sistemas operativos (Windows, Linux, Android, etc.), ya que los desarrolladores en todos los casos preparan componentes comunes, cuyo caso de uso específico es desconocido en el momento del desarrollo. En otras palabras, el desarrollo se lleva a cabo como si en todos los casos se desarrollaran bibliotecas y nunca aplicaciones.

Ningún módulo puede asumir funciones inusuales. Ningún módulo puede exigir estrictamente o suponer implícitamente que interactuará específicamente con el módulo que el desarrollador pretendía o con el que fue probado durante el desarrollo. Por lo tanto, el módulo obviamente no depende de la versión de ningún otro módulo, lo que evita el problema del infierno de dependencia. Una vez más, enfatizamos que dentro del marco de Sivelkiriya, el paradigma de las aplicaciones es rechazado, incluso como programas que consisten en un conjunto predefinido de módulos.

En este caso, el módulo puede determinar a través de qué interfaces interactúa con otros módulos. Además, puede requerir y recomendar que se pasen pruebas específicas presentadas en el repositorio central para el módulo de contraparte. No siempre se requiere que el módulo use la última versión de cada interfaz; puede usar cualquier versión compatible, y el sistema operativo es responsable de traer las versiones.

En términos de idiomas y entornos, Sivelkiriya ofrece la misma flexibilidad que otros sistemas operativos. Un módulo puede contener tanto código de máquina como código de byte o código interpretado. Además, para diferentes tipos de código, se utilizan diferentes ejecutores, que a su vez son módulos. Su tarea es garantizar la ejecución del código del módulo y el paso de llamadas y datos a través de sus límites, así como la implementación del mantenimiento necesario (por ejemplo, recolección de basura). Gracias a este enfoque, está previsto admitir una gran cantidad de idiomas (tanto interpretados como compilados) y entornos. Al mismo tiempo, las restricciones establecidas por el sistema operativo se aplican al módulo independientemente del idioma y método de carga, ya que cualquier ejecutor en última instancia interactúa con el sistema operativo a través de llamadas a métodos de interfaz,permisos para los cuales se controlan de manera universal.

El concepto de bibliotecas dinámicas en Sivelkiriya se reemplaza casi por completo por el concepto de módulos. Los módulos distribuidos conjuntamente pueden, si es necesario, transferir parte del código a la biblioteca compartida, sin embargo, ningún otro módulo que no esté incluido en este paquete podrá acceder a él. El problema de encontrar una biblioteca compartida también se resuelve por el hecho de que en todos los casos se utiliza la biblioteca exacta que se incluye en el paquete. Cualquier otra interacción con el código común ocurre a través de un sistema de módulos.

Organización de la interacción de los desarrolladores.


Obviamente, esta estructura del sistema operativo requiere un enfoque especial para organizar la interacción de los desarrolladores de módulos con los desarrolladores del sistema operativo: sería muy ingenuo creer que los desarrolladores del sistema operativo podrán compilar un conjunto de interfaces a la vez que cubra todas las formas futuras de usar dispositivos que ejecutan este sistema operativo . Por el contrario, la organización de la compatibilidad universal requiere una cooperación bilateral continua entre los desarrolladores del sistema operativo, que proporciona interfaces y prototipos, y los desarrolladores del software que los utiliza.

Cada interfaz se caracteriza por un número de versión que consta de partes principales y secundarias. Con un aumento en la versión menor, la interfaz puede complementarse con nuevas entidades dentro de la misma versión anterior, sin embargo, no se permite la eliminación o alteración de entidades existentes. Se lanzan nuevas versiones anteriores cuando la interfaz requiere un procesamiento profundo.

Todas las versiones menores dentro de una versión principal son compatibles entre sí. En caso de coincidencia implementada realmente por el objeto y esperada por los números de versión menores del contexto de llamada, dicha compatibilidad es obvia. Si el objeto realmente utilizado implementa una versión menor de la interfaz más alta de lo que el contexto de llamada espera, entonces algunos de los datos y funciones provistos por la interfaz simplemente no se usan. Si el objeto implementa una versión menor inferior a la esperada, al acceder a entidades que no se implementan realmente, se llama a los controladores predeterminados, cuyo trabajo se basa en datos y algoritmos ya presentados en una versión anterior de la interfaz. Por lo tanto, si una versión posterior más joven de la interfaz "Artículo" agrega a los datos accesibles a través de la interfaz el campo "Texto publicitario", que se utiliza en algunas publicaciones, por ejemplo,en pancartas que proporcionan acceso al texto completo del artículo, por compatibilidad, el controlador predeterminado puede usar el primer párrafo o la primera oración del texto completo como tal texto. Otro enfoque es devolver valores especiales "No implementados" (excepciones) al acceder a datos inaccesibles, lo que desplaza la responsabilidad de procesar dichas restricciones al contexto de la llamada.

Las versiones anteriores de las interfaces pueden ser compatibles entre sí o no. Por ejemplo, en el caso hipotético de pasar de considerar la posición de los puntos en la pantalla en coordenadas cartesianas a usar coordenadas polares, la interfaz "Point Position 1.0" usa coordenadas cartesianas, mientras que la interfaz "Point Position 2.0" contiene una representación en coordenadas polares. Dado que existe una correspondencia uno a uno entre estas dos representaciones, el sistema operativo siempre puede recalcular las coordenadas en los casos en que la versión real de la interfaz utilizada difiere de la esperada.

Desafortunadamente, este enmascaramiento del número de versión real no siempre es posible. Por ejemplo, si la interfaz "Melody" en la versión 1.0 describe el trabajo como una partitura, y en la versión 2.0 como una grabación de audio, entonces no hay correspondencia uno a uno entre ellos: la misma melodía se puede reproducir en diferentes instrumentos, mientras que la grabación puede contienen sonidos que no se pueden expresar en una partitura musical. Del mismo modo, si la interfaz "Nota" se diseñó originalmente para contenido textual y luego se adaptó para escribir a mano, será difícil traducir una a otra: una nota escrita a mano puede contener imágenes, mientras que los caracteres ocultos (por ejemplo, suaves) transferencias). Finalmente, los mapas de la ciudad se representan tradicionalmente en dos dimensiones,sin embargo, para las megaciudades con intercambios multinivel, esto se vuelve cada vez más insuficiente; Si en el futuro se realiza una transición de tarjetas bidimensionales a tridimensionales, pasar de una a la otra no será tan fácil.

Se aplican reglas similares al cambiar las versiones prototipo de los módulos. Dado que la tarea principal del módulo es implementar interfaces de datos, no nos detendremos en esto con más detalle.

La distribución de interfaces se centraliza a través de un repositorio respaldado por un equipo de desarrolladores del sistema operativo. Las nuevas versiones se cargan cuando se actualiza el sistema operativo. No está permitida la existencia de otros repositorios que distribuyan interfaces, ya que pondrá fin a la compatibilidad universal, que es el objetivo principal de crear el sistema operativo Sivelkiriya. La única excepción pueden ser los repositorios intra-corporativos, utilizados en casos donde el hecho del desarrollo de algunas interfaces es un secreto comercial. Tales interfaces, sin embargo, no pueden ir más allá de las empresas que las utilizan para su trabajo interno.

La distribución de los módulos es posible tanto a través del repositorio respaldado por el equipo de desarrollo del sistema operativo como a través de repositorios respaldados por terceros (empresas de software comercial, comunidades de código abierto, servidores corporativos, etc.). Al mismo tiempo, el repositorio central, respaldado por el equipo de desarrollo del sistema operativo, se posiciona como el principal, ya que proporciona algunos servicios únicos.

Por lo tanto, cuando se cargan nuevas versiones de módulos en el repositorio, se prueban utilizando una biblioteca completa de integración y pruebas unitarias, así como pruebas de rendimiento. La información sobre cómo pasar tales pruebas está disponible tanto para desarrolladores como para usuarios. Al agregar nuevas pruebas, también se aplican a versiones anteriores de módulos presentes en el repositorio. Todas las pruebas proporcionadas por el repositorio central están disponibles para todos los desarrolladores para su uso tanto dentro como en su propia infraestructura; La única excepción es oponerse a la optimización de módulos para pruebas específicas en detrimento del uso en un contexto general.

Además, el repositorio central recopila información sobre todos los módulos disponibles en otros repositorios abiertos, y también los prueba siempre que sea posible, aunque la descarga de dichos módulos todavía está disponible solo desde los repositorios que los alojaron. Esto permite a los usuarios tener toda la información sobre los módulos disponibles en un solo lugar y a los desarrolladores de software obtener promociones adicionales de sus propios repositorios (tiendas).

Finalmente, el repositorio central ayuda a arbitrar en casos contenciosos (por ejemplo, cuando se distribuye software sin licencia a terceros). Crear un repositorio de terceros es imposible sin el registro en un repositorio central (incluidos los repositorios intracorporados); El equipo de soporte para el repositorio central tiene la autoridad y la capacidad de bloquear a los infractores de las reglas (piratas, piratas informáticos, desarrolladores de software con una arquitectura cerrada) tanto a nivel de módulos individuales como a nivel de repositorios de terceros completos.

Los artículos anteriores de la serie están disponibles aquí: uno , dos , tres . El texto completo, como antes, está disponible en el sitio web del proyecto .

More articles:


All Articles