Письмо в редакцию
Юрий Хныкин
Некоторые проблемы, связанные с реализацией ИС, описаны в статье “По лезвию бритвы” (см. PC Week/RE, № 5, с. 59), в частности взаимосвязанные проблемы “многоуровневая интерпретация” и “хождение по лезвию бритвы”.
В прессе также довольно часто муссируется вопрос. “Делать самому или купить на стороне?”. Несколько реже - “Что лучше - много АРМов или одна большая программа?”.
А не кажется ли вам, что все это (и многое другое) определяется степенью открытости ИС? (Гром аплодисментов, летящие тухлые яйца, возгласы “где взять ?”, “покажите пальцем”.)
Так что же такое “открытая ИС” и как ее создать? Попробую объяснить в меру своего представления и попутно попытаюсь сформулировать некоторые основополагающие требования к открытой ИС. Рассматривать “открытость” в отрыве от всего остального достаточно сложно (получится та же Java, которая кроме открытости и переносимости больше ничего хорошего не дает), придется затронуть и другие проблемы ИС, но основной “разбор полетов” хотелось бы посвятить именно “открытости”.
Важнейшие факторы, влияющие на открытость системы
В первую очередь следует назвать опыт и творческие способности разработчиков - именно отдельно взятых индивидуумов, от которых зависит разрабатываемая система, а не команды в целом. И никакие CASE-средства не помогут им создать открытую систему, если они об этом не позаботятся. Возможности команды играют немаловажную роль, но выправить “вывихи” генератора идей или вывести зашедшую в тупик систему она не сможет.
Другой серьезный фактор - способ выбора средства разработки (СР).
Обычно СР выбирает руководитель сотоварищи на основе своих требований (скорость разработки, количество и структура библиотек, производительность компиляторов и готовой программы, визуальные средства программирования и документирования версий, производители, цена и т. п.).
При этом иногда учитываются пожелания будущих потребителей готовой продукции. И как следствие такого выбора - готовые системы оказываются удобными для команды разработчиков, но никак не для пользователей.
Ситуацию усугубляют сами покупатели, выбирая по принципу “побольше функций за меньшую цену”, совершенно не учитывая, что через некоторое время все равно “маловато будет”.
Но какими бы гениями ни были создатели ИС, они все-таки используют какие-то инструменты в своей работе. И достоинства, равно как и недостатки этого инструментария, так или иначе перейдут в готовую программу, при этом перемножившись на интеллект разработчиков. Идеальный вариант: все достоинства инструментария переходят в ИС, а недостатки частично устраняются или сглаживаются.
Так что степень открытости ИС полностью будет соответствовать открытости средства ее реализации.
Попробую обрисовать требования к ИС (и соответственно к средствам ее реализации) с точки зрения пользователя, а потом переведу их на язык программистов. Итак, сначала о пользователе.
Пользователь может иметь различный уровень подготовки - от продавца-кассира, проводящего сканером по этикеткам штрих-кодов, до отставного подполковника, самостоятельно освоившего бух-бейсик.
Своим делом он занимается в зависимости от должностных и функциональных обязанностей, не спрашивая на это согласия разработчика программ.
При этом учтем, что покупатель (пользователь) всегда прав и ни к чему заставлять бабушку изучать то, что ей никогда не потребуется, но не надо мешать молодым и жаждущим наращивать и показывать свои способности. Таким образом, получим некоторые требования.
Удобство восприятия. Незачем применять графический интерфейс там, где нужен расширенный калькулятор, в то же время использовать терминал для многомерного анализа банков данных тоже нереально.
Чувствительность к пользователю и “железу”. Так как “совмещение профессий” конечных пользователей заранее неизвестно, ИС должна позволять комбинировать из модулей нужное конкретному пользователю рабочее место.
Пользовательский интерфейс, посредством которого производится ввод данных в систему и получение от нее нужной информации, отличается сложностью всяческих проверок на корректность введенной информации с точки зрения законодательства или требований хранилища данных. И в то же время эти диалоги должны уметь подстраиваться под нужды оператора.
Не помешает наличие визуальных средств, доступных непосредственно пользователю. Попытаюсь объяснить на примерах.
Пример 1. Допустим, есть реестр каких-то документов. Одному хочется рассматривать его колонки в порядке “дата, сумма, счет,..”, другому - “сумма, кому, за что,..”, а третьему - и то и другое по очереди.
Пример 2. Реквизиты одного документа удобнее вводить в порядке “сумма, кол-во, чего,..”, другого - “номер, дата, сумма,..”, а у третьего вообще диалог на одном экране не умещается.
Пример 3. У одного пользователя монитор 4000х4000, у другого пейджер 9х12, а у третьего - “Web-смотрелка” или, что еще приятнее, - факс.
Пример 4. Один и тот же пользователь может работать с машиной на базе 286 процессора в локальной сети предприятия или на базе Pentium II, сидя дома на диване, в режиме удаленного доступа к корпоративной сети.
Производительность. Система должна быть шустрой, устойчивой и нетребовательной к ресурсам. Даже в условиях многоступенчатой интерпретации (лучше от нее вообще избавиться) пользователи не должны нервничать, ожидая ответа системы.
Длительные процедуры должны выполняться без остановки работы пользователя и/или в свободное от основной работы время.
Желательно, чтобы параметры клиентского “железа” не отражались на производительности рабочего места.
Доступность. ИС должна уметь быть активной круглосуточно и не привязывать пользователя к точке пространства, где он может работать.
Замена модулей (версий) должна производиться без остановки работы пользователей - когда много пользователей, найти время для такой остановки очень непросто.
Активность. Часть работ должна выполняться автоматически по наступлении каких-либо событий, а обработка данных - без участия операторов.
Некоторые события должны находить пользователя (получателя) там, где он находится, т. е. нужна технология не только “клиент - сервер”, но и “сервер - клиент”, и, может быть, даже в довесок к ним “клиент - клиент”. И не только по электронной почте.
Открытость. Серьезная система составляет сотни и даже миллионы строк исходных текстов. Не существует программ без ошибок и полностью удовлетворяющих конечного пользователя, поэтому необходима возможность исправления (переделки) модулей. Развитие ИС на пользовательском уровне должно производиться теми же средствами, которые были у разработчика.
Нужно, чтобы ИС комплектовалась частично из “исходников” (права потребителей) и частично из “бинарников” (авторские права), при этом не должно быть сложностей с конечной сборкой такой системы, даже если модули взяты от разных производителей.
Масштабируемость в разные стороны. Это не только “железо”, ОС, СУБД, но и квалификация пользователей (и “чайники”, и программисты самой высокой квалификации должны получать соответствующие “удовольствия”), юридические отношения с разработчиком (возможность получения исходных текстов), структуры хранилища данных (от простейших типов до M:M, разветвленные деревья, “массив-в-массиве”, объекты) и многое другое.
По каждому из перечисленных выше требований можно написать приличную статью, но раз уж затронута проблема “открытости”, рассмотрим “многоуровневую интерпретацию” более подробно. Автор статьи “По лезвию бритвы” утверждает, что “в руки непрофессионалов можно дать только интерпретатор” и “что такое компилированный код, он не поймет”. И в то же время, “когда нужно ввести в язык новые возможности, очень велик соблазн написать их на "бух-бейсике"”.
Категорически не согласен.
- Непрофессионал не сможет наращивать язык, а если уж смог - значит, это профессионал, да еще и не слабый, а такому не жалко дать в руки настоящий инструмент, а не обрубок.
- “Можно дать только интерпретатор” - это ограничение не разработчика, а средства разработки. Дело в том, что такое утверждение верно только тогда, когда прикладная программа (ПП) не позволяет расширять ее возможности теми же средствами, которыми создавалась сама ПП. Внимание: речь идет об отдельно взятой ПП, а не о системе целиком. Систему можно наращивать, создавая новые ПП, но при этом интерпретатору будут доступны только возможности, имеющиеся в составе данной ПП.
Происходит это потому, что средство разработки не позволяет создавать программы с динамической подгрузкой нужных модулей (библиотек) во время работы ПП (разговор не об оверлеях). В открытой системе ПП должна уметь подгружать дополнительные модули и делать функции (описанные в модуле) доступными для интерпретатора. С такими возможностями ПП может наращиваться до бесконечности (точнее, пока не использует все ресурсы ЭВМ).
Производительность таких ПП будет несколько меньше (в зависимости от реализации), чем “обычных”, зато “бритва” сразу станет “хайвеем”.
Но для того чтобы навсегда избавиться от “многоуровневой интерпретации”, таких способностей маловато, необходимо еще, чтобы ПП имела в своем составе компилятор исходного языка, а не только интерпретатор “бух-бейсика”.
Включить компилятор теоретически можно, если он компактный, нетребовательный к ресурсам и умеет генерировать модули, воспринимаемые ПП как исполняемый код.
Между прочим, тот же Clipper в принципе может быть доведен до свободно расширяемой системы (на базе его кодовых блоков), если упростить компилятор и включить его в ядро Clipper-машины. Небольшая недоделка, а сколько крови попортила.
На языке программистов такое решение будет означать следующее:
ПП должна строиться на основе виртуальной машины (ВМ) с достаточно простым требованием к ВМ: выполнять все, что пропустил компилятор, но не допускать аварийного завершения всей программы.
К тому же ВМ должна уметь:
- перехватывать опасные и ошибочные ситуации, возникающие во время выполнения виртуальных кодов;
- корректно управлять распределением ресурсов;
- распределять и собирать “мусор” в памяти;
- выполнять одновременно несколько модулей (псевдомногозадачность);
- пересылать между модулями события и данные;
- обрабатывать глобальные и системные события.
Требования к языку разработки ПП сформулировать несколько сложнее (сколько программистов, столько и мнений), но если взять за основу компактность, доступность и производительность компилятора, то получится:
- никаких типов, объектов и им подобных атрибутов языков;
- в то же время язык должен позволять обрабатывать сложные структуры разнотипных данных;
- простой синтаксис;
- легкая обучаемость пользователей, не имеющих специального образования;
- быстрое превращение исходных текстов в исполняемый код, невзирая на размер всей системы и количество используемых библиотек (модулей);
- процедуры на бух-бейсике должны легко транслироваться в компилируемый язык виртуальной машины и использоваться только после компиляции.
В рамках одной ВМ возможны варианты нескольких языков, но все варианты компиляторов должны генерировать один и только один вариант кода для ВМ.
Попытаюсь предсказать недалекое будущее.
С появлением свободно расширяемых систем такие понятия, как “АРМ”,” контур”, “блок” и им подобные, исчезнут из компьютерного лексикона так же, как и “программно-аппаратный комплекс”, а понятие “модуль” приобретет совсем другое значение, чем то, которое оно имеет сейчас.
Буду рад узнать ваше мнение. Пишите мне по адресу: uri@itk.udmurtia.su.
