This page is a translation of the original work by Steven P. Reiss that can be found at http://cs.brown.edu/~spr/research/env.html

Badanie środowiska programistycznego

Historia

Programowanie jest trudnym zadaniem. Celem środowiska programistycznego jest dostarczenie narzędzi, które pomagają programistom i upraszczenie procesu programowania. Jesteśmy zdecydowanymi zwolennikami narzędzi programistycznych i rozwijamy takie narzędzia od dłuższego czasu. Podczas studiów pracowałem nad systemem uruchomieniowym Dartmouth Basic. Jedną z kluczowych innowacji tutaj było dodanie do środowiska debuggera w języku źródłowym.

Nasze prawdziwe badania w środowiskach programistycznych rozpoczęły się wraz z pojawieniem się stacji roboczych (Apollos, Suns, Percs, ...). My (wraz z kilkoma innymi grupami) uważaliśmy, że należy skorzystać z dodatkowej mocy obliczeniowej i wyświetlacza graficznego, aby uprościć i ulepszyć programowanie. Nasza początkowa próba znajduje odzwierciedlenie w systemie PECAN. PECAN wykorzystał technologię kompilatora do wygenerowania pakietu narzędzi dla języka. Pakiet narzędzi obejmował edytory tekstowe (częściowo zorientowane na składnię) i graficzne (diagramy Nassi-Schneiderman, diagramy Rothona), widoki semantyki tabeli symboli, przepływ sterowania i wyrażeń oraz widoki wykonania stosu i kodu. Zawierał także kompilację przyrostową podczas wpisywania przez użytkownika. Był to zabawny system i wiele nas nauczył, ale tak naprawdę nie był praktyczny (zabrakło mu pamięci przy około 1000 linii kodu) i nie w pełni wykorzystywał możliwości graficzne stacji roboczych.

W oparciu o tę pracę, następnie staraliśmy się lepiej wykorzystać możliwości graficzne stacji roboczych, używając języków wizualnych. Zdaliśmy sobie sprawę, że języki wizualne zwykle obejmują tylko ograniczoną część programowania (np. tylko przepływ sterowania lub tylko przepływ danych) i że aby wykonać prawdziwe programowanie, musielibyśmy pozwolić programistowi pracować z wieloma takimi językami. Aby to osiągnąć, opracowaliśmy tak zwane środowisko programowania koncepcyjnego, GARDEN, które pozwala programiście rozwijać nowe języki wizualne lub tekstowe (z odpowiednią składnią wizualną i odpowiednią semantyką) oraz zagnieżdżać i w inny sposób mieszać te języki w pełnym systemie. System zapewnił odpowiednie edytory graficzne i tekstowe, język bazowy podobny do Lisp, pełny magazyn obiektów współdzielonych (aby umożliwić wielu programistom pracę nad tym samym programem na raz i w celu obsługi aplikacji rozproszonych), przeglądarki podobne do Smalltalk, wiele wątków, a nawet kompilator. System został wykorzystany do opracowania szerokiej gamy języków wizualnych.

Podczas opracowywania projektu GARDEN kilka osób zakwestionowało ogólne badania w środowiskach programistycznych, twierdząc, że podczas gdy narzędzia, które my i inni opracowywaliśmy, były ładne i mogą być przydatne, nic nie było w rzeczywistości praktyczne i żaden z projektów nie mógł tak naprawdę wykorzystać się do rozwoju; codzienne tworzenie programów w systemie UNIX (lub dowolnym innym systemie operacyjnym w tym czasie) odbywało się za pomocą osobnych edytorów tekstowych, debuggerów itp., które nie zmieniły się znacząco od dziesięciu lat. W ten sposób zaczęliśmy opracowywać praktyczne środowisko do prawdziwego programowania. Zdaliśmy sobie sprawę, że nie trzeba mieć wspólnego sklepu lub centralnej reprezentacji, aby mieć zintegrowane środowisko, ani nie trzeba opracowywać nowych narzędzi, aby mieć graficzne interfejsy. Zamiast tego opracowaliśmy prosty mechanizm integracji oparty na komunikatach, który pozwala narzędziom komunikować się ze sobą, oraz szereg opakowań, które zapewniały interfejsy graficzne do istniejących narzędzi (dbx, gdb, make, rcs, ...). Rezultatem było środowisko FIELD. W miarę jego opracowywania rozszerzyliśmy środowisko o różne widoki graficzne, w tym widoki strukturalne (schemat blokowy, hierarchia klas) i widoki dynamiczne (wyświetlanie struktury danych, wizualizacja sterty, wizualizacje We / Wy). FIELD był całkiem udany. Używaliśmy go przez kilka lat podczas naszych kursów programowania wstępnego, został skomercjalizowany przez DEC (jako FUSE), a skopiowany przez HP (Softbench), Sun (Tooltalk), SGI i inne.

