Get best of the week

OS Sivelkiriya: processo de desenvolvimento de software

Olá, Habr.

Este post continua o ciclo de publicações sobre o projeto Sivelkiriya OS. No primeiro artigo do ciclo, foi apresentada uma descrição geral do conceito, no segundo foi explicado por que era necessário e de que forma o produto podia ver a luz, na terceira solução arquitetônica foi descrita a tese. Como muitos comentaristas levantaram a questão da conveniência do desenvolvimento para este sistema operacional, este artigo pretende destacar este tópico.

Processo de desenvolvimento de software


O processo de desenvolvimento de software no Sivelkiriya difere do de outros sistemas operacionais (Windows, Linux, Android etc.), pois os desenvolvedores sempre preparam componentes comuns, cujo caso de uso específico é desconhecido no momento do desenvolvimento. Em outras palavras, o desenvolvimento é realizado como se em todos os casos as bibliotecas tivessem sido desenvolvidas e nunca aplicativos.

Nenhum módulo pode assumir funções incomuns. Nenhum módulo pode exigir estritamente ou implicitamente assumir que ele irá interagir especificamente com o módulo que o desenvolvedor pretendeu ou com o qual ele foi testado durante o desenvolvimento. Portanto, o módulo obviamente não depende da versão de nenhum outro módulo, o que evita o problema do inferno da dependência. Enfatizamos mais uma vez que, dentro da estrutura de Sivelkiriya, o paradigma de aplicativos é rejeitado, inclusive como programas que consistem em um conjunto predefinido de módulos.

Nesse caso, o módulo pode determinar através de quais interfaces ele interage com outros módulos. Além disso, pode exigir e recomendar que testes específicos apresentados no repositório central sejam aprovados no módulo da contraparte. Nem sempre é necessário que o módulo use a versão mais recente de cada interface - ele pode usar qualquer versão suportada e o sistema operacional é responsável por trazer as versões.

Em termos de idiomas e ambientes, o Sivelkiriya oferece a mesma flexibilidade que outros sistemas operacionais. Um módulo pode conter código de máquina e código de bytes ou código interpretado. Além disso, para diferentes tipos de código, são utilizados diferentes executores, que são módulos. Sua tarefa é garantir a execução do código do módulo e a passagem de chamadas e dados através de seus limites, bem como a implementação da manutenção necessária (por exemplo, coleta de lixo). Graças a essa abordagem, está planejado oferecer suporte a um grande número de idiomas (interpretados e compilados) e ambientes. Ao mesmo tempo, as restrições definidas pelo sistema operacional se aplicam ao módulo, independentemente do idioma e método de carregamento, já que qualquer executor interage com o sistema operacional por meio de chamadas para métodos de interface,permissões para as quais são controladas de maneira universal.

O conceito de bibliotecas dinâmicas em Sivelkiriya é quase completamente substituído pelo conceito de módulos. Os módulos distribuídos em conjunto podem, se necessário, transferir parte do código para a biblioteca compartilhada; no entanto, nenhum outro módulo que não esteja incluído neste pacote poderá acessá-lo. O problema de encontrar uma biblioteca compartilhada também é resolvido pelo fato de que, em todos os casos, a biblioteca exata incluída no pacote é usada. Quaisquer outras interações com o código comum ocorrem através de um sistema de módulos.

Organização de interação de desenvolvedores


Obviamente, essa estrutura do sistema operacional requer uma abordagem especial para organizar a interação dos desenvolvedores de módulos com os desenvolvedores do sistema operacional: seria mais ingênuo acreditar que os desenvolvedores do sistema operacional poderão compor um conjunto de interfaces ao mesmo tempo que cubra todas as formas futuras de usar dispositivos executando este SO . Pelo contrário, a organização da compatibilidade universal requer cooperação bilateral contínua entre os desenvolvedores do sistema operacional, que fornece interfaces e protótipos, e os desenvolvedores do software que os utiliza.

Cada interface é caracterizada por um número de versão composto por partes principais e secundárias. Com um aumento na versão secundária, a interface pode ser complementada com novas entidades na mesma versão anterior; no entanto, a exclusão ou alteração de entidades existentes não é permitida. Novas versões mais antigas são lançadas quando a interface requer processamento profundo.

Todas as versões secundárias em uma versão principal são compatíveis entre si. Em caso de coincidência realmente implementada pelo objeto e esperada pelos números de versão menores do contexto de chamada, essa compatibilidade é óbvia. Se o objeto realmente usado implementa uma versão secundária mais alta da interface do que o contexto de chamada espera, alguns dos dados e funções fornecidos pela interface simplesmente não são utilizados. Se o objeto implementa uma versão menor menor que o esperado, ao acessar entidades que não são realmente implementadas, os manipuladores padrão são chamados, cujo trabalho é baseado em dados e algoritmos já apresentados em uma versão anterior da interface. Portanto, se uma versão posterior mais nova da interface "Artigo" adicionar aos dados acessíveis por meio da interface o campo "Texto de publicidade", usado em algumas publicações, por exemplo,em banners que fornecem acesso ao texto completo do artigo, para compatibilidade, o manipulador padrão pode usar o primeiro parágrafo ou a primeira frase do texto completo como esse texto. Outra abordagem é retornar valores especiais “Não implementados” (exceções) ao acessar dados inacessíveis, o que muda a responsabilidade de processar essas restrições para o contexto de chamada.

