Общие рекомендации по построению диаграмм

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

Минимизация множественных потоков

Часто оказывается, что в одном и том же потоке перемещаются несколько "пакетов" данных. Иногда бывает трудно подобрать имя, которое адекватно отражало бы содержание потока данных. Например, заказчики могут высылать заказы, платежи, делать возврат поврежденных товаров, высылать запросы, предъявлять претензии и т.д. Очень неудобно рисовать множественные потоки данных, как это показано на рис. 19.

Рис. 19. Множественный поток данных

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

Рис. 20. Первое решение для множественного потока данных

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

Рис. 21. Второе решение для множественного потока данных

Дублирование узлов

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

Рис. 22. Дублирование внешних сущностей

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

Рекомендации по построению контекстных диаграмм

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

Рис. 23. Пример контекстной диаграммы простой системы

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

5. Основные принципы нотации проектирования последовательности работ IDEF3. Смысловые примитивы. Связи. Декомпозиция. Перекрёстки.