Почти все книги и уроки по Java для новичков начинаются с описания ООП: какой он замечательный с великолепный. Понятно, поскольку в Яве просто невозможно любое другое программирование, кроме как объектно-ориентированное, то вначале предлагается освоить 40..80 страниц безумных аналогий с иерахией кошечек/собачек/уточек/автомашин, и только после этого предлагается написать «Hello, World!». :-)

При этом стоит заметить, что абсолютно всё обучение Java строится на примитивнейшем выводе результата на консоль. То есть не консольное приложение в привычном понимание, а именно вывод каких-то данных построчно. Ну вот например Turbo Pascal 3.0 вышел в 1985 году и в нём уже была поддержка графических режимов. В 1990 году появился Turbo Vision - очень крутая вещь - аля-Windows только для DOS. А в Яве в 2018 году возможен только вывод на консоль. И вот вся эта восторженность и крутость как-то вдребезги разбивается уже на этапе «Hello, World!»... Хуже наверное это только развлекаться на программируемом калькуляторе МК-61 или МК-52 - а что? там такой же построчный вывод.

Но, самое забавное - это то, что на Java реально можно создавать программы используя визуальное программирование! Я об этом узнал только когда прочитал (или скорее ознакомился) с 500 страничной книгой, где в одной из последних глав, вдруг выяснилось, что для Java существуют нормальные GUI (графические интерфейсы пользователя) и можно оформлять программы с кнопочками, полями ввода и нормальными меню. Спрашивается: зачем вы столько времени «мурыжили» эту паршивую консоль, когда можно было сразу всё делать красиво и аккуратно?

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

Первый - GUI для Java есть трёх видов (библиотек): AWT , Swing (кто придумывает такие названия?) и JavaFX .

На сегодняшний день (Java 8 и 9) все они входят в комплект поставки JDK: то есть всё работает из коробки и не нужно заморачиватся с их установкой. Это большой плюс.

Но, AWT - это первая и очень старая реализация, поэтому её использовать не нужно. В общем - некошерно. Swing - тоже некошерно, поскольку там что-то не так замутили и программы из-за него жутко тормозят. Точнее не скажу, не разбирался, но вроде как она официально больше не развивается несколько версий. А вот JavaFX - это гуд и наше светлое будущее.

Есть ещё такая мерзость - java-апплеты , те которые работают в браузере и при этом его намертво «вешают», примерно как Flash, только ещё хуже. К счастью эту/эти штуку/штуки практически уже не используют, поэтому тратить время на их изучение бессмысленно.

Так что единственное на что стоит потратить время - это JavaFX.

Второй момент . Всё не так просто. Рассмотрим Delphi (или Visual Studio, Lazarus, не важно). Даже для «зеленого» новичка создание простой программы (одна кнопка и текстовое поле для вывода) будет происходить так:

• запускаем Delphi;
• автоматом создается новый проект с главной формой;
• выбираем на палитре компонентов кнопку и размещаем на форме; всё визуально
• аналогично кидаем на форму текстовое поле;
• при необходимости в панели свойств можно указать текст кнопки, размеры и т.п.;
• запускаем - Delphi предложит сохраниться, сохраняемся.

То есть мы не написали ни единой строчки кода, IDE - всё сделала сама. Если посмотреть на сгенерированный код, то назвать его простым нельзя - здесь уже требуются определенные знания, но Delphi достаточно умна, чтобы понимать как с ним работать.

Если мы захотим добавить какое-то действие, например при нажатии на кнопку, заполнять текстовое поле фразой «Привет!», то делаем так:

• два раза кликаем на кнопку (или выбираем событие onClick);
• Delphi создает код обработчика этого события и перекидывает нас в редактор;
• набираем название текстового поля и Delphi выдает подсказки, по которым можно соориентироваться что и как делать.

То есть опять же, IDE выполнила всю черновую работу.

Но это в других языках, Java идёт своим путём. Чтобы создать кнопку в JavaFX нужно вручную создать Stage - «театральные подмостки» (название на полном серьёзе!) и на них разместить сцену (Scene). К ней какой-нибудь контейнер в который уже вкладывается прочие элементы.

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

Response = new Label("Push a Button"); Button btnUp = new Button("Up"); Button btnDown = new Button("Down"); btnUp.setOnAction(new EventHandler() { public void handle(ActionEvent ae) { response.setText("You pressed Up."); } }); btnDown.setOnAction(new EventHandler() { public void handle(ActionEvent ae) { response.setText("You pressed Down."); } }); rootNode.getChildren().addAll(btnUp, btnDown, response); ...

Когда кнопок наберется с десяток, плюс 20 пунктов меню, плюс 30 других компонентов, то код маленьким не покажется. И это ещё без кода, который отвечает за дополнительные свойства, например выравнивание, размеры, шрифт... И вот это второе указывает на то, что обучалки по JavaFX как раз и показывают как писать «fx-код» ручками. Тоска, одним словом...

Но, тут возникает спасительный третий нюанс . Оказывается умные люди (видимо знакомые с полноценными IDE), разработали другой вид приложений, где для генерации «fx-кода» используется описательный xml-файл, который называется fxml , а такие программы менуются как «Приложения FXML JavaFX »

Для меня совершенно удивительно то, что обучение Java не начинается именно с таких приложений. Пусть это не Delphi, но всё-равно это в миллион миллионов раз лучше, чем работать с консолью и забивать себе голову прочим хламом о том, почему нужно использовать стопицот строк с ООП там, где в других языках на это уходит одна простенькая процедура. ;-)

Теперь серьёзно. Если вы никогда не программировали на Java, то можете попробовать сделать это прямо сейчас. На самом деле - это довольно круто, хотя потребуется немного потратить время, чтобы освоится с программами. Если у вас есть опыт работы с «визуальными IDE», то ещё лучше - встретите много знакомого.

JDK

Ява должна быть установлена на компе. Я не буду приводить ссылки как это сделать - гугл в помощь, поскольку всё слишком просто.

IDE

В Яве нет какой-то одной программы - среды разработки, поэтому в Сети встречаются примеры из разных программ. Самые примитивные, вроде Notepad++ годятся только для консольного вывода, но если рассматривать что-то более серьёзное, то выделяются только три кандидата: NetBeans , Eclipse и IntelliJ IDEA .

