Построение DFD-модели
Запустите BPwin. Выберите в главном меню File New. Введите имя модели (например, ARM) и тип модели – DFD (рис.5.1). Нажмите OK.
Рис.5.1. Диалог создания модели.
Настройка рабочего окна. В главном меню выберите View и проследите, чтобы все возможные подпункты были помечены галочкой (кроме ModelMart Toolbar). В стандартной панели инструментов (Standard Toolbar), которая находится под Главным меню, измените масштаб модели, чтобы область для рисования полностью отображалась (например, Full Diagram или Full Sheet).
При возникновении проблемы с русскими символами обращайтесь к пункту меню Model Default Fonts.
Описание диаграммы и модели в целом. Нажмите правой кнопкой мыши на свободном месте на диаграмме. В открывшемся меню выберите Diagram Properties. Укажите своё имя, статус диаграммы (пока рабочий – WORKING) и другую информацию.
Теперь Model Properties. Выберите имя для вашего проекта (Project). Помимо этого необходимо дать краткое описание модели (Definition), указать цель построения диаграммы (Purpose), зафиксировать точку зрения (Viewpoint) – с точки зрения кого (пользователя, администратора и т.п.) создается модель.
Определение и формализация цели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь. Например, если мы моделируем деятельность предприятия с целью построения в дальнейшем на базе этой модели информационной системы, то эта модель будет существенно отличаться от той, которую бы мы разрабатывали для того же самого предприятия, но уже с целью оптимизации логистических цепочек.
Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Например, функциональные модели одного и того же предприятия с точек зрения главного технолога и финансового директора будут существенно различаться по направленности их детализации. Это связано с тем, что в конечном итоге, финансового директора не интересуют аспекты обработки сырья на производственных станках, а главному технологу ни к чему прорисованные схемы финансовых потоков. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели.
Также можно очертить область моделирования (Scope), которая в последующем будет определять общие направления движения и глубину детализации.
Определение контекстного процесса. Теперь нажмите правой кнопкой мыши на блоке в центре экрана, изображающем контекстный процесс. Выберите в появившемся меню Name… и введите “Работа диспетчера районов курсирования”. Внизу под диаграммой появился заголовок: TITLE: Работа диспетчера районов курсирования. Если имя процесса превышает размеры блока и выходит за его границы, то в поле Name после “Работа диспетчера” нажмите Enter.
Если хотите, то можете описать процесс (Definition) и дать дополнительные замечания (Note).
C помощью Color Editor и Font Editor установите цвет фона блока контекстного процесса (например, голубой), цвет текста и шрифт для его имени.
Используя Costs Editor можно задавать стоимость реализации процесса (Cost), число повторений (Frequency) и длительность процесса (Duration).
Внешние сущности. Известно, что в процессе работы диспетчера районов курсирования он взаимодействует с ИТЦ (ГВЦ), железнодорожными администрациями и дорогами приписки собственников. Эти объекты на диаграмме будут отображены в виде внешних сущностей.
Выберем в BPwin Toolbox кнопку  и разместим внешние сущности на диаграмме. Самостоятельно дайте имена и описания (по желанию) для этих объектов.
Определение информационных потоков. Каждому потоку можно давать имя непосредственно с помощью индивидуального Name Editor, который можно вызвать, наведя курсор на поток и нажав правую кнопку мыши.
Возможен и другой путь. Выберем в Главном меню Dictionary Arrow… В столбце Name введем “Телеграмма-разрешение на расширение района курсирования” и нажмем Enter. Последовательно внесем в словарь:
Заявка на расширение района курсирования
Некорректная заявка
Корректировочный файл
Заявка на разрешение расширения района курсирования
Разрешение на расширение района курсирования
Телеграмма-сообщение о согласованных районах курсирования
Закончив формирование словаря, сохраните его (Dictionary Save) и нажмите Dictionary Close.
В BPwin Toolbox выберем  . Соединим внешнюю сущность “Дорога приписки собственника” с центральным блоком (Работа диспетчера районов курсирования. С помощью правой кнопки мыши вызовем Name Editor и в Arrow Dictionary выберем “Заявка на расширение района курсирования”. Для наглядности можно подвести от названия к стрелке ссылку (в меню – Squiggle). Воспользуемся  и покажем точку на стрелке и точку на имени стрелки, которые мы хотим связать. Этого же можно добиться, вызвав правой кнопкой мыши Squiggle. Если название потока, по вашему мнению, неудачно расположено на экране, его можно передвинуть и изменить размеры. Для этого выделите заголовок и растягивайте (сжимайте) и/или перемещайте его подобно обычному окну Windows.
Для информационного потока можно изменить шрифт, стиль и цвет, наведя курсор на поток, нажав правую клавишу мыши и вызвав соответственно Font Editor, Style Editor и Color Editor.
Нарисуйте остальные потоки самостоятельно так, как показано на рис.4. Контекстная диаграмма готова (рис.5.2).
Рис.5.2. Контекстная диаграмма
Детализация контекстной диаграммы. В BPwin Toolbox нажмем  . Откроется окно следующего вида (рис.5.3):
Рис.5.3. Окно декомпозиции диаграммы.
На дочерней диаграмме можно автоматически разместить от 0 до 8 подпроцессов (по умолчанию – 4). При выполнении работы переносить внешние сущности и хранилища родительской диаграммы на дочернюю диаграмму не рекомендуется. При желании это можно сделать, пометив галочкой пункт Include Externals & Data Stores. Но в этом случае вы должны будете самостоятельно разместить на дочерней диаграмме блоки, соответствующие подпроцессам. Поэтому просто нажмите OK.
Диаграмма второго уровня содержит все потоки, которые ей достались в наследство от контекстной диаграммы. Помимо этого на экране вы видите четыре пустых блока, которые обозначают дочерние процессы. Имена процессов должны быть именованы отглагольными существительными, обозначающими действие. Присвойте им с помощью Name Editor следующие названия:
Проверка корректности заявки
Составление телеграммы-заявки на согласование
Согласование с ж./д. администрациями
Формирование корректировочного файла.
Теперь необходимо разместить на диаграмме информационные хранилища (Data Store), которых в модели будет девять. Для размещения хранилищ воспользуйтесь  .
Дадим имена хранилищам:
База данных отпущенных вагонов (БДОН)
База данных технических характеристик (БДТХ)
Дорожная картотека собственных вагонов (БДДКСВ)
База данных районов курсирования (БДРК)
БД заявок с дороги приписки
БД телеграмм-заявок на согласование
БД справочников
БД собственников
БД расширенных районов курсирования.
Привязка унаследованных информационных потоков к объектам диаграммы.
С помощью указателя  из BPwin Toolbox выделим на дочерней диаграмме стрелку “Заявка на расширение района курсирования”, но не целиком, а только самую верхнюю часть (возможно для этого придется сдвинуть название стрелки) и подсоединим ее слева к первому процессу – “Проверка корректности заявки” (рис.5.4).
Рис.5.4.Связь унаследованных потоков и процесса.
В BPwin есть понятие Tunnel (туннель). Говорят, что поток проходит через туннель, если он есть на более подробной дочерней диаграмме, но отсутствует на родительской (чтобы не “перегружать” ее). Туннель в BPwin обозначается круглыми скобками в начальной или конечной точке потока. Обозначение “туннеля” (Arrow Tunnel) вокруг начала потока обозначает, что он не был унаследован от функционального родительского блока и появился (из “туннеля”) только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца стрелки в непосредственной близи от блока – приёмника означает тот факт, что в дочерней по отношению к этому блоку диаграмме этот поток отображаться и рассматриваться не будет. Если вы видите на диаграмме не круглые, а квадратные скобки, это значит, что нарушена целостность диаграммы – поток на родительской диаграмме не совпадает с тем же потоком на дочерней диаграмме или отсутствует на ней. Это происходит, когда вместо присоединения унаследованных потоков к объектам диаграммы пользователь удаляет эти потоки и наносит новые, пусть даже с теми же именами.
Замечание. Возникают проблемы с привязкой унаследованных потоков, которые находятся в нижней части дочерней диаграммы и направлены тоже вниз. Постарайтесь избежать таких ситуаций. Но если такая ситуация имеет место, то выделите этот поток и удалите его. Теперь вернитесь к контекстной диаграмме. Вы увидите, что верхняя часть
удаленной стрелки заключена в квадратные скобки. Это сигнал вам о том, что вы не перенесли этот поток на дочернюю диаграмму. Выделите часть стрелки в скобках и нажмите правую клавишу мыши. Выберите Arrow Tunnel… Вам предлагается убрать скобки (Resolve Border Arrow) или заменить их на круглые скобки (Change To Tunnel). В первом случае вы вновь получите эту стрелку на дочерней диаграмме, во втором вы явно указываете, что эта стрелка на дочерней диаграмме не нужна.
Разъединение и слияние потоков. Вся дуга или ее часть может выходить из одного или нескольких процессов и заканчиваться в одном или нескольких процессах.
Разветвление потока означает, что все содержимое потока или его часть может появиться в каждом ответвлении. Поток помечается до разветвления, чтобы дать название всему набору. Кроме того, каждая ветвь потока может быть помечена или не помечена в соответствии со следующими правилами:
непомеченные ветви содержат все объекты, указанные в метке потока перед разветвлением;
ветви, помеченные после точки разветвления, содержат все объекты или их часть, указанные в метке потока перед разветвлением.
Слияние потоков указывает, что содержимое каждой ветви идет на формирование метки для потока, являющегося результатом слияния исходных потоков. После слияния результирующий поток всегда помечается для указания нового набора объектов, возникшего после объединения. Кроме того, каждый поток перед слиянием может помечаться или не помечаться в соответствии со следующими правилами:
непомеченные ветви содержат все объекты, указанные в общей метке после слияния;
помеченные перед слиянием ветви содержат все или некоторые объекты из перечисленных в общей метке после слияния.
Расширение словаря потоков данных. Откроем в Главном меню Dictionary Arrow…(словарь потоков данных). Внесем в него названия следующих информационных потоков:
Данные заявки с дороги приписки
|
Данные о признаке качества вагонов
|
Данные о районах курсирования вагонов
| | |
Данные о технических характеристиках вагонов
|
Данные об отпущенных номерах вагонов
|
Данные по телеграмме-заявке на согласование
| | | |
Телеграмма-заявка на согласование.
|
Теперь начертим все эти информационные потоки на диаграмме.
Диаграмма второго уровня построена (рис.5.5). Любой процесс этой диаграммы можно детализировать, указав и требующий детализации процесс.
Рис.5.5. Диаграмма второго уровня.
Детализация диаграммы второго уровня.
Аналогично выше приведенному описанию декомпозируем процесс “Проверка корректности заявки”. При этом получаем три новых процесса. Опишем их в Name Editor как:
Проверка принадлежности номеров вагонов данному собственнику
Проверка технических характеристик вагонов
Проверка признака качества вагонов.
Итоговая диаграмма третьего уровня представлена на рис.5.6.
Рис.5.6. Диаграмма третьего уровня.
|
