Elementos de Design de Sistemas

Joy Arulraj (Georgia Tech)

O design de sistemas é frequentemente ensinado através de soluções específicas para domínios particulares, como bancos de dados, sistemas operacionais ou arquitetura de computadores, cada um com seus próprios métodos e vocabulário. Embora essa diversidade seja uma força, ela pode ocultar princípios transversais que se repetem em diferentes domínios. Este artigo propõe uma taxonomia preliminar de princípios de design de sistemas, extraídos de vários domínios em sistemas de computação. O objetivo é um vocabulário compartilhado e conciso que ajude estudantes, pesquisadores e profissionais a raciocinar sobre estrutura e trade-offs, comparar designs entre domínios e comunicar escolhas de forma mais clara.

Tabela Periódica de Princípios de Design de Sistemas

Legenda

Código = símbolo curto único
Nome = princípio
Intenção = descrição curta

Grupo 1: Estrutura

Como dividir e conectar partes com limites claros e pontos de extensão.

Si

Simplicidade

Escolha o design de sistema mais simples que atenda às necessidades atuais; resista à complexidade, como camadas adicionais, serviços ou generalidade adicionados "por via das dúvidas", até que a evidência mostre o benefício.

Exemplo: Evite a otimização arquitetural prematura do sistema [23].

Mo

Modularidade

Particione o sistema em unidades coesas com interfaces mínimas, para que cada unidade possa ser analisada, substituída ou evoluída de forma independente. Este princípio foca na decomposição: escolher limites para favorecer uma clara separação de preocupações, de modo que cada responsabilidade fique em um único módulo.

Exemplo: O modelo OSI decompõe a comunicação em camadas padronizadas com limites bem definidos que permitem o desenvolvimento e a substituição independentes [48].

Co

Composabilidade

Projete componentes que possam ser recombinados de forma segura e flexível; confie em contratos explícitos e interfaces com tipos restritos para que toda composição legal permaneça correta, permitindo que os componentes sejam montados como tijolos intercambiáveis. Diferente da modularidade, este princípio foca na recomposição: garantir que os componentes possam ser combinados de forma segura e flexível.

Exemplo: Programas Unix (por exemplo, grep, sort, uniq) leem de stdin e escrevem para stdout, permitindo que o usuário componha pipelines complexos de processamento de texto [41].

Ex

Extensibilidade

Projete sistemas para permitir extensões seguras definidas pelo usuário, como plug-ins, sem exigir alterações no núcleo do sistema. Quando as extensões vêm de partes não confiáveis, isole-as através de sandboxing para preservar a segurança.

Exemplo: O Unix também ilustra a extensibilidade: novos programas podem ser adicionados pelo usuário sem alterações no kernel [41].

Pm

Separação Política/Mecanismo

Separe o que deve ser feito (política) de como é realizado (mecanismo), expondo uma interface comum através da qual múltiplas políticas podem se conectar ao mesmo mecanismo.

Exemplo: O Hydra possui um kernel de mecanismos genéricos (agendamento, paginação, proteção) e moveu as políticas de alocação de recursos para módulos de nível de usuário [32].

Gr

Design Generalizado

Projete um núcleo único com pontos de variação explícitos como tipos, knobs ou plug-ins, para que possa servir a muitos casos de uso sem duplicação, mas especialize-se quando isso gerar ganhos significativos em desempenho, precisão ou clareza.

Exemplo: A C++ Standard Template Library é uma coleção de contêineres, iteradores e algoritmos parametrizados por templates [45]. O Postgres permite que os usuários adicionem tipos e operadores ao sistema de banco de dados principal [46].

Pd

Design Probabilístico

Introduza aleatoriedade controlada para ganhar eficiência, escalabilidade ou simplicidade, aceitando um risco pequeno e quantificado de erro ou perda.

Exemplo: Roteadores tratam o comprimento da fila como um sinal de probabilidade: à medida que a fila cresce, eles descartam pacotes de entrada com probabilidade crescente, sinalizando proativamente o congestionamento [13].