NetBeans - самая простая программа, которая быстро (относительно остальных) запускается и довольно сносно работает.

Eclipse - тоже неплохой вариант, более мощный чем NetBeans, но слабее чем IntelliJ IDEA.

IntelliJ IDEA - выглядит самой крутой, но за это приходится платить скоростью работы. Стоит отметить, что Android Studio базируется на IntelliJ IDEA, но студия работает почему-то значительно медленней.

Важный момент связан с программированием под Андроид. Из этих трех IDE только IntelliJ IDEA для этого более-менее годится. В Сети масса материалов о программировании под Андроид в Eclipse, но они все уже устаревшие - не тратье время, запуская старенький ADT-плагин и пытаясь хоть что-то с ним сделать. Может быть старый Android SDK и будет работать, но все новые - уже нет.

Я покажу как сделать приложение FXML JavaFX во всех трёх программах, но прежде чем приступать, нужно установить ещё одну программу: SceneBuilder (используйте версию для Java 8). Это ключевая программа, где, собственно и выполняется всё визуальное построение. SceneBuilder самостоятельно может работать без IDE, поэтому можете её запустить и посмотреть как она устроена. На выходе будет fxml-файл, который содержит всю нужную разметку. Этот файл и используется в IDE, вместо написания мегатонны кода. :-)

ТЗ

Создаваемая программа будет очень простой - кнопка и текстовое поле. При нажатии на кнопку в текстовое поле пусть добавляется текст «Привет!».

В каждой программе вам нужно заранее прописать настройку - используемую JDK. Если не можете понять как это сделать, гуглите.

NetBeans

Перед началом работы, нужно подключить SceneBuilder: Сервис - Параметры - Java - JavaFX - Начальная страница Scene Builder . Выберите каталог программы. Настройку достаточно сделать один раз. Это относится ко всем IDE.

Создаём новый проект, где нужно выбрать «Приложение FXML JavaFX».

Жмём «Готово» и, после некоторой работы NetBeans, видим готовые файлы:

• Myfx.java - это main-файл, который, собственно и запускает всю программу.
• FXMLDocumentController.java - это «контролёр», где и будет в основном программирование.
• FXMLDocument.fxml - этот файл хранит визуальную часть.

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

Это круто, потому что мы не написали ни строчки кода, но уже получили программу с работающей кнопкой. :-)

Если вы правильно указали путь к SceneBuilder, то можете выбрать пункт меню «Открыть» на файле FXMLDocument.fxml . Это же самое произойдёт если сделать двойной клик. Откроется SceneBuilder. Если пункта нет, то путь указан не верно, проверьте настройку.

Принцип работы в SceneBuilder един для всех IDE, поэтому пока я опишу только общие моменты, дальше вы уже сами сообразите.

Стоит отметить, что после редактирования файла, закрывать SceneBuilder не нужно. Достаточно только сохраниться (Ctrl+S) и переключиться на IDE - она сама подхватит изменения.

Окно SceneBuilder разделено на три части:

• слева - наборы компонентов, иерархия и Controller, где указывается основной класс (это важно!)
• в центре - сама форма, где и происходит визуальное построение.
• справа - свойства компонентов, разделенные на три закладки (это условное деление). Вкладка Code отвечает за то, что будет использоваться в java-файле.

Построение FX-программ должно начинаться с контейнера. В данном примере NetBeans использовал AnchorPane . Он довольно удобный, позволяя настраивать для вложенных элементов «правильные» отступы. Вкладка Containers содержит другие контейнеры, с которыми вы сможете самостятельно потренироваться (я и сам ещё и половины не освоил:-)).

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

По условиям ТЗ у нас должно быть текстовое поле. NetBeans использует Label, но мы не будем ничего удалять, а просто добавим новый элемент TextField на форму (произвольно на ваш вкус).

В SceneBuilder возможен предварительный просмотр (Ctrl+P). В этом режиме отображается только форма и все элементы «без java-программирования».

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

Первая - проверить, что указан верный контролёр. В нашем случае NetBeans сам уже всё сделал и указал myfx.FXMLDocumentController .

Как видно - это контролёр из файла FXMLDocumentController.java (пакет.контролёр). Не всегда IDE его указывают, но это важно, поскольку fxml-файл (точнее java-код) использует его для привязки.

Второй момент - используемый компонент должен иметь свой ID - это параметр fx:id . Здесь я указал textField1 .

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

У кнопки, которая будет заполнять текстовое поле, тоже должен быть свой id, а также метод события onAction (это основное событие компонента, а не onClick, как в Delphi). NetBeans уже об этом позаботился, поэтому нам ничего не придется писать.

На этом визуальное построение можно завершить. Сохраняемся и переключаемся в NetBeans. Видим, что файл FXMLDocument.fxml изменился: добавился textField1 :

Теперь нам нужно как-то использовать текстовое поле в java-коде. В отличие от Delphi, NetBeans не создаёт для этого никакого кода, потому нам придётся добавлять его в «полу-ручном» режиме. Для этого в разных IDE используются различные способы, но общий принцип в том, что нужно установить курсор на нужное поле в редакторе и выполнить некое «действие» . В NetBeans оно называется Установить контролер в меню Источник . (Да в Яве большие проблемы с именованиями...)

После выполнения этой команды, произойдет переход к файлу FXMLDocumentController.java , где в код будет добавлено объявление переменной textField1 :

Обратите внимание на «@FXML» - эта аннотация указывает, что код как-то используется в FXML. После этих изменений SceneBuilder уже не будет выдавать предупреждение, как желтый треугольник ранее. Если ещё раз запустить SceneBuilder, то это можно проверить.

Запускаем программу на выполнение для теста. Теперь наша задача по клику на кнопке заполнить текстовое поле. Как вы уже поняли метод handleButtonAction как раз и выполняет нужную работу. В нём дописываем:

TextField1.setText("Привет!");

Обратите внимание как работает автодополнение кода после того, как будет нажата точка.

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

Данная возможность присутствует по всех IDE, хотя есть различия в реализации и использовании.

Запускаем программу и видим, что всё работает как нужно.

Нам пришлось написать всего одну строчку кода, ну и выполнить несколько дополнительных действий в редакторе.

Eclipse

Запуск Eclipse происходит несколько дольше, чем NetBeans. Вначале нужно указать путь к SceneBuilder. Делается это в Window - Preferences - JavaFX .

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

