Контрольная работа по "Информатика". 32

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

Кафедра информатики

КОНТРОЛЬНАЯ РАБОТА

г. Пермь, 2012 г.

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

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

- проверить работоспособность разрабатываемой системы на ранних этапах ее разработки;

- общаться с заказчиком системы, уточняя его требования к системе;

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

- Программа представляет собой модель некоторого реального процесса, части реального мира.

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

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

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

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

- Построение информационной модели, абстрагирование реальных сущностей в терминах объектов и атрибутов.

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

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

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

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

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

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

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

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

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

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

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

Именно благодаря любимому детищу Билла Гейтса - Visual Basic, мир узнал о возможности визуального построения интерфейсов программ для Windows. Затем появился Delphi. Если Visual Basic целиком ориентируется на построение программ с визуальными интерфейсами, то Delphi ориентируется на работу с базами данных. Последние годы ходят мифы, что Basic - язык для начинающих. "Начинающие" восприняли Basic как панацею от компьютерных бед...

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

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

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

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

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

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

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

Это и есть визуализированная  форма записи программы. В одном  из диалогов с Митасовым Андреем (ООО "Интелпарт") мы коснулись вопросов реализации алгоритмической мультиязычности (КВ №45 за 1999). Интересен факт, что этот вопрос и визуальное программирование связаны между собой.

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

Список литературы

Для подготовки данной работы были использованы материалы с сайта http://my-pc.jino.ru/

Сначала давайте определимся  с главным – со значением самого термина «визуальное программирование». Объяснения на пальцах в духе школьного сочинения на тему «Что я думаю о высоких технологиях» нас, естественно, не устраивают, но, сколь бы это ни выглядело странным, изобилие статей и работ о Visual Programming (VP) порождает даже не определения, а именно описания наивно-механистического стиля (к слову, мы к этому факту еще вернемся в дальнейшем). Худшие из таких описаний, выполненные как «популярное объяснение», представляют VP чуть ли не технологией, обещающей, наконец, устранение всех сдерживающих, негативных факторов, из-за которых «…любой чернорабочий и любая кухарка не способны сейчас же вступить в управление…» компьютером (знаменитая в искаженной форме фраза «про государство», В. И. Ленин, т. 34, с. 315). Лучшие же, по сути, являются высоконаучными формальными построениями из областей теоретической семантики языков программирования, теории графов и прочих, без сомнения, исключительно важных, но далеких от повседневных потребностей большинства практикующих программистов разделов теоретической науки. Вот и получается, что все слышали о визуальном программировании, но рассказать что-то больше, чем «это там, где вместо слов используются картинки», мало у кого получается.

Впрочем, далеко не все так  плохо. Одно из лучших определений VP можно  встретить в работах Маргарет Барнет (Margaret Burnett) – оно настолько удачно, что его сочли достойным внесения в энциклопедический словарь электричества и электроники (Encyclopedia of Electrical and Electronics Engineering, John Wiley & Sons Inc., New York). Итак, «визуальное программирование – это программирование, в котором для передачи семантики используется более чем одно измерение. В качестве примеров таких дополнительных измерений можно привести применение многомерных объектов, пространственных или временных отношений для спецификации семантики отношения до–после». Традиционная (языковая) техника программирования с семантической точки зрения одномерна, потому как семантика программы определяется «линией» – строкой текста, содержащего собственно программу (Барнет упоминает о возможном «втором измерении» – комментариях и документации, которые только уточняют, поясняют, но никак не определяют семантику). Многие разновидности распространенных инструментальных средств в какой-то мере соответствуют приведенному определению: так, редакторы диаграмм и просто графические редакторы, позволяющие свободно, «от руки» рисовать электронным пером, могут быть (и часто бывают) основой и систем визуального программирования. Последние, к слову, способны играть роль транслятора с «многомерного языка» в «одномерный» – традиционный текстовый. В таком случае дополнительные семантические измерения удастся применить в самых различных целях – от обеспечения высоких показателей качества кода до облегчения работы кодировщика (это особенно ценно в традиционно сложных областях программирования, например при разработке программ, использующих потенциальные возможности параллельных вычислителей). Развитие идеологии и средств VP исторически следовало по двум основным направлениям – трансляция языка многомерной семантики в «одномерный язык программирования» и создание принципиально новых методов программирования. Первый путь фактически себя исчерпал, и редкие разработанные здесь удачные инструментальные средства («последние из могикан»), остающиеся востребованными, нашли применение в очень специфических областях. На втором пути были свои достижения и победы, но практически всегда многомерность VP-инструментов хорошо «работала» исключительно на уровнях сложности, которые смело можно называть учебными. При росте масштабов программного проекта VP утрачивало всякую привлекательность. Даже в области разработки аппаратных средств цифровой логики («даже» потому, что, по сути, эта область очень близка к программированию, разве что более проста) многомерные визуальные средства, схемотехнические редакторы, постепенно почти полностью уступили пальму первенства «одномерным» языковым.

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

