Мысли вслух

• Спам и закон торможения.
  Статья рассматривает причины возникновения спама и причины отсутствия решения этой проблемы.
• ТРИЗ умер. Даздравствует ТРИЗ!
  .... продолжение....
  Статья рассматривает проблемы и неточности ТРИЗ и дает возможные пути их решения.

  ---

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

• Правда и мифы о DBF и xBase
  Статья рассматривает и опровергает устоявщиеся взгляды на DBF и xBase.

  ---

• Нужен ли специальный язык для информ. систем
  Статья Юрия Хныкина с концептуальным взглядом на язык программирования для информационных систем

  ---

• Сравнение ОО-моделей нескольких популярных языков программирования
  Статья Павла Лазарева

  ---

• Вторая жизнь ПК и DOS-программ
  О работе DOS-приложений в связке Linux+dosemu

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

• Манифест информационых систем управления (ИСУ)
  Основные термины и определения, в науке построения ИСУ
• Переписка к Манифесту

  ---

• Реинжиниринг: не автоматизируйте - уничтожайте
  Классико-историческая статья М.Хаммера

  ---

• Что такое (ре)инжиниринг, и при чем тут бизнес
  Критика BPR
• Переписка к статье

  ---

• Кое-что о моде, бизнес-реинжиниринге и НОТе
  Статья М.Каменновой и А.Громова в "ОС" N3(17)/96

  ---

• Цепочки поставок и информационные системы,
  или История одного недоразумения
  Статья Н.Чувахина об азах SCM (Supply Chain Managament)

  ---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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