Создаём новый проект и выбираем JavaFX.

Жмем Next и попадаем на страницу настроек. Здесь я указал название проекта, как и прежде myfx (у меня для разных IDE разные каталоги проектов, поэтому они не пересекаются друг с другом).

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

Здесь всё очень похоже, только добавлен еще один файл application.css - да, да, в JavaFX можно использовать CSS для настройки оформления! Eclipse сразу сгенерировал для этого файла код подключения.

Запустим программу и убедимся, что нет ошибок.

В отличие от NetBeans, здесь совершенно пустая форма. Откроем её в SceneBuilder с помощью контекстного меню.

И здесь мы видим, что формы нет. Но, на самом деле она есть - просто по умолчанию используется вычисляемый размер (высота и ширина), который в данном случае равен нулю. Компонентов-то нет! В нашем случае это не совсем то, что нужно, поэтому мы выберем BorderPane в иерархическом списке и в свойствах Pref Width и Pref Height укажем какие-то значения. Эти свойства задают «желаемые» ширину и высоту. После этого форма сразу же «проявляется».

Контейнер BorderPane состоит из 4-х частей: top, right, bottom, left и center. Компоненты следует помещать в разные части - от этого будет зависеть их положение при изменении размера окна.

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

Я не стал особо мудрить и разместил вверху текстовое поле, а в центре кнопку.

Теперь проверим, что указан контролёр: в данном случае application.SampleController - Eclipse выполнил эту работу за нас.

Теперь нужно указать id у наших элементов. Для кнопки я задал btn1 , а текстовому полю textField1 . У нас опять же возникло сообщение «желтый треугольник».

Для кнопки укажем метод на событие - btn1Click .

Сохранимся и вернёмся в Eclipse. Мы увидим, что файл Sample.fxml обновился, но рядом с некоторыми строками появились значки предупреждения.

Ситуация здесь точно такая же как и в NetBeans - нужно в «полу-ручном» режиме вносить правки. В Eclipse для этого используется контекстное меню по второй кнопке мыши: Quick Fix или горячая клавиша Ctrl+1 (что удобней).

При этом выскакивает подсказка о предполагаемом действии. Например для textField1 предлагается добавить идентификатор в контролёр:

а для кнопки ещё и метод-обработчик события:

При этом, Eclipse немного притормаживает и изменения не сразу отображаются на экране. Тут нужно либо переключиться на файл контролёра, либо немного подождать. В результате в код будет добавлены нужные изменения и значки предупреждений исчезнут.

Добавим наш код как и раньше мы сделали в NetBeans.

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

Запускаем нашу программу.

И записываем себе на счёт ещё одну IDE. :-)

IntelliJ IDEA

IntelliJ IDEA запускается довольно неспешно, можно успеть проверить почту. :-)

Опять же указываем путь к SceneBuilder: File - Settings :

И указываем его имя (как обычно - myfx):

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

Здесь также пустая форма, но зато указан заголовок программы. Если посмотреть на код Main.java , то увидим строчку:

PrimaryStage.setTitle("Hello World");

Это и есть заголовок приложения. В других IDE эта строчка отсутствует, но зато теперь мы знаем для чего нужны «театральные подмостки». ;-)

Переключаемся в SceneBuilder (аналогично Eclipse): второй кнопкой мыши нужно выбрать Open in SceneBuilder .

Здесь также пустая форма, но с контейнером GridPane . Устанавливаем Pref Width и Pref Height , чтобы отобразилась форма.

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

• разместить кнопку и тестовое поле,
• присвоить им id,
• для кнопки прописать метод для обработки клика,
• не забываем проверить, указан ли контролёр (sample.Controller ).

Закрываем SceneBuilder и возвращаемся в IntelliJ IDEA. Здесь нужно добавить идентификаторы id в код, а также создать метод для реакции на нажатие кнопки.

IntelliJ IDEA предлагает для этого два способа. Первый - при наведении мышки на «проблемное место» будет появляться подсказка, на которую можно кликнуть:

Второй - горячая клавиша Alt+Enter

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

При этом, заметьте, не добавляется строчка «@FXML». Если мы вручную его добавим перед переменными и методом, то IntelliJ IDEA сразу предложит добавить нужный java-класс:

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

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

Прекрасно, всё работает!

Итого

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

Три IDE я привел не случайно. В Сети очень много примеров для Явы и все они для разных программ. Лично я ещё не определился со своим предпочтением, поскольку у всех есть как плюсы, так и минусы. Наверное нужно поработать со всеми, тогда и будет понятно.

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

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

Исторически сложилось, что алгоритмы в программах записываются в виде исходных текстов. Почти никто не ставит под сомнение, что текст - это и есть лучшее средство представления алгоритмов. Алгоритм кодируется внутри функций на языке программирования, например, C или JavaScript. Для тех, кто хочет разобраться в алгоритме с высоты птичьего полёта, предусмотрен псевдокод. Однако с текстом есть серьезные проблемы. Дело в том, что человек не оптимизирован под сплошной текст. Человек оптимизирован на восприятие графики. Текст - это относительно новое изобретение, а вот графическую информацию организмы обрабатывают уже миллионы лет.

Исходя из этого, логично было бы составлять алгоритмы в графическом виде. Посмотрите на инженеров. Они повсеместно используют чертежи. Чем же программисты хуже? Они тоже могли бы составлять чертежи алгоритмов. Некоторые здесь возразят: визуальное программирование якобы неэффективно. UML неудобен, а в блок-схемах легко запутаться. Уж лучше программировать традиционным способом - текстом. В структурном программировании есть хотя бы структура, и она обеспечивает порядок и единообразие. А кроме того, рисовать диаграммы долго и трудно. Печатать быстрее, чем рисовать.

Так что же, программисты обречены всю жизнь работать только с текстом?
Возможно, не всё так плохо. Существуют визуальные языки для представления алгоритмов, в которых тоже есть порядок и структура, например ДРАКОН, BPMN и LML Action Diagrams. Здесь мы рассмотрим визуальный алгоритмический язык ДРАКОН.

Как программировать на языке ДРАКОН

ДРАКОН не является самостоятельным языком программирования. Он работает в паре с текстовым языком, например, с JavaScript, Python или C++. Вместе с текстовым языком, ДРАКОН образует гибридный язык: ДРАКОН-JavaScript, ДРАКОН-Python или ДРАКОН-C++.