As versões mais antigas das interfaces podem ser compatíveis entre si ou não. Por exemplo, no caso hipotético de passar da consideração da posição dos pontos na tela nas coordenadas cartesianas para o uso de coordenadas polares, a interface "Posição do ponto 1.0" usa coordenadas cartesianas, enquanto a interface "Posição do ponto 2.0" contém uma representação nas coordenadas polares. Como existe uma correspondência individual entre essas duas representações, o sistema operacional sempre pode recalcular as coordenadas nos casos em que a versão real da interface usada difere da esperada.

Infelizmente, esse mascaramento do número da versão real nem sempre é possível. Por exemplo, se a interface “Melody” na versão 1.0 descreve o trabalho como uma partitura e na versão 2.0 como uma gravação de áudio, não há correspondência individual entre eles: a mesma melodia pode ser tocada em diferentes instrumentos, enquanto a gravação pode contém sons que não podem ser expressos em uma partitura. Da mesma forma, se a interface do Note foi projetada originalmente para conteúdo textual e depois adaptada para escrita à mão, será difícil traduzir uma para a outra: uma nota manuscrita pode conter figuras, enquanto caracteres ocultos (por exemplo, soft transferências). Por fim, os mapas das cidades são tradicionalmente representados em duas dimensões,no entanto, para megacidades com trocas multiníveis, isso está se tornando cada vez mais insuficiente; se no futuro for feita uma transição de cartões bidimensionais para tridimensionais, passar de um para outro não será tão fácil.

Regras semelhantes se aplicam ao alterar versões de protótipo de módulos. Como a principal tarefa do módulo é implementar interfaces de dados, não iremos nos aprofundar nisso com mais detalhes.

A distribuição de interfaces é centralizada através de um repositório suportado por uma equipe de desenvolvedores do sistema operacional. Novas versões são carregadas quando o sistema operacional é atualizado. A existência de outros repositórios que distribuem interfaces não é permitida, pois acabará com a compatibilidade universal, que é o principal objetivo da criação do sistema operacional Sivelkiriya. A única exceção pode ser repositórios intra-corporativos, usados ​​nos casos em que o fato do desenvolvimento de algumas interfaces é um segredo comercial. Tais interfaces, no entanto, não podem ir além das empresas que as utilizam para seu trabalho interno.

A distribuição dos módulos é possível tanto através do repositório suportado pela equipe de desenvolvimento do sistema operacional quanto através de repositórios suportados por terceiros (empresas de software comercial, comunidades de código aberto, servidores corporativos etc.). Ao mesmo tempo, o repositório central, suportado pela equipe de desenvolvimento do sistema operacional, está posicionado como o principal, pois fornece alguns serviços exclusivos.

Portanto, ao carregar novas versões de módulos no repositório, eles são testados usando uma biblioteca reabastecida de testes de integração e unidade, bem como testes de desempenho. As informações sobre a aprovação em tais testes ficam disponíveis para desenvolvedores e usuários. Ao adicionar novos testes, eles também se aplicam a versões mais antigas dos módulos presentes no repositório. Todos os testes fornecidos pelo repositório central estão disponíveis para todos os desenvolvedores para uso dentro dele e em sua própria infraestrutura; a única exceção é opor-se à otimização de módulos para testes específicos em detrimento do uso em um contexto geral.

Além disso, o repositório central coleta informações sobre todos os módulos disponíveis em outros repositórios abertos e também os testa sempre que possível, embora o download desses módulos ainda esteja disponível apenas nos repositórios que os hospedaram. Isso permite que os usuários tenham todas as informações sobre os módulos disponíveis em um único local e os desenvolvedores de software obtenham promoção adicional de seus próprios repositórios (lojas).

Por fim, o repositório central ajuda a arbitrar em casos contenciosos (por exemplo, ao distribuir software não licenciado a terceiros). Criar um repositório de terceiros é impossível sem o registro em um repositório central (incluindo repositórios intracorporativos); a equipe de suporte do repositório central tem autoridade e capacidade de bloquear violadores das regras (piratas, hackers, desenvolvedores de software com uma arquitetura fechada), tanto no nível de módulos individuais quanto no nível de repositórios de terceiros inteiros.

Os artigos anteriores da série estão disponíveis aqui: um , dois , três . O texto completo, como antes, está disponível no site do projeto .

More articles:


All Articles