Проект: Среда программирования без исходного кода

Автор этого ТЗ и эскиза: Сергей Прохоренко   Об авторе

     

English translation of this website

Статья "Почему мы пишем и храним код в текстовых файлах?"

Частичное воплощение в "Семантическом редакторе" Лаптева и Грачева

Валерий Лаптев

Semantic IDE

Видео (старое) прототипа "семантического редактора"

Свежий скриншот "семантического редактора"

Статья "Разработка учебного языка программирования и интерпретатора" (стр. 92)

Статья "Требования к современной обучающей среде по программированию" (стр. 104)

Концепция

Цели PureBuilder

Цели PureBuilder:

1. Использование PureBuilder должно начинаться еще на стадиях, предшествующих написанию программы, - для разработки архитектуры программы.

2. PureBuilder должен обеспечивать быструю, бесшовную и безошибочную интеграцию разрабатываемой программы с различными софтверными технологиями.

3. PureBuilder должен обеспечивать быстрый контекстно-зависимый доступ к разнообразной информации, необходимой при написании программ.

4. PureBuilder должен обеспечивать безошибочность разрабатываемых программ благодаря техническому ограничению безграмотных решений и халтуры программистов и уменьшению возможности случайных ошибок.

5. PureBuilder должен поддерживать разрабатываемую программу в порядке, помогающем в дальнейшем легко и безошибочно вносить в нее изменения.

 

Это всё должно значительно увеличить производительность труда при разработке и сопровождении программ и сократить количество ошибок в программах.

 

Замысел

Среда визуальной разработки PureBuilder [пю'оби'лдэ] (чистый построитель программы - англ.) - должна полностью избавить от исходного кода в текстовом виде и перейти к визуальному программированию на основе универсального языка программирования. PureBuilder относится к классу программных продуктов, который известен как "семантический редактор" или "структурный редактор".

 

Исходный код является источником синтаксических ошибок из-за возможности произвольного ввода текста. Он также является источником смысловых ошибок, так как недостаточно нагляден для безошибочного понимания программы человеком.

Разработчик программы изначально мыслит схемами (зрительными образами) и затем обычно переводит свои мысли в форму исходного кода, понятного компьютеру. При переводе разработчик программы делает ошибки. Задача состоит в том, чтобы заставить компьютер понимать схемы, избавившись от посредника в форме исходного кода. Современный графический интерфейс и тачскрин позволяют разработчику программы создавать схему на экране компьютера наиболее естественным для человека образом.

 

Но исходный код не должен быть заменен на блок-схемы алгоритмов и графические (визуальные) языки программирования, в том числе UML и ДРАКОН, так как их возможности ограниченны, использование трудоемко, а расположение на экране проблематично. Напротив, целесообразно использование автоматически генерируемых структурных схем свободной компоновки. Однако, такие схемы могут быть только вспомогательным средством, так как недостаточно подробны и выразительны для описания деталей алгоритма.

 

Заменой исходного кода должна быть, во-первых, структура из вложенных блоков для описания алгоритма (как дальнейшее развитие идеи структурного программирования), а во-вторых, таблицы для объявления переменных и констант. Они должны непосредственно определять содержимое, соответственно:

Недостатком существующих визуальных средств разработки, не использующих графические языки программирования, является то, что они не являются универсальными, а ориентированы на одну какую-нибудь узкую предметную область.

 

Переход к визуальному программированию потребует интенсивного использования компьютерной мыши. Но частое переключение между использованием мыши и клавиатуры трудоемко. Поэтому клавиатура должна использоваться в исключительно редких случаях - лишь для ввода новых идентификаторов и данных. И даже в этих случаях использование клавиатуры не обязательно, если, например, составной идентификатор набирается путем щелканья мышью по его составным частям, которые пользователь видит в облаке тегов.

 

Идентификатор должен объявляться, специфицироваться и при необходимости инициализироваться значением в соответствующей таблице "элементы документа". Причем это должен быть гибрид таблицы и дерева, так как идентификаторы относятся к объектам различных типов - с различными наборами параметров. Если идентификатор сложный, то для его построения может использоваться построитель идентификаторов. Хранится идентификатор должен в таблице имен.

 

Архитектура PureBuilder

Лучшим кандидатом на роль встроенной СУБД является PostgreSQL, причем для хранения кода во внутреннем представлении должно использоваться поле типа JSONB.

ПОПРАВКА: внутренним представлением программного кода удобнее сделать текст на пока не разработанном языке текстовой разметки программного кода.

 

Карточный интерфейс !!!

Первоначально предполагалось использовать В PureBuilder существенно модифицированный Многодокументный интерфейс со вкладками (tabbed document interface (TDI)), в котором устранены его главные недостатки. Но теперь автор (Прохоренко С.А.) кардинально изменил замысел интерфейса. Это должен быть карточный интерфейс с карточками одинаковой ширины и адаптивным дизайном.

Переход фокуса с одной карточки на другую с отображением на экране осуществляется в основном не с помощью прокрутки и поиска карточки глазами, а:

При работе с карточкой определенного типа в локальном меню будут отображаться инструменты (элементы управления), соответствующие типу карточки и типу объекта в карточке, на котором установлен фокус (выделение). На карточках всех типов должны быть одинаковые элементы управления карточками.

В рабочей области будет одновременно отображаться множество карточек открытых объектов самых разных типов (проект, модуль, функция, процедура, форма, выражение и т.д.), в том числе, отображающие структуру программы (схемы зависимостей, деревья).  В рабочей области с карточками можно делать вкладки, каждой из которых должна соответствовать папка с файлами. В одной вкладке могут быть карточки разных типов. Для отбора карточек может использоваться фильтрация по разным критериям.

Новые карточки должны попадать в открытую вкладку. Карточки могут упорядочиваться и группироваться (с цветовым выделением фона областей групп) в рабочей области вручную или автоматически - с учетом частоты использования и совершенных переходов фокуса с карточки на карточку.

Карточки некоторых типов могут иметь вкладки на всю область карточки (например, текст программы или таблица переменных/объектов программы), полосы прокрутки и раскрываться в отдельном окне или вкладке.

Вот краткий самоучитель по программированию карточек: Implementing the “Card” UI Pattern in PhoneGap/HTML5 Applications. См. также CardStack . Следует по возможности воспользоваться шаблонами карточек в фреймворке Material Design Lite

Эскиз устаревшего дизайна

 

Вкладки открытых документов (проектов, модулей, процедур и т.д.) можно перетаскивать на панель задач MS Windows в качестве открытых окон. Поэтому на разных мониторах или друг под другом могут одновременно отображаться разные вкладки.

Вкладки документов должны содержать (не показанные на рисунках) пиктограммы (значки), обозначающие тип документа (проект, модуль, процедура, функция, форма, выражение и т.д.), которому соответствуют инструментальные панели открытой вкладки.

В качестве более предпочтительного варианта рассматривается расположение вкладок документов не по горизонтали, а по вертикали:

