Информационные потоки, их анализ, методика моделирования данных в логистике
И.
В. ХудояровБиблиографическое описание статьи для цитирования:
Худояров
И.
В.,
Швецова
Е.
В. Информационные потоки, их анализ, методика моделирования данных в логистике // Научно-методический электронный журнал «Концепт». –
2014. – Т. 20. – С.
3291–3295. – URL:
http://e-koncept.ru/2014/54922.htm.
Аннотация. Данная статья посвящена проблеме моделирования информационных потоков, их анализа, в ней также рассматривается методика моделирования данных в логистике. Актуальность выбранной проблемы обусловливается увеличением количества информационных потоков на предприятиях и потребностью в их моделировании и последующей оптимизации и автоматизации. Также в статье описана методика анализа информационных потоков предприятия и приведен пример ее использования.
Ключевые слова:
логистика, системный анализ, информационное обеспечение, информационная логистика, информационное моделирование, проектирование информационных потоков
Текст статьи
Худояров Илья Владимирович,студентСамарского государственного экономического университета, Самараfixorest@gmail.com
Швецова Елена Владиславовна,кандидат экономических наук, доцент Самарского государственного экономического университета, Самараshvetsova.e@mail.ru
Информационные потоки, их анализ, методика моделирования данных в логистике
Аннотация.Данная статья посвящена проблеме моделирования информационных потоков, их анализа,а также рассматриваетсяметодика моделирования данных в логистике.Актуальность выбранной проблемы обуславливается увеличением количества информационных потоков на предприятиях, и потребностью в их моделировании и последующей оптимизации и автоматизации. Так же в статье описана методика анализа информационных потоков предприятия и приведен пример ее использования.Ключевые слова:логистика, информационная логистика, системный анализ, информационное моделирование, проектирование информационных потоков, информационное обеспечение.
Задолго до того, как программисты приступят к разработке программного обеспечения, облик будущего программного изделия должен быть определен в схематическом виде. Это представление должно отражать структуру АИС, порядок ее взаимодействия с внешней средой и быть однозначно понятным как разработчикам, так и будущим пользователям. Такая формализованная модель оказывается чрезвычайно полезной на начальных стадиях создания АИС, когда разработчики должны четко уяснить сами и объяснить заказчику на понятном ему языке, что же будет представлять собой новая АИС как единая система.Для решения указанной задачи предусматривается разработка модели информационных потоков (МИП), выполняемую параллельно с определением требований к будущей системе. МИП позволяет разработчикам:
построить представление о том, как работает автоматизируемый объект;
найти взаимопонимание с будущими пользователями;
выявить требования к системе;
в дальнейшем определить структуру системы.Перечисленные требования отражают в комплекте проектных документов, получившем название "Модель информационных потоков" (МИП). Основу МИП составляют формализованные графические документы "Схемы информационных потоков" (СИП). Кроме того, в состав МИП входят текстовые и табличные документы, содержащие дополнительные сведения о внешних объектах, хранилищах данных, задачах и информационных потоках.СИП и сопутствующая документация служат моделью потоков информации между системой и внешним миром, а также потоков внутри системы независимо от их временной структуры.Основная цель моделирования информационных потоков состоит в том, чтобы получить достаточно наглядное средство взаимодействия между проектировщиком и заказчиком при определении требований к разрабатываемому ПИ и принятии общесистемных проектных решений.На схеме информационных потоков отображают:1) границы системы или рассматриваемой ее отдельной задачи;2) внешние объекты (ВО), обменивающиеся данными с системой;3) задачи, обрабатывающие информацию, порождающие потоки данных и обеспечивающие их поиск и хранение;4) потоки входной и выходной информации, пересекающие границы системы (задачи);5) потоки данных в пределах границ системы (задачи);6) хранилища данных (ХД).Методика применяется на следующих стадиях технологического процесса проектирования ПИ:1. Оценивание реализуемости.2. Предпроектное обследование.3. Выбор варианта автоматизации.4. Разработка технического задания.МИП составляется как для существующей системы, так и для разрабатываемого ПИ. При этом МИП будущего ПИ разрабатывают путем преобразования описания существующей системы (традиционной неавтоматизированной или применяемой автоматизированной). Это преобразование выполняют путем логического абстрагирования от деталей физической реализации, выражая при этом точку зрения пользователей.Одной из целей составления МИП разрабатываемого ПИ является также облегчение выявления автоматизируемых функций и задач.При этом методом анализа входных потоков данных выявляют события и элементарные задачи, связанные с созданием, корректировкой и уничтожением информационных объектов. В дальнейшем, при разработке проектного документа "История информационного объекта", могут быть выявлены некоторые другие события и, возможно, новые задачи, при помощи методики "Динамическое моделирование данных". В этомслучае МИП должна быть доработана, если в ней отсутствуют соответствующие входные данные для вновь выявленных событий и функций, а также задачи, использующие информацию, уже отраженную в МИП.Исходными документами для составления "МИП разрабатываемой системы" являются "Логическая МИП" (созданная на базе "МИП существующей системы"), "Каталог требований" и "Выбранный вариант концепции". Эту модель получают, преобразуя "Логическую МИП" в соответствии со структурой разрабатываемого ПИ, изложенной в описании выбранного варианта автоматизации.Кроме перечисленных документов, при моделировании информационных потоков может оказаться полезным "Каталог пользователей". В нем содержится перечень пользователей и автоматизируемых функций, к которым они будут иметь доступв новой системе. Этот проектный документ может послужить отправной точкой для определения некоторых внешних объектов, которые впоследствии показывают на "Схеме внешнего окружения", "Схеме документооборота", а поэтому и в "МИП существующей системы". Часть этой информации собирают неформально еще до разработки "Каталога пользователей". Завершая работу по составлению МИП, необходимо убедиться, что в "СИП разрабатываемой системы" присутствуют все внешние объекты, нашедшие отражение в "Каталоге пользователей".Конечным продуктом являются следующие документы: "Модель информационных потоков", "Справочник информационных объектов и хранилищ данных", "Каталог данных".В свою очередь полный комплект проектного документа "Модель информационных потоков" состоит из набора "Схем информационных потоков", "Схемы внешнего окружения", "Описаний функций", "Описаний внешних объектов" и "Описаний информационных интерфейсов"."Схемы информационных потоков" (СИП) должны быть построены так, чтобы с их помощью можно было достаточно наглядно представлять все задачи обработки данных и информационные связи между ними. С этой целью в совокупности схем соблюдается иерархия. СИП, занимающая самый верхний иерархический уровень, отражает представление пользователей о функциональной стороне системы в целом, в том числе, о ее интерфейсах, функциональных подсистемах и основных группах данных. СИП нижних уровней является детализацией задач вышестоящих уровней.Весь набор СИП разрабатывается по принципу нисходящего процесса. Эту декомпозицию заканчивают тогда, когда могут быть достаточно четко определены частные функциональные задачи ПИ. При этом составляется краткое описание задач и основные требования к ним. Более детальных подробностей от МИП не требуется, поскольку задачи более четко специфицируются на последующих этапах. Заказчики и будущие пользователи могут участвовать в разработке МИП, проверяя корректность и улучшая модель, поскольку для понимания схемы им не нужны специальные технические знания. Это способствует активизации роли пользователей, что несомненно важно при разработке ПИ.Таким образом, совокупность СИП содержит "Схему информационных потоков" первого уровня и схемы нижних уровней, которые образуют двухили трехуровневую иерархию.СИП должны быть достаточно подробны для визуального восприятия информационных потоков и уяснения функционирования системы, однако атомарные задачи обработки данных должны быть дополнены кратким изложением их сути в "Описаниях функций" (ОФ).Такие схемы образуют иерархию, отражающую представление пользователя о существующих процессах обработки данных и о требованиях к ним в новой системе. Простота обозначений и возможность раздельного представления облика всей системы и ее отдельных задач позволяют проектировщикам строить и обсуждать с заказчиками и будущими пользователями модель системы, не путаясь во множестве деталей.
Основные понятия рассмотрим на примере фрагмента МИП автоматизированной системы оперативного управления предприятием. На рис.1 изображена ее СИП первого уровня, а на рис.2 представлена СИП второго уровня, раскрывающая одну из задач первого уровня.Внешний объект (ВО) представляет собой находящийся вне системы источник и/или получатель данных. Это может быть пользователь ПИ, лицо или организация, находящиеся за пределами системы, или другая система. ВО обозначают овалом с указанным в нем содержательным именем, а для его идентификации используются строчные буквы латинского алфавита. Для того, чтобы избежать пересечений линий информационных потоков, затрудняющих чтение схемы, символ одного и того же ВО может присутствовать на СИП более чем один раз. Повторяющийся ВО отмечают косой линией в нижнем углу. При большом количестве ВО их идентификаторы могут состоять из двух букв алфавита: aa, ab и т.д. На схемах нижнего уровня внешние объекты можно декомпозировать. В этом случае идентификатор состоит из буквенного обозначения исходного ВО и числового суффикса (например, исходный ВО с именем a может быть разбит на a1, a2 и т.д.).Под задачей при системном анализе понимают автоматизированный или внемашинный процесс, для которого указывается назначение без детализации способа реализации конкретных функций. Задачи связаны со сбором, передачей, хранением, поиском, обработкой (преобразованием) информации в системе и представлением ее пользователям.Задачу обозначают в виде прямоугольника, внутри которого указывают:
уникальный идентификатор задачи;
содержательное наименование задачи (имя задачи);
ссылку на место (только в "Существующей СИП" для указания подразделения в организации, где решается данная задача).Каждой задаче на СИП первого уровня присваивают произвольный идентификатор, состоящий из десятичных цифр и прописных букв латинского алфавита. Он не служит указателем приоритета и последовательности выполнения задачи. Каждую задачу в пределах нижнего уровня СИП обозначают идентификатором вышестоящего уровня с добавлением еще одного символа, например, подзадачи внутри задачи 12 будут иметь идентификаторы 121, 122 и т.д.Содержательное наименование задачи это простое предложение без сказуемого. В качестве его подлежащего используют отглагольное имя существительное, выражающее действие или процесс обработки данных, например, "Оценка и подготовка предложения". Атомарную задачу, т.е. задачу, не подлежащую дальнейшей декомпозиции, на СИП помечают косой чертой и звездочкой в правом нижнем углу соответствующего прямоугольника.Хранилище данных (Datastore) логическая совокупность данных, обработка которых происходит после накопления. Не следует путать с хранилищем данных или информационным хранилищем Data Warehouse большой базой данных, предназначенной для решения аналитических задач.Хранилище данных (ХД) изображают в виде узкого прямоугольника без правой стороны. Если информационная система уже существует, то ХД представляет собой некоторый физический объект: компьютерный файл или неавтоматизированное средство хранения данных, например, картотеку. По завершении логической реструктуризации СИП хранилища данных становятся чисто логическими понятиями, без указания на их физическую природу. Каждому ХД на СИП верхнего уровня присваивают уникальный идентификатор, состоящий из буквы S и номера.
Рисунок 1 Примерная схема информационных потоков предприятия.
Рисунок 2Примерная схема информационных потоков предприятия на примере отдела бухгалтерии.
На СИП нижних иерархических уровней показывают только те ХД, к которым имеют доступ задачи, полученные путем декомпозиции задачи вышестоящего уровня. Этим ХД присваивают идентификаторы, содержащие в качестве элемента номер вышестоящей задачи. Например, имяS2/1 относится к ХД, используемому в задаче 2 и изображаемому только на той СИП, которая описывает эту задачу. Идентификатор S24/1 относится к ХД, встречающемуся в задаче 24 вышестоящего уровня и т.д. Хранилищам данных, полученным в результате декомпозиции ХД вышестоящего уровня, присваивают имена, состоящие из имени ХД вышестоящего уровня и буквенного суффикса. Во избежание переусложнения СИП одинаковые ХД могут использоваться несколько раз. На схемах у таких ХД левую границу прямоугольника изображают двойной линией.Информационный поток изображают стрелкой, показывающей направление потока. Рядом с потоком указывается его наименование. В описании существующей системы в качестве таких наименований могут быть использованы названия реальных документов. Однакоследует иметь в виду, что наименование потока должно отражать не столько названия передаваемых документов, сколько их содержание (например, вместо названия "Форма N5" лучше указать "Сведения о регистрации пользователя"). Это облегчает пользователям понимание формализованной модели. Обычно желательно указывать наименования всех потоков, однако если это перегружает схему, допускается делать исключения. Считается, что содержание входных и выходных потоков данных некоторого хранилища, если не указаны их наименования, соответствует наименованию этого хранилища. Но, даже если содержательный смысл данных очевиден, и поэтому нет необходимости комментировать поток, лучше ввести ненужное наименование, чем оставить место для сомнений.На СИП первого уровня следует изображать только наиболее важные потоки данных. Более детальные данные могут быть представлены на нижних уровнях.Двунаправленный поток может быть использован на СИП верхнего уровня, чтобы подчеркнуть наличие как входящих, так и выходящих потоков на нижних уровнях. Использование двунаправленных потоков допускается на всех уровнях СИП (т.е. когда потоки, возможно, представляют собой совокупность элементарных потоков), за исключением самого нижнего. На самом нижнем уровне все потоки должны быть только однонаправленными. СИП всех уровней должны быть согласованы между собой. Любой поток нижнего уровня должен быть представлен на верхнем уровне одноили двунаправленным потоком. Таким образом, любой информационный поток может состоять из нескольких потоков данных нижестоящего уровня СИП.Информационные потоки, существующие между внешними объектами, если необходимо их показать для лучшего понимания процесса функционирования системы, обозначают штриховой линией.Для изображения движения материальных объектов (например,товаров) используют два вспомогательных символа. Материальный поток, т.е. перемещение объектов от одного места к другому, подобно тому, как это имеет место на промышленном производстве, обозначают широкой стрелкой. Замкнутым удлиненным прямоугольником обозначают хранилище материальных объектов.При разработке СИП следует придерживаться ряда синтаксических правил. Каждая задача и каждое хранилище должны иметь хотя бы один входящий и хотя бы один исходящий поток. Не допускается соединять внешние объекты с хранилищами данных и материальных объектов ни информационными, ни материальными потоками. ВО между собой могут соединяться только внешними потоками данных и материальными потоками. Задачи с хранилищами материальных объектов могут соединяться только материальным потоком. Ни информационные, ни материальные потоки никогда не должны соединяться.Иерархия СИП должна быть достаточно простой и понятной, поскольку такие схемы являются средством общения между разработчиком и заказчиком. Их чрезмерная детализация препятствует взаимопониманию. В то же время, единственной СИП редко бывает достаточно для того, чтобы отразить все подробности системы. Поэтому составляют несколько СИП, образующих иерархию. Верхний уровень иерархии называется СИП первого уровня. Эту схему используют для определения облика системы в целом. На ней изображают внешние источники и получатели информации, основные входы и выходы системы, ее функциональные подсистемы, а при необходимости и границу, отделяющую систему от внешних объектов.Представления пользователей об основных функциональных подсистемах на СИП первого уровня изображают в виде прямоугольниковзадач. Каждая из задач может быть разбита на подзадачи, которые изображают на СИП нижестоящего уровня. Такой прямоугольник можно считать "окном",через которое видна соответствующая схема нижестоящего уровня иерархии, содержащая более подробное представление о соответствующей задаче.Если необходимо, прямоугольникизадачи второго уровня можно разбить на задачи третьего уровня. Рекомендуется использовать не более трех уровней, так как их обычно бывает достаточно для представления функциональной стороны автоматизированной системы. На СИП самого нижнего уровня все задачи должны быть атомарными. В то же время, некоторые задачи на СИП вышестоящих уровнеймогут быть на столько просты, что для их описания не требуется СИП нижестоящего уровня. Поэтому атомарные задачи могут присутствовать на СИП любого уровня.Общее число задач на каждой СИП не должно быть слишком мало, чтобы схема не становилась тривиальной, и не должно превышать некоторого предела сложности, выше которого схема становится трудно воспринимаемой заказчиками. Оптимальным является 5 9 задач на одной схеме.На каждом иерархическом уровне проектировщик должен стремиться к представлению примерноодинакового количества информации на СИП. Предполагается, что при разработке "Технического задания" каждая задача уровня 1 порождает СИП второго уровня. Некоторые задачи вообще не нуждаются в декомпозиции. Примерами таких задач могут быть вспомогательные общесистемные функции, для документирования которых обычно достаточно сведений, приводимых в проектном документе "Описание функций". Может случиться так, что на текущем иерархическом уровне СИП для представления некоторых задач потребуется несколько нижестоящих уровней, а остальные задачи не нуждаются в декомпозиции. В этом случае рекомендуется изучить возможность реструктуризации СИП путем расчленения наиболее сложных задач и объединения сравнительно простых. Не следует стремиться к построению "идеальной" модели, требуется лишь правильно зафиксировать представление заказчика о существующей информационной системе.Прямоугольникузадаче на нижестоящем уровне ставят в соответствие границу фрагмента СИП, на котором изображают более детальное представление этой задачи. Информационные потоки, с помощью которых задача связана с другими элементами на СИП вышестоящего уровня, при более детальном представлении должны пересекать границу данной задачи и соединяться с входящими в нее подзадачами. Хранилища данных, используемые только в рассматриваемой задаче, размещают в пределах ее границ. Если хранилище данных используется несколькими задачами, то его помещают вне границ СИП нижнего уровня. Внешние объекты также изображают за пределами границ рассматриваемой задачи. Следует помнить, что декомпозиция задачи это добавление сведений о ней без потери ее связей с другими задачами, хранилищами данных и внешними объектами в их первоначальном виде.При декомпозиции внешние объекты и хранилища данных могут быть разбиты на компоненты на нижестоящем уровне. Это позволяет упростить СИП верхнего уровня и, в то же время, гарантировать непротиворечивость сведений, представленных на различных уровнях.Проектировщик должен проверить каждую СИП нижнего уровня на непротиворечивость и полноту. В частности, он должен проследить, чтобы каждая СИП верхнего уровня соответствовала нижестоящему уровню. Если обнаружены противоречия, то СИП верхнего уровня необходимо доработать. При этом следует иметь в виду, что при представлении задачи в более детальном виде на СИП нижнего уровня потоки данных, их источники и получатели для этой задачи должны быть одни и те же как на рассматриваемом, так и на вышестоящем уровнях. Вместе с тем, на нижестоящем уровне потоки данных, пересекающие границу системы, обычно показывают более подробно. Составной поток данных, исходящий из внешнего объекта и показанный на СИП верхнего уровня как один поток, на нижестоящем уровне может быть разложен на несколько потоков данных.Дополнительные проверки СИП на корректность сводятся к контролю за соблюдением следующих требований:
название каждой задачи в идеальном случае должно содержать активное отглагольное имя существительное; если задаче не удается дать четкое название, то, вероятно, ее смысл до конца не выяснен или же ее следует более четко отделить от других задач;
для каждой задачи должна ясно прослеживаться связь между входящими и выходящими потоками данных;
чем меньше на схеме потоков данных, соединяющих пары задач, тем лучшего разделения задач удалось добиться;
задачи не должны выполнять роль хранилищ или получателей данных; задача преобразует входной информационный поток в выходной, она может формировать некоторые новые элементы данных, например, суммы или средние значения, но никогда не использует данные без последующей передачи их другой задаче, хранилищу данных или внешнему объекту;
каждое хранилище данных должно иметь входящие и выходящие информационные потоки, иными словами, данные должны создаваться и использоваться; если задачи, создающие или использующие данные, тривиальны, то как исключение, на СИП первого уровня их можно не показывать.После этого СИП проверяют на полноту. Для этого прослеживают информационные потоки от входов системы через задачи к хранилищам данных и ее выходам. Обычно это делают визуально. В более сложных случаях для отдельных входов и выходов специально документируют маршруты информационных потоков. В дальнейшем эти документы используют для проверки СИП на полноту при неформальном обсуждении с заказчиками и будущими пользователями системы.Главная цель построения "Существующей СИП" точно отразить сложившуюся систему обработки информации в терминах потоков данных таким образом, чтобы можно было выявить и обсудить все ее недостатки, которые затем соответствующим образом отражают в "Каталоге требований". Параллельно с этим определяют дополнительные функции, которые должна выполнять новая система, и документируют требования к ним.Целью обсуждения "Существующей СИП" с заказчиками и пользователями является проверка того, насколько точно она отражает структуру существующей системы и ее функции. Если к единому мнению относительно облика системы, представленного на СИП, прийти не удается, то это обычно указывает на низкое качество "Заявки на разработку ПИ", о чем следует поставить в известность руководителя проекта. Как правило, в результате обсуждения могут быть обнаружены новые ошибки и несоответствия, для исправления которых потребуется повторная корректировка схем. При этом могут быть также выявлены некоторые недостатки существующей системы, которые следует отразить в виде соответствующих записей в "Каталоге требований".С целью устранения дублирования в "Существующей МИП" задач и хранилищ данных, а также для группирования атомарных подзадач в соответствии с функциональными подсистемами, отвечающими потребностям пользователей, после обсуждения с заказчиками разрабатывают "Логическую МИП" существующей системы. При этом реструктурируют хранилища данных и атомарные задачи и выполняют проверку "Логической СИП" на корректность. Обычно эти действияповторяют несколько раз до тех пор, пока не будет получена непротиворечивая и полная модель потоков данных."МИП разрабатываемой системы" составляют на основе "Логической МИП", которую уточняют с учетом "Выбранного варианта автоматизации" и содержания "Каталога требований". Она служит исходным проектным документом при определении функций системы, а также при контроле корректности "Логической модели данных". Кроме того, при определении функций МИП содержит исходные сведения для предварительного выявления множества событий, которыми сопровождается функционирование системы.Функциями системы называются процедуры обработки данных о событиях, связанных с ее основным назначением. Функции определяют на основе "СИП разрабатываемой системы" самого нижнего уровня посредством трассировки каждого входного потока данных от внешнего объекта к атомарным задачам, принимающим данный поток, и другим задачам, которые должны быть вызваны для его обработки и должны генерировать выходную информацию.Выходная информация функций может направляться как в те же внешние объекты, от которых поступили входные данные, так и в другие внешние объекты. В последнем случае это означает, что выходные потоки формируются не в режиме диалога. Если выходная информация возвращается к тому же внешнему объекту, от которого поступили входные данные, то это может быть, например, отображение информации для визуального контроля в реальном времени. При этом от проектировщика обычно не требуется моделировать процесс диалогового контроля ошибок.Разработчик документа "МИП разрабатываемой системы" должен специально заботиться о том, чтобы этот документ облегчал определение функций.В процессе определения функций события идентифицируют путем изучения описаний входных потоков данных, а также описаний тех элементарных задач, которые не инициируются данными, поступающими от внешних объектов. Некоторые другие события и, возможно, функции, которыми реагирует на них система, могут быть выявлены в ходе анализа истории существования информационных объектов. Если на "Существующей СИП" для некоторого события отсутствует инициируемая им задача или соответствующий входной поток данных, то это означает, что в МИП пропущены важные функциональные части, и поэтому ее следует доработать. Часто для исправления такой ошибки бывает достаточно добавить в "Описание информационного интерфейса" входного потока данных недостающие элементы, порождающие соответствующие события. Как бы то ни было, "МИП разрабатываемой системы" является приложением к "Техническому заданию", поэтому она должна быть приведена в соответствие с "Описаниями функций".Имеются два основных способа выявления сущностей, являющихся для системы входными воздействиями. Первый основан на анализе потоков данных, которые выявляют и изображают на СИП. Второй базируется на ваявлении событий, связанных с модификацией информационных объектов. Эту информацию документируют на схемах "Историй информационных объектов". Оба способа могут быть описаны в терминах элементов данных.Поток данных в общем случае несет в себе одно или связку из нескольких событий. Имея это в виду, проектировщик, перед которым стоит задача проверки правильности "МИП разрабатываемой системы", должен позаботиться об установлении логического соответствия между информационными потоками и всеми событиями.Таким образом, основной особенностью составления "МИП разрабатываемой системы" является учет специфики методики "Динамическое моделирование данных", которая нацелена на анализ влияния событий на состояние хранимых данных.Анализ событий при построении МИП позволяет получить формализованную модель, значительно более полно и строго описывающую требования к автоматизированной системе.
Khudoyarov Ilya VladimirovichStudent, Samara State Economical University, Samarafixorest@gmail.com
Shvetsova Elena VladislavovnaPhD, Associate Professor Samara State Economical University, Samara
shvetsova.e@mail.ruInformation flows, analysis, data modeling technique in logistics.This article is devoted to the modeling of information flows, their analysis, as well as the technique of data modeling in logistics. Relevance of the chosen problem is caused by an increase in the amount of information flow in the enterprises, and the need for their modeling and subsequent optimization and automation. Also the article describes the method of analysis of the information flows of the company and an example of its use.Logistics, information logistics, system analysis, information modeling, information flows, information provision.
Швецова Елена Владиславовна,кандидат экономических наук, доцент Самарского государственного экономического университета, Самараshvetsova.e@mail.ru
Информационные потоки, их анализ, методика моделирования данных в логистике
Аннотация.Данная статья посвящена проблеме моделирования информационных потоков, их анализа,а также рассматриваетсяметодика моделирования данных в логистике.Актуальность выбранной проблемы обуславливается увеличением количества информационных потоков на предприятиях, и потребностью в их моделировании и последующей оптимизации и автоматизации. Так же в статье описана методика анализа информационных потоков предприятия и приведен пример ее использования.Ключевые слова:логистика, информационная логистика, системный анализ, информационное моделирование, проектирование информационных потоков, информационное обеспечение.
Задолго до того, как программисты приступят к разработке программного обеспечения, облик будущего программного изделия должен быть определен в схематическом виде. Это представление должно отражать структуру АИС, порядок ее взаимодействия с внешней средой и быть однозначно понятным как разработчикам, так и будущим пользователям. Такая формализованная модель оказывается чрезвычайно полезной на начальных стадиях создания АИС, когда разработчики должны четко уяснить сами и объяснить заказчику на понятном ему языке, что же будет представлять собой новая АИС как единая система.Для решения указанной задачи предусматривается разработка модели информационных потоков (МИП), выполняемую параллельно с определением требований к будущей системе. МИП позволяет разработчикам:
построить представление о том, как работает автоматизируемый объект;
найти взаимопонимание с будущими пользователями;
выявить требования к системе;
в дальнейшем определить структуру системы.Перечисленные требования отражают в комплекте проектных документов, получившем название "Модель информационных потоков" (МИП). Основу МИП составляют формализованные графические документы "Схемы информационных потоков" (СИП). Кроме того, в состав МИП входят текстовые и табличные документы, содержащие дополнительные сведения о внешних объектах, хранилищах данных, задачах и информационных потоках.СИП и сопутствующая документация служат моделью потоков информации между системой и внешним миром, а также потоков внутри системы независимо от их временной структуры.Основная цель моделирования информационных потоков состоит в том, чтобы получить достаточно наглядное средство взаимодействия между проектировщиком и заказчиком при определении требований к разрабатываемому ПИ и принятии общесистемных проектных решений.На схеме информационных потоков отображают:1) границы системы или рассматриваемой ее отдельной задачи;2) внешние объекты (ВО), обменивающиеся данными с системой;3) задачи, обрабатывающие информацию, порождающие потоки данных и обеспечивающие их поиск и хранение;4) потоки входной и выходной информации, пересекающие границы системы (задачи);5) потоки данных в пределах границ системы (задачи);6) хранилища данных (ХД).Методика применяется на следующих стадиях технологического процесса проектирования ПИ:1. Оценивание реализуемости.2. Предпроектное обследование.3. Выбор варианта автоматизации.4. Разработка технического задания.МИП составляется как для существующей системы, так и для разрабатываемого ПИ. При этом МИП будущего ПИ разрабатывают путем преобразования описания существующей системы (традиционной неавтоматизированной или применяемой автоматизированной). Это преобразование выполняют путем логического абстрагирования от деталей физической реализации, выражая при этом точку зрения пользователей.Одной из целей составления МИП разрабатываемого ПИ является также облегчение выявления автоматизируемых функций и задач.При этом методом анализа входных потоков данных выявляют события и элементарные задачи, связанные с созданием, корректировкой и уничтожением информационных объектов. В дальнейшем, при разработке проектного документа "История информационного объекта", могут быть выявлены некоторые другие события и, возможно, новые задачи, при помощи методики "Динамическое моделирование данных". В этомслучае МИП должна быть доработана, если в ней отсутствуют соответствующие входные данные для вновь выявленных событий и функций, а также задачи, использующие информацию, уже отраженную в МИП.Исходными документами для составления "МИП разрабатываемой системы" являются "Логическая МИП" (созданная на базе "МИП существующей системы"), "Каталог требований" и "Выбранный вариант концепции". Эту модель получают, преобразуя "Логическую МИП" в соответствии со структурой разрабатываемого ПИ, изложенной в описании выбранного варианта автоматизации.Кроме перечисленных документов, при моделировании информационных потоков может оказаться полезным "Каталог пользователей". В нем содержится перечень пользователей и автоматизируемых функций, к которым они будут иметь доступв новой системе. Этот проектный документ может послужить отправной точкой для определения некоторых внешних объектов, которые впоследствии показывают на "Схеме внешнего окружения", "Схеме документооборота", а поэтому и в "МИП существующей системы". Часть этой информации собирают неформально еще до разработки "Каталога пользователей". Завершая работу по составлению МИП, необходимо убедиться, что в "СИП разрабатываемой системы" присутствуют все внешние объекты, нашедшие отражение в "Каталоге пользователей".Конечным продуктом являются следующие документы: "Модель информационных потоков", "Справочник информационных объектов и хранилищ данных", "Каталог данных".В свою очередь полный комплект проектного документа "Модель информационных потоков" состоит из набора "Схем информационных потоков", "Схемы внешнего окружения", "Описаний функций", "Описаний внешних объектов" и "Описаний информационных интерфейсов"."Схемы информационных потоков" (СИП) должны быть построены так, чтобы с их помощью можно было достаточно наглядно представлять все задачи обработки данных и информационные связи между ними. С этой целью в совокупности схем соблюдается иерархия. СИП, занимающая самый верхний иерархический уровень, отражает представление пользователей о функциональной стороне системы в целом, в том числе, о ее интерфейсах, функциональных подсистемах и основных группах данных. СИП нижних уровней является детализацией задач вышестоящих уровней.Весь набор СИП разрабатывается по принципу нисходящего процесса. Эту декомпозицию заканчивают тогда, когда могут быть достаточно четко определены частные функциональные задачи ПИ. При этом составляется краткое описание задач и основные требования к ним. Более детальных подробностей от МИП не требуется, поскольку задачи более четко специфицируются на последующих этапах. Заказчики и будущие пользователи могут участвовать в разработке МИП, проверяя корректность и улучшая модель, поскольку для понимания схемы им не нужны специальные технические знания. Это способствует активизации роли пользователей, что несомненно важно при разработке ПИ.Таким образом, совокупность СИП содержит "Схему информационных потоков" первого уровня и схемы нижних уровней, которые образуют двухили трехуровневую иерархию.СИП должны быть достаточно подробны для визуального восприятия информационных потоков и уяснения функционирования системы, однако атомарные задачи обработки данных должны быть дополнены кратким изложением их сути в "Описаниях функций" (ОФ).Такие схемы образуют иерархию, отражающую представление пользователя о существующих процессах обработки данных и о требованиях к ним в новой системе. Простота обозначений и возможность раздельного представления облика всей системы и ее отдельных задач позволяют проектировщикам строить и обсуждать с заказчиками и будущими пользователями модель системы, не путаясь во множестве деталей.
Основные понятия рассмотрим на примере фрагмента МИП автоматизированной системы оперативного управления предприятием. На рис.1 изображена ее СИП первого уровня, а на рис.2 представлена СИП второго уровня, раскрывающая одну из задач первого уровня.Внешний объект (ВО) представляет собой находящийся вне системы источник и/или получатель данных. Это может быть пользователь ПИ, лицо или организация, находящиеся за пределами системы, или другая система. ВО обозначают овалом с указанным в нем содержательным именем, а для его идентификации используются строчные буквы латинского алфавита. Для того, чтобы избежать пересечений линий информационных потоков, затрудняющих чтение схемы, символ одного и того же ВО может присутствовать на СИП более чем один раз. Повторяющийся ВО отмечают косой линией в нижнем углу. При большом количестве ВО их идентификаторы могут состоять из двух букв алфавита: aa, ab и т.д. На схемах нижнего уровня внешние объекты можно декомпозировать. В этом случае идентификатор состоит из буквенного обозначения исходного ВО и числового суффикса (например, исходный ВО с именем a может быть разбит на a1, a2 и т.д.).Под задачей при системном анализе понимают автоматизированный или внемашинный процесс, для которого указывается назначение без детализации способа реализации конкретных функций. Задачи связаны со сбором, передачей, хранением, поиском, обработкой (преобразованием) информации в системе и представлением ее пользователям.Задачу обозначают в виде прямоугольника, внутри которого указывают:
уникальный идентификатор задачи;
содержательное наименование задачи (имя задачи);
ссылку на место (только в "Существующей СИП" для указания подразделения в организации, где решается данная задача).Каждой задаче на СИП первого уровня присваивают произвольный идентификатор, состоящий из десятичных цифр и прописных букв латинского алфавита. Он не служит указателем приоритета и последовательности выполнения задачи. Каждую задачу в пределах нижнего уровня СИП обозначают идентификатором вышестоящего уровня с добавлением еще одного символа, например, подзадачи внутри задачи 12 будут иметь идентификаторы 121, 122 и т.д.Содержательное наименование задачи это простое предложение без сказуемого. В качестве его подлежащего используют отглагольное имя существительное, выражающее действие или процесс обработки данных, например, "Оценка и подготовка предложения". Атомарную задачу, т.е. задачу, не подлежащую дальнейшей декомпозиции, на СИП помечают косой чертой и звездочкой в правом нижнем углу соответствующего прямоугольника.Хранилище данных (Datastore) логическая совокупность данных, обработка которых происходит после накопления. Не следует путать с хранилищем данных или информационным хранилищем Data Warehouse большой базой данных, предназначенной для решения аналитических задач.Хранилище данных (ХД) изображают в виде узкого прямоугольника без правой стороны. Если информационная система уже существует, то ХД представляет собой некоторый физический объект: компьютерный файл или неавтоматизированное средство хранения данных, например, картотеку. По завершении логической реструктуризации СИП хранилища данных становятся чисто логическими понятиями, без указания на их физическую природу. Каждому ХД на СИП верхнего уровня присваивают уникальный идентификатор, состоящий из буквы S и номера.
Рисунок 1 Примерная схема информационных потоков предприятия.
Рисунок 2Примерная схема информационных потоков предприятия на примере отдела бухгалтерии.
На СИП нижних иерархических уровней показывают только те ХД, к которым имеют доступ задачи, полученные путем декомпозиции задачи вышестоящего уровня. Этим ХД присваивают идентификаторы, содержащие в качестве элемента номер вышестоящей задачи. Например, имяS2/1 относится к ХД, используемому в задаче 2 и изображаемому только на той СИП, которая описывает эту задачу. Идентификатор S24/1 относится к ХД, встречающемуся в задаче 24 вышестоящего уровня и т.д. Хранилищам данных, полученным в результате декомпозиции ХД вышестоящего уровня, присваивают имена, состоящие из имени ХД вышестоящего уровня и буквенного суффикса. Во избежание переусложнения СИП одинаковые ХД могут использоваться несколько раз. На схемах у таких ХД левую границу прямоугольника изображают двойной линией.Информационный поток изображают стрелкой, показывающей направление потока. Рядом с потоком указывается его наименование. В описании существующей системы в качестве таких наименований могут быть использованы названия реальных документов. Однакоследует иметь в виду, что наименование потока должно отражать не столько названия передаваемых документов, сколько их содержание (например, вместо названия "Форма N5" лучше указать "Сведения о регистрации пользователя"). Это облегчает пользователям понимание формализованной модели. Обычно желательно указывать наименования всех потоков, однако если это перегружает схему, допускается делать исключения. Считается, что содержание входных и выходных потоков данных некоторого хранилища, если не указаны их наименования, соответствует наименованию этого хранилища. Но, даже если содержательный смысл данных очевиден, и поэтому нет необходимости комментировать поток, лучше ввести ненужное наименование, чем оставить место для сомнений.На СИП первого уровня следует изображать только наиболее важные потоки данных. Более детальные данные могут быть представлены на нижних уровнях.Двунаправленный поток может быть использован на СИП верхнего уровня, чтобы подчеркнуть наличие как входящих, так и выходящих потоков на нижних уровнях. Использование двунаправленных потоков допускается на всех уровнях СИП (т.е. когда потоки, возможно, представляют собой совокупность элементарных потоков), за исключением самого нижнего. На самом нижнем уровне все потоки должны быть только однонаправленными. СИП всех уровней должны быть согласованы между собой. Любой поток нижнего уровня должен быть представлен на верхнем уровне одноили двунаправленным потоком. Таким образом, любой информационный поток может состоять из нескольких потоков данных нижестоящего уровня СИП.Информационные потоки, существующие между внешними объектами, если необходимо их показать для лучшего понимания процесса функционирования системы, обозначают штриховой линией.Для изображения движения материальных объектов (например,товаров) используют два вспомогательных символа. Материальный поток, т.е. перемещение объектов от одного места к другому, подобно тому, как это имеет место на промышленном производстве, обозначают широкой стрелкой. Замкнутым удлиненным прямоугольником обозначают хранилище материальных объектов.При разработке СИП следует придерживаться ряда синтаксических правил. Каждая задача и каждое хранилище должны иметь хотя бы один входящий и хотя бы один исходящий поток. Не допускается соединять внешние объекты с хранилищами данных и материальных объектов ни информационными, ни материальными потоками. ВО между собой могут соединяться только внешними потоками данных и материальными потоками. Задачи с хранилищами материальных объектов могут соединяться только материальным потоком. Ни информационные, ни материальные потоки никогда не должны соединяться.Иерархия СИП должна быть достаточно простой и понятной, поскольку такие схемы являются средством общения между разработчиком и заказчиком. Их чрезмерная детализация препятствует взаимопониманию. В то же время, единственной СИП редко бывает достаточно для того, чтобы отразить все подробности системы. Поэтому составляют несколько СИП, образующих иерархию. Верхний уровень иерархии называется СИП первого уровня. Эту схему используют для определения облика системы в целом. На ней изображают внешние источники и получатели информации, основные входы и выходы системы, ее функциональные подсистемы, а при необходимости и границу, отделяющую систему от внешних объектов.Представления пользователей об основных функциональных подсистемах на СИП первого уровня изображают в виде прямоугольниковзадач. Каждая из задач может быть разбита на подзадачи, которые изображают на СИП нижестоящего уровня. Такой прямоугольник можно считать "окном",через которое видна соответствующая схема нижестоящего уровня иерархии, содержащая более подробное представление о соответствующей задаче.Если необходимо, прямоугольникизадачи второго уровня можно разбить на задачи третьего уровня. Рекомендуется использовать не более трех уровней, так как их обычно бывает достаточно для представления функциональной стороны автоматизированной системы. На СИП самого нижнего уровня все задачи должны быть атомарными. В то же время, некоторые задачи на СИП вышестоящих уровнеймогут быть на столько просты, что для их описания не требуется СИП нижестоящего уровня. Поэтому атомарные задачи могут присутствовать на СИП любого уровня.Общее число задач на каждой СИП не должно быть слишком мало, чтобы схема не становилась тривиальной, и не должно превышать некоторого предела сложности, выше которого схема становится трудно воспринимаемой заказчиками. Оптимальным является 5 9 задач на одной схеме.На каждом иерархическом уровне проектировщик должен стремиться к представлению примерноодинакового количества информации на СИП. Предполагается, что при разработке "Технического задания" каждая задача уровня 1 порождает СИП второго уровня. Некоторые задачи вообще не нуждаются в декомпозиции. Примерами таких задач могут быть вспомогательные общесистемные функции, для документирования которых обычно достаточно сведений, приводимых в проектном документе "Описание функций". Может случиться так, что на текущем иерархическом уровне СИП для представления некоторых задач потребуется несколько нижестоящих уровней, а остальные задачи не нуждаются в декомпозиции. В этом случае рекомендуется изучить возможность реструктуризации СИП путем расчленения наиболее сложных задач и объединения сравнительно простых. Не следует стремиться к построению "идеальной" модели, требуется лишь правильно зафиксировать представление заказчика о существующей информационной системе.Прямоугольникузадаче на нижестоящем уровне ставят в соответствие границу фрагмента СИП, на котором изображают более детальное представление этой задачи. Информационные потоки, с помощью которых задача связана с другими элементами на СИП вышестоящего уровня, при более детальном представлении должны пересекать границу данной задачи и соединяться с входящими в нее подзадачами. Хранилища данных, используемые только в рассматриваемой задаче, размещают в пределах ее границ. Если хранилище данных используется несколькими задачами, то его помещают вне границ СИП нижнего уровня. Внешние объекты также изображают за пределами границ рассматриваемой задачи. Следует помнить, что декомпозиция задачи это добавление сведений о ней без потери ее связей с другими задачами, хранилищами данных и внешними объектами в их первоначальном виде.При декомпозиции внешние объекты и хранилища данных могут быть разбиты на компоненты на нижестоящем уровне. Это позволяет упростить СИП верхнего уровня и, в то же время, гарантировать непротиворечивость сведений, представленных на различных уровнях.Проектировщик должен проверить каждую СИП нижнего уровня на непротиворечивость и полноту. В частности, он должен проследить, чтобы каждая СИП верхнего уровня соответствовала нижестоящему уровню. Если обнаружены противоречия, то СИП верхнего уровня необходимо доработать. При этом следует иметь в виду, что при представлении задачи в более детальном виде на СИП нижнего уровня потоки данных, их источники и получатели для этой задачи должны быть одни и те же как на рассматриваемом, так и на вышестоящем уровнях. Вместе с тем, на нижестоящем уровне потоки данных, пересекающие границу системы, обычно показывают более подробно. Составной поток данных, исходящий из внешнего объекта и показанный на СИП верхнего уровня как один поток, на нижестоящем уровне может быть разложен на несколько потоков данных.Дополнительные проверки СИП на корректность сводятся к контролю за соблюдением следующих требований:
название каждой задачи в идеальном случае должно содержать активное отглагольное имя существительное; если задаче не удается дать четкое название, то, вероятно, ее смысл до конца не выяснен или же ее следует более четко отделить от других задач;
для каждой задачи должна ясно прослеживаться связь между входящими и выходящими потоками данных;
чем меньше на схеме потоков данных, соединяющих пары задач, тем лучшего разделения задач удалось добиться;
задачи не должны выполнять роль хранилищ или получателей данных; задача преобразует входной информационный поток в выходной, она может формировать некоторые новые элементы данных, например, суммы или средние значения, но никогда не использует данные без последующей передачи их другой задаче, хранилищу данных или внешнему объекту;
каждое хранилище данных должно иметь входящие и выходящие информационные потоки, иными словами, данные должны создаваться и использоваться; если задачи, создающие или использующие данные, тривиальны, то как исключение, на СИП первого уровня их можно не показывать.После этого СИП проверяют на полноту. Для этого прослеживают информационные потоки от входов системы через задачи к хранилищам данных и ее выходам. Обычно это делают визуально. В более сложных случаях для отдельных входов и выходов специально документируют маршруты информационных потоков. В дальнейшем эти документы используют для проверки СИП на полноту при неформальном обсуждении с заказчиками и будущими пользователями системы.Главная цель построения "Существующей СИП" точно отразить сложившуюся систему обработки информации в терминах потоков данных таким образом, чтобы можно было выявить и обсудить все ее недостатки, которые затем соответствующим образом отражают в "Каталоге требований". Параллельно с этим определяют дополнительные функции, которые должна выполнять новая система, и документируют требования к ним.Целью обсуждения "Существующей СИП" с заказчиками и пользователями является проверка того, насколько точно она отражает структуру существующей системы и ее функции. Если к единому мнению относительно облика системы, представленного на СИП, прийти не удается, то это обычно указывает на низкое качество "Заявки на разработку ПИ", о чем следует поставить в известность руководителя проекта. Как правило, в результате обсуждения могут быть обнаружены новые ошибки и несоответствия, для исправления которых потребуется повторная корректировка схем. При этом могут быть также выявлены некоторые недостатки существующей системы, которые следует отразить в виде соответствующих записей в "Каталоге требований".С целью устранения дублирования в "Существующей МИП" задач и хранилищ данных, а также для группирования атомарных подзадач в соответствии с функциональными подсистемами, отвечающими потребностям пользователей, после обсуждения с заказчиками разрабатывают "Логическую МИП" существующей системы. При этом реструктурируют хранилища данных и атомарные задачи и выполняют проверку "Логической СИП" на корректность. Обычно эти действияповторяют несколько раз до тех пор, пока не будет получена непротиворечивая и полная модель потоков данных."МИП разрабатываемой системы" составляют на основе "Логической МИП", которую уточняют с учетом "Выбранного варианта автоматизации" и содержания "Каталога требований". Она служит исходным проектным документом при определении функций системы, а также при контроле корректности "Логической модели данных". Кроме того, при определении функций МИП содержит исходные сведения для предварительного выявления множества событий, которыми сопровождается функционирование системы.Функциями системы называются процедуры обработки данных о событиях, связанных с ее основным назначением. Функции определяют на основе "СИП разрабатываемой системы" самого нижнего уровня посредством трассировки каждого входного потока данных от внешнего объекта к атомарным задачам, принимающим данный поток, и другим задачам, которые должны быть вызваны для его обработки и должны генерировать выходную информацию.Выходная информация функций может направляться как в те же внешние объекты, от которых поступили входные данные, так и в другие внешние объекты. В последнем случае это означает, что выходные потоки формируются не в режиме диалога. Если выходная информация возвращается к тому же внешнему объекту, от которого поступили входные данные, то это может быть, например, отображение информации для визуального контроля в реальном времени. При этом от проектировщика обычно не требуется моделировать процесс диалогового контроля ошибок.Разработчик документа "МИП разрабатываемой системы" должен специально заботиться о том, чтобы этот документ облегчал определение функций.В процессе определения функций события идентифицируют путем изучения описаний входных потоков данных, а также описаний тех элементарных задач, которые не инициируются данными, поступающими от внешних объектов. Некоторые другие события и, возможно, функции, которыми реагирует на них система, могут быть выявлены в ходе анализа истории существования информационных объектов. Если на "Существующей СИП" для некоторого события отсутствует инициируемая им задача или соответствующий входной поток данных, то это означает, что в МИП пропущены важные функциональные части, и поэтому ее следует доработать. Часто для исправления такой ошибки бывает достаточно добавить в "Описание информационного интерфейса" входного потока данных недостающие элементы, порождающие соответствующие события. Как бы то ни было, "МИП разрабатываемой системы" является приложением к "Техническому заданию", поэтому она должна быть приведена в соответствие с "Описаниями функций".Имеются два основных способа выявления сущностей, являющихся для системы входными воздействиями. Первый основан на анализе потоков данных, которые выявляют и изображают на СИП. Второй базируется на ваявлении событий, связанных с модификацией информационных объектов. Эту информацию документируют на схемах "Историй информационных объектов". Оба способа могут быть описаны в терминах элементов данных.Поток данных в общем случае несет в себе одно или связку из нескольких событий. Имея это в виду, проектировщик, перед которым стоит задача проверки правильности "МИП разрабатываемой системы", должен позаботиться об установлении логического соответствия между информационными потоками и всеми событиями.Таким образом, основной особенностью составления "МИП разрабатываемой системы" является учет специфики методики "Динамическое моделирование данных", которая нацелена на анализ влияния событий на состояние хранимых данных.Анализ событий при построении МИП позволяет получить формализованную модель, значительно более полно и строго описывающую требования к автоматизированной системе.
Khudoyarov Ilya VladimirovichStudent, Samara State Economical University, Samarafixorest@gmail.com
Shvetsova Elena VladislavovnaPhD, Associate Professor Samara State Economical University, Samara
shvetsova.e@mail.ruInformation flows, analysis, data modeling technique in logistics.This article is devoted to the modeling of information flows, their analysis, as well as the technique of data modeling in logistics. Relevance of the chosen problem is caused by an increase in the amount of information flow in the enterprises, and the need for their modeling and subsequent optimization and automation. Also the article describes the method of analysis of the information flows of the company and an example of its use.Logistics, information logistics, system analysis, information modeling, information flows, information provision.