Nasze kolejne środowisko, DESERT, próbowało rozszerzyć FIELD na kilka sposobów. Po pierwsze, miał zapewnić programiście wyświetlanie kodu w wysokiej jakości. Dokonano tego poprzez rozszerzenie Adobe Framemaker jako edytora programu. Rozszerzenie zawierało formatowanie kodu w stylu Baeker-Marcus, które zostało wykonane podczas pisania przez użytkownika, co obejmowało semantyczne wyszukiwanie symboli w całym systemie (a nie tylko w bieżącym pliku). Po drugie, chcieliśmy, aby programiści mogli zobaczyć system na różne sposoby, będąc w stanie wyodrębnić kod odnoszący się do konkretnej zmiany lub funkcji. Dokonano tego poprzez podzielenie programu na fragmenty i uruchomienie edytora na plikach wirtualnych składających się z różnych fragmentów zebranych z rzeczywistych plików źródłowych. Programista może określić zestaw fragmentów za pomocą odpowiednich zapytań. Fragmenty podlegały zarządzaniu konfiguracją, a zmiany dokonane w plikach wirtualnych zostały zintegrowane z oryginalnymi plikami źródłowymi podczas zapisywania plików wirtualnych. Wreszcie chcieliśmy zapewnić wyższej jakości wizualizacje kodu i wykonania, dlatego opracowaliśmy system wizualizacji 3D zintegrowany ze środowiskiem.

Nasze ostatnie wysiłki koncentrowały się raczej na zapewnieniu wsparcia dla ewolucji i spójności oprogramowania niż na próbie zapewnienia kompleksowego środowiska programistycznego. W tym pakiecie o nazwie CLIME, założono, że istnieją narzędzia do tworzenia i utrzymywania wszystkich różnych artefaktów towarzyszących systemowi oprogramowania: specyfikacje, projekt, źródło, przypadki testowe, dokumentacja itp. Semantyka każdego z tych artefaktów jest następnie definiowana w kategoriach zestaw metakonstrukcji w odniesieniu do innych artefaktów. Projekt jest postrzegany jako przeciwwskazania dla źródła (i odwrotnie), więc klasa na diagramie UML musi mieć odpowiednią klasę w źródle; reguły użycia języka ograniczają formę źródła; dokumentacja musi być zgodna z kodem; przypadki testowe muszą obejmować kod i być uruchamiane ponownie, gdy kod się zmienia. Wszystko to jest sprawdzane przyrostowo, gdy użycie edytuje artefakty, a wszelkie wynikające niespójności są wyświetlane za pomocą interfejsu graficznego.

Podczas gdy CLIME koncentruje się na statycznej strukturze źródła i różnych artefaktach oprogramowania, zdaliśmy sobie sprawę, że niektóre specyfikacje i artefakty projektowe dotyczą zachowania aplikacji, a nie samego kodu. Aby temu zaradzić, opracowaliśmy CHET, narzędzie do sprawdzania specyfikacji klas i bibliotek w prawdziwych systemach oprogramowania. CHET może pobierać dane wejściowe w oparciu o rozszerzone automaty nad zdarzeniami (które można uzyskać ze schematów interakcji UML, umów klasowych itp.), Znaleźć wszystkie wystąpienia specyfikacji w dużym systemie, a następnie sprawdzić każdą z nich.

Nasza najnowsza praca dotyczy nowego interfejsu dla środowisk programistycznych o nazwie Code Bubbles. Ta praca wraca do widoku jak w DESERT polegającego na pokazywaniu fragmentów plików, takich jak poszczególne funkcje, i została zaprojektowana tak, aby programista widział na ekranie cały odpowiedni kod dla bieżącego zadania, a właściwie ich aktualny zestaw roboczy.