Get best of the week

OS Sivelkiriya: Softwareentwicklungsprozess

Hallo Habr.

Dieser Beitrag setzt den Zyklus der Veröffentlichungen über das OS-Projekt Sivelkiriya fort. Im ersten Artikel des Zyklus wurde eine allgemeine Beschreibung des Konzepts gegeben, im zweiten wurde erklärt, warum es notwendig war und in welcher Form das Produkt das Licht sehen konnte, in der dritten wurden architektonische Lösungen beschrieben. Da viele Kommentatoren das Problem der Entwicklungsfreundlichkeit für dieses Betriebssystem angesprochen haben, soll dieser Artikel dieses Thema hervorheben.

Softwareentwicklungsprozess


Der Softwareentwicklungsprozess für Sivelkiriya unterscheidet sich von dem für andere Betriebssysteme (Windows, Linux, Android usw.), da Entwickler in allen Fällen gemeinsame Komponenten vorbereiten, deren spezifisches Verwendungsszenario zum Zeitpunkt der Entwicklung unbekannt ist. Mit anderen Worten, die Entwicklung erfolgt so, als ob in allen Fällen Bibliotheken entwickelt worden wären und niemals Anwendungen.

Kein Modul kann ungewöhnliche Funktionen übernehmen. Kein Modul kann strikt verlangen oder implizit davon ausgehen, dass es spezifisch mit dem Modul interagiert, das der Entwickler beabsichtigt hat oder mit dem er während der Entwicklung getestet wurde. Somit hängt das Modul offensichtlich nicht von der Version eines anderen Moduls ab, was das Problem der Abhängigkeitshölle verhindert. Wir betonen noch einmal, dass im Rahmen von Sivelkiriya das Paradigma der Anwendungen abgelehnt wird, auch als Programme, die aus einem vordefinierten Satz von Modulen bestehen.

In diesem Fall kann das Modul bestimmen, über welche Schnittstellen es mit anderen Modulen interagiert. Darüber hinaus kann es erforderlich und empfehlenswert sein, bestimmte im zentralen Repository präsentierte Tests für das Gegenparteimodul zu bestehen. Das Modul muss nicht immer die neueste Version jeder Schnittstelle verwenden - es kann jede unterstützte Version verwenden, und das Betriebssystem ist dafür verantwortlich, die Versionen zu bringen.

In Bezug auf Sprachen und Umgebungen bietet Sivelkiriya die gleiche Flexibilität wie andere Betriebssysteme. Ein Modul kann sowohl Maschinencode als auch Bytecode oder interpretierten Code enthalten. Darüber hinaus werden für verschiedene Codetypen verschiedene Ausführende verwendet, die selbst Module sind. Ihre Aufgabe ist es, die Ausführung des Modulcodes und die Weitergabe von Aufrufen und Daten über seine Grenzen hinweg sowie die Durchführung der erforderlichen Wartung (z. B. Garbage Collection) sicherzustellen. Dank dieses Ansatzes ist geplant, eine große Anzahl von Sprachen (sowohl interpretiert als auch kompiliert) und Umgebungen zu unterstützen. Gleichzeitig gelten die vom Betriebssystem festgelegten Einschränkungen für das Modul unabhängig von der Sprache und der Lademethode, da jeder Executor letztendlich über Aufrufe von Schnittstellenmethoden mit dem Betriebssystem interagiert.Berechtigungen, für die auf universelle Weise gesteuert wird.

Das Konzept der dynamischen Bibliotheken in Sivelkiriya wird fast vollständig durch das Konzept der Module ersetzt. Die gemeinsam verteilten Module können bei Bedarf einen Teil des Codes in die gemeinsam genutzte Bibliothek übertragen. Kein anderes Modul, das nicht in diesem Paket enthalten ist, kann jedoch darauf zugreifen. Das Problem, eine gemeinsam genutzte Bibliothek zu finden, wird auch dadurch gelöst, dass in allen Fällen die genaue Bibliothek verwendet wird, die im Paket enthalten ist. Alle anderen Interaktionen mit dem allgemeinen Code erfolgen über ein Modulsystem.

Organisation der Interaktion von Entwicklern