Не все то не золото, что не блестит

Казалось бы, какое отношение  к программированию может иметь  такая организация, как Департамент  труда США (www.dol.gov)? Тем более к такой специфической технике, как визуальное программирование? Но давайте прислушаемся к прогнозам аналитиков этой организации: в 2012 г. в США к претендентам на 30% новых и 8% всех рабочих мест будет предъявляться требование владения навыками программирования. К сожалению сторонников евгеники, срок, отделяющий нас от 2012 года, не настолько велик, чтобы можно было успеть за это время вывести новую породу предрасположенных к программированию людей… Да и вообще, специфика прогнозирования в социологии такова, что глубина прогноза делает любые попытки евгенического улучшения общества бессмысленными. Собственно, из-за этого незначительного (но неприятного) недоразумения и начинается «вторая волна» интереса к VP – практичные и рассудительные ученые считают, что нет смысла гнать массы «в программирование», тем более в такое программирование, которое мы сегодня имеем. Более рационально создавать новое, так называемое «программирование на уровне конечного пользователя» (end-user programming), устраняющее ряд недостатков и даже фундаментальных барьеров, препятствующих освоению людьми, в принципе, не столь уж и мудреных ремесленных основ данной профессии. А вот барьеров этих не так уж и мало. Более того, по мнению исследователей Института человеко-машинного взаимодействия Университета Карнеги-Миллон (Human-Computer Interaction Institute Carnegie Mellon University), фундаментальных барьеров на пути «в непрограммирующие программисты» на сегодняшний день слишком много для того, чтобы рассчитывать на скорое многомиллионное пополнение армии умеющих писать хоть бы несложные «пользовательские» программки. К слову, «барьер» здесь использован не как метафора, а напротив как вполне конкретное понятие. Когнитивные барьеры в программировании – предмет изучения такой дисциплины, как «психология программирования», – это особые ситуации, возникающие в процессе познания человеком техники, инструментальных средств и т. д. Первая особенность таких ситуаций заключается в том, что они активируют проведение человеком оценок, описываемых моделью «перспективности умственных усилий» (перевод не дословный, англоязычный термин – attention-investment perspective). Эти оценки часто подсознательны, но любой здравомыслящий человек непременно соразмеряет затраты усилий и времени (и сопутствующие этим затратам риски) с возможными выгодами от них. Впрочем, здравомыслие ни в коем случае не означает обязательной правильности результата оценки. Вторая особенность определяется этим очевидным соображением и существенно сокращает перечень ситуаций, именуемых когнитивными барьерами, – результат оценки перспективности умственных усилий в этих ситуациях должен быть ошибочным. Забавно, что понятие когнитивных барьеров только на первый взгляд вступает в противоречие с откровениями об умных, которые учатся на чужих ошибках. Несмотря на то что о наличии когнитивных барьеров можно узнать только «после того», фактически – по безуспешным результатам их преодолений, их экспериментальное изучение дает исключительно важную информацию разработчикам программных систем. А подобные эксперименты проводились и проводятся. Так, в Университете Карнеги-Миллон над сорока «подопытными» будущими программистами, не имеющими никакой начальной программистской подготовки, провели масштабный эксперимент по изучению более чем лояльных в требованиях среды и языка программирования Visual Basic .NET. Продолжительное изучение процесса изучения позволило сформировать список больше чем из ста тридцати так называемых непреодолимых когнитивных барьеров (то есть приводящих к такой путанице «в голове», разобраться в которой без сторонней помощи уже невозможно).

Барьер, определенный фундаментальной  спецификой проблематики программирования, имеет, вопреки расхожему анекдоту об «ошибке в ДНК», весьма низкую степень важности – 0,03 (максимальное значение – единица). Речь идет о способности человека преодолеть отрыв между постановкой задачи и хотя бы первыми шагами к ее решению (даже без учета синтаксических и прочих правил описания решения). Чтобы было понятнее, этот барьер легче всего продемонстрировать на примере «алгоритма» решения задачи сортировки списка фамилий, предложенного одной из участниц эксперимента: «просто изменяйте положение фамилий в списке, показывайте список мне, а я скажу, когда задача решена».

Барьеры выбора намного более  важны (степень важности – 0,1, и это  при изучении такой насыщенной всевозможными  удобствами среды, как Visual Basic .NET). И, как показывает практика, куда более опасны. Суть их заключается в сложности определения доступных программных интерфейсов, сложности понимания скрывающейся за ними функциональности, сложности ассоциирования этой функциональности с потребностями при решении задачи. Примечательно, что при попытке написания программы «часы с будильником» многие «подопытные» будущие программисты затруднялись с выбором на разных этапах: при формировании правильных критериев поиска в справочной системе, при выборе наиболее подходящих для решения задачи функций, предложенных справочной системой, и наконец, даже при выборе наиболее подходящего фрагмента образцового кода из коллекции примеров.