Grupo 2: Eficiência

Fazer menos trabalho, ou fazê-lo de forma mais barata, concentrando o esforço onde ele compensa.

Sc

Escalabilidade

Projete o sistema para lidar com o crescimento de dados, tráfego ou nós com custo ou latência quase linear.

Exemplo: O MapReduce escala entre nós dividindo o trabalho em tarefas paralelas e agregando resultados com coordenação mínima [10].

Rc

Reutilização de Computação

Evite trabalho redundante através de cache, materializando resultados intermediários (por exemplo, índices) ou atualizando incrementalmente as saídas em entradas repetidas ou ligeiramente modificadas, economizando computação.

Exemplo: Uma árvore B+ reutiliza a ordem de suas chaves classificadas: as buscas seguem o caminho de pesquisa existente em vez de reescanear todo o conjunto de dados a cada vez, reutilizando assim a computação [2].

Wv

Evitação de Trabalho

Pule a computação que não alteraria os resultados externamente observáveis. Exemplos incluem avaliação preguiçosa (lazy evaluation) e curto-circuito de predicados.

Exemplo: A avaliação preguiçosa adia o trabalho até que um valor seja demandado, eliminando computação inútil [19].

Cc

Especialização do Caso Comum

Detecte os caminhos de execução ou itens de dados que dominam o tempo de execução ("hot spots") e crie um caminho rápido e otimizado apenas para eles, enquanto um caminho mais lento e geral ainda lida com todos os casos corretamente.

Exemplo: Fazer cache do método de destino para a classe do receptor na primeira chamada, para que chamadas subsequentes nesse receptor comum atinjam o caminho rápido; classes incomuns recorrem à rotina completa de busca de método [5].

Bo

Otimização Orientada a Gargalos

Analise o desempenho de ponta a ponta, localize a restrição de recurso mais apertada e concentre o esforço de melhoria ali até que outro estágio se torne o limitador.

Exemplo: Raros retardatários do 99º percentil gargalam a latência, e solicitações replicadas ajudam a reduzir os tempos de resposta da cauda [9].

Ha

Design Consciente do Hardware

Molde algoritmos e estruturas de dados às propriedades de latência, largura de banda, paralelismo e persistência do hardware subjacente (por exemplo, hierarquia de cache, NUMA, SSDs, GPUs).

Exemplo: O BLAS define kernels ajustados para cache e vetores para que o código de álgebra linear explore o hardware de forma eficiente [31].

Op

Design Otimista

Prossiga como se o caso comum fosse bem-sucedido, pulando a coordenação, e confie em um caminho de recuperação (possivelmente caro) apenas quando essa suposição se provar errada.

Exemplo: O Controle de Concorrência Otimista executa transações sem bloqueios, depois valida no commit e reverte apenas quando um conflito é detectado [24].

La

Aproximação Aprendida

Substitua algoritmos artesanais por modelos treinados em dados, trocando imprecisão limitada por eficiência ou flexibilidade.

Exemplo: O preditor de desvio de perceptron aprende pesos online para prever os resultados dos desvios, superando os contadores fixos de dois bits sem aumentar a tabela [22].

Grupo 3: Semântica

Especificar comportamento e interfaces com precisão.

Al

Elevação de Abstração

Encapsule operações de baixo nível por trás de uma interface de nível superior ou uma linguagem específica de domínio (DSL) que expresse a intenção em vez dos passos. Isso permite a otimização interna e também permite que uma única definição vise diversos back-ends.

Exemplo: Consultas SQL declaram o resultado a ser recuperado; o SGBD escolhe caminhos de acesso, ordens de junção e operadores físicos automaticamente [44].

Lu

Homogeneidade da Linguagem

Adote uma única representação intermediária (ou linguagem) bem especificada em todos os componentes principais e extensões para que a semântica se alinhe, as ferramentas se componham e as otimizações e reutilização entre camadas ocorram com esforço mínimo.