Программирование на гибридном языке происходит следующим образом:

1. Рисуем ДРАКОН-схему.
2. Внутрь икон помещаем небольшие кусочки кода на соответствующем языке программирования.
3. Программа-транслятор преобразует ДРАКОН-схему в текстовый файл с исходным кодом.
4. Этот текстовый файл включается в проект обычным образом.
   Генерацию кода из диаграмм на сегодняшний день поддерживают несколько редакторов. Примеры в данной статье сделаны в DRAKON Editor.

Генерация кода из диаграммы

В диаграмме ДРАКОН берёт на себя управление потоком выполнения. Поэтому кусочки исходного кода в иконах не должны содержать ключевых слов типа if , else , switch , case , for , while и т. п.

Внутри икон должен быть только простой однозначный код: арифметические выражения, присваивания значений, вызовы функций, сравнения. А вот ветвление и циклы реализуются конструкциями языка ДРАКОН.

Генерация кода происходит следующим образом:

• Из каждой диаграммы создаётся функция.
• Название диаграммы становится названием функции.
• Параметры функции берутся из иконы «Формальные параметры», что расположена справа от названия диаграммы.
• Тело функции генерируется, исходя из структуры диаграммы и содержимого икон.

На рис. 1 представлен пример небольшой диаграммы на гибридном языке ДРАКОН-JavaScript и сгенерированный код на JavaScript:

Прямоугольник с текстом console.log(cat, dog) на рис. 1 - это икона «Действие». Сколько кода можно поместить в одну икону «Действие»? Следует стремиться к тому, чтобы в одной иконе содержалась одна мысль. Иногда это одна строка кода, иногда несколько.
Сгенерированный код снабжён комментариями, в которых указаны номера икон. Находясь в редакторе, можно быстро перескочить к любой иконе, нажав Ctrl+I.

Рис 1. Диаграмма на ДРАКОН-JavaScript и сгенерированный из неё код.

Икона «Вопрос»

Для ветвления применяются иконы «Вопрос» и «Выбор».

Икона «Вопрос» (рис. 2) соответствует конструкции if-then-else .

Обратите внимание, что вместо слов true и false используются слова Да и Нет (можно переключить на Yes и No ).

«Истина» и «ложь» - это звучит эффектно, по-учёному. Однако человеку ближе знакомые с раннего детства «да» и «нет».

Надписи Да и Нет можно менять местами. Неизменным остаётся расположение выходов из иконы «Вопрос». Один выход идёт вниз, а другой - вправо. Ветвление в языке ДРАКОН всегда направлено вправо, поэтому выход из левой стороны иконы запрещён. Такая предсказуемость облегчает чтение диаграммы, так как читатель заранее знает, где искать выходы.

Ещё одной особенностью языка ДРАКОН является то, что для ветвления используется не полный ромб, а усечённый. Это экономит место на диаграмме.

Рис 2. Икона «Вопрос»

Визуальные логические формулы

Язык ДРАКОН делает ненужными логические операторы И , ИЛИ и НЕ , а также оператор «не равно». Сами логические операции, конечно, необходимы. Но вместо текстовых операторов ДРАКОН вводит визуальные логические формулы.

Чтобы получить визуальную логическую формулу, следует соединить несколько икон «Вопрос» (как на рис. 3).

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

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

Рис 3. Визуальные логические формулы

Цикл со стрелкой

Для обозначения обычного порядка выполнения в языке ДРАКОН стрелки не нужны. Следующая икона всегда находится внизу. Стрелка требуется только тогда, когда поток выполнения должен прыгнуть вверх по диаграмме. Такой прыжок вверх означает цикл. Следовательно, стрелка в языке ДРАКОН есть признак цикла. При беглом взгляде на ДРАКОН-схему стрелки сразу заметны. А значит, сразу видны и циклы. Это серьёзное преимущество ДРАКОНа по сравнению с другими графическими языками. Циклы не приходится выискивать.

Итак, если соединить икону «Вопрос» со стрелкой, получится цикл. Это аналог конструкций while и do-while . На рисунке 4 показаны несколько видов циклов со стрелками.
Икона «Вопрос» в цикле со стрелкой проверяет условие выхода из цикла. Конечно, вместо одной иконы «Вопрос» может быть несколько. Тогда за выход из цикла отвечает визуальная логическая формула.

Рис 4. Стрелочные циклы

Икона «Выбор»

Икона «Вопрос» содержит логическое выражение, то есть может принимать два значения: Да и Нет . Типичный пример - сравнение двух объектов. Если же нужно сравнить некое выражение с несколькими значениями, применяется икона «Выбор» (рис. 5). Это соответствует конструкции witch-case .

Значения, с которыми будет сравниваться выражение в иконе «Выбор», помещаются в иконы «Вариант». Если в самом правом варианте нет текста, это означает «все остальные значения». Такой пустой вариант похож на ключевое слово default внутри оператора switch .
Самый правый вариант может окончиться стрелкой, которая ведёт вверх. В таком случае мы опять имеем дело со стрелочным циклом. В таком цикле за условие выхода будет отвечать икона «Выбор», а не «Вопрос».

Рис 5. Икона «Выбор» и иконы «Вариант»

Икона «Цикл ДЛЯ»

Вместо циклов for и foreach в ДРАКОН-JavaScript применяется икона «Цикл ДЛЯ». Икона «Цикл ДЛЯ» (рис. 6) может быть нескольких видов.

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

Если после ключевого слова foreach стоят две переменные, DRAKON Editor поймёт, что требуется итерация по свойствам объекта (записям хэш-таблицы). Только собственные свойства объектов попадут в перечисление.

Третий вариант цикла подразумевает наличие трёх выражений, разделённых точками с запятой. Это традиционный цикл for , характерный для языков C и Java.

Из цикла под управлением иконы «Цикл ДЛЯ» возможен досрочный выход при помощи иконы «Вопрос» или «Выбор». Такой выход примерно соответствует ключевому слову break .

Рис 6. Различные виды иконы «Цикл ДЛЯ» в ДРАКОН-JavaScript

Только один вход в цикл

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

Несколько выходов из цикла - это допустимо, но вход должен быть только один. На рис. 7 показаны циклы, у которых есть по два выхода. Это разрешено. На рис. 8 представлены примеры запрещённых циклов. Запрещённых потому, что в них можно войти разными путями.
Однако не стоит заучивать наизусть внешний вид этих запрещённых циклов. DRAKON Editor автоматически обнаружит такие циклы и выдаст ошибку.

Рис 7. Разрешённые циклы, у которых по два выхода

Рис 8. Запрещённые циклы, у которых по два входа

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

Как видим, иконы и макроиконы языка ДРАКОН имеют соответствие со стандартными конструкциями текстового структурного программирования. Однако есть и различия. Текст, пусть даже с индентацией, - одномерный объект. А диаграмма - двумерный. В диаграмме появляется дополнительная степень свободы, которая повышает выразительность. Попробуйте, например, на текстовом языке программирования без повторов и goto изобразить такой алгоритм, как на рис. 9.

Несмотря на дополнительную по сравнению с текстом свободу, ДРАКОН всё же не позволяет удариться в анархию. Его правила достаточно суровы, чтобы не допустить беспорядка. ДРАКОН предоставляет разумный компромисс между гибкостью и строгостью.

Рис 9. Алгоритм, который трудно изобразить только текстом

Преимущества графического языка

Язык ДРАКОН имеет интересную судьбу. Его основные принципы были заложены ещё самим Дейкстрой. Нынешнюю свою форму ДРАКОН приобрёл в недрах российской космической отрасли. Примечательно то, что правила языка ДРАКОН не возникли случайно. Они были сначала обкатаны в фокус-группах, а потом отточены в реальных космических проектах.
Так в чём же именно заключаются сильные стороны ДРАКОНа?

Начнем с того, что ДРАКОН - это графический язык. А у графического языка имеются фундаментальные преимущества по сравнению с текстом.

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

Во-вторых, путь через алгоритм можно проследить пальцем (или взглядом). После if не нужно искать else . Идите по линии и попадёте в нужный квадратик. Не требуется бегать глазами по исходному коду в поисках ответа на вопрос: что же было дальше?

А ещё у диаграмм есть одно почти волшебное свойство. Бывает, смотрит человек на диаграмму, и вдруг приходит какое-то дополнительное понимание. Становятся очевидными ранее невидимые связи. С текстом так бывает редко.

Особые эргономические правила

Но ДРАКОН - это не просто диаграммы, это тщательно продуманные диаграммы. ДРАКОН-схемы воспринимаются легче, чем обычные блок-схемы. Это обеспечивается особыми эргономическими приемами. Вот некоторые из них.

• Пересечения линий запрещены. Вообще. Пересечения заставляют наш зрительный анализатор подозревать, что линии касаются, а значит, каким-то образом связаны. Эти подозрения создают дополнительную умственную работу. Ненужную работу следует отбросить.
• Начало содержит название алгоритма и всегда расположено в левом верхнем углу диаграммы. Поэтому начало даже и искать не надо. Оно есть там, где обычно.
• Диаграмма имеет только один конец. Что бы ни случилось по дороге (кроме исключений), мы всегда придём в конец.
• Разрешены только прямые линии. Никаких кривых и изгибов, а также ненужных изломов.
• Разрешены только строго вертикальные и строго горизонтальные линии. Наклонные линии запрещены. Пояснение для любителей математики: ДРАКОН-схема представляет собой плоский прямоугольный граф (манхэттенский граф). Зрительный аппарат человека моментально схватывает объекты, соединённые прямыми ортогональными линиями. А вот отслеживание того, куда приведёт «кривая американской мечты», требует от читателя дополнительной концентрации.
• ДРАКОН-схема исполняется сверху вниз. Данное правило позволяет избежать необходимости лихорадочно сканировать глазами диаграмму в поисках следующей иконы. Следующая икона всегда внизу. Вход у иконы сверху, а выход снизу. Раз мы знаем где следующая икона, то и стрелки не нужны. Достаточно простых линий. Стрелки возле каждой иконы - это зрительный шум. Сняв со стрелок задачу соединения икон, можно возложить на них особую миссию. В ДРАКОНе стрелка означает цикл.
• Ветвление происходит только вправо. Это огромное подспорье в разрезе предсказуемости и единообразия.
• Иконы, находящиеся на одной вертикали, должны иметь одну и ту же ширину. Это даёт ощущение принадлежности икон к единому целому. Когда ширина у всех одна, и нет икон-выскочек, глаз легко и свободно скользит по диаграмме.

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

Диаграммы на рис. 10 и 11 демонстрируют эргономические приёмы языка ДРАКОН на реальных примерах.

Рис 10. Эргономические приёмы языка ДРАКОН на примере

Рис 11. Ещё один пример диаграммы на языке ДРАКОН
Помимо эргономических приемов, язык ДРАКОН имеет уникальные особенности, которых больше нигде нет.

Чем правее, тем хуже

ДРАКОН имеет средство для изображения happy path , или царской дороги . Царская дорога - это наиболее удачный путь через алгоритм. В некоторых алгоритмах понятия «удачный/неудачный», «хороший/плохой» не применимы. В них царская дорога показывает наиболее ожидаемый путь. Царская дорога проходит по вертикали, расположенной в левой части диаграммы. Эта вертикаль называется шампур. Менее вероятные и менее удачные сценарии, а также обработка ошибок помещаются в правой части диаграммы. Причём чем ситуация хуже, тем правее она должна быть расположена. Хорошим стилем является размещение кода, который бросает исключения или возвращает код ошибки, справа на диаграмме.

Общая судьба

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

Рис. 12 показывает шампур с царской дорогой, а также применение приёма «общая судьба».

Рис 12. Царская дорога и общая судьба

Силуэт

Силуэт - это настоящий бриллиант ДРАКОНа. Силуэт позволяет разбить диаграмму на логические части. В программировании для этого обычно используют декомпозицию при помощи подпрограмм. Подпрограммы - действенный метод. Но иногда хотелось бы расположить подпрограмму визуально недалеко от основной программы, а также избежать возни с передачей параметров и возвратом значений. Для этих целей отлично подходит силуэт. Ещё одно применение силуэта - конечные автоматы. Но об этом мы поговорим в другом месте.
Случается, что алгоритм не получается разложить на плоскости так, чтобы не было пересечения линий. В таком случае, в зависимости от ситуации, применяют либо декомпозицию при помощи подпрограмм, либо силуэт.

Силуэт состоит из нескольких малых диаграмм, соединённых в один целостный блок. Эти малые диаграммы называются ветками силуэта. Наверху каждой ветки расположена икона «Шапка ветки», внизу - икона «Адрес». В шапке ветки помещают название данной ветки, а в адресе указывают название следующей ветки. Названия веток расположены на одной горизонтальной линии в верхней части диаграммы. Благодаря этому, можно ухватить суть алгоритма, пробежав лишь по шапкам веток. Силуэт отвечает на три царских вопроса:

1. Как называется проблема?
2. Из скольких частей она состоит?
3. Как называются эти части?

Рассмотрим пример на рис. 13. Вот ответы на царские вопросы:

1. Как называется проблема? Упорядочить связанный список.
2. Из скольких частей она состоит? Из четырёх.
3. Как называются эти части? Построить матрицу связей. Проверить наличие циклов. Пройтись по матрице связей. Завершить.

Рис 13. ДРАКОН-схема «силуэт»

Силуэтный цикл

Ветки силуэта следует упорядочивать слева-направо. В некоторых случаях необходимо выполнить какую-то ветку или группу веток несколько раз. Такая конструкция называется силуэтный цикл. Если икона «Адрес» указывает на свою собственную ветку, либо на ветку, которая расположена левее, её следует пометить специальной меткой. Такую же метку нужно поставить на соответствующую икону «Шапка ветки» (см рис. 14). Назначение метки - сделать силуэтный цикл заметным.

Рис 14. Силуэтный цикл и метки

Соединение веток силуэта запрещено

Соединения двух веток силуэта (как на рис. 15) запрещены. Каждая ветка внутри силуэта должна быть самостоятельной.

Рис 15. Соединение веток силуэта запрещено.

Размер диаграмм

Во время программирования на языке ДРАКОН возникает вопрос: какого размера должны быть диаграммы? Ответ такой: чем меньше, тем лучше. Чем меньше объектов на зрительной сцене, тем понятней. В текстовом программировании есть такой ориентир: хорошо, если вся функция целиком помещается на экране. Похожий совет можно дать и для ДРАКОН-схем. Избегайте огромных диаграмм. Когда весь алгоритм виден полностью, его гораздо легче понять.
Для программирования на ДРАКОНе лучше иметь большой монитор. Хотя бы 1080 точек в высоту. Тогда не придётся искусственно укорачивать ДРАКОН-схемы.

ДРАКОН-схема силуэт должна помещаться на экране по высоте, но не обязательно по ширине. Диаграммы силуэт могут быть довольно широкими, гораздо шире, чем 2000 пикселей. Это нормально. Не обязательно видеть одновременно все ветки силуэта. Главное, чтобы та ветка, с которой вы сейчас работаете, была полностью видна на экране.

Критика программирования на ДРАКОНе

Рассмотрим основные направления критики программирования на ДРАКОНе и попытаемся дать на них ответ.

• «ДРАКОН-схемы занимают больше места на экране, чем текстовые программы.» Это правда. Но надо иметь в виду, что задача ДРАКОНа - показать сложность, как она есть. Читатель программы не должен распаковывать в голове сложные структуры. Они должны быть показаны ему в явном виде.
• «Простые алгоритмы лучше смотрятся в текстовом виде». Возможно. Hello world на любом языке смотрится элегантно. Но в реальной жизни не всё просто. Как только появляется хотя бы один if , вложенный в другой if , ДРАКОН выигрывает.
• «ДРАКОН не имеет средств для отображения исключений (exceptions).» Такая проблема есть. Исключения были недавно добавлены в язык ДРАКОН, но не все реализации их поддерживают. Пока реализации не подоспели, можно писать блоки try/catch на соответствующем языке программирования.
• «ДРАКОН-схемы долго рисовать.» В специализированных редакторах рисовать ДРАКОН-схемы гораздо легче, чем, например, в Visio. А в некоторых из них рисовать стало почти так же просто, как писать.
• «Отсутствует инструменты для diff и merge.» Это, к сожалению, так. При работе с системой контроля версий сравнивать приходится сгенерированные исходные файлы.
• «Отсутствуют средства отладки ДРАКОН-схем.» Это правда. Но можно отлаживать сгенерированный код. В нём есть метки, которые указывают, к какому месту в диаграмме относится данный кусок кода.

Обзор языка дракон

На рисунке 16 представлен обзор языка ДРАКОН.

Рис 16. Обзор языка ДРАКОН

Инструменты для работы с языком дракон

Самой первой реализацией языка ДРАКОН была система ГРАФИТ-ФЛОКС (рис. 17). ГРАФИТ-ФЛОКС создавалась в 1986-1996 гг. специалистами ФГУП НПЦ АП им. Пилюгина под руководством В.Д. Паронджанова. Эта среда предназначалась для проектирования систем управления ракет-носителей и космических аппаратов.

ГРАФИТ-ФЛОКС - закрытая разработка, поэтому о ней известно относительно немного. Список космических аппаратов, созданных с применением ГРАФИТ-ФЛОКС, можно посмотреть .

В начале 90-х годов был создан ещё один ДРАКОН-редактор. Разработка велась в Институте прикладной математики имени М.В. Келдыша под руководством Л.К. Эйсымонта. Редактор Эйсымонта (рис. 18) можно скачать и запустить, но он более не поддерживается. Редактор написан под MS DOS, поэтому для запуска на современных компьютерах может потребоваться DOSBox.

В 2008 году увидел свет редактор ИС Дракон от Геннадия Тышова (рис. 19). ИС Дракон активно поддерживается и развивается. В ИС Дракон реализована генерация программного кода из диаграмм. Одной из интересных возможностей ИС Дракон является возможность помещать в одной иконе код на языке программирования и описание на естественном языке. Безусловное достоинство ИС Дракон - так называемое «исчисление икон». Исчисление икон - это способ редактирования, который помогает пользователю рисовать диаграмму и гарантирует, что диаграмма не нарушит правила языка ДРАКОН. Среди недостатков ИС Дракон можно отметить нестандартный интерфейс пользователя и некоторые неудобства при генерации кода. ИС Дракон - коммерческий продукт.

DRAKON Editor - ещё один современный ДРАКОН-редактор (рис. 20). DRAKON Editor был разработан группой энтузиастов под руководством Степана Митькина. DRAKON Editor не поддерживает исчисление икон. Это означает, что ДРАКОН-схемы собираются в нём вручную из примитивов, как в векторных графических редакторах. Но зато интерфейс пользователя в DRAKON Editor максимально прост. Он построен по более привычной схеме, чем ИС Дракон. Основным преимуществом среды DRAKON Editor является удобство программирования и генерации кода. DRAKON Editor поддерживает несколько языков программирования, включая C, C++, C#, Java, Processing, JavaScript, Lua, Erlang, Python, Tcl, Verilog, AutoHotkey, D и Go. Для некоторых языков имеется возможность генерировать конечные автоматы. Поддерживаются правила для экспертной системы nools. Реализовано подмножество языка УТОПИСТ Э. Тыугу. DRAKON Editor имеет открытый исходный код.

Интересное применение для языка ДРАКОН придумал Олег Гарипов в своём проекте Integrator CodeView. CodeView позволяет визуализировать имеющийся код в виде взаимосвязанного набора ДРАКОН-схем. Особенность Integrator CodeView заключается в том, что визуализируются не отдельные методы, а проект целиком, включая граф вызовов, стек и т. п. Integrator CodeView уникален ещё и тем, что он наглядно показывает не только алгоритмы, но и данные. Движок визуализации данных в системе Integrator работает совместно с ДРАКОНом.

DRAKON Editor Web - это коммерческое облачное решение на базе языка ДРАКОН. DRAKON Editor Web предназначен для технических заданий, бизнес-процедур и чек-листов. DRAKON Editor Web никак не связан с DRAKON Editor и не поддерживает генерацию кода из диаграмм. Среди плюсов DRAKON Editor Web следует отметить удобный редактор, совместную работу и поддержку мобильных устройств.

Рис 17. ДРАКОН-схема в системе ГРАФИТ-ФЛОКС

Рис 18. ДРАКОН-редактор Эйсымонта

Рис 19. Программа с пояснениями в ИС Дракон

Рис 20. DRAKON Editor

Выводы

Подведем итоги. ДРАКОН - закалённый в космосе практический язык. Он привнёс в блок-схемы структуру, порядок и единообразие. Предсказуемость и опрятность ДРАКОН-схем приводят к тому, что визуальное программирование работает .

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

Добавить метки

Визуальное программирование – способ создания программы для ЭВМ путём манипулирования графическими объектами вместо написания её текста. Визуальное программирование часто представляют как следующий этап развития текстовых языков программирования.

Визуальные языки программирование появились очень давно, задолго до того, как появился визульный рекадтор от Unreal Engine -> Unreal BluePrint.

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

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

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

Визуальное программирование поможет в обучении

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

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

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

Рассматривая современные средства визуального программирования, стоит упомянуть о проекте The Blockly от компании Google, главная функция которого, это образование.

Blockly позволяет разработать свои приложения под Web, Android, iOS и научится программировать просто перемещая и создавая блоки. Логические и математические операции, переменные, циклы, списки, функции – это то, что можно выучить и сделать с помощью Blockly.

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

Существуют достаточно хорошие решения визуального программирования, тот же Unreal BluePrint, Unity3D Maker и другие, однако не один из них не является идеальным на данный момент.

Визуальное программирование – выводы

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

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

Судя по всему, игры всё ещё нельзя делать только при помощи клика мышки, программы нельзя писать без кода, но мы постепенно приближаемся к таким технологиям. Главный вопрос, хорошо это или плохо? Так или иначе, будущее ещё не наступило.

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

Удачи в жизни и до встречи.

Визуальное программирование - одна из технологий в современном программировании

Визуальное программирование (от лат. visualis - зрительный) - это технология программирования, предусматривающая создание приложений с помощью наглядных средств.

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

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

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

Так, например, фирма IBM наиболее полно реализовала концепцию визуального программирования в среде VisualAge Smalltalk.

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

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

Поддержка графического интерфейса, предоставляемая готовыми компонентами, отвечает CUA (Common User Access) спецификациям и содержит ряд расширений для организации гибкого ввода-вывода в сложных формах и таблицах. Библиотека готовых компонент предоставляет также поддержку устройств мультимедиа, коммуникаций через протоколы APPC, TCP/IP, NetBIOS, программных интерфейсов CICS External Call Interface, EHLLAPI, Message Queue Interface (MQI), работу с реляционными базами данных семейств DB2, Oracle, Sybase и многое другое.

Фирма Microsoft, разрабатывая концепцию.NET Framework, создала Visual Studio.NET Enterprise Architect 2003, в которой реализовала все последние достижения в области программирования и в частности, в технологии визуального программирования.

Visual Studio.NET - полная многоязычная среда разработки для платформы Microsoft.NET. Visual Studio.NET предоставляет набор технологий, упрощающих создание, развертывание и последующее усовершенствование безопасных, масштабируемых и высокодоступных веб-приложений и веб-служб XML.

Фирма Borland Software Corporation традиционно развивает интегрированную среду программирования, имеющую несомненный успех на рынке профессиональных программных продуктов. Эта среда всегда поддерживала методы визуального программирования, предлагала разработчику мощные библиотеки, интерактивные мастера-построители, готовые элементы графического интерфейса. На сегодняшний день Borland Developer Studio - программный продукт от Borland Software Corporation, представляющий собой среду быстрой разработки приложений (RAD) для платформ Win32 и.NET на языках Delphi (Object Pascal), C++ и C#.

Еще один пакет от фирмы Borland - Delphi Enterprise Edition 7.0. Этот пакет обеспечивает поддержку новейших перспективных технологий Веб-служб, включает предварительную версию средств работы с Microsoft.NET Framework.

При помощи пакета Delphi 7 разработчики, использующие Delphi, могут приобрести навыки программирования для.NET, готовить свои приложения к работе под управлением.NET, не теряя при этом имеющихся наработок и навыков работы на платформе Windows. Среда разработки Delphi 7 - это проектирование; развертывание архитектуры, управляемой моделью (MDA); интегрирующее моделирование, разработка и развертывание приложений и систем электронного бизнеса для платформы Windows.