Общие требования к дизайну: углы скругляются, количество элементов в поле зрения уменьшается, прямые и плоскости заменяются кривыми и объемом, гладкий фон заменяется неупорядоченной текстурой, цветовые акценты сразу обращают внимание на главное, а менее важное обозначается привычными природными оттенками. Поля и панели для ввода и редактирования должны иметь белый фон, а все остальные - окрашенный.

Требования к шрифту: моноширинный, без засечек, с большим количеством символов Unicode, с кириллицей, с приятным начертанием, не позволяющий спутать буквы со схожим начертанием (и ноль), не растровый.

Этим требованиям удовлетворяет шрифт Liberation Mono. От него меньше устают глаза, чем от Courier или  Consolas. В нем есть необходимые для составления выражений символы "больше или равно", "меньше или равно" и "не равно". Символы, отсутствующие в этом шрифте, должны заимствоваться из других шрифтов.

Отображение грамматики языка программирования на интерфейс PureBuilder

Функциональные возможности PureBuilder, в основном, должны соответствовать возможностям языков Go (преимущественно), Python, Rust (в части управления памятью) и языков семейства Oberon (включая Zonnon). Кроме того, должна быть реализована функциональная парадигма программирования.

Грамматика языка, в основном, включает в себя:

1. Импорт

2. Объявления

3. Последовательность инструкций

4. Выражения

5. Идентификаторы

 

Эти разделы должны реализовываться совершенно различными графическими средствами PureBuilder:

Вставка элементов из коллекции в панель структуры

Вставка шаблона элемента из панели коллекций элементов в панель структуры

Традиционные технологии drag-and-drop и щелчки по значкам «копировать» и «вставить» должны быть дополнены более быстрыми технологиями работы с мышью:

Упорядочение шаблонов элементов на панели коллекций

Шаблоны элементов на панели коллекций должны быть упорядочены. Для этого панель коллекций может быть разбита по вертикали на несколько разделов. Разделы с заголовком - свертываемые. Они могут состоять из разделов без заголовка - несвертываемых.

 

Например, операции, используемые в выражениях, должны быть упорядочены по приоритетам - чем выше приоритет, тем выше операция на панели коллекций в построителе выражений.

 

Заглушки в элементах на панели структуры

Элемент, вставленный из панели коллекций элементов в панель структуры, автоматически содержит заглушки вида «выражение», «число», «дата», «угол», «массив», «строка», «формат», «тело цикла» и т.п. аналогично тому, что происходит в построителе выражений MS Access. Текст заглушки подсказывает, что необходимо вставить вместо заглушки. Заглушки автоматически выделяются цветом. Они не считаются ошибкой, пока не производится попытка трансляции кода в форму, предназначенную для исполнения.

 

Примеры заглушек в построителе выражений MS Access и в строке формул MS Excel:

 

Пиктограммы типов контейнеров

 

 

Нумерация массивов должна начинаться не с 0, а с 1, что должно найти свое отражение и в пиктограммах.

В PureBuilder должен быть также тип "унифицированный контейнер". Контейнер – это набор однотипных элементов. К контейнерам относятся массивы, списки и типизированные файлы. См. статью В. В. Лаптев, А. Тырнава, В. В. Толасова "Об унификации агрегатных типов данных при обучении программированию"

 

Локальное меню элемента в панели структуры

Локальное меню элемента в панели структуры должно появляться при наведении курсора на элемент, без необходимости щелчка правой клавишей мыши.

 

Оно по умолчанию имеет не обычный вид, а вид ярко-голубой горизонтальной панели значков над соответствующим элементом. Значки в панели соответствуют ниже перечисленным пунктам:

 

Структура программного кода

Скобка операторного блока

Скобка операторного блока используется в PureBuilder вместо операторных скобок. Она автоматически охватывает слева весь операторный блок в коде, включая заголовок. Она имеет закругленные углы.

 

При коротком щелчке левой кнопкой мыши по скобке она действует как кнопка «свернуть/развернуть», осуществляя фолдинг кода. Сворачивание происходит до строки заголовка. Разворачивание не охватывает вложенные блоки, если те были свернуты. Операторный блок не выделяется. Локальное меню не появляется. Двойной щелчок по скобке воспринимается как два коротких.

 

Также за скобку операторный блок можно буксировать вверх или вниз по коду. Это происходит без одновременного сворачивания или разворачивания операторного блока, но буксируемый блок выделяется цветом фона, а после окончания буксировки над ним появляется локальное меню. Возможно использование залипания кнопки мыши (включается в панели управления операционной системой).

 

При задержке курсора над скобкой рядом всплывает подсказка в желтом прямоугольнике, отображающая заголовок блока.

 

При щелчке правой кнопкой мыши по скобке весь операторный блок выделяется, и над ним появляется локальное меню. При любом способе выделения операторный блок выделяется только целиком, включая вложенные блоки, но вложенный блок может быть выделен отдельно.

Для циклов скобка операторного блока имеет модифицированный вид - со стрелкой вправо в верхней части и окружностью в нижней части (см. ниже пример функции, реализующей алгоритма Эвклида для нахождения наибольшего общего делителя двух целых чисел с помощью цикла Дейкстры):

Заголовок для этой функции не нужен, потому что алгоритм функции записывается не внутри длинного программного кода, а в отдельной вкладке интерфейса. Также не нужно ключевое слово return, потому что объявление параметров и возвращаемого значения функции осуществляется в отдельной таблице в панели элементов документа.

 

Многоветочные конструкции и особенности циклов

PureBuilder должен поддерживать многоветочные конструкции:

 

Верхний левый угол - обычная длинная форма условного оператора

Нижний левый угол - переключатель (case, switch)

Верхний правый угол - цикл Дейкстры (ветка else исполняется однократно, если изначально ни одно из условий не соблюдено)

Нижний правый угол - модификация цикла Дейкстры, предназначенная для автоматного программирования в форме SWITCH-технологии

 

Значения, с которыми сравниваются выражения-селекторы, также являются вычислимыми выражениями.

Разумеется, лишние ветви в каждом конкретном случае удаляются. Для добавления или удаления пустых (!) ветвей используются всплывающие при наведении курсора графические элементы с символами "+" и "×".

 

После выполнения ветви по какому-либо условию не производится проверка следующего условия (как в switch без break в языках С/С++), а управление сразу передается ветви anyway.

 

Ветви в многоветочных конструкциях for и foreach аналогичны ветвям в многоветочной конструкции while. Более того, одноветочные for и foreach тоже могут содержать дополнительное условие while, что позволит обойтись без оператора досрочного выхода из цикла break.

 

Ветвь else обязательна. По умолчанию она генерирует сигнал отказа. См ссылку. Программист при желании может заменить генерацию сигнала отказа на иное действие.

 

Циклы с постусловиями не применяются в PureBuilder.

 

Для линейного поиска используется функция select или построитель запросов. Кроме того, для схем "полный проход" и "линейный поиск" используются специализированные конструкции со словом until. Вот эти схемы:

Полный проход

1. Задать переменным первоначальные значения (ввод и/или присвоение)

2. Перейти к первому элементу

