Проектирование архитектуры системы

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

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

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

Хранилища данных, используемые на уровне оперативного управления, подразделяются на две группы: отображающие «состояние» предприятия в фиксированные моменты времени и отображающие «движение» материальных, финансовых и управляющих потоков предприятия. «Состояние» предприятия отображают следующие хранилища: остатки хлебопродуктов (х/п), МТС, ОС, НМА в разрезе объектов учета, подразделений и материально-ответственных лиц; остатки финансовых средств на расчетных счетах и в кассе; показатели качества х/п при хранении. «Движение» (выполнение бизнес-процессов предприятия) отображают хранилища первичных документов системы: приказы на отпуск; накладные по движению х/п; показатели качества при движении х/п; банковские документы; кассовые ордера; накладные МТС, ОС, НМА; контракты; счета-фактуры.. Информационная структура хранилищ, отображающих «состояние» и «движение», должна обеспечивать количественный, качественный, суммовой (многовалютный), партионный учет по подразделениям, партиям (объектам учета), ценам, фондам (целевым назначениям партий), клиентам, контрактам.

На уровне бухгалтерского учета используются хранилища: бухгалтерские проводки и остатки на бухгалтерских счетах. Их структура должна обеспечивать подсистемам бухгалтерского учета моделирование суммового, количественного, партионного учета в разрезе счетов бухгалтерского учета, подразделений, партий, цен, клиентов, контрактов. Необходимо реализовать возможности: раздельного (по времени или по пользователям) формирования проводок с «двойной аналитикой» (по аналитике ДЕБЕТОВОГО или КРЕДИТОВОГО счета); одновременного формирования проводок по балансовым, забалансовым, управленческим и налоговым счетам; работы по российскому плану счетов и международным стандартам.

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

На основании анализа информационных потоков и схем документооборота многих зерноперерабатывающих предприятий разных регионов страны проведена классификация основных понятий предметной области, объектов учёта и управления, идентифицированы их параметры для зерноперерабатывающих предприятий. На основании проведённой классификации разработаны словарная подсистема и подсистема классификации типовой системы управления [101].

Словари – это справочные таблицы базы данных, описывающие базовые понятия предметной области системы, на которых основываются стандартные алгоритмы обработки данных и, следовательно, эти таблицы недоступны для модификации пользователями. Разработаны и поставляются заказчикам вместе с системой следующие словари: документов; типов базовых единиц измерения; типов клиентов; типов и видов сырья и продукции; видов комбикормов; типов фондов; типов адресов хранения; типов подразделений; рангов должностей сотрудников; типов операций; типов пунктов погрузки/разгрузки; типов транспорта; видов тары; видов оплаты; типов расчетов за доставку; видов помолов. Примеры словарей системы приведены в приложении 1.

Подсистема классификации описывает многомерное пространство состояний системы управления типового объекта. Фрагмент информационной модели (диаграмма «сущность-связь») подсистемы классификации представлен на рис. 3.4. Разработаны классификаторы следующих объектов учета и управления: клиентов (предприятий, сотрудников, частных лиц, регионов); подразделений (участков) предприятия; продукции (работ, услуг); партий (сырья, продукции, МТС, товаров, услуг, налогов и т.д.); фондов (целевых назначений партий); составных партий (рецептов, комплектов); единиц измерения; счетов бухгалтерского учета; транспортных средств; видов доставки; видов оплаты; типов цен. Разработаны следующие классификаторы параметров объектов учета, которые могут меняться во времени: банковских реквизитов; должностей сотрудников; пунктов погрузки/разгрузки; курсов валют; коэффициентов; цен по партиям; базисных кондиций (показателей качества) зерна; тарифов на перевозку грузов бортовыми автомобилями; тарифов на перевозку грузов самосвалами и тракторами. Построитель типовых операций (классификатор алгоритмов пользовательских бизнес-функций) осуществляет построение алгоритмов пользовательских бизнес-функций, их трансляцию, централизованное хранение и обслуживание в рамках системы.

