Author: cs.brown.edu
Programação de Pesquisa Ambiental
História
A programação é uma tarefa difícil. O objetivo de um ambiente de programação é fornecer ferramentas que ajudem o programador e simplifique a tarefa. Somos um forte defensor das ferramentas de programação e desenvolvemos essas ferramentas há muito tempo. Enquanto estudante de graduação, trabalhei no sistema de tempo de execução Dartmouth Basic. Uma das principais inovações aqui foi adicionar um depurador de idioma de origem ao meio ambiente.
Nossa pesquisa real em ambientes de programação começou com o advento das estações de trabalho (Apollos, Suns, Percs, ...). Nós (juntamente com vários outros grupos) sentimos que se poderia usar o poder computacional adicional e a exibição de gráficos para simplificar e melhorar a experiência de programação. Nossa tentativa inicial aqui é refletida no sistema PECAN. A PECAN usou a tecnologia de compilação para gerar uma suíte de ferramentas para uma linguagem. O conjunto de ferramentas inclui diagramas gráficos (diagramas Nassi-Schneiderman, diagramas Rothon) e gráficos gráficos (diagramas Nassi-Schneiderman), visualizações semânticas da tabela de símbolos, fluxo de controle e expressões e visualizações de execução da pilha e do código. Também apresentou compilação incremental à medida que o usuário digitou. Foi um sistema divertido e nos ensinou muito, mas na verdade não era prático (ficou sem memória em cerca de 1000 linhas de código) e não aproveitava plenamente os recursos gráficos das estações de trabalho.
Com base nesse trabalho, tentamos usar melhor as capacidades gráficas das estações de trabalho usando linguagens visuais. Percebemos que as linguagens visuais geralmente cobrem apenas uma parte limitada da programação (por exemplo, apenas fluxo de controle ou fluxo de dados), e para fazer uma programação real, teríamos que deixar o programador trabalhar com vários desses idiomas. Para realizar isso, desenvolvemos o que chamamos de ambiente de programação conceitual, GARDEN, que permitem que o programador desenvolva novos idiomas visuais ou textuais (com sintaxe visual apropriada e semântica apropriada) e aninhe e entremeille estes idiomas em um sistema completo. O sistema forneceu editores gráficos e textuais adequados, um idioma de base semelhante a Lisp, uma loja de objetos compartilhados completos (para permitir que programadores múltiplos funcionem no mesmo programa de uma vez e para suportar aplicativos distribuídos), navegadores de tipo Smalltalk, vários segmentos e até mesmo um compilador. O sistema foi utilizado para desenvolver uma grande variedade de linguagens visuais.
Ao desenvolver o GARDEN, várias pessoas desafiaram a pesquisa geral em ambientes de programação, alegando que, enquanto as ferramentas que nós e os outros estávamos desenvolvendo eram agradáveis e podiam ser úteis, nada era realmente prático e nenhum dos projetos poderia realmente se usar para o desenvolvimento; O desenvolvimento diário de programas no UNIX (ou qualquer outro sistema operacional naquele momento) foi feito usando editores, devolvedores, etc., que não mudaram significativamente em dez anos. Assim, começamos a desenvolver um ambiente prático para a programação real. Percebemos que não precisava ter uma loja comum ou uma representação central para ter um ambiente integrado, nem precisava desenvolver novas ferramentas para ter finanças gráficas. Em vez disso, desenvolvemos um simples mecanismo de integração baseado em mensagens que permitiu que as ferramentas se conversassem e uma série de wrappers que fornecessem interfaces gráficas para ferramentas existentes (dbx, gdb, make, rcs, ...). O resultado foi o ambiente FIELD. À medida que foi desenvolvido, ampliamos o ambiente com uma variedade de visualizações gráficas, incluindo vistas estruturais (fluxograma, hierarquia de classes) e visualizações dinâmicas (displays de estrutura de dados, vizualização de heap, visualizações de E / S). FIELD foi bem sucedido. Usamos isso durante vários anos em nossos cursos de programação de introdução, foi comercializado pela DEC (como FUSE), e foi copiado pela HP (Softbench), Sun (Tooltalk), SGI e outros.
Nosso próximo ambiente, DESERT, tentou estender o CAMPO de várias maneiras. Primeiro, queria fornecer ao programador uma exibição de alta qualidade do código. Isso foi feito expandindo o Adobe Framemaker como editor de programas. A extensão caracterizou a formatação de código de estilo Baeker-Marcus que foi feita como o usuário digitado, que incluiu pesquisa semântica de símbolos em todo o sistema (e não apenas no arquivo atual). Em segundo lugar, queríamos deixar o programador visualizar o sistema de diferentes maneiras, podendo isolar o código relevante para uma determinada mudança ou recurso. Isso foi feito dividindo o programa em fragmentos e fazendo com que o editor funcione em arquivos virtuais consistindo em diferentes fragmentos coletados de arquivos originais reais. O programador poderia especificar um conjunto de fragmentos usando consultas apropriadas. Fragmentos estavam sob gerenciamento de configuração e as alterações feitas nos arquivos virtuais foram integradas nos arquivos originais quando os arquivos virtuais foram salvos. Finalmente, queríamos fornecer visualizações de código e execução de melhor qualidade e, assim, desenvolvemos um sistema de visualização 3D integrado ao meio ambiente.
Nossos esforços mais recentes se concentraram em fornecer suporte para a evolução e a consistência do software em vez de tentar fornecer um ambiente de programação abrangente. Este pacote, CLIME, assume que há ferramentas para criar e manter todos os diferentes artefatos que acompanham um sistema de software: as especificações, o design, a fonte, os casos de teste, a documentação, etc. A semântica de cada um desses artefatos é então definida em termos de um conjunto de metaconstraintes com respeito aos outros artefatos. O design é visto como contraints na fonte (e vice-versa) para que uma classe em um diagrama UML tenha que ter uma classe correspondente na fonte; regras de uso de linguagem que restringem a forma da fonte; a documentação deve ser consistente com o código; os casos de teste devem cobrir o código e ser atualizados à medida que o código muda. Tudo isso é verificado de forma incremental à medida que o uso edita os artefatos e as inconsistências resultantes são exibidas usando uma interface gráfica.
Enquanto o CLIME se concentra na estrutura estática da fonte e nos vários artefatos de software, percebemos que algumas das especificações e artefatos de design relacionados ao comportamento da aplicação em vez do próprio código. Para acomodar isso, estamos desenvolvendo CHET, uma ferramenta para verificar especificações de classe e biblioteca em sistemas de software reais. O CHET pode tomar a entrada com base em um autômato estendido sobre eventos (que podem ser derivados de diagramas de interação UML, contratos de classe, etc.), encontre todas as instâncias da especificação em um sistema grande e, em seguida, verifique cada instância.
Our most recent work involves a new front end for programming environments, Code Bubbles. Este trabalho vai para a visão do deserto mostrando fragmentos de arquivos, como funções individuais, e é projetado para que o programador possa ver todo o código relevante para sua tarefa atual, efetivamente seu conjunto de trabalho atual, na tela ao mesmo tempo.