Exemplo: O LLVM expõe uma IR (Representação Intermediária) tipada e baseada em SSA que muitos front-ends visam e muitos back-ends compartilham, permitindo a otimização entre linguagens e a reutilização dos mesmos passes de middle-end [30].

Se

Interfaces Semanticamente Explícitas

Especifique uma interface com precisão (cobrindo visibilidade de efeitos, ordenação, durabilidade, etc.) para que os usuários possam raciocinar sobre o verdadeiro estado externamente observável de uma chamada sem adivinhar sobre buffering ou replicação ocultos.

Exemplo: Os níveis de isolamento SQL especificam semânticas precisas de anomalias e tornam as garantias de visibilidade explícitas [3].

Fs

Especificação Formal

Descreva o comportamento do sistema usando modelos matemáticos ou lógicos para apoiar o raciocínio rigoroso, a verificação ou a síntese. Mecanismos para realizar este princípio incluem lógica temporal, máquinas de estado e outros formalismos que tornam as propriedades do sistema analisáveis.

Exemplo: O TLA+ mostra como especificar e verificar sistemas usando lógica e teoria dos conjuntos para encontrar erros de design antes da codificação [27].

Ig

Transformação Guiada por Invariantes

Use invariantes formalmente declarados para conduzir refatoração, otimização ou reconfiguração seguras.

Exemplo: Em compiladores, o SSA trata "uma definição por nome" como uma invariante da IR; os passes reescrevem o código preservando a semântica e depois restabelecem o SSA [8]. Em otimizadores de consulta, as equivalências da álgebra relacional (por exemplo, empurrar seleção/projeção) preservam a semântica do resultado [44].

Grupo 4: Distribuição

Coordenar trabalho e dados em arquiteturas distribuídas.

Lt

Transparência de Localização

Oculte a localização física dos recursos para que os clientes interajam através de nomes ou identificadores uniformes.

Exemplo: Programas podem chamar procedimentos remotos como se fossem locais, mascarando a localização do host [4].

Dc

Controle Descentralizado

Distribua a tomada de decisão entre muitos nós para evitar pontos únicos de falha ou gargalos.

Exemplo: O Dynamo particiona dados via hashing consistente e usa um protocolo de fofoca (gossip) para gerenciamento de membros, evitando qualquer coordenador central [12].

Fp

Posicionamento de Função

Posicione a funcionalidade onde o contexto e os recursos necessários existem para alcançar correção e eficiência, evitando trabalho redundante em outros lugares.

Exemplo: O argumento de ponta a ponta (end-to-end) mostra que funções como verificações de confiabilidade alcançam a correção apenas nos pontos finais [42].

Lo

Localidade de Referência

Posicione dados e operações relacionados próximos no tempo e no espaço para preservar padrões de acesso e minimizar a separação entre computação e estado.

Exemplo: O modelo de conjunto de trabalho (working-set) formaliza a localidade temporal para manter as páginas "quentes" na memória [11].

Cz

Evitação de Coordenação

Projete computações e fluxos de dados para reduzir a necessidade de coordenação distribuída, identificando operações que podem prosseguir de forma independente, preservando a correção no nível da aplicação.

Exemplo: CRDTs permitem que réplicas atualizem de forma independente e mesclem estados deterministicamente, garantindo a convergência sem coordenação em tempo de execução [47].

Grupo 5: Planejamento

Selecionar planos automaticamente a partir de objetivos, custos e restrições.

Ep

Planejamento Baseado em Equivalência

Aplique regras de reescrita algébricas/lógicas sobre uma IR comum que preserve a equivalência semântica; adie a escolha final para estágios posteriores de custo/restrição.

Exemplo: O sistema de reescrita baseado em regras do Starburst aplica equivalências relacionais (por exemplo, empurrar predicados) para gerar consultas logicamente equivalentes [39].

Cm

Planejamento Baseado em Custo

Quando um sistema precisa escolher entre designs, configurações ou estratégias de execução alternativos, use um modelo de custo para guiar a busca por soluções de baixo custo (energia, dinheiro, etc.) sem precisar enumerar todo o espaço.

