ТРЕУГОЛЬНЫЙ СТОЛ

Наталья Никитина, Юлия Гараева, Юрий Юдкин

Продолжение. Начало см. PC Week/RE, №/2002, с. 29; №/2002, с. 30; №, с. 28, №-17, с. 48.

Методы и средства моделирования. Базовые модели предметной области

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

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

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

Авторы имеют в виду концептуальную схему (далее КС) потоков, обычно называемую “потоковой моделью”. В ее основе лежат накопители (резервуары) и направленное движение носителей потока (частиц, ресурсов) между ними в пространстве и времени, которое будем называть актами переноса носителей потока. Каждый накопитель характеризуется емкостью, т. е. максимальным количеством носителей потока, которое может находиться в нем одновременно, и уровнем носителей потока в нем в некоторый момент времени, задающим его состояние. Любой носитель потока всегда находится в одном из накопителей. Мощность потока определяется количеством актов переноса во времени.

В практике бухучета КС потоков интерпретируется “бухгалтерскими самолетиками”. Суть “модели бухгалтерского самолетика” заключается в перемещении денежных средств между счетами. Графически она изображается так:

Впоследствии КС потоков была проинтерпретирована в других предметных областях, таких, как логистика, торговля, документооборот и т. д.

Проинтерпретируем эту КС на финансово-хозяйственную деятельность организации в целом. В организации имеются “накопители” различных ресурсов, между которыми происходит перемещение ресурсов. В роли накопителей выступают склады, кассы, расчетные счета, сотрудники с финансовыми средствами на руках, архивы документов, бухгалтерские и аналитические счета. В роли носителей потока (ресурсов) - товарно-материальные ценности (ТМЦ), финансы, люди и информация. Актами переноса являются так называемые “транзакции”, перевозки ТМЦ, перечисление денег, передача документов, бухгалтерские проводки и т. д.

Анализ моделей различных программных продуктов осложняется тем, что в них для обозначения атрибутов потоковой КС используются разные термины, в то время как описание моделей в большинстве случаев отсутствует. Давайте попробуем разобраться, что есть что.

В “1С:Предприятии” накопители - это “учетные регистры (планы счетов)”, в “Эталоне” это базовые классы - балансовый счет, забалансовый счет и др. В “ТБ.Корпорации” роль накопителей играют так называемые наборы ресурсов, причем любой ресурс в каждый момент хранится в одном из наборов ресурсов.

Эффективность использования потоковой КС в конкретной информационной системе зависит от того, насколько правильно и полно она реализована. Поэтому пользователям следует обращать внимание на “тонкие места” в ее реализации.

Одним из таких “тонких мест”, к которым следует тщательно подходить при выборе системы, является то, как устроены накопители. С математической точки зрения они могут быть скаляром (однорегистровым), вектором (многорегистровым, например, в “1С:Предприятии” и “Алефе” учетные регистры представляют собой многомерные массивы данных) или тензором. И наиболее выразительным является тензорный накопитель, так как он позволяет удобно организовать учет для многоуровневых складов, филиалов, аналитических и бухгалтерских субсчетов и т. д.

Еще несколько важных моментов:

- какова допустимая мощность потоков (например, максимальное количество проводок в единицу времени при введении и чтении);

- выполняются ли расходная и приходная операции при акте переноса одновременно (производит ли система “откат” к предыдущему состоянию при срыве в выполнении одной из операций);

- можно ли в системе ввести емкости для определенных накопителей, т. е. ограничение сверху на уровень в накопителях (например, транспортный контейнер переполнен);

- выполняет ли система автоматическую проверку действий по недопустимому снижению уровней в накопителях ниже нуля или ниже допустимого резерва (актуально для материалов на складе).

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

С актами переноса носителей потока из накопителя в накопитель также наблюдается многоликость терминов: в одних системах они называются проводками - “1С:Предприятие”, “Алеф”, Axapta (иногда разделяют бухгалтерские и складские проводки), в других - бизнес-процессами (“ТБ.Корпорация”), в третьих - транзакциями, в четвертых - операциями и т. д.

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

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

- выполняются ли взаимосвязанные акты переноса целостно (производит ли система автоматическое создание или планирование нужных актов переноса и “откат” при срыве в выполнении одного из актов переноса по всем модулям)?

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

- как реализован перенос из одного накопителя одновременно в несколько других?

- как реализована “вариантность разветвлений”, когда в одном случае хозяйственная операция реализуется по одной ветке цепочек, а в другом - по другой?

- как отличить начало и конец цепочек? и др.

Еще один вопрос - есть ли в выбираемой системе “обратный отсчет” по цепочкам актов переноса и как он реализован? - тесно связан с возможностью соответствия системы стандартам MRP, MRP II. Взаимоувязанное планирование потребности в материалах и комплектующих, а тем более во всех ресурсах (материальных, финансовых, кадровых, информационных) исходя из ограничений, рыночного спроса и оптимальной загрузки производственных мощностей означает, что система должна сквозным образом рассчитывать акты переноса в обратном порядке по всем цепочкам для каждого вида ресурсов, начиная с накопителей, выступающих в роли ограничений (например, потребности покупателей и мощность парка транспортной техники).

