Контекстная диаграмма: пример с программкой концерта
Контекстная диаграмма: пример IDEF0 для подготовки концертной программки. Показываю один блок, входы, управление, выход и ресурсы, объясняю границы процесса.
Евгений
Дизайнер-партнёр LibraChat
6 мин чтения
Семь подписей достаточно, чтобы обсудить подготовку концертной программки: какие материалы я получаю, по каким правилам работаю, что отдаю и чем пользуюсь. Для этого мне подходит контекстная диаграмма. Пример ниже построен в нотации IDEF0: один блок показывает функцию целиком, четыре его стороны задают роли связей. Название процесса — «Подготовить программку концерта». Печать тиража в эту границу я не включаю; результатом будет файл программки.
Контекстная диаграмма: пример на одном листе
Я начинаю с предмета разговора. Нужна программка камерного концерта: названия произведений, исполнители и небольшие пояснения для слушателя. Организатор передаёт список номеров и сведения об участниках. Мне предстоит собрать из них макет на четыре полосы. Такой объём — условие этого проекта, а не требование ко всем программкам.
В IDEF0 верхнюю контекстную страницу обозначают A-0. На ней один функциональный блок с номером 0. Внутри я пишу действие с объектом: «Подготовить программку концерта». Подпись «Концерт» была бы слишком широкой для моей задачи: она не объясняет, какую работу моделируют и где эта работа заканчивается.
Схематически страница выглядит так:
```text
Требования к формату; редакционные правила
|
v
Список номеров; +----------------------------+ Файл
сведения -->| Подготовить программку |--> программки
об участниках | концерта 0 | PDF
+----------------------------+
^
|
Редактор; программа вёрстки
Страница A-0
```
Это моя текстовая схема для разбора связей. В графическом редакторе подписи можно разнести, сохранив направления и стороны блока. Здесь в одной линии объединены однородные подписи, а полный состав виден в таблице. Я собрал 7 строк: две с исходными материалами, две с условиями работы, две с ресурсами и одну с результатом.
Список концертных номеров — Вход — Слева, стрелка внутрь
Сведения об участниках — Вход — Слева, стрелка внутрь
Требования к формату программки — Управление — Сверху, стрелка внутрь
Редакционные правила — Управление — Сверху, стрелка внутрь
Файл программки PDF — Выход — Справа, стрелка наружу
Редактор — Механизм — Снизу, стрелка вверх
Программа вёрстки — Механизм — Снизу, стрелка вверх
Под схемой я также фиксирую цель и точку зрения. Цель — договориться о составе задачи до подробного планирования работы. Точка зрения — редактор, который готовит файл. Иначе на том же листе легко начать обсуждать продажу билетов, подготовку сцены и рассадку слушателей. Всё это относится к концерту, но лежит за выбранной границей.
Четыре стороны задают разные вопросы
Слева находится то, что функция преобразует в результат. Список номеров превращается в упорядоченный текст программки; сведения об участниках — в короткие представления исполнителей. Материал может остаться узнаваемым, но его роль в модели связана с преобразованием. Сам по себе факт получения документа ещё не делает его входом: надо понять, зачем документ нужен этой функции.
Сверху я помещаю условия правильного результата. Требование «четыре полосы, формат A5» ограничивает макет. Редакционные правила задают написание имён и оформление названий произведений. Их не нужно превращать в содержание концертных номеров. По ним проверяют работу. Это помогает разделить исходные сведения и требования к их обработке.
Справа находится произведённый результат. В нашем случае — файл PDF с программкой. Этот формат выбран в задании. Готовность файла оценивается по согласованным требованиям: в нём должны быть нужные сведения и нужное число полос. Если типография предъявляет дополнительные условия, их тоже нужно явно включить в управление.
Снизу расположены средства выполнения функции. Я указал редактора и программу вёрстки. Они участвуют в подготовке, но не становятся содержанием программки. В IDEF0 эту роль называют механизмом. Тихое слово для обычного рабочего вопроса: кто и с помощью чего делает работу?
Чтобы разобрать похожее описание, в LibraChat можно попросить список элементов с объяснением ролей. Например:
Разбери описание для контекстной диаграммы IDEF0 A-0. Функция: подготовить программку концерта. Исходные материалы: список номеров и сведения об участниках. Условия: четыре полосы A5 и редакционные правила. Средства: редактор и программа вёрстки. Результат: файл программки PDF. Дай таблицу: элемент, роль, сторона блока, причина. Не добавляй функции продажи билетов и печати тиража. Заверши вопросами о неописанных требованиях к программке и её исходным сведениям.
Попробуй такой запрос со своим описанием, сохранив одну границу процесса. Таблицу подписей удобно сверять с брифом до построения схемы. Если исходные требования лежат в документе, условия его загрузки можно сверить в тарифах LibraChat. Я сначала согласую смысл связей, а уже потом двигаю линии на листе.
Бумага показывает, зачем нужна точная граница
У программки есть физическое продолжение: её напечатают. Поэтому бумага кажется очевидным участником всей истории. Но моя функция заканчивается файлом. Бумагу редактор в программку не преобразует. На этой контекстной странице она не нужна. Это следует из выбранного результата, а не из желания сделать схему короче.
Если выбрать другую функцию — «Напечатать программки концерта», роли изменятся. Бумага станет преобразуемым материалом слева. Печатное оборудование и оператор окажутся средствами выполнения снизу, а справа появится тираж. Это уже другая модель. Переносить в неё подписи из первой диаграммы без пересмотра смысла нельзя: функция определяет роль объекта.
Я проверяю пограничный элемент тремя вопросами:
Что с ним происходит в пределах именно этой функции?
Он преобразуется, задаёт условие или обеспечивает выполнение?
Можно ли объяснить его связь с названным выходом?
Такой разбор особенно помогает с людьми и документами. Организатор может передавать материал, утверждать требования или сам готовить текст. Одного названия должности недостаточно, чтобы выбрать сторону блока. Нужна его роль в рассматриваемой работе. Я уточняю действие и только затем оставляю подпись в нужном месте.
Что остаётся внутри прямоугольника
Сбор материалов, редактирование и вёрстка входят в подготовку программки. На контекстном листе они ещё не разложены на отдельные блоки. Если добавить их рядом и соединить последовательностью, получится другой уровень подробности. Сначала я оставляю весь предмет в одном блоке. Его внутреннее устройство можно раскрыть на дочерней диаграмме A0.
До этого полезно прочитать лист без объяснений автора:
Название блока отвечает, какую работу рассматривают.
Входы и выход показывают преобразование материалов.
Управление описывает условия пригодности результата.
Механизмы называют средства выполнения.
Цель и точка зрения удерживают общий смысл страницы.
Контекстная диаграмма в нотации DFD устроена по другой логике: она показывает обмен данными между системой и внешними сущностями. Для такого задания потребуется пример именно DFD. В этой статье стороны блока имеют смысл IDEF0; смешивать правила двух нотаций на одном рисунке не стоит. При сдаче работы сначала сверяй название требуемой нотации.
Внешний вид можно доработать отдельно. Если хочется подобрать подачу будущей иллюстрации, пригодится материал об изображении по текстовому описанию. Но считывать назначение стрелки здесь должно помогать её соединение с блоком и подпись. Цвет сам по себе не назначает объекту роль.
На обсуждение программки я принесу этот лист рядом с кратким брифом. Семь подписей уже распределяют разговор: материалы запрашиваем у организатора, условия уточняем до вёрстки, результат называем заранее. После этого вопрос о бумаге можно спокойно передать тому, кто планирует печать. На странице A-0 остаётся именно та работа, за которую я взялся.