В статье рассматривается комплекс новых технологий, включающий в себя элементы, отображенные на рисунке 1.

Наиболее интересной среди них является технология задач, которая определяет характер доступа к базе данных (БД) предприятия для всех прочих информационных технологий.

Разработка любой информационной системы состоит из следующих этапов:

-        концептуальное проектирование,

-        разработка,

-        внедрение и сопровождение.

Различные источники по-разному оценивают трудовые и финансовые затраты по каждому этапу и сходятся в одном: первый этап самый важный, а прочие этапы наиболее трудоемкие.

Трудоемкость определяется следующими обстоятельствами.

При программировании локального АРМ приходится каждый раз организовывать доступ к одним и тем же БД и, значит, разрабатывать похожие процедуры доступа к данным.

Данная проблема решается при помощи репозитория приложений доступа к БД и методов обработки, реализованных в крупных СУБД типа SQL Windows, Oracle, Informix. При этом данный метод является "программистским" приемом работы, не прост в использовании, не отменяет необходимость работы непосредственно с БД.

Модификация структуры БД может повлечь серьезные изменения программного обеспечения, выявить которые во многочисленных АРМах - не простая задача.

Предлагаемый подход к разработке и реализации АРМ для работы с БД масштаба предприятия может быть проиллюстрирован рисунком 3.

В основе нового подхода разработки приложений лежит понятие "Задача", близкое к понятию "Объект" в технологии объектно-ориентированного программирования, которое полностью инкапсулирует работу ,с некоторой совокупностью БД. Предполагается, что к БД запрещено обращаться иначе, чем через задачу, которая содержит все необходимые средства для работы с инкапсулированной БД.

Обратите внимание на то, что задачи могут быть составивши, то есть включать в себя другие задачи, например: задача 4 включает в себя задачи 2 и 3, между тем как АРМ1 напрямую включает в себя задачу 2 (а не через задачу 4).

Другой особенностью данной технологии является тот факт, что сами АРМ - это те же задачи, которые могут быть включены в задачи более высокого уровня, например: АРМ1 включен в АРМ2 аналогично задачам 1 и 4.

Все задачи оформляются в виде визуальных . объектов и хранятся в репозитории - библиотеке визуальных объектов.

Очевидно, что подобный подход меняет всю технологическую цепь разработки информационных систем, начиная со стадии концептуального проектирования. Раньше после этапа определения основных и ключевых реквизитов главной проблемой было определение взаимосвязей между отдельными таблицами и различными БД. Теперь главными моментами этапа проектирования становятся:

- распределение таблиц и БД по задачам;

- определение методов доступа, обработки и выборки из инкапсулированных БД;

- определение связей между задачами.Технология задач не решает всех проблем,

возникающих в процессе реструктуризации БД, и методов обработки в процессе разработки и внедрения, например: замена типа поля БД с числового на символьное повлечет за собой изменение переменных, констант и соответствующих им способов обработки в пользовательских приложениях, так как не решают этого прочие технологии. Между тем следует отметить, что большая часть случаев реструктуризации приходится на:

-  введение дополнительных полей в обрабатываемые таблицы,

-  включение в состав БД дополнительных таблиц,

-  изменения в составе и количестве индексных файлов,

-  изменение существующих методов обработки,

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

Таким образом, технология задач является основой реализационной части информационной системы предприятия и интегрирует следующие возможности:

-  инкапсуляцию в себе части БД информационной системы предприятия и методов работы с нею;

-  обеспечение методов логического увязывания БД, инкапсулированных в задачах, в составную БД;

-  возможность быстрой модификации задач в соответствии с изменениями потребностей пользователей;

-  визуальный метод программирования по RAD-технологии.

Очевидно, что объект "Задача" должен содержать весь необходимый инструмент и структуры данных для использования в приложениях пользователя и для взаимоувязывания БД различных задач. В решении этой проблемы немаловажным обстоятельством является выбор языка программирования, который должен:

à        быть объектно-ориентированным;

à        поддерживать парадигму визуального программирования (4GL);

à        содержать определенный набор возможностей и перечень необходимых объектов;

à        иметь все необходимые средства для создания новых объектов (в том числе визуальных) и их потомков;

à        поддерживать возможность групповой разработки задач и приложений;

à        поддерживать современные концепции обработки данных (распределенные БД, клиент-серверные технологии, OLE-технологию);

à        иметь доступ к SQL-серверам и БД других СУБД;

