Історія
Програмування – складний процес. Метою програмного середовища є надання інструментів, які допомагають програмісту спростити завдання. Ми палкі прихильники інструментів програмування та тривалий час розробляємо такі інструменти. Будучи студентом, я працював над мовою програмування Dartmouth Basic. Одне з ключових нововведень полягало в тому, щоб додати до середовища налагоджувач мови оригіналу.
Наше справжнє дослідження в середовищах програмування розпочалося з появою робочих станцій (Apollos, Suns, Percs, …). Ми (поряд з кількома іншими групами) відчували, що треба вміти користуватися додатковою обчислювальною потужністю та графічним дисплеєм, щоб спростити та покращити досвід програмування. Наша перша спроба спроектована в системі PECAN. PECAN використовує технологію компілятора для створення набору інструментів для мови. Набір інструментів включає текстові (частково синтаксично направлені) та графічні редактори (діаграми Nassi-Schneiderman, графіки Ротона), семантичні перегляди таблиці символів, керування потоком і виразами, а також представлення виконання стеку та коду. Вона також містила додаткову компіляцію, як набрала користувач. Це була цікава система і навчила нас багато, але це було не практично (воно вичерпало пам’ять приблизно на 1000 рядків коду), і не користувалося перевагами графічних можливостей робочих станцій.
На основі цієї роботи ми намагалися краще використовувати графічні можливості робочих станцій, використовуючи візуальні мови. Ми зрозуміли, що візуальні мови зазвичай охоплюють лише обмежену частину програмування (наприклад, лише керуючий потік або тільки потоки даних), і для реального програмування нам доведеться дозволити програмісту працювати з кількома такими мовами. Для цього ми розробили те, що ми назвали концептуальним середовищем програмування GARDEN, що дозволяє програмісту створювати нові візуальні або текстові мови (з належним візуальним синтаксисом та семантикою), вставити та змішати ці мови іншим способом в цілій системі. Система забезпечувала відповідні графічні та текстові редактори, базову мову Lisp, повний об’єкт загального користування (дозволити програмістам одночасно працювати на одній і тій же програмі, а також підтримувати розподілені програмні обчислення), браузери Smalltalk, кілька потоків і навіть компілятор. Система була використана для розробки широкого спектру візуальних мов.
Під час розробки SARDEN кілька людей кинули виклик загальним дослідженням в середовищах програмування, стверджуючи, що, хоча і інструменти, які ми і інші розробляли, були непоганими і можуть бути корисними, насправді не були практичними, і жоден з проектів не міг надалі розвиватись; Щоденна розробка програм на UNIX (або будь-якій іншій ОС на той час) була зроблена за допомогою окремих і текстових редакторів, зневаджувачів тощо, які протягом десяти років істотно не змінилися. Таким чином, ми розпочали розробку практичного середовища для реального програмування. Ми зрозуміли, що ви не повинні бути власником звичайного магазину або центрального представництва, щоб мати інтегроване середовище, а також не потрібно розробляти нові інструменти для графічного інтерфейсу. Замість цього ми розробили простий механізм інтеграції на основі повідомлень, який дозволяє користувачам обговорювати один одного та серію бандеролей, що надають графічні інтерфейси з існуючими інструментами (dbx, gdb, make, rcs, …). Результатом стало середовище FIELD. При розробці, ми розширили середовища з різними графічними видами, включаючи структурні (блок-схема, ієрархія класів) та динамічні види (дисплеї структури даних, візуалізація маси, візуалізації введення-виведення). FIELD був досить успішним. Ми використовували його протягом кількох років на наших вступних курсах програмування, він був задекларований DEC (як FUSE), і був скопійований HP (Softbench), Sun (Tooltalk), SGI та іншими.
Наше наступне середовище DESERT спробувало розширити FIELD кількома способами. По-перше, він хотів забезпечити програмісту якісне відображенням коду. Це було зроблено шляхом розширення Adobe Framemaker як редактора програм. Розширення містило формат кодування стилю Baeker-Marcus, яке було зроблено користувачем, який включав семантичний пошук символів по всій системі (і не тільки поточний файл). По-друге, ми хотіли дозволити програмісту переглядати систему по-різному, маючи змогу виділити код, пов’язаний із певною зміною чи функцією. Це було зроблено шляхом розбиття програми на фрагменти та роботи редактора з віртуальними файлами, що складаються з різних фрагментів, зібраних з фактичних вихідних файлів. Програміст міг вказати набір фрагментів, використовуючи відповідні запити. Фрагменти знаходяться під управлінням конфігурації, а зміни, внесені до віртуальних файлів, були інтегровані в оригінальні вихідні файли, якщо файли були збережені. Нарешті, ми хотіли забезпечити більш якісну візуалізацію коду та його виконання, і таким чином створила систему 3D-візуалізації, інтегровану в навколишнє середовище.
Наші недавні зусилля були зосереджені на наданні підтримки розвитку та послідовності програмного забезпечення, а не намагання забезпечити комплексне середовище програмування. Пакет – CLIME — передбачає наявність інструментів для створення та підтримки різних артефактів, які супроводжують програмну систему: специфікацію, дизайн, джерело, тестові випадки, документацію тощо. Тоді семантика кожного з цих артефактів визначається в термінах набору мета-обмежень у співвідношенні до інших артефактів. Дизайн розглядається як обмеження на джерело (і навпаки), так що клас в UML-діаграмі повинен мати відповідний клас у джерелі; правила використання мови, що обмежують форму джерела; документація повинна відповідати кодексу; тестування повинно забезпечувати код і переналаштовувати при зміні коду. Все це перевіряється поступово, коли користувач змінює артефакти, і будь-які невідповідності на шляху відображаються за допомогою графічного інтерфейсу.
Хоча CLIME концентрується на статичній структурі джерела та різних програмних артефактах, ми зрозуміли, що деякі специфікації та конструкторські артефакти пов’язані з поведінкою програми, а не самим кодом. Для цього ми розробляємо CHET, інструмент для перевірки специфіки класів та бібліотек у реальних програмних системах. CHET може приймати дані на основі розширеної автоматизації над подіями (які можуть бути отримані з діаграм UML взаємодії, контрактів класу тощо), знайти всі екземпляри специфікації у великій системі, а потім перевірити кожен екземпляр.
Наша найновіша робота передбачає новий інтерфейс для середовищ програмування Code Bubbles. Ця робота є вихідна з середовища DESERT з відображення фрагментів файлів, таких як окремі функції, і розроблена таким чином, що програміст може одночасно бачити потрібний код для поточного завдання, ефективно слідкувати за поточним робочим набором на екрані.
Добавить комментарий