Exemplo: O otimizador de consultas Selinger seleciona o plano de menor custo sob um modelo de custo [44].

Cp

Planejamento Baseado em Restrições

Codifique decisões e restrições rígidas ou flexíveis e confie em um solver (ILP/SMT, etc.) para encontrar uma atribuição viável ou ótima.

Exemplo: O Quincy formula o agendamento de cluster como um fluxo de custo mínimo com restrições de localidade e justiça e o resolve para obter uma atribuição [21].

Gd

Planejamento Orientado a Objetivos

Aceite uma descrição declarativa do estado final desejado e sintetize automaticamente uma sequência concreta de operações para alcançá-lo, protegendo o usuário dos detalhes de implementação.

Exemplo: O otimizador de consultas Cascades transforma uma consulta SQL (o objetivo) em um plano executável através de transformação baseada em regras e busca guiada por custo [14].

Bb

Ajuste de Caixa-Preta

Quando modelos de custo analíticos não estão disponíveis, pesquise o espaço de planos/configurações medindo candidatos no sistema alvo, escolhendo iterativamente os melhores (por exemplo, busca heurística ou Bayesiana) e armazenando em cache o vencedor.

Exemplo: O ATLAS cronometra empiricamente as configurações candidatas de kernel BLAS na CPU alvo e fixa os parâmetros de melhor desempenho, sem um modelo de custo analítico [47].

Ah

Dicas Consultivas

Forneça dicas não vinculativas que os sistemas podem explorar para melhorar o desempenho, sem alterar a correção ou exigir aplicação.

Exemplo: Lampson defende "dicas" opcionais que ajudam no desempenho, mas não devem afetar a correção se ignoradas [29].

Grupo 6: Operabilidade

Observar, adaptar e evoluir sistemas em execução com o mínimo de interrupção.

Ad

Processamento Adaptativo

Monitore as condições de tempo de execução e ajuste automaticamente os parâmetros ou a estratégia.

Exemplo: O Eddies reordena continuamente os operadores de consulta em tempo de execução com base no feedback, adaptando-se sem interromper a execução [1].

Ec

Elasticidade

Ajuste automaticamente a alocação de recursos em resposta à mudança de demanda e metas de custo. Exemplos incluem auto-escalonamento preditivo e modelagem de carga.

Exemplo: Chase et al. provisionam servidores dinamicamente com base na carga e na utilidade, exemplificando o gerenciamento elástico de recursos [6].

Wa

Otimização Consciente da Carga de Trabalho

Observe continuamente a forma da carga de trabalho (distorção, localidade, frequência de acesso, etc.) e adapte os layouts de dados, escolhas de algoritmos ou alocações de recursos para corresponder aos padrões atuais.

Exemplo: O "craqueamento" de banco de dados reorganiza incrementalmente os dados da coluna com base nos predicados da consulta, adaptando o layout dos dados continuamente à carga de trabalho observada [20].

Au

Automação e Autonomia

Deixe o sistema realizar tarefas rotineiras ou reativas sem intervenção humana, muitas vezes aprendendo a partir de rastreamentos ou exemplos fornecidos pelo usuário.

Exemplo: O AutoAdmin recomenda automaticamente índices/visões materializadas a partir de rastreamentos de carga de trabalho [7]. Sistemas de programação por exemplo automatizam tarefas generalizando a partir de alguns exemplos fornecidos pelo usuário [33].

Ho

Observabilidade Humana

Exponha o estado interno do sistema, como métricas, rastreamentos, planos, para tornar o sistema intencionalmente transparente; essa transparência melhora a observabilidade, depuração, introspecção e controle.

Exemplo: A análise de Paxson da dinâmica de pacotes da Internet de ponta a ponta demonstra como medições e rastreamentos ricos permitem depuração e ajuste informados [37].

Ev

Evolutividade