à        быть достаточно универсальным, так как разработка информационной системы масштаба предприятия не ограничивается задачами работы с БД, а может содержать задачи по делопроизводству, планированию, оптимизации и пр.;

à        иметь по возможности минимальные требования к аппаратному обеспечению (потребность в оперативной памяти, дисковом пространстве) и обладать при этом достаточно высоким быстродействием в работе;

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

à        иметь полную документацию (желательно на русском языке).

После анализа доступного программного обеспечения может быть выбрана система "Delphi" фирмы BORLAND, которая примерно на 80% удовлетворяет указанному перечню условий.

Кратко опишем прочие технологии, входящие в состав предлагаемого комплекса.

Технология предописания

Содержит описание всей файловой информационной системы предприятия и является ее фундаментом. В нее входит:

-  описание полей БД как объектов;

-  поддержка синонимов имен полей и "джокеров" в составе имен БД и таблиц;

-  состав таблиц БД;

- состав и перечень индексных файлов;-перечни таблиц, входящих в составные

БД;

-реализация функций паролирования в рамках уровня доступа пользователей;

-информация, необходимая для формирования складов информации и для работы по технологии дополнительных параметров.

Основные функции, возлагаемые на данную технологию, следующие:

- создание и увязывание между собой БД втерминах уже существующих объектов,

-предоставление системному администратору средств визуального и логического контроля за БД предприятия,

-поддержание целостности БД предприятия,

- предоставление необходимой информации задачам, находящимся в режиме выполнения (run-time).

Технология дополнительных параметров

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

Материальный учет: каждый материал/ комплектующее, кроме стандартных (номенклатурный номер, единица измерения, количество, цена, сумма), обладает дополнительными характеристиками. Если комплектующим является компьютер, то это - тип процессора, быстродействие, величина оперативной памяти и дискового пространства, тип монитора, срок гарантии; а если краска, то это - цвет, тип краски, срок годности.

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

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

Не известен ни один удовлетворительный способ работы с дополнительными параметрами (при использовании реляционной модели БД). Предлагаемая технология дополнительных параметров помогает решить большую часть проблем.

Генератор отчетов

Очевидно, что все существующие генераторы отчетов ориентированы на реально существующие БД, а не на задачи. Для поддержания целостности системы необходим генератор отчетов, который в качестве входных данных использует БД предописания, а в качестве источников данных задачи.

Генератор первичных документов

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

Технология складов информации и технология запросов

Отдельные БД, объединенные между собой, невозможно назвать БД предприятия до тех пор, пока не будут задаваться запросы к этой БД как к единому целому. Предполагается, что количество отдельных таблиц велико, а точное местонахождение необходимой информации неизвестно или не может быть указано в принципе.

В настоящий момент технология складов информации (Data where house) развивается, как и все прочие технологии, быстрыми темпами, но, по нашему мнению, не в том направлении. Ставка на создание "физических" хранилищ (что требует очень значительных финансовых и трудовых затрат) не может быть рекомендована в информационных системах масштаба предприятия из-за ее узкой направленности. В то время как существующие склады ориентированы на создание архивов обработанной и использованной информации (причем данная информация больше не может быть изменена), интерес предприятий сосредоточен в большей степени на получение оперативной информации, где возможность модификации информации является естественным состоянием БД. А потребность в получении справок на основе информации прошлых периодов может быть удовлетворена более простыми методами. Следует отметить, что по результатам обследования российских предприятий (более 30) потребность повторного использования отработанной информации крайне низка и составляет менее 1% от общего объема информационных запросов.

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

Стандарты информационной системы

В любом коллективе разработчиков существует собственный взгляд на порядок работы и на то, как следует оформлять программные модули и приложения. Если такой взгляд не выработан, то это привносит серьезные трудности в модификацию программного обеспечения, изготовленного различными разработчиками внутри группы. Кроме того, сам процесс разработки от стадии концептуального проектирования до логически завершенного приложения требует определенной стандартизации, гарантирующей его увязки с другими параллельно разрабатываемыми приложениями. Речь не идет об использовании CASE-технологий, необходимость использования которых в каждом случае определяется индивидуально в зависимости от цены проекта и его сложности, а о правилах, выработанных (и продолжающих вырабатываться по мере накопления опыта) в процессе создания систем, ориентированных на задачи.

В настоящее время все предлагаемые информационные технологии прошли этап опытной проверки и находятся в стадии внедрения в производственные системы масштаба предприятия.