Offensichtlich erfordert diese Struktur des Betriebssystems einen speziellen Ansatz zur Organisation der Interaktion von Modulentwicklern mit den Entwicklern des Betriebssystems: Es wäre höchst naiv zu glauben, dass die Entwickler des Betriebssystems in der Lage sein werden, eine Reihe von Schnittstellen gleichzeitig zu erstellen, die alle zukünftigen Möglichkeiten der Verwendung von Geräten abdecken, auf denen dieses Betriebssystem ausgeführt wird . Im Gegenteil, die Organisation der universellen Kompatibilität erfordert eine kontinuierliche bilaterale Zusammenarbeit zwischen Entwicklern des Betriebssystems, das Schnittstellen und Prototypen bereitstellt, und Entwicklern der Software, die sie verwendet.

Jede Schnittstelle ist durch eine Versionsnummer gekennzeichnet, die aus Haupt- und Nebenteilen besteht. Mit einer Erhöhung der Nebenversion kann die Schnittstelle durch neue Entitäten innerhalb derselben älteren Version ergänzt werden. Das Löschen oder Ändern vorhandener Entitäten ist jedoch nicht zulässig. Neue ältere Versionen werden veröffentlicht, wenn die Schnittstelle eine gründliche Verarbeitung erfordert.

Alle Nebenversionen innerhalb einer Hauptversion sind miteinander kompatibel. Im Falle eines Zusammentreffens von tatsächlich vom Objekt implementierten und vom aufrufenden Kontext erwarteten Nebenversionsnummern ist eine solche Kompatibilität offensichtlich. Wenn das tatsächlich verwendete Objekt eine niedrigere Version der Schnittstelle implementiert, als der aufrufende Kontext erwartet, werden einige der von der Schnittstelle bereitgestellten Daten und Funktionen einfach nicht verwendet. Wenn das Objekt eine niedrigere Nebenversion als erwartet implementiert, werden beim Zugriff auf nicht tatsächlich implementierte Entitäten Standardhandler aufgerufen, deren Arbeit auf Daten und Algorithmen basiert, die bereits in einer früheren Version der Schnittstelle vorgestellt wurden. Wenn also eine spätere jüngere Version der Benutzeroberfläche "Artikel" zu den über die Benutzeroberfläche zugänglichen Daten das Feld "Werbetext" hinzufügt, das beispielsweise in einigen Veröffentlichungen verwendet wird, z.Bei Bannern, die aus Kompatibilitätsgründen Zugriff auf den vollständigen Text des Artikels bieten, kann der Standardhandler den ersten Absatz oder den ersten Satz des vollständigen Textes als solchen Text verwenden. Ein anderer Ansatz besteht darin, beim Zugriff auf unzugängliche Daten spezielle Werte (Ausnahmen) "Nicht implementiert" zurückzugeben, wodurch die Verantwortung für die Verarbeitung solcher Einschränkungen auf den aufrufenden Kontext verlagert wird.

Ältere Versionen von Schnittstellen können entweder miteinander kompatibel sein oder nicht. In dem hypothetischen Fall, dass von der Betrachtung der Position von Punkten auf dem Bildschirm in kartesischen Koordinaten zur Verwendung von Polarkoordinaten übergegangen wird, verwendet die Schnittstelle „Punktposition 1.0“ kartesische Koordinaten, während die Schnittstelle „Punktposition 2.0“ eine Darstellung in Polarkoordinaten enthält. Da zwischen diesen beiden Darstellungen eine Eins-zu-Eins-Entsprechung besteht, kann das Betriebssystem die Koordinaten immer dann neu berechnen, wenn die tatsächliche Version der verwendeten Schnittstelle von der erwarteten abweicht.

Leider ist diese Maskierung der tatsächlichen Versionsnummer nicht immer möglich. Wenn beispielsweise die „Melodie“ -Schnittstelle in Version 1.0 das Werk als Partitur und in Version 2.0 als Audioaufnahme beschreibt, besteht keine Eins-zu-Eins-Entsprechung zwischen ihnen: Dieselbe Melodie kann auf verschiedenen Instrumenten gespielt werden, während die Aufnahme dies kann enthalten Töne, die nicht auf einem Notenblatt ausgedrückt werden können. Wenn die Notizoberfläche ursprünglich für Textinhalte konzipiert und dann für die Handschrift angepasst wurde, ist es ebenfalls schwierig, eine in die andere zu übersetzen: Eine handschriftliche Notiz kann Bilder enthalten, während versteckte Zeichen (z. B. weich) vorhanden sind Transfers). Schließlich werden Stadtpläne traditionell in zwei Dimensionen dargestellt:Für Megastädte mit mehrstufigem Austausch wird dies jedoch zunehmend unzureichend. Wenn in Zukunft ein Übergang von zweidimensionalen zu dreidimensionalen Karten erfolgt, wird es nicht so einfach sein, von einer zur anderen zu gelangen.

