Get best of the week

OS Sivelkiriya: proses pengembangan perangkat lunak

Halo Habr.

Posting ini melanjutkan siklus publikasi tentang proyek OS Sivelkiriya. Dalam artikel pertama dari siklus, deskripsi umum konsep diberikan, di kedua dijelaskan mengapa perlu dan dalam bentuk apa produk dapat melihat cahaya, dalam solusi arsitektur ketiga dijelaskan tesis. Karena banyak komentator telah mengangkat masalah kenyamanan pengembangan untuk OS ini, artikel ini dimaksudkan untuk menyoroti topik ini.

Proses pengembangan perangkat lunak


Proses pengembangan perangkat lunak di bawah Sivelkiriya berbeda dari yang di bawah OS lain (Windows, Linux, Android, dll), karena pengembang dalam semua kasus menyiapkan komponen umum, kasus penggunaan khusus yang tidak diketahui pada saat pengembangan. Dengan kata lain, pengembangan dilakukan seolah-olah dalam semua kasus perpustakaan dikembangkan dan tidak pernah aplikasi.

Tidak ada modul yang dapat menjalankan fungsi yang tidak biasa. Tidak ada modul yang dapat secara ketat menuntut atau secara implisit menganggap bahwa modul itu akan berinteraksi dengan modul persis seperti yang dimaksudkan pengembang atau yang diuji selama pengembangan. Dengan demikian, modul jelas tidak tergantung pada versi modul lain, yang mencegah masalah neraka ketergantungan. Kami menekankan sekali lagi bahwa dalam kerangka kerja Sivelkiriya, paradigma aplikasi ditolak, termasuk sebagai program yang terdiri dari serangkaian modul yang telah ditentukan.

Dalam hal ini, modul dapat menentukan melalui antarmuka mana ia berinteraksi dengan modul lain. Selain itu, ini mungkin memerlukan dan merekomendasikan agar tes khusus yang disajikan dalam repositori pusat diteruskan untuk modul counterparty. Modul tidak selalu diperlukan untuk menggunakan versi terbaru dari setiap antarmuka - ia dapat menggunakan versi yang didukung, dan sistem operasi bertanggung jawab untuk membawa versi.

Dalam hal bahasa dan lingkungan, Sivelkiriya memberikan fleksibilitas yang sama dengan sistem operasi lainnya. Modul dapat berisi kode mesin dan kode byte atau kode yang ditafsirkan. Selain itu, untuk berbagai jenis kode, pelaksana yang berbeda digunakan, yang itu sendiri adalah modul. Tugas mereka adalah memastikan pelaksanaan kode modul dan berlalunya panggilan dan data melintasi batas-batasnya, serta pelaksanaan pemeliharaan yang diperlukan (misalnya, pengumpulan sampah). Berkat pendekatan ini, direncanakan untuk mendukung sejumlah besar bahasa (baik ditafsirkan dan dikompilasi) dan lingkungan. Pada saat yang sama, pembatasan yang ditetapkan oleh sistem operasi berlaku untuk modul terlepas dari bahasa dan metode pemuatan, karena setiap pelaksana akhirnya berinteraksi dengan sistem operasi melalui panggilan ke metode antarmuka,izin yang dikontrol secara universal.

Konsep perpustakaan dinamis di Sivelkiriya hampir sepenuhnya digantikan oleh konsep modul. Modul yang didistribusikan bersama dapat, jika perlu, mentransfer sebagian kode ke pustaka bersama, namun, tidak ada modul lain yang tidak termasuk dalam paket ini yang dapat mengaksesnya. Masalah menemukan perpustakaan bersama juga dipecahkan oleh fakta bahwa dalam semua kasus perpustakaan yang tepat yang termasuk dalam paket digunakan. Interaksi lain dengan kode umum terjadi melalui sistem modul.

Organisasi interaksi pengembang


Jelas, struktur sistem operasi ini memerlukan pendekatan khusus untuk mengatur interaksi pengembang modul dengan pengembang sistem operasi: akan sangat naif untuk percaya bahwa pengembang sistem operasi akan dapat membuat satu set antarmuka pada waktu yang mencakup semua cara masa depan menggunakan perangkat yang menjalankan OS ini. . Sebaliknya, organisasi kompatibilitas universal memerlukan kerja sama bilateral terus menerus antara pengembang OS, yang menyediakan antarmuka dan prototipe, dan pengembang perangkat lunak yang menggunakannya.

Setiap antarmuka ditandai dengan nomor versi yang terdiri dari bagian-bagian besar dan kecil. Dengan peningkatan dalam versi minor, antarmuka dapat ditambah dengan entitas baru dalam versi lama yang sama, namun, penghapusan atau perubahan entitas yang ada tidak diperbolehkan. Versi lama yang baru dirilis ketika antarmuka membutuhkan pemrosesan yang dalam.

Semua versi minor dalam satu versi utama kompatibel satu sama lain. Dalam hal kebetulan benar-benar dilaksanakan oleh objek dan diharapkan oleh konteks panggilan nomor versi minor, kompatibilitas seperti itu jelas. Jika objek yang benar-benar digunakan mengimplementasikan versi minor yang lebih tinggi dari antarmuka daripada yang diharapkan oleh konteks panggilan, maka beberapa data dan fungsi yang disediakan oleh antarmuka sama sekali tidak digunakan. Jika objek mengimplementasikan versi minor yang lebih rendah dari yang diharapkan, maka ketika mengakses entitas yang tidak benar-benar dilaksanakan, penangan default dipanggil, yang karyanya didasarkan pada data dan algoritma yang telah disajikan dalam versi antarmuka yang lebih lama. Jadi, jika versi yang lebih muda dari antarmuka "Artikel" menambah data yang dapat diakses melalui antarmuka, bidang "Iklan teks", yang digunakan dalam beberapa publikasi, misalnya,pada spanduk yang menyediakan akses ke teks lengkap artikel, untuk kompatibilitasnya, pawang dapat menggunakan paragraf pertama atau kalimat pertama dari teks lengkap sebagai teks tersebut. Pendekatan lain adalah mengembalikan nilai khusus "Tidak Diimplementasikan" (pengecualian) ketika mengakses data yang tidak dapat diakses, yang menggeser tanggung jawab untuk memproses pembatasan tersebut ke konteks panggilan.