Projete para que o sistema possa mudar com o mínimo de tempo de inatividade ou reescritas e fazê-lo sem quebrar contratos externos ou comportamento observável para clientes existentes. Diferente da extensibilidade, que permite que terceiros adicionem novo comportamento através de pontos de gancho definidos sem tocar no núcleo, a evolutividade permite que o interior do sistema mude ao longo do tempo sem quebrar os contratos externos existentes.

Exemplo: Parnas apresenta como um design modular torna o sistema mais fácil de estender sem reescritas disruptivas [36].

Grupo 7: Confiabilidade

Manter a correção sob falhas, concorrência e falha parcial.

Ft

Tolerância a Falhas

Projete o sistema para continuar operando, talvez de forma degradada, apesar de falhas nos componentes.

Exemplo: A análise de Gray sobre por que os computadores param mostra que a replicação e o reinício automático permitem que os serviços continuem funcionando através de falhas de hardware e software [15].

Is

Isolamento para Correção

Evite interferência não intencional entre componentes para que o raciocínio local permaneça válido.

Exemplo: O bloqueio de duas fases no nível da linha impede que uma transação leia ou sobrescreva dados não confirmados de outra, preservando as garantias de isolamento [16].

At

Execução Atômica

Agrupe múltiplas operações para que pareçam indivisíveis: ou todas têm efeito ou nenhuma tem.

Exemplo: Com a Memória Transacional, as operações de memória dentro de uma transação são executadas especulativamente e, em seguida, confirmadas atomicamente; se ocorrer algum conflito ou falha, todo o bloco é abortado e não deixa estado parcial [18].

Cr

Relaxamento da Consistência

Relaxe deliberadamente restrições fortes de consistência ou ordenação, mas apenas dentro de limites documentados, para melhorar o desempenho, a disponibilidade ou a concorrência.

Exemplo: O Bayou permite que clientes móveis atualizem réplicas enquanto estão desconectados, garantindo a convergência eventual quando as réplicas se reconectam, trocando consistência estrita por disponibilidade offline [38].

Grupo 8: Segurança

Limitar a autoridade e impor o isolamento para preservar a segurança e a integridade.

Sy

Segurança via Isolamento

Imponha limites fortes para que falhas ou código hostil não possam afetar outros componentes.

Exemplo: Um monitor de máquina virtual correto apresenta a cada convidado uma máquina completa e isolada e intercepta operações privilegiadas, impedindo que um convidado comprometa outros ou o host [40].

Ac

Controle de Acesso e Auditoria

Defina permissões e registre cada acesso para responsabilidade.

Exemplo: A taxonomia de Lampson de listas de controle de acesso, capacidades e trilhas de auditoria sustenta os mecanismos de segurança modernos [28].

Lp

Mínimo Privilégio

Conceda apenas a autoridade mínima necessária para uma tarefa, diminuindo o raio de explosão.

Exemplo: A análise post-mortem do Worm da Internet de 1988 mostra como o excesso de privilégios permitiu que o worm se espalhasse e estimulou a adoção generalizada de daemons de mínimo privilégio [35].

Tq

Confiança via Quórum

Confie no acordo de múltiplos participantes independentes em vez de uma única autoridade.

Exemplo: O algoritmo Paxos replica o estado em um quórum majoritário para que o serviço permaneça correto mesmo que nós minoritários falhem ou ajam maliciosamente [26].

Cf

Padrões Conservadores

Entregue com configurações restritivas e seguras; permita que especialistas optem por modos mais arriscados e rápidos.

Exemplo: Com uma política de "acesso negado por padrão", todo mecanismo de proteção deve permitir o acesso apenas quando explicitamente concedido [43].

Sa

Segurança por Construção

Estruture o código ou os dados de forma que classes inteiras de erros se tornem impossíveis, em vez de meramente detectadas.

Exemplo: O verificador de propriedade e empréstimo (ownership and borrow checker) do Rust previne corridas de dados e ponteiros pendentes em tempo de compilação [34].

4. ESTUDO DE CASO

Para ilustrar como múltiplos princípios de design se cruzam na prática, considere o mapeamento de planos de operadores lógicos para físicos em um sistema de banco de dados relacional.