3. Задать условие продолжения перебора элементов в цикле (while)

4. В теле цикла выполнить полезные действия

5. В теле цикла перейти к следующему элементу

Линейный поиск

1. Задать переменным первоначальные значения (ввод и/или присвоение)

2. Перейти к первому элементу

3. Задать условие продолжения перебора элементов в цикле (while) и условие ненахождения искомого элемента (and)

4. В теле цикла выполнить полезные действия (это редко требуется)

5. В теле цикла присвоить переменным номер и значение элемента

6. В теле цикла перейти к следующему элементу

7. После цикла использовать переменные с номером и значением элемента

8. После цикла, если искомый элемент не был найден, то выполнить полезные действия

Конструкция поэтапного выполнения

Эта конструкция предназначена для упрощения программ, в которых используется большое количество последовательных проверок. Она основана на реальной потребности программистов.

Нумерация этапов автоматическая.

После выполнения любой ветви else выполняется ветвь failed, а затем завершается выполнение всей конструкции progress. Лишние ветви удаляются. Возможна конструкция даже из одного этапа.

Внутри конструкции progress нет ограничений видимости имен.

 

Конструкция progress, вложенная в цикл, позволяет обойтись без оператора продолжения цикла со следующей итерации continue.

Изменение: слово progress лучше заменить словом check.

 

 

Конструкция обобщенного цикла

Эта конструкция предназначена для упрощения программ, в которых используется большое количество последовательных проверок в условии цикла, между которыми необходимо произвести какие-то вычисления. Конструкция предложена Ильей Ермаковым в несколько иной форме.

 

В PureBuilder конструкция обобщенного цикла cинтаксически аналогична конструкции поэтапного выполнения, но вместо ключевого слова progress используется ключевое слово loop. После выполнения ветви failed выполнение цикла прекращается.

 

Манипулирование ветвями многоветочной конструкции

 (возможен это альтернативный дизайн - значки и ) разворачивается или сворачивается соответствующая ветвь многоветочной конструкции. При этом треугольная стрелка поворачивается острием вниз или вправо, а на месте свернутого программного кода появляется многоточие "...". Щелчок по многоточию должен развернуть ветвь многоветочной конструкции.

При щелчке левой клавишей мыши по треугольной стрелке

При щелчке правой клавишей мыши по треугольной стрелке появляется локальное меню, содержащее, в частности, пункты «Добавить ветвь выше» и «Добавить ветвь ниже».

При щелчке левой клавишей мыши и удержании ее на треугольной стрелке ветвь сворачивается и может быть перемещена вверх или вниз в данной многоветочной конструкции.

Элементы интерфейса expansion panel не используются, так как они слишком громоздкие.

 

 

Синтаксис полного детерминированного конечного автомата

Автоматы в PureBuilder предназначены не только для работы с текстами, но и для программирования управляющих алгоритмов, и синтаксис это отражает.

Исходя из тех же соображений читабельности и возможности проговаривать программный код в PureBuilder используется ключевое слово call в операторе вызова процедуры. Это позволяет легко отыскать глазами в программном коде все вызовы процедур.

 

Выбор элемента call в "палитре" позволяет автоматизировать выбор вызываемой процедуры, а выбор элемента set в "палитре" позволяет автоматизировать выбор переменной в левой части оператора присваивания.

 

Функции не должны вызываться оператором call. По замыслу функции в PureBuilder не должны создавать неожиданностей при использовании в выражениях. Поэтому они не должны иметь каких-либо побочных эффектов - как в функциональных языках программирования. В том числе, они не должны возвращать какие-либо результаты через параметры или через глобальные переменные или как-то ещё, кроме как через использование имени функции. Поэтому гипотетический вызов функции оператором call не позволил бы функции вернуть результаты никаким образом.

Правила видимости и объявление имен

В PureBuilder не действует правило "каждый идентификатор должен быть определен выше (по тексту) его первого использования".

Параметры циклов должны получить статус локальных переменных внутри цикла, аналогичный статусу формальных параметров функции. При этом обычные правила о приоритете локальных переменных с тем же идентификатором остаются в силе. За пределами цикла его параметр не имеет никакого определенного значения. В теле цикла запрещается явное изменение параметра цикла (например, оператором присваивания).

В остальных случаях границами видимости являются границы модуля, функции или процедуры.

 

Программный проект, слои, подсистемы и модули

 

Каждая программа (проект) состоит из модулей, содержащих функции и процедуры, которые могут быть сложным образом связаны между собой, в том числе через границы модулей (с помощью экспорта и импорта переменных в режиме "на чтение"). PureBuilder берет на себя отслеживание этих связей, поддержание целостности и непротиворечивости программы и представление её структуры программисту с помощью древовидных схем наподобие вкладки "Зависимости объектов" в Microsoft Access и/или графов. Древовидная структура освобождает программиста от необходимости заботиться о расположении элементов на экране, хотя граф может быть более наглядным. Щелкнув по линии, изображающей связь, можно специфицировать ее.

 

Модули не могут быть вложенными в другие модули. Модули можно объединять в подсистемы и извлекать из подсистем перетаскиванием мышью. Подсистемы могут вложенными друг в друга.

Все модули и подсистемы группируются в слои, которым программист дает наименования. По умолчанию слоям даются наименования Crosscutting Concerns (самый нижний), Infrastructure, Data Access, Business Logic, Services, User Interface (самый верхний), которые можно изменить. Наименования слоев не используются в каких-либо составных идентификаторах в программе. Слои не могут быть вложенными друг в друга. Пустые слои можно удалять. Можно вставлять новые пустые слои сверху или снизу от выделенного произвольного слоя.

По умолчанию модуль/подсистема помещается в самый верхний из имеющихся слоев. Можно перемещать подсистемы и модули между слоями вниз или вверх с помощью мыши. Модули и подсистемы более нижних слоев не могут использовать никакие объекты модулей и подсистем более верхних слоев. Перемещение модуля/подсистемы в более нижний слой или или импорт из других модулей констант, переменных, процедур/функций и иных объектов допускаются, если не нарушается это требование. В противном случае пользователю выдается подробное сообщение.

 

Проектная документация (относящаяся как к программе, так и к аппаратуре, объекту управления, человеку-оператору) должна быть составной частью каждого программного проекта - с возможностью по гиперссылкам переходить к конкретным местам программы и интернет-страницам. Проектная документация (ТЗ, спецификация, руководство пользователя и т.д.) в свернутом виде должна отображаться как пиктограммы документов, связанные линиями гиперссылок, в том числе, с пиктограммами модулей.

 

Документы проектной документации должны создаваться непосредственно в PureBuilder и содержатся в файлах модулей. Кроме того, должна поддерживаться динамическая вставка объектов из PureBuilder (программного кода, тестовых данных, интерфейса и т.д.) в такие документы, см. рисунок ниже:

 