На основании синтеза типовой модели потоков данных объекта и подсистемы классификации разработана универсальная информационная модель системы управления для объектов данного класса [101]. Она объединяет модели материальных, финансовых и управляющих потоков и состояний объекта, описывающих динамику и статику структурных элементов объекта автоматизации. Представить в работе полную информационную модель системы не представляется возможным из-за ее размерности. Фрагмент информационной модели (модель данных, основанная на ключах) подсистемы «Управление движением хлебопродуктов» приведен на рис. 3.5. Фрагмент информационной модели (модель данных, основанная на ключах) комплекса задач «Построитель типовых операций» представлен на рис. 3.6. Структуры нескольких таблиц БД («сущностей» информационной модели) системы в качестве примера приведены в приложении 2.

Проектирование интерфейса пользователя (диалога в системе «человек – ЭВМ») основывается на изучении деятельности пользователя. Задача проектировщика – определить концептуальный образ системы, соответствующий задачам и типу пользователей, затем сконструировать ее так, чтобы образ системы привел пользователя к воспроизведению такой модели, которая соответствует концептуальной модели системы у проектировщика. Организация диалогового режима предполагает шесть основных типов взаимодействия, включающих: режим форматированного ввода посредством заполнения форм, машинный запрос, выбор из меню, командные языки, формальные языки запросов и ограниченный, естественный язык. Первые три диалоговых режима управляются главным образом ЭВМ, в то время как три последних – пользователем. Сформулируем основные принципы проектирования диалога [96, 119, 120]: совместимость, согласованность, память, структура, обратная связь, рабочая нагрузка, индивидуализация.

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

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

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

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

Принцип обратной связи предусматривает обеспечение положительной обратной связи (реакции системы) в результате выполнения действий, инициируемых пользователем. Отсутствие реакции системы не является соответствующей обратной связью. Информационное сообщение от ЭВМ, связанное с реакцией на запрос пользователя, обнаружением ошибок в его действиях, пропуском им необходимых частей вводимых данных и изменениями состояния системы, вызванными его действиями, должно поступать к пользователю без существенных временных задержек. При возникновении задержек, превосходящих 15 сек., система должна освобождать пользователя от необходимости ожидания ее реакции с тем, чтобы он мог заниматься другими операциями. Желательно наличие сообщения, указывающего ожидаемое время обработки. Время реакции системы от 5 до 15 сек. слишком велико для диалогового режима, поскольку при этом от пользователя требуется сохранять информацию о задании в кратковременной памяти. Интервал, превосходящий 2 сек., может создавать трудности тем пользователям, которые работают с высокой концентрацией внимания. Реакция (выводимый на экран символ или звуковой сигнал) на нажатие клавиши должна быть почти немедленной, т.е. меньше, чем 2 сек.

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

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

В соответствии с перечисленными принципами разработан интерфейс системы управления для зерноперерабатывающих предприятий. Методы адаптации интерфейса к индивидуальным особенностям пользователей рассмотрены в 5 главе работы. Разработке методов автоматизации управления бизнес-процессами зерноперерабатывающих предприятий посвящена 4 глава. Вопросы проектирования средств обеспечения надежности системы рассмотрены в следующем разделе.

На основании разработанных модели потоков данных и информационной модели системы осуществляется синтез архитектуры ПО – агрегирование системы. При объединении отдельных функций управления в программные модули необходимо стремиться к высокой «прочности» и слабому «сцеплению» модулей. Прочность и сцепление модулей являются, соответственно, мерами их внутренних и внешних связей. В зависимости от назначения модулей необходимо стремиться либо к их функциональной прочности (объединению взаимосвязанных функций управления), либо к информационной прочности (объединению функций, выполняемых на ограниченном подмножестве информационного пространства системы). Структура программного обеспечения разработанной системы управления с указанием объемов исходных текстов модулей системы приведена в таблице 3.1. В таблице серым цветом выделены модули системы, спроектированные автором настоящего исследования. Вопросы проектирования программного обеспечения с использованием типовых программных компонентов рассмотрены в 5 главе работы.

Таблица 3.1.

Структура ПО АИС КХП и объемы исходных текстов модулей