книги / Структурные модели бизнеса DFD-технологии
..pdfСледование всем принципам в комплексе позволяет на более ранних ста диях проекта понять, что представляет собой моделируемая система, обна ружить промахи и недоработки. Фактически структурный анализ снабжает всех участников проекта общим языком, с одной стороны, - достаточно стро гим и формализованным, с другой - простым и интуитивно понятным.
В настоящее время известно около 90 разновидностей структурного сис темного анализа, однако практически все активно используемые методоло гии могут быть разбиты на две группы - применяющие методы и техноло гию диаграмм потоков данных D FD (в различных нотациях) и использую щие SADT-методологию (точнее ее стандартизированное подмножество IDEF0).
1.2. DFD-технология: интегрированная
структурная модель
Прежде чем подробно рассмотреть каждый из основных эле ментов D FD -технологии, необходимо обсудить их в общем виде и проде монстрировать их взаимосвязи.
В основе классической D FD -технологии лежат три группы средств моде лирования:
•диаграммы, иллюстрирующие функции, которые система должна вы полнять, и связи между этими функциями - для этой цели используются соб ственно диаграммы потоков данных D FD (Data Flow Diagrams), дополнен ные словарями данных и спецификациями процессов нижнего уровня;
•диаграммы, моделирующие данные и их взаимосвязи, - для этой цели используются диаграм мы «сущ ность-связь» ER D (E ntity -R elationship Diagrams);
•диаграммы, моделирующие поведение системы, - для этой цели исполь зуются диаграммы переходов состояний STD (State Transition Diagrams).
Все эти диаграммы содержат графические и текстовые средства модели рования: первые - для удобства демонстрирования основных компонентов модели, вторые - для обеспечения точного определения ее компонентов и связей.
Основа модели - диаграмма D FD показывает внешние по отношению к системе адресаты и адресанты данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с дру гой (потоки), а также идентифицирует накопители (хранилища) данных, к которым осуществляется доступ. Структуры потоков данных и определения их компонентов хранятся и анализируются в словаре данных. Каждая логи ческая функция (процесс) может быть детализирована с помощью D FD ниж него уровня; когда дальнейшая детализация перестает быть полезной, пере ходят к выражению логики функции при помощи спецификации процесса нижнего уровня (мини-спецификации). Содержимое каждого накопителя так же сохраняют в словаре данных, модель данных накопителя раскрывается с
помощью ERD. В случае построения поведенческой модели D FD дополня ется средствами описания, зависящего от времени поведения системы, рас крывающегося с помощью STD. Эти связи показаны на рис. 1.1.
Перечисленные средства дают полное описание бизнес-системы незави симо от того, является ли она существующей или разрабатываемой с нуля. Таким образом строится логическая функциональная спецификация - под робное описание того, что должна делать система, освобожденное насколь ко это возможно от рассмотрения путей реализации. Это дает проектиров щику четкое представление о конечных результатах, к которым следует стре миться.
DFD
Процесс
Ь.„ .. - .
ДЕТАЛИЗИРУЮЩАЯ DFD |
|
|
|
Поток |
|
|
|
~'4 данных |
Накопитель |
( |
Управляющий \ |
Процесс |
|||
I X |
_____________ процесс |
" --------^ — *- |
|
|
Т Х |
|
|
/7 Х |
|
|
Г х |
|
|
|
|
-X —г' |
Х А |
|
|
Спецификация |
Словарь |
ERD |
STD |
процесса |
данных |
|
|
Рис. 1.1. Компоненты DFD-технологии
1.2.1. Иерархическая функциональная модель
Диаграммы потоков данных (DFD) являются основным средством функ ционального моделирования бизнес-системы. С их помощью система разби вается на функциональные компоненты (процессы) и представляется в виде сети, связанной потоками данных. Главная цель таких средств - продемонст рировать, как каждый процесс преобразует свои входные данные в выход ные, а также выявить отношения между этими процессами.
Диаграммы потоков данных известны очень давно. В фольклоре упоми нается следующий пример использования DFD для реорганизации перепол ненного клерками офиса, относящийся к 1920-м годам. Осуществлявший ре организацию консультант обозначил кружком каждого клерка, а стрелкой - каждый документ, передаваемый между ними. Используя такую диаграмму, он предложил схему реорганизации, в соответствии с которой двое клерков, интенсивно обменивающихся большим количеством документов, были по сажены рядом, а клерки с малым взаимодействием были посажены на боль шом расстоянии. Так родилась первая модель, представляющая собой пото ковую диаграмму, - предшественник DFD.
Диаграммы потоков данных чрезвычайно просты, наглядны и понятны. Базовая их нотация включает всего четыре рассматриваемых ниже объекта.
1. Поток данных является механизмом, использующимся для моделиро вания передачи информации (или даже физических компонентов) из одной части системы в другую. Важность этого объекта очевидна: он дает название целому инструменту. Потоки на диаграммах обычно изображаются имено ванными стрелками (при этом имя потока отражает его содержимое), ориен тация которых указывает направление движения информации.
2. Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Это имя должно содержать глагол в неопределенной форме с последующим дополне нием (например, ВЫЧИСЛИТЬ М АКСИМ АЛЬНУЮ ВЫСОТУ) или отгла гольное существительное (ВЫЧИСЛЕНИЕ М АКСИМ АЛЬНОЙ ВЫСОТЫ).
Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с но мером диаграммы для получения уникального индекса процесса во всей мо дели. Процессы обозначаются на диаграмме, как показано на рис. 1.2; сим вол процесса включает три разделенных горизонтальными чертами поля:
•верхнее поле содержит номер процесса и аббревиатуру детализирую щего объекта (КД - контекстная диаграмма, ДПД - диаграмма потоков дан ных, МС - мини-спецификация);
•среднее поле содержит имя процесса;
•нижнее поле содержит имя исполнителя процесса (идентификатор под
разделения, должности, механизма и т.п.).
' 1 |
ДПД |
Начисление заработной платы
^ Бухгалтерия______________
Рис. 1.2. Изображение процесса на диаграммах
3. Накопитель данных позволяет на определенных участках определять данные, которые будут сохраняться вне процессов. Фактически накопитель представляет «срезы» потоков данных во времени. Информация, которую он содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя накопителя должно идентифицировать его содержимое и быть существительным во множествен ном числе.
Логически накопители данных есть некие устройства для хранения ин формации, куда ее можно поместить и через некоторое время извлечь. При этом не уточняется способ помещения и извлечения данных в накопитель, нас не интересует, происходит ли извлечение данных для чтения (копирова ния) или для изъятия и другие подобные вопросы.
Накопитель данных обозначается, как показано на рис. 1.3. Каждый на копитель данных идентифицируется для ссылки буквами «БД» и числом в
квадрате с левой стороны, определяющим его номер. Имеется возможность
создавать копии накопителя, в этом случае номер соответствующей копии фиксируется под идентификатором накопителя.
БД1 Договора
Рис. 1.3. Изображение накопителя на диаграммах
Когда процесс сохраняет данные, то стрелка потока данных направлена в накопитель данных, и, наоборот, когда доступ в накопитель данных осу ществляется для чтения, стрелка потока данных направлена в процесс.
4. Внешняя сущность представляет сущность вне контекста системы, являющуюся источником или приемником системных данных, например
ЗАКАЗЧИК, ПОСТАВЩ ИК, СКЛАД ТОВАРОВ. Определение некоторого объекта в качестве внешней сущности указывает на то, что он находится за пределами анализируемой системы. Предполагается, что такие объекты не должны участвовать ни в какой обработке. Внешняя сущность обозначается на диаграмме, как показано на рис. 1.4.
Заказчик
Рис. 1.4. Изображение внешней сущности на диаграммах
В качестве примера D FD рассмотрим верхний уровень функциональной модели компании, занимающейся распределением товаров по заказам (рис. 1.5). Заказы подвергаются входному контролю и сортировке. Если заказ не отвечает номенклатуре товаров или оформлен неправильно, то он аннули руется с соответствующим уведомлением заказчика. Если заказ не аннулиро ван, то определяется, имеется ли на складе соответствующий товар. В случае положительного ответа выписывается счет к оплате и предъявляется заказ чику, при поступлении платежа товар отправляется заказчику. Если заказ не обеспечен складскими запасами, то отправляется заявка на товар произво дителю. После поступления требуемого товара на склад компании заказ ста новится обеспеченным и повторяет вышеописанный маршрут.
Рис. 1.5. Пример диаграммы потоков данных
При детализации процессов часто возникает необходимость в детализа ции (структуризации) потоков данных. Например, на диаграмме верхнего уровня может находиться один информационный поток, а при детализации на следующих уровнях иерархии может выясниться, что данный поток есть результат слияния нескольких потоков. Такое слияние осуществляется через информационный канал. Логически информационный канал есть среда пере дачи информации. Он может реализоваться в виде, например, курьерской службы, почты, магистрали или шины данных и т.п.
Обозначающий канал символ имеет поле имени и поле номера копии, как показано на рис. 1.6.
Гик1 Внутренний документооборот
D
Рис. 1.6. Изображение информационного канала на диаграммах
Как уже отмечалось, декомпозиция DFD осуществляется на основе процес сов: каждый процесс может раскрываться с помощью DFD нижнего уровня.
Важную специфическую роль в модели играет специальный вид DFD - контекстная диаграмма, моделирующая систему наиболее общим образом. Контекстная диаграмма отражает интерфейс системы с внешним миром, а именно информационные потоки между системой и внешними сущностями, с которыми она должна быть связана. Она идентифицирует эти внешние сущ
ности, а также, как правило, единственный процесс, отражающий главную цель или природу системы, насколько это возможно. И хотя контекстная диаграмма выглядит тривиальной, несомненная ее полезность заключается в том, что она устанавливает границы анализируемой системы.
D FD первого уровня строится как декомпозиция процесса, который при сутствует на контекстной диаграмме. Построенная диаграмма первого уров ня также имеет множество процессов, которые в свою очередь могут быть декомпозированы в D FD нижнего уровня. Таким образом строится иерар хия D FD с контекстной диаграммой в корне дерева. Этот процесс декомпо зиции продолжается до тех пор, пока процессы могут быть эффективно опи саны с помощью коротких (до одной страницы) спецификаций процессов (мини-спецификаций).
Мини-спецификация (МС) используется для описания функционирования процесса в случае отсутствия необходимости детализировать его с помощью DFD. Фактически МС представляют собой алгоритмы описания задач, вы полняемых процессами: множество всех МС является полной спецификаци ей системы. МС содержат номер и (или) имя процесса, списки входных и вы ходных данных и тело (описание) процесса, являющееся спецификацией ал горитма, или операции, трансформирующей входные потоки данных в выходные.
Решение о завершении детализации процесса с помощью D FD и исполь зовании для этой цели МС принимается исходя из следующих критериев:
•наличия у процесса относительно небольшого количества входных и выходных потоков данных;
•возможности описания преобразования данных процессом в виде по следовательного алгоритма;
•выполнения процессом единственной логической функции преобразо вания входной информации в выходную;
•возможности описания логики процесса при помощи МС небольшого объема.
МС должны удовлетворять следующим требованиям:
•для каждого процесса нижнего уровня должна существовать одна и толь ко одна спецификация;
•спецификация должна определять способ преобразования входных по токов в выходные;
•нет необходимости (на данном этапе) определять метод реализации этого преобразования;
•спецификация должна стремиться к ограничению избыточности - не следует переопределять то, что уже было определено на диаграмме;
•набор конструкций для построения спецификации должен быть про стым и понятным.
Одним из наиболее интенсивно и часто применяемых методов задания МС является структурированный естественный язык, обеспечивающий чи таемое, достаточно строгое описание спецификаций процессов. Он представ ляет собой разумное сочетание строгости языка программирования и читае мости естественного языка и состоит из подмножества слов, организован ных в определенные логические структуры.
В состав языка входят следующие основные символы:
•глаголы, ориентированные на действие и применяемые к объектам;
•термины, определенные на любой стадии проекта;
•предлоги и союзы, используемые в логических отношениях;
•общеупотребительные математические, физические и технические тер мины;
•арифметические уравнения;
•таблицы, диаграммы, графы и т.п.;
•комментарии.
При использовании структурированного естественного языка приняты следующие соглашения:
•логика процесса выражается в виде комбинации последовательных кон струкций, конструкций выбора и итераций;
•глаголы должны быть активными, недвусмысленными и ориентирован ными на целевое действие (заполнить, вычислить, извлечь, а не модернизиро вать, обработать);
•логика процесса должна быть выражена четко и недвусмысленно. Ниже приведен пример МС процесса «Покупка лотерейных билетов».
Для каждого клиента выполняются:
1)проверка наличия требуемого числа билетов лотереи;
2)заполнение приходного кассового ордера (Форма 53) и занесение его в накопи тель ДОКУМЕНТЫ ДНЯ;
3)прием наличных денег и занесение операции в накопитель БАНКОВСКИЕ ОПЕ РАЦИИ (при этом осуществляются проводки: Д-т 54, К-т 207);
4 ) вы дача билет ов лотереи.
При построении иерархии DFD каждый процесс более низкого уровня необходимо соотнести с процессом верхнего уровня. Обычно для этой цели используются структурированные номера процессов. Так, например, если мы детализируем процесс номер 2 на диаграмме первого уровня, раскрывая его с помощью DFD, содержащей три процесса, то их номера будут иметь следующий вид: 2.1, 2.2 и 2.3. При необходимости можно перейти на следу ющий уровень, т.е. для процесса 2.2 получим 2.2.1, 2.2.2. и т.д.
Кроме этого при детализации должно соблюдаться правило балансиров ки - детализирующая диаграмма в качестве внешних адресатов и адресантов данных может иметь только те компоненты (процессы, внешние сущности, накопители и информационные каналы), с которыми детализируемый про цесс имеет связи, обозначенные потоками данных.
Помимо описанной выше функциональной декомпозиции, D FD -техно логии регламентируют и декомпозицию данных.
Индивидуальные данные в системе часто являются независимыми. Одна ко иногда необходимо иметь дело с несколькими независимыми данными одновременно. Например, в системе имеются потоки ЯБЛОКИ, АПЕЛЬСИ Н Ы и ГРУШИ. Эти потоки могут быть сгруппированы с помощью введения нового потока ФРУКТЫ. Для этого необходимо определить формально по ток ФРУКТЫ как состоящий из нескольких элементов-потомков. Такое оп-
2 “ 1599
1 7
ределение задается в словаре данных. В свою очередь поток ФРУКТЫ сам может содержаться в потоке-предке ЕДА вместе с потоками ОВОЩИ, МЯСО и др. Такие потоки, объединяющие несколько потоков, получили название групповых. При обратной операции (расщепление потоков на подпотоки) также необходимо формально определить подпотоки в словаре данных.
Важно понимать, что точные определения потоков содержатся в словаре данных, а не на диаграммах. Например, на диаграмме может иметься поток X, расщепляемый на подпотоки Y и Z. Однако это вовсе не означает, что соответствующее определение в словаре данных обязательно должно быть X = Y + Z. Это определение может быть следующим: X = А + В + С; Y = A + В; Z = В + С.
Фактически словарь данных представляет собой определенным образом орга низованный список всех потоков данных системы с их точными определения ми, что дает возможность различным категориям пользователей иметь общее понимание структуры и содержимого всех входных и выходных потоков.
Для упрощения бизнес-системы и достижения ясности и понятности ее компонентов и их взаимодействий при построении иерархии D FD целесо образно пользоваться следующими рекомендациями.
1. Размещать на каждой диаграмме от 3 до 6-7 процессов. Верхняя гра ница соответствует человеческим возможностям одновременного восприя тия и понимания структуры сложной системы с множеством внутренних свя зей, нижняя граница выбрана по соображениям здравого смысла: нет необ ходимости детализировать процесс диаграммой, содержащей всего один или два процесса.
2. Не загромождать диаграммы несущественными на данном уровне де талями.
3. Декомпозицию потоков данных осуществлять параллельно с деком позицией процессов; эти две работы должны выполняться одновременно, а не одна после завершения другой.
4. Выбирать ясные, отражающие суть дела имена процессов и потоков для улучшения понимаемости диаграмм, при этом стараться не использо вать аббревиатуры.
1.2.2. Моделирование поведения системы
D FD -технологии обеспечивают построение моделей поведе ния системы за счет расширения базового набора символов диаграммы по токов данных (путем включения так называемых “управляющих” символов)
ивведения диаграмм переходов состояний в качестве собственно специфи каций управления.
Вкачестве базовых управляющих объектов используются управляющие потоки и управляющие процессы, изображаемые на диаграммах так же, как
иобычные потоки и процессы, но с использованием штриховых, а не сплош ных ограничивающих линий.
Управляющий поток представляет собой «трубопровод», через который проходит управляющая информация. Его имя не должно содержать глаго лов, а только существительные и прилагательные. Обычно управляющий поток имеет дискретное, а не непрерывное значение. Это может быть, напри мер, сигнал, представляющий состояние или вид операции.
Управляющий процесс представляет собой интерфейс между D FD и специ фикациями управления, собственно моделирующими и документирующими аспекты поведения системы. Его имя указывает на тип управляющей деятель ности, вырабатываемой спецификацией. Фактически управляющий процесс представляет собой преобразователь входных управляющих потоков в вы ходные управляющие потоки; при этом точное описание этого преобразова ния должно задаваться в спецификации управления. Логически управляю щий процесс есть некий командный пункт, реагирующий на изменения вне шних условий, передаваемые ему с помощью управляющих потоков, и продуцирующий в соответствии со своей внутренней логикой выполняемые процессами команды.
Спецификации управления предназначены для моделирования и докумен тирования, поведенческих аспектов систем, они позволяют осуществлять де композицию управляющих процессов и описывают отношения между вход ными и выходными управляющими потоками на детализируемом управляю щем процессе.
Для этой цели в D FD -технологиях обычно используются диаграммы пе реходов состояний (STD), содержащие следующие объекты.
Состояние - объект, рассматривающийся как условие устойчивости для системы. Находясь в определенном состоянии, система имеет достаточно информации о ее прошлой истории, чтобы определить очередное состояние в зависимости от текущих входных событий. Имя состояния должно отра жать реальную ситуацию, в которой находится система, например НАГРЕ ВАНИЕ, ОХЛАЖ ДЕНИЕ и т.п. Особую роль играет начальное состояние -
узел STD, являющийся стартовой точкой для начала функционирования си стемы. STD имеет ровно одно начальное состояние, соответствующее состо янию системы после ее инсталляции, но перед началом реальной обработки, а также любое (конечное) число завершающих состояний.
Переход - объект, определяющий перемещение моделируемой системы из одного состояния в другое. При этом имя перехода идентифицирует усло вие, являющееся причиной перехода и управляющее им. Это условие обычно продуцирует управляющий поток (сигнал), возникающий как во внешнем мире, так и внутри моделируемой системы (например, СЧЕТЧИК-999 или КНОПКА НАЖА ТА). Таким образом, условие представляет собой событие (или события), вызывающее переход и идентифицируемое именем перехода. Кроме условия с переходом может связываться действие или ряд действий, выполняющихся, когда переход имеет место.
Фактически условие есть некоторое внешнее или внутреннее событие, которое система способна обнаружить и на которое она должна отреагиро вать определенным образом, изменяя свое состояние. При изменении состо яния система обычно выполняет одно или более действий, представляющих собой отклик, посылаемый во внешнее окружение, или вычисление, резуль-
2*
таты которого запоминаются в системе (обычно в накопителях данных на DFD) для того, чтобы обеспечить реакцию на некоторые из планируемых в будущем событий.
На STD состояния представляются узлами, а переходы - дугами (рис. 1.7). Условия идентифицируются именем перехода и возбуждают выполне ние перехода. Действия привязываются к переходам и записываются под со ответствующим условием. Начальное состояние на диаграмме должно иметь входной переход, изображаемый потоком из подразумеваемого стартового узла (иногда этот стартовый узел изображается небольшим квадратом и при вязывается к входному состоянию).
Начальное состояние
Состояшие 1
Условие
Действие
Состояние 2
Рис. 1.7. Символы STD
1.2.3. Информационная модель системы
D F D -технологии предполагаю т использование диаграмм «сущность-связь» (ERD) для разработки информационных моделей и обес печения стандартного способа определения данных и отношений между ними. Фактически с помощью ERD осуществляется детализация накопителей дан ных D FD -диаграммы, а также документируются информационные аспекты бизнес-системы, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их связей с други ми объектами (отношений).