Нумерация состояний и переходов («1 to 2» и т.п.) в отображаемом программном коде синхронизируется с таблицей переходов, являющейся частью программы. Заполнение, просмотр и редактирование таблиц переходов может осуществляться в специальной вкладке, а также с помощью экспорта/импорта из таблиц, совместимых с Microsoft Excel. Во вкладке возможно отображение как собственно в виде таблицы переходов, так и в виде графа (т.е., диаграммы состояний) - с переключением между видами. Возможен переход из программного кода в таблицу переходов (или в диаграмму состояний) и обратно по гиперссылкам в обозначениях состояний и переходов. Изменения в программном коде автомата и в таблице переходов (диаграмме состояний) осуществляются синхронно.

 

Для таблиц переходов имеется специальный структурный тип данных. Таблица переходов является локальной константой процедуры/функции. В одной и той же процедуре/функции может быть несколько экземпляров программного кода автоматов, связанных с одной и той же таблицей переходов (диаграммой состояний). Можно делать копии таблицы переходов с различными именами в одной процедуре/функции, или с любыми (в том числе, совпадающими) именами - в различных процедурах/функциях.

 

Компилятор и среда времени выполнения выявляют явные и возможные ошибки в таблице переходов автономно и в сопоставлении с массивом/строкой входных условий/символов. Начальное состояние должно быть указано в таблице переходов и/или в секции start, которая имеет более высокий приоритет. Первый переход осуществляется после выполнения действий для начального состояния. Заключительные состояния должны быть указаны в таблице переходов.

Если (1) достигнуто заключительное состояние или (2) если исчерпаны входные условия/символы, но заключительное состояние не достигнуто, то итерации прекращаются, а управление передается на следующую после блока автомата строку. В первом случае секция acceptance возвращает результат true, а во втором – false.

 

Значение переменной состояния не может быть изменено оператором присваивания или другим аналогичным способом, и является неопределенным после завершения работы автомата. Во время работы автомата оно может быть возвращено специальной функцией, получающей в качестве аргумента имя таблицы переходов.

В будущем компилятор должен быть способен осуществлять оптимизацию указанной программистом таблицы переходов, добиваясь минимального количества состояний.

Гипертекстовые заголовки (комментарии) блоков программного кода

Циклы и ветви и этапы управляющих конструкций могут иметь гипертекстовые заголовки (по сути, комментарии) с различными отступами и выделением шрифтом и графическими элементами.

Таблицы для ввода фактических параметров

В PureBuilder ввод фактических парметров функций и процедур должен осуществляться в выпадающей табличной форме, содержащей формальные параметры, комментарии и гиперссылки на разделы справки, содержащие описание соответствующих параметров.

 

 

Автоматическая генерация inline-процедур из выделенного программного кода

В PureBuilder должны быть средства автоматического преобразования выделенного кода в инлайновую процедуру, размещаемую (как и все другие процедуры) на отдельной вкладке. Это облегчит восприятие разветвленных алгоритмов, в которых приходится "перескакивать" взглядом через побочные ветви с большим объемом программного кода.

 

 

Встроенный язык

Безопасность встроенного языка

У пользователя должна быть возможность заранее сконфигурировать тот диалект (подмножество языка), на котором будет осуществляться разработка, например, заблокировав удобные, но небезопасные или ресурсоемкие средства. Удобно вынести описание подмножества языка в отдельный файл, что позволит соблюдать единые стандарты стиля программирования в команде разработчиков.

Добавляемые языковые конструкции не должны расцениваться как небезопасные, в частности, таким документом, как NASA Software Safety Guidebook. В соответствии со структурной парадигмой программирования в PureBuilder не применяются операторы перехода goto, операторы досрочного выхода exit, break, exit when, continue, return, операторы генерации исключительной ситуации throw (допускается в отладочном режиме) и raise, а также аналогичные им, функции assert (которые опасны обрушением всей программы из-за отказа второстепенной процедуры или, будучи отключенными, пропускают недопустимые значения переменных). В соответствии с функциональной парадигмой программирования в PureBuilder не применяются глобальные и статические переменные.

 

Синтаксис встроенного языка

По замыслу встроенный "язык" среды визуальной разработки не наследует синтаксис какого-то из существующих языков программирования, включая Си. Это не полноценный язык программирования, а скорее надписи на графических элементах среды визуальной разработки. Надписи должны быть легко проговариваемы, поэтому используется принцип "как слышится, так и пишется", а сокращения слов не допускаются (в отличие от общепринятых аббревиатур и математических символов). Многие служебные слова заменяются графическими элементами управления с изменяемой степенью подробности.

