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

Для подготовки данной работы были использованы материалы с сайта 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, Вы можете многократно запускать свою программу на выполнение, проверяя и отлаживая ее работу, и возвращаться обратно.