Assim, o mapeamento de operadores lógicos para físicos em sistemas de banco de dados exemplifica como vários princípios de design se unem para processar eficientemente consultas SQL declarativas.

5. LIMITAÇÕES

Qualquer tentativa de organizar um campo tão amplo quanto o de sistemas de computação envolve trade-offs. Esta tabela não é uma lista de verificação ou uma teoria universal; é um vocabulário compartilhado que destaca princípios recorrentes e incentiva a reflexão estrutural. Dito isso, existem várias limitações:

Em última análise, esta tabela é um meio para ajudar os estudantes a verem os princípios de design recorrentes com mais clareza, para auxiliar os designers de sistemas a comunicarem os trade-offs com mais precisão e para ajudar os pesquisadores a reconhecerem onde suas ideias se encaixam no cenário mais amplo do design de sistemas.

6. CONCLUSÃO

O design de sistemas abrange diversos domínios e vocabulários, o que pode dificultar a discussão compartilhada. Herdamos mecanismos, estudamos trade-offs e construímos intuições, mas termos concisos para as ideias subjacentes nem sempre estão disponíveis. A "tabela periódica" de princípios de design oferecida aqui visa fornecer uma modesta linguagem comum, nomeando ideias recorrentes para que sejam mais fáceis de ensinar, comparar e desenvolver.

REFERÊNCIAS

[1] Ron Avnur and Joseph M. Hellerstein. Eddies: Continuously Adaptive Query Processing. In SIGMOD, 2000.

[2] Rudolf Bayer and Edward McCreight. Organization and Maintenance of Large Ordered Indexes. Acta Informatica, 1972.

[3] Hal Berenson, Philip A. Bernstein, Jim Gray, Jim Melton, Elizabeth J. O'Neil, and Patrick E. O'Neil. A Critique of ANSI SQL Isolation Levels. In SIGMOD, 1995.

[4] Andrew D. Birrell and Bruce J. Nelson. Implementing Remote Procedure Calls. ACM TOCS, 1984.

[5] Craig Chambers and David Ungar. Customization: Optimizing Compiler Technology for SELF. In PLDI, 1989.

[6] Jeffrey S. Chase et al. Managing Energy and Server Resources in Hosting Centers. In SOSP, 2001.

[7] Surajit Chaudhuri and Vivek R. Narasayya. An Efficient, Cost-Driven Index Selection Tool for Microsoft SQL Server. In VLDB, 1997.

[8] Ron Cytron et al. Efficiently Computing Static Single Assignment Form and the Control Dependence Graph. ACM TOPLAS, 1991.

[9] Jeff Dean and Luiz André Barroso. The Tail at Scale. Communications of the ACM, 2013.

[10] Jeffrey Dean and Sanjay Ghemawat. MapReduce: Simplified Data Processing on Large Clusters. In OSDI, 2004.

[11] Peter J. Denning. The Working Set Model for Program Behavior. Communications of the ACM, 1968.

[12] Giuseppe DeCandia et al. Dynamo: Amazon's Highly Available Key-Value Store. In SOSP, 2007.

[13] Sally Floyd and Van Jacobson. Random Early Detection Gateways for Congestion Avoidance. In SIGCOMM, 1993.

[14] Goetz Graefe. The Cascades Framework for Query Optimisation. HPL Technical Report HPL-95-18, 1995.

[15] Jim Gray. Why Do Computers Stop and What Can Be Done About It? Tandem Technical Report, 1986.

[16] Jim Gray and Andreas Reuter. Transaction Processing: Concepts and Techniques. Morgan Kaufmann, 1993.

[17] J. N. Gray et al. Granularity of Locks in a Shared Data Base. In VLDB, 1975.

[18] Maurice Herlihy and J. Eliot B. Moss. Transactional Memory: Architectural Support for Lock-Free Data Structures. In ISCA, 1993.

[19] John Hughes. Why Functional Programming Matters. In Research Topics in Functional Programming, Addison-Wesley, 1990.