Необходимо воспользоваться возможностью изображать традиционно составные ключевые слова (elsif, foreach и т.п.) по правилам английского языка - как несколько слов. Наоборот, составные обозначения <=, >= и т.п. должны быть заменены одним символом Unicode. Знаки операций, воспринимаемые с затруднением, должны быть заменены словесными обозначениями (and, not и т.п.). Знак решетка (#), используемый для обозначении операции "не равно", должен быть заменен символом "не равно" Unicode (U+2260). Используются математические знаки операций (например, косой крестик - для умножения) вместо их аналогов, принятых в программировании (звездочка).

Операторных скобок "begin end" или { } не должно быть, как, например, их нет в языке Python. Не должно быть и каких-то ключевых слов (end, начальные ключевые слова, записанные буквами в обратном порядке), обозначающих конец синтаксической конструкции - для этого должна использоваться скобка операторного блока вместе с автоматическими отступами. Также не используется пустой оператор. Так как все операторы записываются на отдельных строках, то не используются символы ";", разделяющие операторы или обозначающие конец оператора.

 

Не должно быть скобок комментариев, так как все комментарии привязаны к соответствующим элементам программы, включая операторы (имнструкции), располагающиеся на отдельных строках. Обычная практика, когда можно "закомментировать" программный код, чтобы сделать его недоступным компилятору, должна быть заменена на специальную конструкцию, которая одним щелчком мыши делает программный код доступным/недоступным для компилятора с соответствующим выделением этого кода.

Все ключевые слова должны набираться в нижнем регистре жирным шрифтом. Подсветка синтаксиса использоваться не должна. Наоборот, цвет букв должен использоваться для временного выделения одинаковых идентификаторов или переменных одного типа. Кроме того, раскрашиваться должны экспортируемые переменные и выходные параметры процедур при вызове этих процедур.

Перед идентификаторами должны автоматически появляться иконки, обозначающие тип переменной или константы.

В выражениях автоматически вставляются цветные парные скобки (вложенные скобки меньше объемлющих), обозначающие приоритеты выполнения операций. После завершения редактирования выражения цветные скобки становятся обычными. При наведении курсора на скобку автоматически выделяется пара скобок.

Элементарные типы данных PureBuilder

Элементарные типы данных PureBuilder должны быть совместимы с типами данных:

Кроме того, должны поддерживаться такие типы данных, как UUID, ULID, хеш и веб-адрес.

Ассоциативные массивы с UUID-ключами

В PureBuilder должен быть определен специальный тип данных - ассоциативный массив с ключом, имеющим тип UUID. Для таких ассоциативных массивов необходим специальный упрощенный синтаксис с квадратными скобками и встроенные функции.

Элементами такого ассоциативного массива могут быть данные любого типа, например, записи или ассоциативные массивы.

Элементами такого ассоциативного массива могут быть одновременно данные нескольких типов. Сведения о типе данных конкретного элемента хранятся вместе с элементом и могут быть получены и использованы во время исполнения программы.

Связанные данные с одинаковыми значениями UUID-ключа в разных ассоциативных массивах должны обновляться синхронно, и система также должна отслеживать и обеспечивать одинаковость их значений (в частности, для файлов - путем сопоставления хешей) и уникальность составного ключа (как в реляционных СУБД).

Элементами такого ассоциативного массива не упорядочены. Однако они могут быть помещены в очередь, стек и т.п.

Такой ассоциативный массив может быть проиндексирован подобно таблицам баз данных с целью ускорения доступа к элементам.

Поддержка работы с матрицами

В PureBuilder поддерживается работа с матрицами. В качестве образца может быть использован набор операций в языке программирования Active Oberon, а также в языке программирования Zonnon.

Операторы присваивания и вызова процедуры

Вместо значков "=", ":=" или "", которые зрительно теряются в программном коде, и которые легко спутать с операциями, в PureBuilder используется конструкция set variableto expression (как в AppleScript или в Scratch). Это тем более удобно, что в русском языке нет хорошего термина, который можно было бы проговорить при чтении программного кода. Обычно используемое слово "присвоить" крайне неудачно, так как в нормальном русском языке означает нечто совершенно иное - завладеть чем-либо, приписать себе авторство чего-либо или наградить чем-либо (последнее значение - только на официально-канцелярском языке).

 

Модуль не содержит непосредственно операторных последовательностей, но может содержать указания на (не обязательно содержащуюся в нем) процедуру или функцию, выполняемую при загрузке модуля, и/или на (не обязательно содержащуюся в нем) процедуру или функцию, выполняемую при выгрузке модуля из памяти.

 

Для модулей не существует понятий "раньше-позже", "вышестоящий-нижестоящий" и "вложенный-объемлющий". Эти понятия остаются на более низком уровне: в процедурах и функциях. Модули служат лишь для удобной группировки функций и процедур, а также для их одновременной загрузки/выгрузки из памяти во время исполнения программы. Зависимость между модулями - это использование переменных, функций и других объектов одного модуля другим.

 

Высокоуровневые представления (проект, подсистема, модуль) должны отображаться двумерными графами на панели структуры, а кроме того, таблицами содержимого. Графы не должны отображать очередность (следование, ветвление, циклы), а только лишь состав элементов и зависимости между ними. Щелкнув по значку элемента или зависимости, можно "провалиться" на уровень ниже (процедура, функция), где увидеть очередность выполнения инструкций алгоритма.

Объем, внутренняя сложность, количество изменений модуля должны отображаться размером, формой и цветом значка.  Теснота и направление связей между модулями должны обозначаться разного вида стрелками.

Модуль является полноценным электронным документом - зашифрованным криптостойким шифрованием и подписанным электронной подписью и timestamp по UTC. Все модули одинакового ранга и формата, кроме модулей, описывающих модульную архитектуру программы.

Каждый модуль содержится в отдельном файле, не предназначенном для чтения в текстовых редакторах. Программист перед продолжением работы с программным проектом должен указать конкретный файл с модулем, описывающим модульную архитектуру программного проекта. Таких файлов в одной папке может быть несколько. Файлы модулей, описывающих модульную архитектуру программного проекта, имеют специальное расширение имени.

 

Функции и процедуры

 

В PureBuilder функции и процедуры не могут быть вложенными в другие функции и процедуры.

В PureBuilder функции не только имеют единственное возвращаемое значение, ассоциированное с именем функции, но и, в отличие от процедур, для функций не допускается никаких побочных эффектов. Для процедур побочные эффекты допускаются только путем изменения значений переменных через параметры (при передаче параметра по ссылке) и только если эти процедуры объявлены как имеющие побочные эффекты. Переменные, объявленные снаружи функций и процедур, доступны внутри этих функций и процедур только в режиме "для чтения".

 

Все переменные в PureBuilder строго локальные, то есть объявляются не непосредственно в модуле, а в процедурах и функциях - в табличном виде в панели элементов структуры. Непосредственно в теле процедуры или функции (на панели структуры) содержатся только последовательности операторов.

 

Принцип "сначала объяви, потом используй" в PureBuilder неприменим. В процедуре/функции объявления делаются в одном месте - в таблице на панели элементов структуры, а алгоритм записывается совершенно в другом месте - на панели структуры. Естественно, что к моменту компиляции должно быть готово и то, и другое, но что из них по времени раньше - безразлично. Наполнение их содержанием происходит параллельно. А чисто пространственно объявления располагаются даже ниже алгоритма.

Логические функции могут задаваться в табличной форме, аналогичной построителю запросов в MS Access, или в форме таблиц истинности. Такие функции очень удобны для применения в качестве условий в условных операторах и операторах циклов.

При отображении таблиц истинности необходимо использовать прокрутку, перемещения аргументов, устойчивую сортировку по нескольким аргументам щелчками по их названиям в произвольном порядке и протяжку ячеек для копирования содержимого. Таблицу истинности удобнее "положить на бок", разместив аргументы в левом столбце и закрепив в поле зрения строку со значениями функции.

При завершении функции/процедуры (независимо от того, возник ли сигнал отказа) должны быть автоматически освобождены все ресурсы, занятые этой функцией/процедурой. Например, должны быть закрыты открытые в ней файлы. Ответственность за это возлагается на компилятор, действие которого аналогично действию конструкции using в C#.

Стандартный ввод и вывод данных 

В PureBuilder стандартный ввод и вывод данных осуществляется в следующих формах:

PureBuilder имеет текстовый и табличный редактор для ввода, просмотра, редактирования данных, а также конверторования данных в/из различных форматов.

 

 

Генерация и обработка сигналов отказа

 

Сигналы отказа в PureBuilder являются переменными логического типа и заменяют собой исключения и функции Assert и Exit в языках программирования, а также создаваемые программистом коды ошибок.

В вызывающей процедуре/функции программист может произвольным образом (обычно в условных операторах, в том числе вложенных, и даже в заголовках циклов) использовать сигналы отказа, которые считаются автоматически объявленными и имеют идентификатор вида:

Необходимо автоматически информировать программиста, какие из сигналов отказа, могущих возникнуть в вызываемой процедуре/функции, учтены в вызывающей процедуре/функции. Для этого около идентификатора процедуры/функции должна появляться всплывающая табличка со всеми возможными сигналами отказа (включая реально возможные прерывания операционной системы) и обозначениями действий ("не учтено", "учтено", "игнорировать") напротив них. Идентификаторы процедур/функций, имеющих хотя бы один неучтенный сигнал отказа, должны автоматически помечаться.

В вызываемой процедуре/функции сигналы отказа используются один раз – только в качестве параметра в операторе escape(имя_сигнала_отказа) – и без указания имени вызываемой процедуры. Они не могут каким-либо ещё образом использоваться в вызываемой процедуре.

Как и оператор Exit в языках программирования, оператор escape(имя_сигнала_отказа):

Но, в отличие от оператора Exit (отсутствующего в PureBuilder), оператор escape(имя_сигнала_отказа):

При разработке критических программ или отсутствии жестких ограничений по используемым программой ресурсам передача объектов в процедуру/метод по ссылке должна быть запрещена на уровне среды разработки, кроме доступа к базе данных с возможностью отката неудачной транзакции. Если в такой программе используются крупные объекты, то ее придется изменить:

Опасные операторы и части программы, которые могут вызвать прерывания операционной системы (ошибка выделения памяти, ошибка оператора присваивания или ввода/вывода, деление на ноль, выход индекса за границу массива и т.д.) или иные сигналы отказа, следует выделять в отдельные процедуры/функции по следующим причинам:

Сигналы отказа также автоматически генерируются, если входные или выходные параметры, возвращаемое значение и локальные переменные функции/процедуры не соответствуют ограничениям, заданным при их объявлении. Имена сигналов отказа вносятся программистом в таблицу объявлений. Соответствующие проверки осуществляются при вызове и при завершении функции/процедуры.

В деструкторе объекта сигнал отказа объекта (в отличие от сигнала отказа самого деструктора) генерируется при выполнении оператора destroy(имя_сигнала_отказа). При этом происходит бесследное уничтожение всего объекта.

Сигналы отказа записываются в специальный стандартный журнал (аналог "черного ящика" самолета). Не всегда последствия ошибок времени исполнения можно предотвратить, но можно будет хотя бы сделать какие-то выводы.

  

Легковесные процессы и обмен сообщениями между ними

В PureBuilder функции, процедуры и объекты (в парадигме ООП) являются легковесными процессами, имеют отдельные "кучи" в памяти с отдельной "сборкой мусора" и могут исполняться параллельно на разных ядрах процессора или разных компьютерах, объединенных в сеть. Реализован обмен сообщениями между легковесными процессами на основе модели акторов, аналогично языку Erlang.

PureBuilder имеет собственную виртуальную машину, подобно BEAM в языке Erlang.

Управление памятью

В PureBuilder используются автоматическая память и сборка мусора (точная, не "консервативная"). Программисту также предоставляются возможности использовать динамические многомерные массивы, предотвратить сборку мусора в неподходящий момент, а также форсировать освобождение памяти указанными программистом объектами не дожидаясь сборки мусора, если эта память одновременно не используется другими объектами. Для ускорения работы программы программист может использовать передачу значения переменной в виде константного параметра в функцию или процедуру по ссылке (т.е., без копирования) вместо передачи по значению (с копированием).

 

Предотвращение типичных ошибок в программах

В PureBuilder используются следующие средства предупреждения типичных ошибок в программах:

Парадигмы программирования

Мультипарадигменность

PureBuilder должен, оставаясь по-возможности лаконичным, наглядными средствами поддерживать разнообразные (но не любые существующие) парадигмы программирования:

Средства PureBuilder, относящиеся к какой-либо парадигме программирования, должны отображаться на отдельной вкладке или в виде скобки операторного блока соответствующего цвета.

ООП

Полиморфизм

В PureBuilder полиморфизм обеспечивается следующим образом. Для каждого метода в таблице методов класса программист указывает псевдоним, по которому вызывается этот метод. Разные методы разных классов, обладающие похожим действием, могут иметь общий (одинаковый) псевдоним. Метод не может быть вызван непосредственно по своему имени, а только по псевдониму. Всякий раз при использовании псевдонима будет вызываться тот из методов с общим псевдонимом, который содержится в классе объекта, к полям которого применяется псевдоним. По умолчанию псевдоним создается автоматически на основе имени метода и может быть отредактирован программистом разом во всей программе (рефакторинг).

 

Классы

Классы (типы объектов) в PureBuilder принадлежат тому или иному модулю. Класс изображается в виде таблицы полей, таблицы методов и таблицы родительских интерфейсов. Программист добавляет в таблицы класса поля, методы и родительские интерфейсы, принадлежащие данному модулю или другим модулям и специфицированные именем модуля. Поля и методы объявляются в модуле независимо от классов, которые могут их содержать.

 

Непосредственное добавление полей и псевдонимов методов

Программист может добавить в таблицы класса поля (переменные) и псевдонимы методов (процедур и функций) непосредственно, без сохранения сведений о родительском классе. При этом поиск полей и псевдонимов методов, необходимых для создания нового класса, автоматизирован, а соответствующая ячейка в таблице класса не содержит имени родительского класса.

 

Копирование полей и псевдонимов методов из родительских классов

Программист может добавить в соответствующие таблицы класса все поля и псевдонимы методов одного или нескольких других классов, указав имена этих классов. Эти поля и методы автоматически помечаются в таблицах именем родительского класса, от которого они непосредственно получены. Имя родительского класса в таблице не может быть изменено программистом.

Программист может произвольно отключать в таблицах класса некоторые поля и псевдонимы методов, без удаления, и снова их включать. Отключенные поля и псевдонимы методов не используются в программе, но могут быть скопированы в дочерние классы в отключенном состоянии.

Никакие изменения (добавление, удаление, отключение, включение) в родительских классах (в отличие от связанных интерфейсов) не наследуются автоматически в классах-потомках.

Тем не менее, программист может явным образом передать изменения, уже произошедшие в родительских (в том числе, библиотечных) классах, в классы-потомки. Если поле или псевдоним метода в родительском классе были удалены, отключены или включены (а в дочернем классе они находятся в противоположном состоянии), то такие поля и псевдонимы методов выделяются соответствующим образом в дочернем классе без автоматического удаления, отключения или включения. Если поле или псевдоним метода были добавлены в родительский класс, то они автоматически добавляются в дочерний класс в отключенном состоянии и выделяются как добавленные, и программист может их включить. Для доступа с целью внесения изменений ко всем классам-потомкам данного класса (во всех поколениях) используется дерево зависимостей объектов программы. Классы-потомки, в которых программист может принять или отклонить унаследованные изменения, автоматически выделяются. Таким образом, хотя наследование и не применяется в явном виде, но программисту предоставляются удобства, свойственные наследованию.

Программист может частично или полностью разорвать отношения наследования, сделав некоторые или все ячейки таблицы с именем соответствующего родительского класса пустыми.

 

Постоянное связывание с родительскими интерфейсами (композиция или агрегирование)

Если программист добавил один или несколько классов (например, библиотечных) в таблицу родительских интерфейсов, то впоследствии программист не сможет удалять, отключать или включать унаследованные от этого интерфейса поля и псевдонимы методов. Но эти поля и псевдонимы методов могут быть удалены, отключены или включены в тех классах, куда они будут скопированы.

Для решения проблемы «хрупкости базового класса» классы, от которых образуются объекты, не могут быть добавлены в таблицу родительских интерфейсов, а от классов, добавленных в таблицу родительских интерфейсов, нельзя непосредственно создавать объекты (экземпляры классов, переменные). Исключение составляют библиотечные классы, на которые оба этих ограничения не распространяются. Интерфейсы и библиотечные классы соответствующим образом выделяются по отношению к другим классам.

 

Устранение дублирования полей и псевдонимов методов

Если имеются дублирующие одинаковые поля и псевдонимы методов, полученные от разных родительских классов, содержащиеся в связанных родительских интерфейсах или добавленные непосредственно (без копирования полей и псевдонимов методов какого-то класса), то они автоматически выделяются как ошибочные. Программист должен отключить или удалить дублирующие поля и псевдонимы методов.

 

Сравнение классов

В процессе разработки программы содержимое классов можно сравнивать путем конструирования запросов, аналогичных запросам к базе данных.

 

Проверки целостности классов

PureBuilder осуществляет проверки во время конструирования программы или компиляции: (1) объявлены ли в новом классе все необходимые поля, обрабатываемые при вызове всех его псевдонимов методов (выдача ошибки "нет поля или лишний псевдоним метода"); (2) есть ли в новом классе поля, не обрабатываемые ни одним из его псевдонимов методов, кроме конструктора (выдача ошибки "нет псевдонима метода или лишнее поле")?

 

Создание объектов (экземпляров классов)

Объекты (экземпляры классов) в куче (динамической памяти) создаются с помощью оператора new, а объекты в стеке (статической памяти) создаются путем объявления в соответствующей таблице – как и переменные базовых типов.

 

 

Программирование по контракту

В PureBuilder поддерживается программирование по контракту.

В таблице формальных параметров и возвращаемого значения функции/процедуры имеются столбцы Предусловие и Постусловие. Если параметр является исключительно входным (передача по значению), то постусловие автоматически помечается как недоступное. Если параметр является исключительно выходным, то предусловие автоматически помечается как недоступное. Для возвращаемого значения функции предусловие автоматически помечается как недоступное.

В таблице объявления переменных имеется столбец Инвариант, проверка условия которого происходит при экспорте переменной в другой модуль, а также при использовании в качестве фактического параметра и при входе и выходе из циклов.

В таблице импорта переменных имеется столбец Предусловие, проверка условия которого происходит при импорте соответствующей переменной.

Работа в среде

Сохранение кода на жесткий диск

Сохранение кода на жесткий диск осуществляется путем записи во встроенную базу данных, в которой формат хранения данных почти совпадает с внутренним представлением PureBuilder (абстрактное синтаксическое дерево в табличной форме и таблица символов). Преимущества:

Поддержка последовательных версий программных проектов

Исходный программный код каждого программного проекта должен сохраняться в отдельный файл, содержащий базу данных. В качестве СУБД рекомендуется PostgreSQL. В базе данных программного проекта должна храниться не только текущая версия проекта, но и полная история его изменений. Это позволит производить сравнение версий и откат изменений на любую глубину как в Википедии.

Также на основании истории изменений можно наглядно воспроизвести последовательность работы программиста в виде автоматической анимированной презентации или со сменой последовательных кадров вручную. Это, например, позволит преподавателю программирования увидеть ход мыслей студента.

Удаленные, модифицированные и новые элементы должны автоматически выделяться соответствующими цветами. Щелкнув по модифицированному элементу, можно посмотреть, что же изменилось в его структуре.

Сравнение версий и откат изменений должны быть возможны как в целом по проекту, так и по отдельному модулю, функции и т.п.

Если в ранней версии содержатся части программного кода, которые должны быть возвращены в текущую версию, то это может осуществляться копированием в буфер обмена (где программист может подвергнуть программный код рефакторингу) и вставкой в текущую версию проекта. С той же целью может быть использован и механизм, аналогичный средству экспорта и импорта таблиц, запросов и других объектов в Microsoft Access. В случае совпадения идентификаторов копируемых модулей, функций и т.п. с идентификаторами в текущей версии проекта конфликт должен разрешаться по выбору программиста: перезаписать, записать с новым именем или отменить изменения.

Если в проекте участвуют несколько программистов, то изменения помечаются их именем как в Википедии.

Изменения каждого модуля, функции и т.п. сопровождаются нередактируемым автоматическим комментарием в таблице, отображающей изменения, например, «Произведен откат к версии от 14.09.2012 13:57». Может быть также добавлен комментарий программиста, а в необходимых случаях PureBuilder может требовать от программиста ввода комментария.

Любую версию можно сохранить в отдельный проект с новым именем (форк, то есть, параллельный вариант).

Разработка программы методом "сверху вниз" и поддержка стадий готовности

PureBuilder должен обеспечивать пошаговое проектирование программы методом "сверху вниз" с последующей реализацией "снизу вверх" и от потребителя данных к источнику данных.

Значок каждого проекта, модуля, функции и т.п. сопровождается дополнительным значком, обозначающим стадию готовности: от заглушки, которая ничего не делает и обозначается контурным обесцвеченным значком, или макета, который имитирует еще не реализованный объект, до принятого заказчиком кода. В частности, соответствующими значками должен помечаться программный код, не содержащий ошибок времени компиляции, и программный код, не содержащий ошибок при последнем тестировании на указанном наборе данных. Также должны отображаться дата и время достижения текущей стадии готовности.

Поддержка списка ToDo

Список ToDo должен храниться в базе данных проекта – как текущая версия списка ToDo, так и полная история его изменений, в том числе изменений стадии готовности пунктов списка ToDo. Список ToDo может просматриваться как в целом по программному проекту (в порядке очередности исполнения), так и в разрезе модулей, функций и т.п., к которым относятся соответствующие пункты списка ToDo (т.е., иерархически).

 

Поддержка форков (веток, параллельных вариантов) программных проектов

PureBuilder должен обеспечить сравнение двух проектов, имеющих общего предка, а также копирование (по выбору программиста) несовпадающих частей программного кода из одного проекта в другой – аналогично принятию исправлений в сравниваемых документах Microsoft Word.

Однако при этом PureBuilder может ошибочно находить мнимые отличия из-за измененных идентификаторов или общей структуры сравниваемых проектов. Для исправления таких ошибок программист может в ходе сравнения проектов производить рефакторинг или изменение общей структуры любого из двух проектов.

При копировании модуля, функции и т.п. из одного проекта в другой история изменений этого модуля, функции и т.п. тоже копируется.

 

Поддержка комментариев к программному коду

Комментарии к программному коду хранятся в базе данных проекта в привязке к модулям, функциям, параметрам и т.п. Комментарий может относиться к строке алгоритма, к строке объявления или к строке свойства объявленной переменной или иного объявленного объекта программы. Для комментариев поддерживается стандартная структура, например: необходимость элемента, способ реализации элемента и обоснование выбора, достоинства и недостатки, область применения, условия применения и т.п. Стандартная структура комментария зависит от типа элемента (модуль, функция, цикл и т.п.). Комментарии могут содержать гиперссылки и внедренные в текст маленькие пиктограммы.

 

 

Поддержка тестирования и отладки 

Тестирующие модули, тестовые данные и результаты тестирования с комментариями хранятся в базе данных проекта в привязке к соответствующей версии проекта, а также к тестируемому модулю, функции и т.п.

 

При отладке программ именованный ввод тестовых данных и вывод результатов тестирования осуществляется в табличной форме в формате, совместимом с Microsoft Excel.

 

PureBuilder должен иметь встроенные статические и динамические отладчики. Отладчики должны быть спроектированы таким образом, чтобы препятствовать безответственному стилю программирования "методом тыка".

Экспертная система

Вопрос о пользовательском интерфейсе экспертной системы требует дальнейшей проработки. В качестве примера можно рассматривать интерфейс веб-сервиса Яндекс.Маркет. Пользовательский интерфейс экспертной системы должен располагаться на панели задач.

Твердые копии

Если достаточно распечатки экрана нажатием одной клавиши и/или сохранения картинки экрана на жесткий диск, то это безусловно должно быть реализовано в семантическом редакторе.

 

Необходимо также предусмотреть возможность разворачивания отдельных панелей и вкладок на весь экран и их сохранения целиком (в том числе частей, вылезающих за границы экрана) в отдельных файлах (гипертекстовых, векторных и растровых) и/или распечатывания.

 

Требования к интерфейсу

Мгновенная навигация по коду с помощью закладок

PureBuilder должен быть оснащен экспертной системой (не путать со справкой по программному продукту PureBuilder!), помогающей сделать правильный выбор программно-аппаратной платформы (аппаратная архитектура, ОС, эмуляторы и средства виртуализации, файловая система, фреймворк), СУБД, middleware, алгоритма, типа и структуры данных, интерфейса с другим программным обеспечением, интерфейса пользователя, элементов стандартной библиотеки (функций, процедур).

 

PureBuilder должен обеспечивать мгновенную навигацию по коду с помощью закладок - как внутри программного проекта, так и между программными проектами.

Закладки должны размещаться на отдельной панели - непосредственно или в папках. При щелчке по закладке или значку, обозначающему какой-либо элемент программного проекта, должна открываться соответствующая этому элементу вкладка в главном окне.

Вкладки в главном окне

Закладка должна указывать на определенное место в программном проекте, и это место в программном проекте должно отображаться в специализированной вкладке.

Например, функция должна отображаться во вкладке "Функция". Во вкладке "Проект" должен быть граф (или таблица), показывающий зависимости модулей и объединение модулей в подсистемы. Во вкладке "Модуль" должен быть граф или таблица функций и процедур, входящих в модуль (способ и степень подробности отображения выбирает пользователь). Каждая большая вкладка отображает содержимое объекта соответствующего типа. Поскольку содержимое объектов разных типов различается кардинальным образом, то изображение этого содержимого, действия над ним и, соответственно, интерфейс в каждой вкладке особенные. Малые вкладки позволяют изменить способ и степень подробности отображения.

Открытые ранее вкладки элементов должны укладываться в штабеля (папки, стопки, группы - устоявшегося русского перевода нет) вкладок (модули отдельно, функции отдельно и т.д.), соответствующие типу элементов и имеющие соответствующий значок. Похожий механизм под названием tab stacking реализован в браузере Opera 11. Но в PureBuilder штабель вкладок должен раскрываться в виде выпадающего списка при нажатии находящегося на нем значка

. При нажатии на сам штабель должна открываться последняя вкладка, с которой осуществлялась работа. При нажатии на пустой штабель должна открываться новая вкладка.

Локализация

Текстовые элементы интерфейса (операторы и другие служебные слова), которые в традиционных языках программирования являются частью исходного программного кода, должны быть на английском языке. Прочие элементы интерфейса должны "на лету" переключаться между русским (или другим) языком и английским языком.

Идентификаторы (в том числе, составные и идентификаторы файлов) должны иметь внутреннее программное представление в формате  UUID - истинно случайную строку символов, отвечающую требованиям уникальности и совместимости с другими программными платформами. При изменении версии ПО UUID не должен изменяться. Помимо UUID, идентификатор может иметь несколько написаний для соответствующих естественных языков (английского, русского, китайского и т.п.). Кроме того, идентификаторы могут иметь сокращенные наименования и псевдонимы. Пользователь при настройке PureBuilder указывает, в каком порядке будут применяться написания идентификаторов на разных языках. Например, при отсутствии русского написания идентификатора будет применяться английское написание. Пользователь может добавлять написания идентификаторов на разных языках, когда это ему удобно и в любом месте, где встречается идентификатор.

UUID - идентификаторы также должны использоваться для идентификации библиотечных или сторонних программных компонентов.

Например, русское написание идентификатора складскойЗапасНаНачалоНедели, английское написание идентификатора warehouseStockOnTheWeekend, а внутреннее программное представление, созданное на основе генератора случайных чисел, - 550e8400-e29b-41d4-a716-446655440000. Внутреннее представление нужно как одно из ключевых полей в таблице с написаниями идентификаторов на разных языках. Пока программа разрабатывается и отлаживается, доступны все внешние представления идентификатора с указанием на язык. После окончательной компиляции в байт-коде остается только внутреннее программное представление 550e8400-e29b-41d4-a716-446655440000.

"Плюсов" много:

Если сгенерировалось внутреннее программное представление, которое уже имеется, то процесс повторяется. Чтобы это не происходило часто, и чтобы уменьшить вероятность конфликта имен, должны генерироваться истинно случайные (на основе измерения дрожания "мыши" или сигнального шума), а не псевдослучайные числа (вычисления по повторяющемуся алгоритму).

Локализация комментариев аналогична локализации идентификаторов.

Эргономика

PureBuilder должен работать на мониторах с диагональю 15.6 дюймов с соотношением сторон 16:9 и разрешением 1366x768, а также на мониторах большего размера. В перспективе интерфейс должен быть приспособлен для планшетных компьютеров с мультитачем. В частности, должны применяться руководства разработчика по использованию тачскрина.

 

В PureBuilder размер шрифта должен автоматически масштабироваться до удобочитаемого физического размера, причем пользователи с ослабленным зрением должны иметь возможность увеличить физический размер шрифта в разумных пределах. Это в равной степени относится к элементам интерфейса, к программному коду и к данным.  

Стратегия развития

Обеспечение обратной совместимости

Все рабочие версии PureBuilder должны иметь такую полную обратную совместимость, которая не препятствует развитию средств разработки. То есть, код и данные, созданные в ранних версиях, должны безошибочно читаться более поздними версиями, а устаревшие средства разработки не должны использоваться в свежих версиях.

 

Первые - нерабочие - версии не обязательно должны обеспечивать обратную совместимость, но тестирование средств обратной совместимости необходимо произвести еще на нерабочих версиях.

 

Полная обратная совместимость, не препятствующая развитию, будет обеспечиваться следующими средствами:

Обновление онлайн

PureBuilder должен обновляться онлайн, в том числе, должны обновляться стандартная библиотека и экспертная система.

Поддерживаемые платформы

PureBuilder должен транслировать программный код для следующих платформ:

Ссылки