Antarmuka versi yang lebih lama dapat kompatibel satu sama lain atau tidak. Sebagai contoh, dalam kasus hipotetis bergerak dari mempertimbangkan posisi titik pada layar dalam koordinat Cartesian untuk menggunakan koordinat polar, antarmuka "Point Position 1.0" menggunakan koordinat Cartesian, sedangkan antarmuka "Point Position 2.0" berisi representasi dalam koordinat polar. Karena ada korespondensi satu-ke-satu antara dua representasi ini, sistem operasi selalu dapat menghitung ulang koordinat dalam kasus ketika versi aktual dari antarmuka yang digunakan berbeda dari yang diharapkan.

Sayangnya, penutupan nomor versi aktual ini tidak selalu memungkinkan. Misalnya, jika antarmuka "Melody" di versi 1.0 menggambarkan pekerjaan sebagai skor, dan dalam versi 2.0 sebagai rekaman audio, maka tidak ada korespondensi satu-ke-satu di antara mereka: melodi yang sama dapat dimainkan pada instrumen yang berbeda, sementara rekaman dapat mengandung suara yang tidak dapat diekspresikan pada selembar musik. Demikian pula, jika antarmuka "Note" pada awalnya dirancang untuk konten tekstual dan kemudian diadaptasi untuk tulisan tangan, menerjemahkan satu ke yang lain akan sulit: catatan tulisan tangan mungkin berisi gambar, sementara karakter tersembunyi (misalnya, karakter lunak) transfer). Akhirnya, peta kota secara tradisional digambarkan dalam dua dimensi,namun, untuk kota-kota besar dengan persimpangan multi-level, ini semakin tidak mencukupi; jika di masa depan transisi dibuat dari kartu dua dimensi menjadi tiga dimensi, beralih dari satu ke yang lain tidak akan begitu mudah.

Aturan serupa berlaku ketika mengubah versi prototipe modul. Karena tugas utama modul adalah untuk mengimplementasikan antarmuka data, kami tidak akan membahas hal ini secara lebih rinci.

Distribusi antarmuka terpusat melalui repositori yang didukung oleh tim pengembang sistem operasi. Versi baru dimuat ketika sistem operasi diperbarui. Keberadaan repositori lain yang mendistribusikan antarmuka tidak diperbolehkan, karena akan mengakhiri kompatibilitas universal, yang merupakan tujuan utama pembuatan OS Sivelkiriya. Satu-satunya pengecualian adalah repositori intra-perusahaan, yang digunakan dalam kasus di mana fakta pengembangan beberapa antarmuka adalah rahasia komersial. Antarmuka seperti itu, bagaimanapun, tidak dapat melampaui perusahaan yang menggunakannya untuk pekerjaan internal mereka.

Distribusi modul dimungkinkan baik melalui repositori yang didukung oleh tim pengembangan sistem operasi, dan melalui repositori yang didukung oleh pihak ketiga (perusahaan perangkat lunak komersial, komunitas open source, server perusahaan, dll.). Pada saat yang sama, repositori pusat, didukung oleh tim pengembangan OS, diposisikan sebagai yang utama, karena menyediakan beberapa layanan unik.

Jadi, ketika memuat versi modul baru ke dalam repositori, mereka diuji menggunakan perpustakaan yang terintegrasi dari tes integrasi dan unit, serta tes kinerja. Informasi tentang lulus tes semacam itu tersedia untuk pengembang dan pengguna. Saat menambahkan tes baru, tes ini juga berlaku untuk modul versi lama yang ada di repositori. Semua tes yang disediakan oleh repositori pusat tersedia untuk semua pengembang untuk digunakan baik di dalamnya maupun pada infrastruktur mereka sendiri; satu-satunya pengecualian adalah menentang optimalisasi modul untuk pengujian khusus sehingga merugikan penggunaan dalam konteks umum.

Selain itu, repositori pusat mengumpulkan informasi tentang semua modul yang tersedia di repositori terbuka lainnya, dan juga mengujinya sedapat mungkin, walaupun mengunduh modul semacam itu masih hanya tersedia dari repositori yang menampungnya. Ini memungkinkan pengguna untuk memiliki semua informasi tentang modul yang tersedia di satu tempat, dan pengembang perangkat lunak untuk mendapatkan promosi tambahan dari repositori mereka sendiri (toko).

Akhirnya, repositori pusat membantu menengahi dalam kasus-kasus yang kontroversial (misalnya, ketika mendistribusikan perangkat lunak yang tidak berlisensi kepada pihak ketiga). Membuat repositori pihak ketiga tidak mungkin tanpa registrasi dalam repositori pusat (termasuk repositori intracorporate); tim dukungan untuk repositori pusat memiliki wewenang dan kemampuan untuk memblokir pelanggar aturan (bajak laut, peretas, pengembang perangkat lunak dengan arsitektur tertutup) baik di tingkat modul individu dan di tingkat seluruh repositori pihak ketiga.

Artikel sebelumnya dalam seri ini tersedia di sini: satu , dua , tiga . Teks lengkap, seperti sebelumnya, tersedia di situs web proyek .

More articles:


All Articles