[20] Stratos Idreos et al. Database Cracking. In CIDR, 2007.

[21] Michael Isard et al. Quincy: Fair Scheduling for Distributed Computing Clusters. In SOSP, 2009.

[22] Daniel A. Jiménez and Calvin Lin. Dynamic Branch Prediction with Perceptrons. In HPCA, 2001.

[23] Donald E. Knuth. Structured Programming with go to Statements. ACM Computing Surveys, 1974.

[24] H. T. Kung and John T. Robinson. On Optimistic Methods for Concurrency Control. ACM TODS, 1981.

[25] Leslie Lamport. The Part-Time Parliament. ACM TOCS, 1998.

[26] Leslie Lamport. The Part-Time Parliament. ACM TOCS, 1998.

[27] Leslie Lamport. Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers. Addison-Wesley, 2002.

[28] Butler W. Lampson. Protection. ACM Operating Systems Review, 1974.

[29] Butler W. Lampson. Hints for Computer System Design. ACM Operating Systems Review, 1983.

[30] Chris Lattner and Vikram Adve. LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation. In CGO, 2004.

[31] C. L. Lawson et al. Basic Linear Algebra Subprograms for Fortran Usage. ACM TOMS, 1979.

[32] R. Levin et al. Policy/Mechanism Separation in Hydra. In SOSP, 1975.

[33] Henry Lieberman. Your Wish is My Command: Programming by Example. Morgan Kaufmann, 2001.

[34] Nicholas D. Matsakis and Felix Klock. The Rust Language. In ACM SIGAda, 2014.

[35] Robert T. Morris. A Tour of the Worm. USENIX, 1989.

[36] David L. Parnas. Designing Software for Ease of Extension and Contraction. IEEE TSE, 1979.

[37] Vern Paxson. End-to-End Internet Packet Dynamics. IEEE/ACM TON, 1999.

[38] K. Petersen et al. Flexible Update Propagation for Weakly Consistent Replication. In SOSP, 1997.

[39] Hamid Pirahesh et al. Extensible/Rule-Based Query Rewrite Optimization in Starburst. In SIGMOD, 1992.

[40] Gerald J. Popek and Robert P. Goldberg. Formal Requirements for Virtualizable Third Generation Architectures. Communications of the ACM, 1974.

[41] Dennis M. Ritchie and Ken Thompson. The UNIX Time-Sharing System. Communications of the ACM, 1974.

[42] J. H. Saltzer et al. End-to-End Arguments in System Design. ACM TOCS, 1984.

[43] Jerome H. Saltzer and Michael D. Schroeder. The Protection of Information in Computer Systems. Proc. IEEE, 1975.

[44] Patricia G. Selinger et al. Access Path Selection in a Relational Database Management System. In SIGMOD, 1979.

[45] Alexander A. Stepanov and Meng Lee. The Standard Template Library. HP Laboratories Technical Report, 1994.

[46] Michael Stonebraker and Lawrence A. Rowe. The Design of POSTGRES. In SIGMOD, 1986.

[47] R. Clint Whaley and Jack J. Dongarra. Automatically Tuned Linear Algebra Software. In SC, 1998.

[48] Hubert Zimmermann. OSI Reference Model – The ISO Model of Architecture for Open Systems Interconnection. IEEE Transactions on Communications, 1980.

COMO CITAR

Se você achar esta análise útil, por favor, cite-a como:

@misc{arulraj2025periodictablecomputerdesign,
     title={Towards a Periodic Table of Computer System Design Principles},
     author={Joy Arulraj},
     year={2025},
     eprint={2507.22098},
     archivePrefix={arXiv},
     primaryClass={cs.OH},
     url={https://arxiv.org/abs/2507.22098},
}

> Joy Arulraj. Towards a Periodic Table of Computer System Design Principles arXiv preprint arXiv:2507.22098, 2025.

COMO CONTRIBUIR

Aceitamos PRs que adicionem, refinem ou reagrupem princípios, e PRs que adicionem artigos "clássicos" como exemplos. Abra uma issue descrevendo: