разработка информационных систем
Banner  
О нас О нас
Наши продукты Наши продукты
Clip CLIP
R2D2 R2D2
Статьи Статьи
Контакты Контакты
Карта
English English

Мысли вслух

Статьи о программировании


Статьи об управлении, бухгалтерском и управленческом учете, принципах и подходах в создании информационных систем управления (ИСУ).

Нужен ли специальный язык для информационных систем ?


Часть проблем,связанных с реализацией ИС описана в статье "По лезвию бритвы" в PCWEEK/ RE N 5, и в частности взаимосвязанные проблемы "многоуровневая интерпретация" и "хождение по лезвию бритвы". Еще более частомуссируется в прессе проблема "делать самому или купить на стороне ". Несколько реже - "много АРМ или одна большая программа ". И не кажется ли вам что все это (и многое другое) определяется степенью открытости ИС? (Гром аплодисментов, летящие тухлые яйца, возгласы "где взять ?", "покажите пальцем"). Так что же такое "открытая ИС" и как ее создать? Попробую объяснить как смогу и попутно попытаюсь сформулировать некоторые ключевые требования к открытой ИС. Рассматривать "открытость" в отрыве от всего остального достаточно сложно (получится та же JAVA, которая кроме открытости и переносимости больше ничего хорошего не дает), придется затронуть и другие проблемы ИС, но основной "разбор полетов" хотелось бы сделать именно про "открытость".

Основные факторы влияющие на открытость системы:

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

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

Но какие бы не были гении, создававшие ИС, они все-таки используют какие-то иструменты в своей работе. И достоинства/недостатки этого инструментария так или иначе перейдут в готовую программу, при этом перемножившись на интелект разработчиков. В идеале - все достоинства инструментария перейдут в ИС, а недостатки частично устранены или сглажены. Так что степень открытости ИС полностью будет соответсвовать открытости средств реализации.

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

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

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

Пример 1. Допустим есть реестр каких-то документов, одному хочется рассматривать его колонки в порядке "дата,сумма,счет,...", а другому "сумма,кому,за_что,...", а третьему и то и другое поочереди.
Пример 2. Реквизиты одного документа удобнее вводить в порядке "сумма,кол-во, чего,..", другого - "номер, дата, сумма,..", а у третьего вообще диалог на одном экране не умещается.
Пример 3. У одного пользователя монитор 4000*4000, а у другого пейджер 9*12, а у третьего вообще WEBсмотрелка или еще приятнее - факс.
Пример 4. Один и тот же пользователь может использовать 286-машину в локальной сети предприятия или PII сидя дома на диване в режиме удаленного доступа к корпоративной сети.

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

Доступность. ИС должна уметь быть активной круглосуточно и не должна привязывать пользователя к точке пространства, откуда он может поработать. Замена модулей/версий должна производится без остановки работы пользователей - когда много пользователей найти время для остановки работы всей системы бывает очень непросто.

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

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

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

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

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

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

  • перехватывать опасные и ошибочные ситуации, возникающие во время выполнения виртуальных кодов
  • корректно управлять распределением ресурсов
  • распределять и собирать "мусор" в памяти
  • выполнять одновременно несколько модулей (псевдомногозадачность)
  • пересылать между модулями события и данные
  • обрабатывать глобальные и системные события
Требования к языку разработки ПП сформулировать несколько сложнее (сколько программистов столько и мнений), но если взять за основу компактность, доступность, и производительность компилятора, то получится:
  • никаких типов, объектов и им подобных атрибутов языков;
  • в тоже время язык должен позволять обрабатывать сложные структуры разнотипных данных;
  • простой синтаксис;
  • легкая обучаемость пользователей без специального образования;
  • быстрое превращение исходных текстов в исполняемый код, невзирая на размер всей системы и количества используемых библиотек/модулей процедуры на бух-бейсике должны легко транслироваться в компилируемый язык виртуальной машины и использо- ваться только после компиляции В рамках одной ВМ возможны варианты нескольких языков, но все варианты компиляторов должны генерировать один и только один вариант кода для ВМ. Попытаюсь предсказать недалекое будующее: с появлением свободнорасширяемых систем такие понятия как "АРМ","контур", "блок" и им подобные изчезнут из компьютерного лексикона так же как и "програмноаппаратный комплекс", а понятие "модуль" изменит свое значение на совсем не то, которое оно имеет сейчас.
    © Ю.Хныкин uri at itk dot ru , 1998
  • © ООО "Инженерно-Техническая Компания" (ИТК) 2006
    426072, Удмуртская республика, Ижевск а/я 1247, uri at itk dot ru