Фирма Borland Software Corporation является первой компанией, открывшей независимый путь к.NET с Delphi 7, межплатформенной средой быстрой разработки приложений (RAD) для платформы Windows. Характерной чертой Delphi 7 является возможность разработки и развертывания корпоративных приложений. Это позволяет разработчикам создавать корпоративные приложения, от концепции к готовому продукту, еще быстрее с использованием нового UML™-дизайнера и технологии Model Driven Architecture™ (MDA™).

Мы рассмотрели роль и место визуального программирования в области современного программирования. Теперь перейдем к рассмотрению конкретных приемов и методов, относящихся к визуальному программированию. Рассмотрим использование компонентов и приемов визуального программирования в рамках Visual Studio.NET Framework фирмы Microsoft.

Основы визуального программирования

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

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

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

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

Возможно, именно наличие визуальных средств построения интерфейсов в таких языках, как Microsoft Visual Basic и Delphi, а также создаваемые с помощью этих языков визуальные программные интерфейсы, закрепили за ними термин "визуальное программирование". Безусловно, существует много других аналогичных продуктов (Visual C++, Borland C++ начиная с версии 4, Symantec Visual Cafe, C++ Builder и др.), но они не смогли завоевать такой популярности, как Visual Basic и Delphi. Именно благодаря Visual Basic, мир узнал о возможности визуального построения интерфейсов программ для Windows.

В Visual Basic и Delphi выполняется визуальное построение интерфейса программы, но не самого кода. Определяющими элементами процесса визуализации являются:

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

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

Окно свойств (PropertyBox) - окно, в котором отображаются параметры (свойства) выбранного элемента визуальной модели. Термин "свойство" пришел из объектно-ориентированного программирования и обозначает параметр объекта (элемента).

Визуализируемой моделью в Visual Basic и Delphi является окно (форма, диалог) Windows, а не код программы.

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

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

Рис.8.1. Визуализация разработки кода программы

Присоединение модуля, созданного средствами визуального программирования выполняется также визуальными средствами - в режиме конструирования (рис.8.2).

Рис.8.2. Средства визуального программирования

Другим примером визуализации создания кода программы может служить процесс создания макро программ в Microsoft Excel (рис.8.3).

Рис.8.3. Диалог MS Excel при автоматической записи действий пользователя

Визуализируемой моделью в данном случае является рабочий лист Excel, в котором программист выполняет действия по обработке данных. Программный код пишется автоматически в фоновом режиме, при этом происходит описание в операторах языка VBA (Visual Basic for Application) всех визуальных действий пользователя.

Окно свойств Properties присутствуют, но не в самом рабочем листе, а в среде VBA (рис.8.4). Окно инструментов при выборе объекта Module выключается, но в случае редактирования программного кода для каждого программного объекта появляется раскрывающийся список со свойствами, методами и событиями, т.е. в каждой строке записи макроса в отдельности имеется возможность выбора или смены текущей команды макроса.

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

Рис.8.4. Результат автоматической записи программного кода как протокола действий пользователя

Применение визуального программирования при построении интерфейса приложения в Visual Studio.Net

Visual Studio.NET - это универсальная среда разработки всех типов приложений на базе.NET и на основе единого визуального интерфейса. Платформа.NET Framework представляет собой набор объектов и планов (blueprints, то есть описание объектов), созданных корпорацией Microsoft для разработки приложений (Windows и Internet). Большая коллекция визуальных объектов позволяет конструировать различные элементы управления: Надпись, Надпись с гиперссылкой, Кнопку, Поле, Флажок и многие другие. Все эти элементы располагаются на панели инструментов (рис.8.5). Настройка свойств элементов выполняется с помощью списка свойств.

Элементы управления, как и все другие объекты среды.NET, реализованы в виде классов в определенном пространстве имен, в данном случае - System.Windows.Forms.

Рис.8.5. Визуальное программирование средствами Visual Studio.NET

Методы элементов программируются пользователем "вручную", но и тут имеются визуальные помощники: после двойного щелчка по элементу управления в конструкторе автоматически открывается окно редактора кода и автоматически пишется заголовок процедуры обработки события. Боле того, после набора имени объекта автоматически появляется список свойств и методов объекта (рис.8.6). Таким образом, процесс написания программного кода также частично визуализирован.

Рис.8.6. Визуализация свойств и методов объекта

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

Отдельный класс Dialog в.NET не предусмотрен. Диалоговое окно - это форма (рис.8.7.), обладающая некоторыми специальными характеристиками. Программирование диалоговых окон, как и многих других стандартных компонент, в Visual Studio поддерживается визуальными средствами программировании (рис.8.8).

Рис.8.7. Пример стандартного диалога

Рис.8.8. Программирование стандартных элементов средствами Visual Studio

Концепция.NET Framework и Visual Studio.NET предоставляют в распоряжение программистов огромную библиотеку объектов, ускоряющую процесс разработки приложений. Многие объекты в этой библиотеке имеют визуальное представление и дают возможность назначения свойств объекта в режиме конструирования с помощью окна Properties или диалогов с мастером-построителем.

Выводы

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

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

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

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

Визуальные средства поддержки программирования в Visual Studio.NET превращают программистов в разработчиков Windows и Internet приложений.

Вопросы для самопроверки

1. В чем принципиальное отличие визуального программирования от любого другого программирования?
2. Возможно, ли средствами визуального программирования создать законченное программное приложение?
3. Какие достоинства и недостатки присущи визуальному программированию?
4. Какие языки программирования поддерживают визуальный стиль программирования?
5. В каких средах программирования реализован визуальный стиль программирования?
6. Какие фирмы-разработчики пакетов программирования имеют наиболее удачные решения для визуального программирования?
7. Можно ли сказать, что визуальное программирование - это построение графического интерфейса пользователя?
8. Какие элементы процесса визуализации вы можете перечислить?
9. Что такое "визуализируемая модель"?
10. Приведите примеры визуального программирования в известных вам программных средах.

Литература

1. Гарнаев Ф.Ю. Самоучитель Visual Studio.NET 2003.- СПб.: БХВ-Петербург, 2005.- 688.с.: ил.
2. Подлин Ш. Освой самостоятельно программирование для Micrsoft Excel 2000. Пер. с англ.: Уч. Пос. - М.: Издательский дом "Вильямс", 2006. - 304 с.: ил.- Парал. тит. англ.
3. Харитонова И.А., Михеева В.Д. Microsoft ACCESS 2000: Разработка приложений. - СПб.: БХВ-Петербург, 2004. - 832 с.: ил.