Get best of the week

OS Sivelkiriya: processus de développement logiciel

Bonjour, Habr.

Ce billet poursuit le cycle de publications sur le projet Sivelkiriya OS. Dans le premier article du cycle, une description générale du concept a été donnée, dans le second, il a été expliqué pourquoi il était nécessaire et sous quelle forme le produit pouvait voir la lumière, dans la troisième solution architecturale a été décrite la thèse. Étant donné que de nombreux commentateurs ont soulevé la question de la commodité du développement pour ce système d'exploitation, cet article est destiné à mettre en évidence ce sujet.

Processus de développement logiciel


Le processus de développement logiciel sous Sivelkiriya diffère de celui sous d'autres systèmes d'exploitation (Windows, Linux, Android, etc.), car les développeurs préparent dans tous les cas des composants communs, dont le cas d'utilisation spécifique est inconnu au moment du développement. En d'autres termes, le développement s'effectue comme si dans tous les cas les bibliothèques étaient développées et jamais les applications.

Aucun module ne peut assumer des fonctions inhabituelles. Aucun module ne peut strictement exiger ou supposer implicitement qu'il interagira avec exactement le module que le développeur a prévu ou avec lequel il a été testé pendant le développement. Ainsi, le module ne dépend évidemment pas de la version de tout autre module, ce qui évite le problème de l'enfer des dépendances. Nous soulignons une fois de plus que dans le cadre de Sivelkiriya, le paradigme des applications est rejeté, y compris en tant que programmes constitués d'un ensemble prédéfini de modules.

Dans ce cas, le module peut déterminer à travers quelles interfaces il interagit avec d'autres modules. En outre, il peut exiger et recommander que des tests spécifiques présentés dans le référentiel central soient passés pour le module de contrepartie. Le module n'est pas toujours requis pour utiliser la dernière version de chaque interface - il peut utiliser n'importe quelle version prise en charge, et le système d'exploitation est responsable d'apporter les versions.

En termes de langues et d'environnements, Sivelkiriya offre la même flexibilité que les autres systèmes d'exploitation. Un module peut contenir à la fois du code machine et du code octet ou du code interprété. De plus, pour différents types de code, différents exécuteurs sont utilisés, qui sont eux-mêmes des modules. Leur tâche est d'assurer l'exécution du code du module et le passage des appels et des données à travers ses frontières, ainsi que la mise en œuvre de la maintenance nécessaire (par exemple, la collecte des ordures). Grâce à cette approche, il est prévu de prendre en charge un grand nombre de langues (interprétées et compilées) et d'environnements. Dans le même temps, les restrictions définies par le système d'exploitation s'appliquent au module indépendamment de la langue et de la méthode de chargement, car tout exécuteur interagit finalement avec le système d'exploitation via des appels aux méthodes d'interface,dont les autorisations sont contrôlées de manière universelle.

Le concept de bibliothèques dynamiques à Sivelkiriya est presque complètement remplacé par le concept de modules. Les modules distribués conjointement peuvent, si nécessaire, transférer une partie du code vers la bibliothèque partagée, cependant, aucun autre module non inclus dans ce package ne pourra y accéder. Le problème de la recherche d'une bibliothèque partagée est également résolu par le fait que dans tous les cas, la bibliothèque exacte incluse dans le package est utilisée. Toute autre interaction avec le code commun se produit via un système de modules.

Organisation de l'interaction des développeurs


De toute évidence, cette structure du système d'exploitation nécessite une approche spéciale pour organiser l'interaction des développeurs de modules avec les développeurs du système d'exploitation: il serait très naïf de croire que les développeurs du système d'exploitation seront en mesure de composer un ensemble d'interfaces à la fois qui couvre toutes les futures manières d'utiliser des appareils exécutant ce système d'exploitation. . Au contraire, l'organisation de la compatibilité universelle nécessite une coopération bilatérale continue entre les développeurs du système d'exploitation, qui fournit des interfaces et des prototypes, et les développeurs du logiciel qui les utilise.

Chaque interface est caractérisée par un numéro de version composé de parties majeures et mineures. Avec une augmentation de la version mineure, l'interface peut être complétée par de nouvelles entités dans la même version plus ancienne, cependant, la suppression ou la modification d'entités existantes n'est pas autorisée. De nouvelles versions plus anciennes sont publiées lorsque l'interface nécessite un traitement approfondi.

Toutes les versions mineures dans une version principale sont compatibles les unes avec les autres. En cas de coïncidence de mise en œuvre effective par l'objet et attendue par les numéros de version mineurs du contexte appelant, une telle compatibilité est évidente. Si l'objet réellement utilisé implémente une version mineure de l'interface plus élevée que ce que le contexte appelant attend, alors certaines des données et fonctions fournies par l'interface ne sont tout simplement pas utilisées. Si l'objet implémente une version mineure inférieure à celle attendue, lors de l'accès à des entités qui ne sont pas réellement implémentées, des gestionnaires par défaut sont appelés, dont le travail est basé sur des données et des algorithmes déjà présentés dans une version antérieure de l'interface. Ainsi, si une version plus récente de l'interface "Article" ajoute aux données accessibles via l'interface le champ "Texte publicitaire", qui est utilisé dans certaines publications, par exemple,sur les bannières qui donnent accès au texte intégral de l'article, pour des raisons de compatibilité, le gestionnaire par défaut peut utiliser le premier paragraphe ou la première phrase du texte intégral comme tel. Une autre approche consiste à renvoyer des valeurs spéciales «non implémentées» (exceptions) lors de l'accès à des données inaccessibles, ce qui transfère la responsabilité du traitement de ces restrictions au contexte d'appel.