Ähnliche Regeln gelten beim Ändern von Prototypversionen von Modulen. Da die Hauptaufgabe des Moduls darin besteht, Datenschnittstellen zu implementieren, werden wir nicht näher darauf eingehen.

Die Verteilung der Schnittstellen erfolgt zentral über ein Repository, das von einem Entwicklerteam des Betriebssystems unterstützt wird. Neue Versionen werden geladen, wenn das Betriebssystem aktualisiert wird. Die Existenz anderer Repositorys, die Schnittstellen verteilen, ist nicht zulässig, da dadurch die universelle Kompatibilität beendet wird, die das Hauptziel bei der Erstellung des Betriebssystems Sivelkiriya ist. Die einzige Ausnahme können unternehmensinterne Repositorys sein, die in Fällen verwendet werden, in denen die Entwicklung einiger Schnittstellen ein Geschäftsgeheimnis ist. Solche Schnittstellen können jedoch nicht über Unternehmen hinausgehen, die sie für ihre interne Arbeit verwenden.

Die Verteilung der Module ist sowohl über das vom Entwicklungsteam des Betriebssystems unterstützte Repository als auch über von Dritten unterstützte Repositorys (kommerzielle Softwareunternehmen, Open Source-Communities, Unternehmensserver usw.) möglich. Gleichzeitig wird das zentrale Repository, das vom OS-Entwicklungsteam unterstützt wird, als Haupt-Repository positioniert, da es einige einzigartige Dienste bereitstellt.

Wenn Sie also neue Versionen von Modulen in das Repository laden, werden diese mithilfe einer aufgefüllten Bibliothek mit Integrations- und Komponententests sowie Leistungstests getestet. Informationen zum Bestehen solcher Tests stehen sowohl Entwicklern als auch Benutzern zur Verfügung. Wenn Sie neue Tests hinzufügen, gelten sie auch für ältere Versionen von Modulen, die im Repository vorhanden sind. Alle vom zentralen Repository bereitgestellten Tests stehen allen Entwicklern zur Verwendung sowohl innerhalb als auch in ihrer eigenen Infrastruktur zur Verfügung. Die einzige Ausnahme ist die Ablehnung der Optimierung von Modulen für bestimmte Tests zum Nachteil der Verwendung in einem allgemeinen Kontext.

Darüber hinaus sammelt das zentrale Repository Informationen zu allen Modulen, die in anderen offenen Repositorys verfügbar sind, und testet sie nach Möglichkeit. Das Herunterladen solcher Module ist jedoch nur in den Repositorys möglich, in denen sie gehostet wurden. Auf diese Weise können Benutzer alle Informationen zu verfügbaren Modulen an einem Ort haben und Softwareentwickler können zusätzliche Werbung für ihre eigenen Repositorys (Stores) erhalten.

Schließlich hilft das zentrale Repository bei der Schlichtung in strittigen Fällen (z. B. bei der Verteilung nicht lizenzierter Software an Dritte). Das Erstellen eines Repositorys eines Drittanbieters ist ohne Registrierung in einem zentralen Repository (einschließlich unternehmensinterner Repositorys) nicht möglich. Das Support-Team für das zentrale Repository hat die Befugnis und Fähigkeit, Verstöße gegen die Regeln (Piraten, Hacker, Softwareentwickler mit einer geschlossenen Architektur) sowohl auf der Ebene einzelner Module als auch auf der Ebene ganzer Repositorys von Drittanbietern zu blockieren.

Frühere Artikel der Reihe finden Sie hier: eins , zwei , drei . Der vollständige Text ist nach wie vor auf der Projektwebsite verfügbar .

More articles:


All Articles