Кроме вышесказанного, потоковая КС может иметь множество дополнительных атрибутов - время начала акта переноса, время завершения и др. Например, при добавлении в эту схему субъектов хозяйственной деятельности на основании экономических ролей и ответственности их делают “хозяевами” актов переноса. При выборе системы необходимо также выяснить, можно ли выстроить эти субъекты в иерархию (структуру юридических лиц в холдингах, оргструктуры в организациях и т. д.), какие роли или должности субъектов предусмотрены в системе (контролер, как в ТБ, исполнитель, ответственный, участник и т. д.), сколько субъектов может быть у одного акта переноса, можно ли указать в качестве субъекта конкретное лицо и другие вопросы.

Еще одно “тонкое место” в моделях, заложенных в системах-конструкторах: как и для каких атрибутов КС потоков реализована множественность иерархических деревьев. Для накопителей это может означать допустимое количество планов счетов в организации, для ТМЦ - вариантность конструкционного состава (для возможной замены одной детали на другую), для субъектов - допустимость неоднократного подчинения (например, по разным аспектам деятельности, что актуально для проектного управления).

Многообразие моделей, представленных в системах-конструкторах, конечно, не ограничивается рассмотренными выше и часто выходит за пределы класса моделей для описания финансово-хозяйственной деятельности - например, модели для технологических задач с использованием векторной графики (система-транформер “TOPAZ GRAPHICS”), но каждая модель требует пристального взгляда потребителя.

Методы и средства моделирования. Визуальные средства моделирования.

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

Представленные системы-конструкторы обладают различными средами визуального проектирования и, как следствие, обеспечивают пользователям разные преимущества.

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

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

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

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

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

- Разработка поведения и алгоритмов работы системы в различных ситуациях (алгоритмы взаимосвязи объектов, настройка связей между таблицами данных, бизнес-логика).

- Построение запросов (методов обработки данных).

Разработка (настройка) внешнего вида форм ввода информации (интерфейс ввода).

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

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

- Конструирование печатных документов и отчетов произвольной структуры (или заранее заданных типов структур), оформление печатных форм документов и отчетов с использованием различных шрифтов, рамок, цветов, рисунков, разработка алгоритмов печати.

- Настройка констант (параметрическая настройка).

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

Возможности визуального проектирования рассматриваемых систем

Большая часть конструкторов (“1С: Предприятие”, “Тектон”, “Алеф”, Navision Axapta, а возможно, и другие) включает визуальные средства для первых трех пунктов описанной типологии, а именно для задания структуры базы данных. Обычно это модифицированная Entity-Relationship модель, позволяющая задавать структурную взаимосвязь данных (сущностей).

При конфигурировании системы “1С:Предприятие” все основные действия по описанию документов, справочников, планов счетов и определению их свойств выполняются визуальными средствами. Конфигуратор позволяет для различных категорий пользователей визуально создавать индивидуальные интерфейсы, включающие пункты меню, панели инструментов, функциональные клавиши. Для проектирования форм ввода и просмотра информации используется редактор диалогов. Редактор табличных документов позволяет создавать печатные формы документов и отчетов с использованием оформительских возможностей - шрифтов, рамок, цветов, рисунков, встроенных объектов.

В системе “Эталон” структура проекта и все его элементы могут быть представлены в виде дерева классов с детализацией вплоть до поля таблицы. Кроме того, система визуализации проекта снабжена большим набором сервисных функций (навигация, поиск и т. п.). Система позволяет также осуществлять добавление (корректировку) форм ввода и отображение информации, добавление новых методов обработки данных. Проектирование в основном осуществляется визуальным способом, с использованием многооконного интерфейса.

В “Тектоне” планируется реализовать модель бизнес-процессов и импорт моделей из внешних CASE-систем в формате UML. Используется параметрическая настройка плана счетов, хозяйственных операций, начислений и удержаний для расчета зарплаты. Кроме того, графический интерфейс позволяет разрабатывать дизайн визуализируемых объектов - наборов данных, бизнес-объектов, форм, отчетов. Визуально конструируемые макросы образуют ТЕКТОН-Процедуры и используются как для реализации параметрических настроек, так и для взаимодействия между модулями.

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

В “ТБ.Корпорации” модуль “ТБ.Студия” содержит визуальный редактор экранных форм (визуальная разработка экранных форм, стиль электронной таблицы, связь экранной формы с базой данных, управление поведением формы на основе событий) и редактор структуры баз данных с возможностью описания на русском языке.

Среда разработки в Navision Axapta позволяет проектировать интерфейс и автоматически создавать обработчики событий. Поддержка Drag&Drop реализована везде, где это возможно. Кроме того, в систему встроены различные редакторы, позволяющие создавать новые виды (классы) объектов, задавать связи между ними, при удалении объектов определять действия на них самих, задавать значения констант, свойств и методов работы с объектами, прописывать алгоритмы, определять расширенные типы данных.

Что положишь, то и получишь

Завершая разговор о модельном уровне систем-конструкторов, хочется напомнить читателю, что модель всегда отражает более узкую часть реальности, чем моделируемый объект. Ее выразительные возможности по отношению к объекту ограничены точкой зрения “модельера”, задачей, которую он собирался решить с помощью модели, и средствами, которыми он ее задавал. По этому поводу в среде концептуалистов есть поговорка: “Что положишь, то и получишь”. Нельзя получить из модели больше, чем позволяют ее выразительные возможности.

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

(Окончание следует)