Les versions plus anciennes des interfaces peuvent être compatibles entre elles ou non. Par exemple, dans l'hypothèse de passer de la prise en compte de la position des points à l'écran en coordonnées cartésiennes à l'utilisation de coordonnées polaires, l'interface «Point Position 1.0» utilise des coordonnées cartésiennes, tandis que l'interface «Point Position 2.0» contient une représentation en coordonnées polaires. Puisqu'il existe une correspondance biunivoque entre ces deux représentations, le système d'exploitation peut toujours recalculer les coordonnées dans les cas où la version réelle de l'interface utilisée diffère de la version attendue.

Malheureusement, ce masquage du numéro de version réel n'est pas toujours possible. Par exemple, si l'interface «Melody» dans la version 1.0 décrit l'œuvre comme une partition et dans la version 2.0 comme un enregistrement audio, il n'y a pas de correspondance biunivoque entre eux: la même mélodie peut être jouée sur différents instruments, tandis que l'enregistrement peut contiennent des sons qui ne peuvent pas être exprimés sur une feuille de musique. De même, si l'interface «Note» a été initialement conçue pour le contenu textuel puis adaptée pour l'écriture manuscrite, la traduction de l'une en l'autre sera difficile: une note manuscrite peut contenir des images, tandis que des caractères cachés (par exemple, doux transferts). Enfin, les plans de villes sont traditionnellement représentés en deux dimensions,cependant, pour les mégapoles avec des échanges à plusieurs niveaux, cela devient de plus en plus insuffisant; si à l'avenir une transition est faite de cartes bidimensionnelles vers des cartes tridimensionnelles, passer de l'une à l'autre ne sera pas si facile.

Des règles similaires s'appliquent lors du changement de versions prototypes de modules. Étant donné que la tâche principale du module est de mettre en œuvre des interfaces de données, nous ne nous attarderons pas sur cela plus en détail.

La distribution des interfaces est centralisée via un référentiel supporté par une équipe de développeurs du système d'exploitation. De nouvelles versions sont chargées lorsque le système d'exploitation est mis à jour. L'existence d'autres référentiels qui distribuent des interfaces n'est pas autorisée, car elle mettra fin à la compatibilité universelle, qui est l'objectif principal de la création du système d'exploitation Sivelkiriya. La seule exception peut être les référentiels intra-entreprise, utilisés dans les cas où le fait du développement de certaines interfaces est un secret commercial. De telles interfaces, cependant, ne peuvent aller au-delà des entreprises qui les utilisent pour leur travail interne.

La distribution des modules est possible à la fois via le référentiel pris en charge par l'équipe de développement du système d'exploitation et via des référentiels pris en charge par des tiers (éditeurs de logiciels commerciaux, communautés open source, serveurs d'entreprise, etc.). Dans le même temps, le référentiel central, soutenu par l'équipe de développement du système d'exploitation, se positionne comme le principal, car il fournit des services uniques.

Ainsi, lors du chargement de nouvelles versions de modules dans le référentiel, ils sont testés à l'aide d'une bibliothèque remplie de tests d'intégration et de tests unitaires, ainsi que de tests de performances. Les informations sur la réussite de ces tests deviennent accessibles aux développeurs et aux utilisateurs. Lors de l'ajout de nouveaux tests, ils s'appliquent également aux anciennes versions des modules présents dans le référentiel. Tous les tests fournis par le référentiel central sont disponibles pour tous les développeurs pour une utilisation à la fois à l'intérieur et sur leur propre infrastructure; la seule exception s'oppose à l'optimisation des modules pour des tests spécifiques au détriment de l'utilisation dans un contexte général.

En outre, le référentiel central collecte des informations sur tous les modules disponibles dans d'autres référentiels ouverts et les teste chaque fois que possible, bien que le téléchargement de ces modules ne soit toujours disponible que depuis les référentiels qui les ont hébergés. Cela permet aux utilisateurs d'avoir toutes les informations sur les modules disponibles en un seul endroit et aux développeurs de logiciels d'obtenir une promotion supplémentaire de leurs propres référentiels (magasins).

Enfin, le référentiel central permet d'arbitrer dans les cas litigieux (par exemple, lors de la distribution de logiciels sans licence à des tiers). La création d'un référentiel tiers est impossible sans enregistrement dans un référentiel central (y compris les référentiels intracorporatifs); l'équipe de support du référentiel central a l'autorité et la capacité de bloquer les contrevenants aux règles (pirates, pirates, développeurs de logiciels à architecture fermée) à la fois au niveau des modules individuels et au niveau des référentiels tiers entiers.

Les articles précédents de la série sont disponibles ici: un , deux , trois . Le texte intégral, comme précédemment, est disponible sur le site Web du projet .

More articles:


All Articles