Get your own Free Home Page
"Сценарий-W" - инструментальная система визуальной разработки компьютерных программ для Windows |
Рассматриваются теоретические и концептуальные основы новой среды разработки программ, являющиеся результатом новейших достижений в области технологий программирования.
На протяжении всего существования вычислительной техники её развитие шло в направлении повышения быстродействия компьютеров, по пути увеличения объёма памяти последних и в сторону наращивания их вычислительной мощности, что делало возможным решение всё более и более сложных вычислительных задач. В то же самое время, развитие вычислительной техники сопровождалось также уменьшением размеров и стоимости оборудования, позволившим открыть доступ к компьютерной технике самому широкому кругу потребителей, вплоть до бытового, домашнего применения.
Однако история развития вычислительной техники - это не только история увеличения быстродействия, объёма памяти и вычислительной мощности, а также уменьшения размеров и стоимости оборудования. Вместе с тем, это ещё и история развития инструментальных средств и технологий разработки компьютерных программ, и история эволюции языков программирования. Кроме того, история развития вычислительной техники отмечена также упрощением пользовательских интерфейсов, являющихся, в частности, неотъемлемой частью любой системы программирования, и, так или иначе, приближением принципов взаимодействия пользователей с компьютерами к естественным, то есть интуитивно понятным каждому человеку и позволяющим полностью раскрыться его творческим способностям.
В самом деле, на первых порах программы для вычислительных машин составлялись напрямую в кодах, однако очень скоро началось создание и использование всевозможных автокодов, ассемблеров, компоновщиков, перемещающих загрузчиков, отладчиков, трансляторов с языков высокого уровня, библиотек поддержки разработки программ, авторских систем и других инструментальных средств разработки программ для компьютеров, предоставляя всё более и более широкому кругу людей возможность непосредственно участвовать в процессе создания программ. Иными словами, началась эпоха средств автоматизации программирования.
Одним из таких средств и является инструментальная система визуальной разработки компьютерных программ для Windows "Сценарий-W".
"Сценарий-W" - это универсальная авторская система поддержки визуального программирования с уникальным графическим интерфейсом, играющим роль языка визуального программирования, не уступающая по мощности таким языкам программирования, как, например, Pascal или C. Вместе с тем, эта система доступна более широкому кругу пользователей, чем традиционные языки программирования, выходящему далеко за рамки профессиональных программистов, благодаря тому, что она, как система визуального программирования, более легка в изучении и освоении, и зачастую её использование вообще не требует никакой предварительной подготовки, а также тому, что она не требует знания соглашений среды Windows для разработчиков прикладных программ, а также множества тонкостей, сопровождающих разработку программ для Windows.
Система "Сценарий-W" обладает следующими особенностями:
В данном разделе рассматриваются основные аспекты, связанные с применением в современных инструментальных средствах новой "синтаксической" формы, а именно визуального подхода, а также определяется место, занимаемое визуальным подходом в процессе создания современных компьютерных программ.
Есть возможность все широко известные средства общения пользователей с компьютерами разделить на следующие две категории:
dir c:*.txt /p/w/o:n/l
for i := 0 to 10 do Writeln (i);
for (i = 0; i <= 10; i++) printf ("%d\n", i);
10 timesRepeat: [ Turtle go: 10; turn: 5 ].
type APPLE_BASKET is new POSITIVE;
В последнее время наметились тенденции к замене традиционных "линейных" языков общения пользователей с компьютерами визуальными пользовательскими интерфейсами, особенно в области систем, предназначенных для самого широкого круга потенциальных пользователей, например Windows. Так, командные языки операционных систем постепенно вытесняются графическими операционными оболочками, прикладные программные системы больше не используют командные языки, а предоставляют вместо этого своим пользователям удобный визуальный пользовательский интерфейс[2]. Однако, к сожалению, в области инструментальных систем поддержки разработки компьютерных программ такая замена произошла ещё не в полной мере.
Инструментальные системы разработки компьютерных программ, существенно использующие визуальные языки, называются инструментальными системами визуального программирования или авторскими инструментальными системами.
Необходимость перехода к использованию визуальной технологии взаимодействия пользователей с компьютерами продиктована главным образом следующими причинами:
В настоящее время очень часто приходится иметь дело с информацией самого разного характера при использовании компьютера и, в частности, при создании прикладных программ. Например, компьютерное приложение ведения электронной базы данных может содержать запросы к базе данных, оформленные на специальном языке запросов[3], описание экранных форм пользовательского интерфейса, спецификации, используемые генератором отчётов при печате отчётов о состоянии базы данных и многое другое. Компьютерные игры и обучающие программы содержат графические изображения, музыкальное сопровождение, сценарии и другую информацию. Система автоматического перевода может состоять из описаний, выполненных на специальном языке и предоставляющих языковую информацию об исходном и целевом языках, а также из программы, которая пользуется этими описаниями в процессе перевода. Очевидно, что всю необходимую для описания этой информации гамму изобразительных средств невозможно представить в одном, к тому же традиционном языке программирования, поэтому современные компьютерные приложения включают в себя информацию, подготовленную на нескольких различных языках, включая визуальные языки, при помощи группы специализированных программных инструментальных средств представления информации.
Визуальные языки обеспечивают, как правило, более полный и своевременный контроль правильности предоставляемой пользователем информации по сравнению с традиционными языками. Система, использующая визуальный язык, имеет возможность взвесить и проконтролировать буквально каждый шаг, осуществляемый пользователем. Действительно, если, например, необходимо специфицировать один из режимов работы программы, пользователю ничего не остаётся другого, как сделать это. Он просто не сможет сделать ошибку, ведь при этом перед собой он видит диалоговую панель выбора режима работы. Аналогично, при выборе строки из меню или списка невозможно сделать ошибку, как при её наборе.
Работать с визуальными языками можно, как правило, намного быстрее, чем с традиционными, ведь на выбор той же строки из меню или списка из предыдущего примера уходит гораздо меньше времени, чем на её набор.
Для визуального подхода, в отличие от традиционного, характерна естественность и высокая наглядность представления любой информации, в то время, как в традиционных языках информация представляется часто в несколько закодированном[4] или условном виде, и уж тем более это представление совершенно неадекватно, когда речь идёт, например, о представлении графической информации. Действительно, вполне разумно, например, создавать графические изображения в графическом редакторе, музыкальное сопровождение - в музыкальном, а экранные формы разрабатывать в редакторе диалогов, чем использовать для представления этой информации языки традиционной архитектуры. Аналогично развитые алгоритмы обработки данных нагляднее представлять на экране компьютера в двумерном виде в форме направленного графа (в виде сценарной схемы, говоря, пользуясь терминологией системы "Сценарий-W"), а не в одномерном, как это происходит в обычных языках программирования. Важно понять, что визуальные языки часто способствуют настолько адекватному представлению информации, которое одни лишь традиционные языки, вследствие наличия у них определённых ограничений на их выразительность изобразительных средств, обеспечить не могут.
Визуальные языки являются на самом деле чем-то вроде синтаксически-ориентированных редакторов в самом своём сильном, даже можно сказать немыслимом или крайнем проявлении. Они всегда полностью ориентированы на структуру описываемой информации и её внутреннее содержание, а также на характерные для неё способы обращения с ней и постоянно направляют пользователя по правильному пути, подсказывая ему его ход дальнейших действий. Поэтому-то визуальные языки более просты в изучении, чем языки традиционной архитектуры. Зачастую визуальные языки вообще не требуют никакого предварительного изучения и интуитивно понятны. В то же самое время, большинство пользователей, как правило, испытывают известные трудности при изучении синтаксиса и грамматики традиционных "линейных" языков.
Ниже даны разъяснения по поводу двух факторов, тормозящих применение визуального подхода в качестве средства общения пользователей с компьютерами вообще и как средства разработки компьютерных программ в частности:
Существует целый ряд специалистов, предпочитающих использовать, например, командный язык UNIX Shell вместо современных графических операционных оболочек. По их утверждению, для них командный язык UNIX Shell обладает большей гибкостью по сравнению с Windows-подобным пользовательским интерфейсом. Что ж, это действительно может быть так в некоторых ситуациях, однако дело тут отнюдь не в преимуществах командного языка как такового, а в чрезвычайной стандартизованности форматов файлов, порождаемых и используемых утилитами операционной системы UNIX, и в наличии, таким образом, возможности совместного использования этих утилит, а также в конкретных недостатках существующих реализаций визуального подхода.
Для кого-то визуальное программирование может показаться нетрадиционным и необычным занятием, а потому незаслуживающим повсеместного применения. Что ж, до сих пор есть люди, предпочитающие, например, Fortran, язык, разработанный в 50-х годах, можно сказать на заре развития вычислительной техники, другим более современным языкам программирования. Программисты - народ чрезвычайно консервативный в вопросах перехода к использованию новых языков и технологий разработки программ, однако это, конечно же, не принижает достоинства сравнительно нового визуального подхода, и только время сможет исправить положение. В конце концов предпочтение того или иного средства - это личное дело каждого.
В данном разделе рассматриваются основные аспекты, связанные с применением в инструментальных средствах разработки программ, в том числе, базирующихся на визуальной технологии, современных подходов к организации компьютерных программ, особенно, когда дело касается так называемого программирования "в большом".
Одним из основных источников трудностей, с которыми сталкиваются при решении достаточно серьёзных задач, является большой размер программ. Для того чтобы преодолеть сложности, связанные с построением больших программ (для подавления "монстров" сложности), задачу необходимо разбивать на части, то есть проводить декомпозицию.
В результате декомпозиции образуются более или менее независимые части программного проекта. Однако на декомпозицию можно смотреть и с другой точки зрения - как на расширение языка, то есть разработку дополнительных специализированных инструментальных средств для последующего решения с их помощью основной задачи; с первой же точки зрения эти инструментальные средства, конечно же, являются частями исходного программного проекта (в случае применения для разработки программ системы "Сценарий-W" такими инструментальными средствами являются авторские типы элементов и авторские классы объектов). Таким образом, возможность лёгкого и быстрого построения новых инструментальных средств в рамках основной инструментальной системы является непременным условием для создания больших и сложных программ.
Для того чтобы действительно провести декомпозицию и иметь возможность отдельного и независимого рассмотрения частей программного проекта, необходимо решить какие части программного проекта будут иметь доступ к какой информации, то есть решить вопросы разграничения полномочий доступа. Существует целая гамма подходов к этой проблеме, часть из которых будет рассмотрена ниже.
В настоящее время существует немало авторских систем визуального программирования, среди которых можно выделить, например, такие системы, как Authorware Professional и Icon Author. Однако до настоящего времени системы разработки программ, использующие визуальные языки, были предназначены лишь для решения узкоспециализированных задач или небольших задач из широкого круга областей деятельности. Поэтому-то им было и не под силу тягаться с известными системами программирования, базирующимися на традиционных "линейных" языках, таких, как, например, Pascal или C. Дело в том, что до сих пор не было предпринято попытки использовать в практике визуального программирования современных технологий и принципов организации программ, таких, как:
Процедурное программирование является одним из эффективных способов декомпозиции больших и сложных программ; кроме того, многие другие мощные принципы разработки программ существенно опираются на него. В свою очередь, последний в полной мере реализуется лишь совместно с ними, особенно со статической типизацией данных, обеспечивающей необходимую в современных условиях независимость процедур.
При статической типизации данных каждое данное принадлежит к определённому типу, и уже во время разработки программы инструментальной системе известно, к какому. Система использует эту информацию для контроля правильности выполняемых над данными операций и предотвращает от совершения некоторых видов возможных ошибок при обращении с этими данными.
Динамическая типизация данных отличается от статической тем, что система не имеет возможности использовать эту информацию на этапе разработки программы.
Практика показывает, что программы, использующие статическую типизацию, более надёжны и предсказуемы (отсутствие "сюрпризов" и "подводных камней") и легче модифицируются, чем программы, использующие только динамическую типизацию.
Создание новых типов данных как абстрактных является наиболее естественным подходом, предоставляющим полную свободу действий по определению свойств объектов нового типа. Это достигается тем, что одновременно как бы существуют две точки зрения на объекты такого типа - внутренняя и внешняя. Имеется возможность заранее определить и зафиксировать в системе, какие части разрабатываемого программного проекта будут рассматривать эти объекты с внутренней точки зрения, то есть реализовывать их абстрактное поведение, а какие - с внешней, то есть использовать это абстрактное поведение. Объём последних, как правило, должен быть больше, чем первых, или, по крайней мере, должно планироваться, что это станет так в ходе развития проекта. Этих последних можно назвать клиентами или пользователями абстрактного типа. Они лишены возможности непосредственно иметь дело с внутренним представлением объекта и делают это только косвенно с помощью первых, называемых методами доступа к объекту Абстрактного Типа.
Когда мы создаём процедуру, мы абстрагируемся от деталей её реализации и её внутренних данных и впоследствии можем спокойно забыть об этом, освобождая голову для того, чтобы заняться чем-либо другим, более полезным в данной ситуации, что позволяет полностью сосредоточить своё внимание на реализации других частей программного проекта, в частности, других процедур. Однако эти внутренние данные существуют, как правило, лишь во время исполнения данной процедуры, в то время, как, создавая Абстрактный Тип Данных, мы имеем возможность абстрагироваться также и от данных, существующих любое, сколь угодно продолжительное, время. К тому же, нам предоставляется возможность иметь сколь угодно много независимых экземпляров (объектов данного Абстрактного Типа) таких данных.
Объектно-Ориентированное Программирование - это программирование от данных[5], при котором они становятся как бы полноправными действующими лицами процесса решения задачи, то есть объектами. Таким образом, объект неотделим от своего поведения. Так, об объектах совершенно справедливо говорится: "объект = данные + программы". В свою очередь, ООП невозможно без инкапсуляции данных, то есть сокрытия данных, являющихся лишь внутренним представлением объектов, внутри оболочки или капсулы, обеспечиваемого механизмом АТД. Объекты, как и любые другие данные, подвержены классификации - каждый объект принадлежит своему классу объектов, определяющему в общих чертах свойства данного объекта.
Популярность объектной модели в программировании объясняется, по всей видимости, её естественностью, то есть близостью концепции объекта к сущностям и явлениям реального мира.
Система "Сценарий-W" как раз и представляет собой подобную попытку, и многое из этого и даже кое-что своё (например, возможность создания собственных видов литералов) уже заложено в ней.
Одна из важных особенностей, которой должна обладать хорошая инструментальная система разработки программ - это однообразие и концептуальная экономия, упрощающая изучение и применение системы. Этой особенностью вполне обладает система "Сценарий-W", так как в процессе проектирования её ядра каждый механизм, каждая концепция была тщательно взвешены и проверены на непротеворечивость с другими. И действительно, всего лишь несколькими основными понятиями оперирует пользователь при работе с этой системой: класс объектов, объект, тип элементов, элемент, сценарная схема и некоторыми другими. Эти понятия немногочисленны, но весьма эффективны в концептуальном плане.
Давайте назовём литералами такие строки символов, являющиеся языковыми выражениями известных языков программирования и не только программирования, как, например:
10, 314.159e-2, "This is a string", 'a',
обозначающие некоторые понятия в нетрадиционной для основной грамматики языка форме и являющиеся, таким образом, с точки зрения этой грамматики лексемами, то есть неделимыми атомарными единицами, имеющими, тем не менее, вполне самостоятельное значение и смысл. Как правило, литералы изображают значения данных или состояния объектов, как, например, в языках программирования Pascal, C, Ada или Modula-2, или же некоторые виды предопределённых объектов, как это происходит, к примеру, в Clu или Smalltalk. По большому счёту, литералы невозможно заменить никакими грамматическими конструкциями языка, а посему его возможности ограничиваются богатством имеющихся в нём видов и форм литералов.
Ни один из известных языков программирования и ни одна из существующих систем программирования не предоставляют разработчикам компьютерных программ возможности на уровне языка создавать и использовать свои собственные виды литералов, в то время, как в системе "Сценарий-W" эта возможность воплощена в жизнь в полной мере, где свои виды литералов представлены в лице дизайнеров объектов авторских классов.
Даже универсальные макропроцессоры не решают эту проблему в полной мере и поэтому редко применяются для подобных целей, так как создание новых видов литеральных конструкций в них сопряжено, как правило, с определёнными трудностями, связанными с необходимостью реализации алгоритмов грамматического разбора этих литеральных конструкций и последующей их интерпретации, что, к тому же, не даёт максимального эффекта, поскольку изобразительные возможности литералов, представленных в традиционном "линейном" (не визуальном) языке, ограничены изобразительными возможностями такого языка, которых часто явно недостаточно для представления таких понятий, как, например, графические изображения, музыкальное сопровождение, описания диалоговых панелей, и вообще любых других понятий, описание которых требует достаточно индивидуального подхода.
Конечно, всегда есть возможность решить эту проблему и в отсутствие вышеупомянутого механизма, например, представляя информацию в неадекватной форме или же храня её в отдельных файлах и создавая в специализированных редакторах, однако последнее способствует возникновению неоправданных и немотивированных неоднородностей в отношении подходов, касающихся обращения с ней, а также приводит к ухудшению контроля правильности использования этой информации, заставляя полагаться в этом на явно устаревшую и не предназначенную для этого традиционную файловую систему.
Используя же систему "Сценарий-W" для создания программ, можно с лёгкостью избежать подобных проблем, прибегая к возможности создания своих собственных дизайнеров объектов. В этом смысле систему "Сценарий-W" можно рассматривать как своеобразную специализированную объектно-ориентированную файловую систему, в которой каждый файл - дизайн объекта или, попросту говоря, объект - служит, как правило, для описания части программного проекта и принадлежит к определённому классу. С точки же зрения операционной системы весь проект выглядит как один файл для обеспечения полноты контроля целостности объектов (заметьте, что разработчики системы "Сценарий-W" не претендовали на создание новой самостоятельной операционной системы).
Остаётся подчеркнуть, что лишь данная уникальная возможность, позволяющая в рамках основной инструментальной системы создавать новые визуальные инструменты разработки программ, даёт возможность говорить о визуальном программировании в полном смысле этого слова.
В данном разделе подробно рассмотрены концептуальные механизмы системы "Сценарий-W".
В дальнейшем изложении программный проект будет называться сценарием, процесс его разработки - сценаризацией, а пользователь системы "Сценарий-W", разрабатывающий с её помощью сценарий - автором сценария.
Алгоритмическая часть программного проекта определяется в системе "Сценарий-W" сценарной схемой, являющейся некоторым подобием известной блок-схемы (flowchart). Однако в отличие от последней, внутреннее содержание основных структурных единиц построения сценарной схемы - элементов - и действия, выполняемые ими, гораздо разнообразнее, чем это обычно происходит в случае блок-схем.
Итак, сценарная схема состоит из соединённых друг с другом элементов сценарной схемы, обеспечивающих выполнение определённых действий. Каждый элемент имеет один или два выхода в зависимости от своего типа элементов. Каждый выход данного элемента, в свою очередь, связывается с каким-либо другим элементом сценарной схемы, тем же самым элементом или остаётся несвязанным ни с каким элементом, то есть является точкой выхода из сценарной схемы. В сценарной схеме имеется также специальная точка входа, связанная с одним из её элементов, называемым в этом случае стартовым элементом.
При исполнении сценарной схемы последовательно исполняются её элементы, начиная со стартового элемента, на который указывает точка входа. После исполнения некоторого элемента управление передаётся по одному из его выходов в зависимости от результата исполнения и решения, принятого элементом по этому поводу. Если данный выход связан с каким-либо элементом сценарной схемы, то последний и будет следующим в цепочке исполняемых элементов, в противном случае исполнение сценарной схемы завершается. В процессе своего исполнения элемент определённым образом воздействует на объекты, выполняя при этом соответствующую операцию.
В сценарии всегда присутствует так называемая главная сценарная схема. Исполнение сценария - это исполнение его главной сценарной схемы.
Внутренним содержанием любого элемента является набор его параметров, предназначенный для передачи информации об участвующих в операции объектах. Таким образом, каждый параметр несёт свою смысловую нагрузку и связывается, в свою очередь, с каким-либо объектом. Операция связывания параметра элемента с объектом называется операцией установления соответствия "параметр элемента - объект". Каждый параметр характеризуется некоторым классом объектов, с объектами которого он может быть связан, и система строго следит за соответствием классов. На самом деле, просто-напросто отсутствует возможность сделать ошибку, связанную с несоответствием классов, так как при выполнении операции связывания параметра элемента с объектом система предъявляет автору список объектов лишь нужного класса объектов, что возможно, поскольку в системе "Сценарий-W" принадлежность объекта к конкретному классу объектов известна ещё на этапе разработки программы. Таким образом реализуется парадигма статической типизации данных. Параметры элемента имеют наименования и предъявляются в окне Windows в строго установленном порядке.
Каждый элемент, в свою очередь, снабжается иконой - небольшим стилизованным изображением, используемым для визуального представления данного элемента в сценарной схеме и позволяющем легко различать его тип элементов. Ему также автоматически присваивается уникальный номер в данной сценарной схеме, чтобы всегда иметь возможность отличать его от других элементов той же схемы. Кроме того, элемент может иметь авторский комментарий, что позволяет автору сделать программный проект документированным, прозрачным и удобочитаемым, и, таким образом, без труда находить нужный элемент среди прочих других элементов сценарной схемы.
Каждый элемент принадлежит какому-либо типу элементов и является отдельным, независимым представителем - экземпляром - своего типа. Тип элементов системы "Сценарий-W" может рассматриваться как инструментальное средство, порождающее элементы и определяющее для каждого из них икону, количество выходов (один или два), количество, классы, наименования и порядок следования параметров, а также в общих чертах характер выполняемых действий. Икона, количество выходов, количество, классы, наименования и порядок следования параметров, а также наименование типа элементов составляют внешнее формальное проявление последнего или, другими словами, его интерфейс с использующими его в своих целях другими частями программного проекта, коими являются главная сценарная схема, авторские типы элементов и авторские классы объектов.
Принадлежность к определённому типу элементов является первичной, неотъемлемой характеристикой элемента, определяемой в момент создания последнего. Тип элементов - это как бы шаблон, в соответствии с которым может быть создано любое количество конкретных элементов данного типа. Остаётся отметить, что существуют типы элементов без параметров. В частности, возможна разработка такого типа элементов самим автором сценария[7].
Интересно обратить внимание на следующий терминологический сдвиг: В системе "Сценарий-W" аналогом процедуры является тип элементов. А соответственно, аналогом вызова процедуры является элемент.
В процессе изложения концепции элементов сценарной схемы не раз упоминалось понятие объекта, которое наряду с понятием элемента также является одним из важнейших понятий системы "Сценарий-W". Объект в системе "Сценарий-W" - это универсальное средство представления предметов и явлений реального мира, а также всевозможных абстракций. Объекты существуют и проявляют свои свойства главным образом лишь во время исполнения программы.
Посредством объекта можно представить практически любую сущность. Простейшие переменные (целые, вещественные, строковые и другие), структуры данных, графические изображения, описания диалоговых панелей, окна Windows, действия, процессы - вот лишь небольшой перечень примеров концепций, представимых объектами, однако в отличии от элемента объект никогда не связывается ни с другими объектами, ни вообще с какими-либо другими понятиями системы и существует независимо от них; в этом состоит основное различие в назначении объектов и элементов и одна из главных причин, по которой необходимо было ввести оба эти понятия. Таким образом, объект способен проявлять свои свойства как пассивно, так и активно, являясь как бы полноправным действующим лицом, принимающим участие в процессах, происходящих при решении задачи.
Сходство элементов и объектов состоит в том, что каждый объект принадлежит какому-либо классу объектов и является отдельным, независимым представителем - экземпляром - своего класса. Принадлежность объекта к конкретному классу объектов известна уже во время разработки программы, что способствует проявлению механизма статической типизации данных. Класс объектов системы "Сценарий-W" может рассматриваться как инструментальное средство, порождающее объекты и определяющее в общих чертах их свойства, а также характер процессов, в которых они могут принимать участие. Подобно типу элементов, класс объектов также имеет своё наименование.Итак, как можно заметить, сценарная схема как бы объединяет вместе разнородные элементы сценарной схемы и разнородные объекты для их совместного функционирования. Таким образом происходит совместное использование существующих инструментальных средств, коими являются типы элементов и классы объектов, для создания самой программы решения основной задачи пользователя, то есть главной сценарной схемы, и образования новых инструментальных средств, а именно авторских типов элементов и авторских классов объектов.
Для того чтобы обеспечить существование какого-либо объекта во время исполнения сценария, этот объект необходимо описать. При этом, первое, что происходит при описании объекта - это специфицируется его класс объектов, а затем объекту даётся наименование. Каждая сценарная схема имеет своё множество описаний локальных объектов, область действия которых распространяется лишь на данную сценарную схему, то есть эти объекты могут участвовать в операции установления соответствия "параметр элемента - объект" только с параметрами элементов этой схемы. Всякий раз, когда начинается исполнение данной сценарной схемы, по этим описаниям локальных объектов создаются и начинают жить в системе реальные объекты. Следовательно, пользуясь терминологией языка C, можно говорить о том, что объекты в системе "Сценарий-W" всегда имеют автоматический класс хранения, что гарантирует полную независимость активаций сценарной схемы и отсутствие труднообнаруживаемых ошибок, связанных с возникновением так называемых побочных эффектов. Остаётся добавить, что по этой же причине в принципе возможны рекурсивные вызовы типов элементов, когда речь идёт о разработке авторских типов элементов.
Объект может иметь сопровождающий его описание дизайн. Это значит, что имеется как бы возможность работать с объектом уже на этапе разработки программы, то есть влиять на него (с целью придания ему необходимых начальных индивидуальных свойств) посредством использования специальной программы, поставляемой его классом объектов и называемой дизайнером, которая, как правило, представляет информацию об объекте в наиболее адекватной форме и естественном для него виде, благодаря тому, что дизайнер почти ничем не отличается от любой другой программы Windows и посему ничем не стеснён в изобразительных средствах. В действительности же, совместно с процессом определения дизайна происходит так называемое сохранение объекта, то есть создание автономного клона объекта в специальной независимой перманентной среде, например, во внешнем файле, и последующее его восстановление - процесс абсолютно прозрачный для сценария. Таким образом, дизайн объекта есть тоже объект того же класса объектов, что и исходный объект, со свойствами идентичными начальным свойствам исходного объекта, однако тем не менее отличный от последнего, ведь, как уже было замечено выше, сам описанный объект конечно же всё ещё не существует на этапе разработки сценария. Важно что, несмотря на идентичность начальных свойств объекта и свойств его дизайна, действия с этим объектом никогда не смогут испортить дизайн последнего, а следовательно, и сам сценарий, частью которого и является дизайн объекта. В клоне проявляется суть исходного объекта, то есть всё то, что существенно для внутренней логики исполнения сценария. Таким образом, реализуется идея так называемых устойчивых объектов (persistent objects), яркий пример реализации которой можно видеть также в системе Smalltalk. Использование механизма устойчивых объектов гораздо предпочтительнее самостоятельного сохранения объекта в какую бы то ни было среду и последующего восстановления последнего[8], так как оно обеспечивает полный контроль корректности выполнения операции и гарантирует полную сохранность свойств исходного объекта.
В связи с проблемой сохранения объектов, наверное, целесообразно будет рассмотреть понятие индивидуальности объектов. Индивидуальность - свойство присущее любому объекту быть самим собой. Клон объекта теряет свойство индивидуальности последнего, так как является уже другим объектом, и приобретает своё. При этом все остальные свойства исходного объекта сохраняются. Свойство индивидуальности некоторого объекта может быть как существенным в рассматриваемой ситуации, так и, напротив, несущественным. Например, существенно свойство индивидуальности объекта-переменной, хранящей информацию о наличии средств на банковском счету, потому как в противном случае можно было бы легко разбогатеть, просто пользуясь клонами этой переменной при изъятии средств. Однако, по всей видимости, предполагается несущественность индивидуальности объектов, расположенных в файле или на съёмном носителе информации, например, на дискете, так как всегда имеется возможность сделать копию файла или носителя информации, образовав тем самым клоны этих объектов. Этим, очевидно, объясняется несущественность индивидуальности дизайна, потому что дизайн, являясь структурной единицей самого сценария, явно должен быть достаточно самостоятельным объектом способным, по-видимому, свободно располагаться в независимом файле на съёмном носителе информации.
Теперь становится понятным, что не каждый объект можно сохранить в независимой перманентной среде, то есть не для каждого объекта возможно создание клона. К примеру, остаётся непонятным каким образом это можно сделать для окон Windows, ведь суть этих объектов проявляется в их взаимоотношениях с другими окнами, а следовательно, и в их индивидуальности; другими словами, клоны этих объектов были бы уже другими объектами, лишёнными индивидуальности первых, а ведь в этом проявляется их суть. Те объекты, сохранение которых возможно, называются сохраняемыми. Для любого сохраняемого объекта автор сценария всегда может определить дизайн. Те объекты, сохранение которых невозможно называются несохраняемыми. Для них невозможно определить дизайн. Свойство сохраняемости или несохраняемости в системе "Сценарий-W" характерно одновременно для всех объектов данного класса объектов. Классы сохраняемых объектов называются сохраняемыми. Соответственно, классы несохраняемых объектов называются несохраняемыми. Тем не менее, большинство системных классов объектов системы "Сценарий-W" являются сохраняемыми классами объектов.
На тот случай, если автора сценария не устраивают по тем или иным причинам предоставляемые ему системой "Сценарий-W" инструментальные средства - типы элементов и классы объектов - он имеет возможность самому создавать свои собственные инструментальные средства - авторские типы элементов и авторские классы объектов.
Цели создания авторских инструментальных средств могут быть самые разные. Например:
При разработке авторского типа элементов разрабатывается сценарная схема исполнителя элементов данного типа, которая исполняется при исполнении любого элемента этого типа. Параметры исполняемого элемента формально используются в процессе построения сценарной схемы исполнителя элементов соответствующего типа на правах объектов; причём каждый из этих параметров является представителем объекта, с которым данный параметр связан. При выполнении операции установления соответствия "параметр элемента - объект" для элементов этой сценарной схемы каждый из этих параметров появляется в списках объектов характеризующего данный параметр класса или же класса внутреннего представления объектов этого класса, если данный параметр характеризуется авторским классом объектов, и для этого параметра при определении интерфейса соответствующего типа элементов была включена специальная установка "вскрываемый". Таким образом происходит передача информации об объектах, принимающих участие в процессе исполнения данного элемента, и дальнейшее использование этой информации.
Для лучшего понимания назначения сценарной схемы исполнителя элементов данного авторского типа элементов можно мысленно представить себе, что эта сценарная схема как бы подставляется вместо какого бы то ни было элемента соответствующего типа. При этом вместо параметров данного элемента, фигурирующих в этой сценарной схеме, подставляются соответствующие объекты, а точки выхода из этой сценарной схемы ассоциируются с выходом этого элемента (другими словами, этот выход подставляется вместо этих точек выхода), если речь идёт о разработке одновыходового типа элементов, то есть типа элементов, имеющих по одному выходу. При разработке же двухвыходового типа элементов имеется возможность определить для каждой точки выхода из этой сценарной схемы с каким из выходов данного элемента она ассоциирована.
Итак, как можно заметить, фактическая реализация любого авторского типа элементов полностью определяется сценарной схемой исполнителя элементов данного авторского типа элементов.
Авторский класс объектов всегда разрабатывается как Абстрактный Тип Данных. Таким образом, при создании авторского класса объектов обязательно указывается один из уже существующих в системе классов объектов, являющийся классом внутреннего представления объектов создаваемого класса. На объекты любого авторского класса объектов могут одновременно существовать две точки зрения: внешняя и внутренняя. Внешняя точка зрения должна использоваться, по идее, в большинстве случаев - частями программного проекта, являющимися клиентами данного класса объектов и использующими его в своих целях; при этом объекты этого класса рассматриваются как имеющие непосредственно свой класс. Внутренняя точка зрения должна использоваться, по идее, лишь в небольшом числе мест программного проекта, а именно в дизайнерах объектов данного класса и типах элементов, являющихся методами доступа к объектам этого класса и реализующих их абстрактное поведение; при этом объекты этого класса рассматриваются как имеющие класс своего внутреннего представления. Таким образом, объект любого авторского класса объектов может рассматриваться как имеющий как непосредственно свой класс, так и класс, характеризующий его внутреннее представление. В последнем случае говорится, что имеет место вскрытие объекта Абстрактного Типа[9] или доступ к его внутреннему представлению. В системе "Сценарий-W" имеется возможность весьма гибкого управления полномочиями доступа к внутреннему представлению объектов авторского класса с точностью до отдельного авторского типа элементов. Так, для каждого параметра элемента в его типе элементов указывается, будет ли он рассматриваться в сценарной схеме исполнителя как имеющий свой класс или же как имеющий класс внутреннего представления.
При разработке авторского класса объектов разрабатывается сценарная схема дизайнера объектов данного класса, которая исполняется всякий раз при определении дизайна любого объекта этого класса. Специальный предопределённый параметр ">>>>> ДИЗАЙН <<<<<", характеризующийся классом внутреннего представления объектов данного класса, формально используется в процессе построения сценарной схемы дизайнера объектов на правах объекта для доступа к дизайну объекта, являясь полномочным представителем дизайна, который, в свою очередь, как уже было замечено выше, сам по себе является объектом соответствующего класса.
Весьма немаловажным является то обстоятельство, что при разработке авторских инструментальных средств - авторских типов элементов и авторских классов объектов - используются в основном те же инструментальные средства, те же механизмы и те же принципы, что и при разработке главной сценарной схемы решения основной задачи пользователя, то есть описываются объекты и строятся соответствующие сценарные схемы, что делает систему концептуально однообразной и освобождает пользователя системы "Сценарий-W" от необходимости изучения каких-либо специальных средств разработки авторского инструментария и средств расширения возможностей системы. В свою очередь, авторские инструментальные средства используются наравне с любыми другими средствами. В этом смысле между ними нет абсолютно никаких различий, и в принципе существует возможность подмены инструментальных средств, предоставляемых системой "Сценарий-W", авторскими инструментальными средствами.
В сценарии такие сущности, как объекты, авторские классы объектов и авторские типы элементов, имеют свои наименования, являющиеся скорее авторскими комментариями к их содержанию, дескриптивными описаниями их назначения, чем их идентификаторами, ибо каждая такая сущность представляется отдельной строкой с соответствующим наименованием в соответствующем списке и специфицируется всего лишь указанием такой строки. Таким образом, всегда можно изменить наименования этих сущностей, приводя тем самым их в соответствие с их функциями, в том случае, если это соответствие было так или иначе нарушено в результате развития программного проекта; при этом логика работы программы никак не нарушается, и не нужно заботится о соответствующем изменении ссылок на эти сущности в проекте, так как они просто-напросто не идентифицируются своими наименованиями, но скорее идентифицируются индивидуальностью своих описаний. Данная возможность, возникновение которой является естественным и прямым проявлением визуального подхода, позволяет легко поддерживать документированность и наглядность программного проекта на хорошем уровне, что способствует повышению культуры разработки компьютерных программ.
Для того чтобы определить место, занимаемое в системе "Сценарий-W" инструментальными средствами (классами объектов и типами элементов), предоставляемыми непосредственно самой системой, необходимо рассмотреть классификацию инструментальных средств системы "Сценарий-W". Итак, все имеющиеся в системе "Сценарий-W" инструментальные средства (классы объектов и типы элементов) подразделяются главным образом на следующие категории:
Системные инструментальные средства, в свою очередь, подразделяются по способу реализации на следующие две категории:
В системе "Сценарий-W" проблемно-ориентированные инструментальные средства и, конечно же, авторские инструментальные средства всегда небазовые. Таким образом, отсюда видно, что система "Сценарий-W" является саморазвиваемой системой, то есть принадлежит к разряду самонастраиваемых систем, наиболее яркими примерами которых являются такие системы программирования, как Smalltalk, Lisp или Forth, что, учитывая существенное повышение производительности труда при разработке новых инструментальных средств в рамках основной инструментальной системы, как и при разработке непосредственно программ решения прикладных задач пользователя, позволяет говорить о возможности осуществления гибкой настройки системы, а также о быстроте её ориентации к изменяющимся запросам рынка программных средств путём разработки новых специализированных инструментальных средств. Самонастраиваимость вообще является весьма важным своиством системы, так как оно позволяет проводить последовательно повторное использование имеющихся наработок и вырабатывать оптимальные взаимозависимости между различными компонентами системы, коими являются в данном случае системные и проблемно-ориентированные классы объектов и типы элементов. Разработка небазовых системных и проблемно-ориентированных инструментальных средств для системы "Сценарий-W" ведётся точно также, как и разработка авторских инструментальных средств.
Итак, системные инструментальные средства системы "Сценарий-W" могут быть как базовыми, полностью реализованными в коде на традиционных языках программирования, так и небазовыми, реализованными средствами самой же системы "Сценарий-W".
Базовые инструментальные средства системы в первую очередь призваны дополнить совокупность вышеописанных механизмов ядра системы, основной задачей которых является обеспечение возможности управления взаимодействием различных частей программного проекта и инструментальных средств между собой, до полнофункциональной системы программирования, обладающей вычислительной мощностью равной вычислительной мощности любого процедурного языка программирования. Это касается как чисто теоретических аспектов, например, необходимости предоставления памяти теоретически неограниченного объёма, так и практических, связанных со скоростью исполнения реально разрабатываемых программ, а также с возможностью всё же достаточно быстрой дальнейшей раскрутки возможностей системы при помощи самой же системы и разумным использованием при этом производительных сил, то есть с выбором компромисса между стоимостью такой раскрутки и гибкостью результирующей совокупности базовых инструментальных средств.
Принимая во внимание всё сказанное, было тщательно подобрано и разработано порядка двадцати (20) базовых классов объектов и ста восьмидесяти четырёх (184) базовых типов элементов, объединённых в библиотеки типов элементов. Эти классы объектов и типы элементов охватывают практически все аспекты программирования для среды Windows и программирования процедур обработки данных и включают в себя:
Средства доступа к возможностям операционной оболочки Windows, предоставляемые автору системой "Сценарий-W", зачастую гораздо выше уровнем, чем средства, предоставляемые непосредственно интерфейсом прикладных программ среды Windows API (Windows Application Program Interface), что избавляет автора от необходимости изучать и знать все тонкости и соглашения, характерные для разработки программ для среды Windows, при сохранении в большей части гибкости и функциональных возможностей этой операционной оболочки, и, таким образом, позволяет говорить о наличии в системе "Сценарий-W" специализированной высокоуровневой библиотеки поддержки разработки программ для среды Windows, то есть некоего посредника между интерфейсом прикладных программ среды Windows и автором, примерами которых являются, к примеру, такие достаточно широко известные библиотеки, как Object Windows или же MFC (Microsoft Foundation Class).
Так, система "Сценарий-W" освобождает автора от необходимости разработки процедур удовлетворения запросов системы Windows на перерисовку содержимого окна (обработки сообщения WM_PAINT), гарантируя тем самым последовательность[10] получаемого в окне изображения и позволяя непосредственно приступить к созданию программ для среды Windows тем, для кого непривычна идеалогия программирования, управляемого событиями (event driven programming), навязываемая системой Windows.
Также много возможностей предоставляют автору средства группировки и аггрегирования данных, представленные в лице базового системного класса объектов "Коллекция" и методов доступа к объектам этого класса, предоставляющего огромные возможности по формированию и хранению всевозможных списков, массивов, наборов, записей, деревьев и объединений данных, избавляя при этом автора от необходимости заботиться о явном освобождении памяти, что вообще характерно для библиотек базового набора и для инструментальных средств системы "Сценарий-W". Данное обстоятельство позволяет говорить, используя терминологию языка C++, о наличии в системе "Сценарий-W" механизма автоматического вызова деструкторов объектов и о последовательном использовании этой возможности.
В системе "Сценарий-W" средства вызова внешних функций, в отличие от других подобных авторских систем, позволяют автору вызывать любую внешнюю функцию с любым интерфейсом, то есть с любой совокупностью параметров и методов передачи и организации информации. Так, всё, что может быть вызвано, например, из программы на C или Pascal может быть вызвано также и из сценария.
Вместе с тем, постоянно идёт развивитие также и набора небазовых системных инструментальных средств, предоставляя всё больше и больше функциональных возможностей широчайшему кругу потенциальных пользователей этой авторской инструментальной системы. Охватываются такие области, как: небазовый высокоуровневый ввод и вывод информации, анимация, работа с внешними источниками информации, такими как файлы, специализированные типы данных, представленные, естественно, в лице специализированных классов объектов, поддержка мультимедиа и многое другое.
Подводя итог сказанному, хотелось бы подчеркнуть, что система "Сценарий-W" реализовывает по-видимому самый естественный подход к разработке компьютерных программ из когда-либо предложенных на рынке инструментальных систем, снимая порой искусственно образовавшиеся трудности на и без того нелёгком пути создания компьютерных программ. Таким образом, система "Сценарий-W" являет собой важный шаг в развитии инструментальных средств разработки программ для компьютеров, заслуживающий внимания как со стороны профессиональных программистов и системных аналитиков, так и со стороны пользователей самых различных категорий.
Get your own Free Home Page
[1] Именно этими языками интересуется так называемая теория формальных языков.
[2] Даже появился стандарт, регламентирующий основные принципы некоторых видов взаимодействий пользователей с компьютерами, касающихся выбора всевозможных элементов конечного дискретного множества. Речь здесь идёт о стандарте, названном CUA (Common User Access), которому удовлетворяют практически все современные графические операционные оболочки и прикладные программные системы. При этом стандарт CUA не является просто "ещё одним" условным соглашением разработчиков подобных систем. Напротив, он носит скорее чисто фундаментальный характер, так как в нём зафиксированы лишь наиболее естественные и интуитивно понятные с точки зрения большинства нормальных пользователей и здравого смысла приёмы работы в вышеуказанных ситуациях. В частности, он даже не регламентирует то, что, например, так называемая Radio-кнопка должна быть "круглой", уделяя при этом основное внимание более существенным вещам.
[3] Например на языке SQL (Structured Query Language), ставшим фактически промышленным стандартом в области систем управления распределёнными базами данных.
[4] Как знать, быть может от этого возникло название процесса программирования как кодирования, ведь эра составления программ в кодах вычислительной машины канула в лету довольно давно, по сравнению с временем существования данной индустрии.
[5] Программирование, управляемое данными (data driven programming), в противоположность классическому программированию, управляемому процедурами.
[6] Приведём здесь лишь некоторые, наиболее интересные из них: Модульное программирование (Modula-2, Ada, Turbo Pascal, C, C++), Настраиваемые пакеты, модули, кластеры (Ada, Clu), Обработка исключительных ситуаций (Ada, Clu, современные версии языков Pascal и C++), Наследные типы данных (Ada), Мультизадачность с механизмом rendez-vous (Ada), ...
[7] Речь идёт о разработке авторского типа элементов без параметров.
[8] А проще говоря, самостоятельного копирования объекта или создания его дубликата.
[9] В данном случае было бы более естественно сказать "Класса", однако термин "Абстрактный Тип" является в некотором роде фразеологизмом, то есть словосочетание "Абстрактный Класс" понималось бы не так как "Абстрактный Тип", если бы вообще понималось.
[10] Правильноподобность, то есть, в частности, отсутствие мусора в окне, связанного с окказиональной перерисовкой, вызванной активностью пользователя.