Еще более важным барьерам (степень важности – почти 0,2) присвоено  весьма расплывчатое название «координационных». Более точно их можно именовать  барьерами неортогональности – в современных системах программирования существуют тысячи явно определенных и латентных отклонений от правила «полной ортогональности»: все действия применимы ко всем сущностям. Иначе говоря, программные интерфейсы и типы данных современных систем программирования налагают море ограничений на их совместную работу в сложных построениях.

Барьер использования (степень  важности – 0,28) – это следствие  оторванности описания программных  интерфейсов и типов данных от собственно интерфейсов и типов  данных. Да и кроме того, следствие невразумительности, нечеткости собственно описаний.

Барьер понимания (степень  важности – 0,29) возникает из-за огромного  отрыва между программой – последовательностью  воспринимаемых человеком символов – и программами времени компиляции и исполнения. К слову, многие специалисты  склонны считать, что попытки  решить эту проблему «в лоб», например максимально сблизив все три фазы существования программы, до сих пор к успехам не приводили. В качестве примера можно использовать замечательную во всех отношениях систему программирования Forth, в которой язык вынуждает программиста держать «в голове» среду времени исполнения программы (если быть точным, стеки Forth-системы).

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

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

VP. День сегодняшний

Реально работающих свободно распространяемых систем визуального  программирования на сегодняшний день существует не так уж и много. Некоторые  проекты давно заброшены авторами, некоторые так и не дошли до стадии пригодного к использованию  продукта. Упомянутый в начале статьи наивно-механистический стиль описания VP сыграл злую шутку – серьезные  программисты не восприняли в свое время все эти графические  «цацки» всерьез, а пытающиеся научиться программировать на уровне пользователя, столкнувшись с несоответствием декларируемой простоты и реальными характеристиками VP-самоделок, также утратили к ним интерес. Ну а технология, не получившая поддержки массового потребления, – это уже не технология.

И все-таки… Одна из очень любопытных систем визуального программирования разработана учеными Университета экономики и бизнеса Афин. Система VUFC интересна, впрочем, далеко не всем. В ней помощь в преодолении когнитивных барьеров даже не фигурировала в перечне ключевых требований к системе. Хотя бы потому, что основной потребитель VUFC – профессиональный пользователь, поменявший рабочую станцию под управлением Unix-совместимой ОС на ПК с «сугубо настольной ОС». И между тем VUFC (Visual Unix Filter Components) интересна тем, что в ней можно увидеть весьма неожиданный (но вполне соответствующий всему сказанному ранее)… прирост функциональности. По сути, VUFC аналогична командному интерпретатору, в котором программирование на уровне пользователя – это «склеивание» из компонентов-фильтров новых сущностей. В традиционных «одномерных» командных интерпретаторах выход одного компонента можно соединить с выходом другого. В VUFC потенциально возможны компоненты – концентраторы, направляющие один вход на группу выходов. Возможны и мультиплексоры входов – объединяющие группы потоков данных в один (например, по принципу «строка за строкой», когда в результирующем потоке следуют одна за другой строки разных входных потоков). Интересна и реализация VUFC: помещение фактически немодифицированных Unix-утилит в компонентные «облатки» – прием красивый и действенный.

Если VUFC можно отнести  к системам визуального программирования надкомпонентного уровня, то весьма симпатичную и хорошо документированную разработку SIVIL (www-cs.canisius.edu/~meyer/VP/home.html) без малейших сомнений следует причислить к «среднему классу». По сути, это «язык программирования и библиотека подпрограмм в картинках» с упрощенными механизмами выбора используемых конструкций (барьер выбора). К низкоуровневым средствам визуального программирования относится отличный «визуальный ассемблер» Algorithm Builder, целевой платформой которого являются 8-битные микроконтроллеры фирмы Atmel (home.tula.net/algrom/russian.html). Algorithm Builder – яркий представитель VP-систем специального назначения. Ограниченные ресурсы 8-битных микроконтроллеров и стремление разработчиков встраиваемого ПО добиться максимальной функциональности оправдывают использование машинного языка во многих проектах. А визуальная нотация в большинстве случаев позволяет добиться не только достаточно высокого уровня показателей качества кода, но и лучшей его «читаемости», т. е. большей пригодности к его сопровождению, что немаловажно при создании устройств с продолжительным сроком эксплуатации.

Приведенные примеры призваны продемонстрировать даже не столько  возможности VP-систем трех разных классов, сколько ситуацию с инструментальными  средствами визуального программирования в этих классах. Весьма удачная концептуально VUFC фактически осталась келейной разработкой, автор SIVIL хоть и довел систему  до более чем пристойного состояния, о ее широком использовании и речи идти не может (хотя… при минимальной языковой адаптации она более чем хороша для уроков информатики). И только узкоспециализированный Algorithm Builder можно назвать во всех отношениях благополучной разработкой, и главное – востребованной.

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

В систему программирования Visual Basic входит текстовый редактор для написания текстов программ и конструктор форм. Программист пишет исходные тексты программ на формализованном языке, который представляет собой последовательность команды или операторов.

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

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