<<
>>

Иерархическая функциональная модель

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

Главная цель таких средств - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

Диаграммы потоков данных известны очень давно. В фольклоре упоминается следующий пример использования DFD для реорганизации переполненного клерками офиса, относящийся к 1920-м годам. Осуществлявший реорганизацию консультант обозначил кружком каждого клерка, а стрелкой - каждый документ, передаваемый между ними. Используя такую диаграмму, он предложил схему реорганизации, в соответствии с которой двое клерков, интенсивно обменивающихся большим количеством документов, были посажены рядом, а клерки с малым взаимодействием были посажены на большом расстоянии. Так родилась первая модель, представляющая собой потоковую диаграмму, - предшественник DFD.

Диаграммы потоков данных чрезвычайно просты, наглядны и понятны. Базовая их нотация включает всего четыре рассматриваемых ниже объекта. Поток данных является механизмом, использующимся для моделирования передачи информации (или даже физических компонентов) из одной части системы в другую. Важность этого объекта очевидна: он дает название целому инструменту. Потоки на диаграммах обычно изображаются именованными стрелками (при этом имя потока отражает его содержимое), ориентация которых указывает направление движения информации. Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Это имя должно содержать глагол в неопределенной форме с последующим дополнением (например, ВЫЧИСЛИТЬ МАКСИМАЛЬНУЮ ВЫСОТУ) или отглагольное существительное (ВЫЧИСЛЕНИЕ МАКСИМАЛЬНОЙ ВЫСОТЫ).

Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели. Процессы обозначаются на диаграмме, как показано на рис. 1.2; символ процесса включает три разделенных горизонтальными чертами поля: верхнее поле содержит номер процесса и аббревиатуру детализирующего объекта (КД - контекстная диаграмма, ДПД - диаграмма потоков данных, МС - мини-спецификация); среднее поле содержит имя процесса; нижнее поле содержит имя исполнителя процесса (идентификатор подразделения, должности, механизма и т.п.).

s              \

-I ДПД

Начисление заработной платы

^ Бухгалтерия              t

Рис. 1.2. Изображение процесса на диаграммах Накопитель данных позволяет на определенных участках определять данные, которые будут сохраняться вне процессов. Фактически накопитель представляет «срезы» потоков данных во времени. Информация, которую он содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя накопителя должно идентифицировать его содержимое и быть существительным во множественном числе.

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

Накопитель данных обозначается, как показано на рис. 1.3. Каждый накопитель данных идентифицируется для ссылки буквами «БД» и числом в киадраге с левой стороны, определяющим его номер. Имеется возможность создавать копии накопителя, в этом случае номер соответствующей копии фиксируется под идентификатором накопителя.

БД1 Договора

Рис. 1.3. Изображение накопителя на диаграммах

Когда процесс сохраняет данные, то стрелка потока данных направлена в накопитель данных, и, наоборот, когда доступ в накопитель данных осуществляется для чтения, стрелка потока данных направлена в процесс.

Внешняя сущность представляет сущность вне контекста системы, являющуюся источником или приемником системных данных, например ЗАКАЗЧИК, ПОСТАВЩИК, СКЛАД ТОВАРОВ. Определение некоторого объекта в качестве внешней сущности указывает на то, что он находится за пределами анализируемой системы. Предполагается, что такие объекты не должны участвовать ни в какой обработке. Внешняя сущность обозначается на диаграмме, как показано на рис. 1.4.

Заказчик

Рис. 1.4. Изображение внешней сущности на диаграммах

В качестве примера DFD рассмотрим верхний уровень функциональной модели компании, занимающейся распределением товаров по заказам (рис. . Заказы подвергаются входному контролю и сортировке. Если заказ не отвечает номенклатуре товаров или оформлен неправильно, то он аннулируется с соответствующим уведомлением заказчика. Если заказ не аннулирован, то определяется, имеется ли на складе соответствующий товар. В случае положительного ответа выписывается счет к оплате и предъявляется заказчику, при поступлении платежа товар отправляется заказчику. Если заказ не обеспечен складскими запасами, то отправляется заявка на товар производителю. После поступления требуемого товара на склад компании заказ становится обеспеченным и повторяет вышеописанный маршрут.

Рис. 1.5. Пример диаграммы потоков данных

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

Обозначающий канал символ имеет поле имени и поле номера копии, как показано на рис.

1.6.

ГиК1 Внутренний документооборот              J

Рис. 1.6. Изображение информационного канала на диаграммах

Как уже отмечалось, декомпозиция DFD осуществляется на основе процессов: каждый процесс может раскрываться с помощью DFD нижнего уровня.

Важную специфическую роль в модели играет специальный вид DFD - контекстная диаграмма, моделирующая систему наиболее общим образом. Контекстная диаграмма отражает интерфейс системы с внешним миром, а именно информационные потоки между системой и внешними сущностями, с которыми она должна быть связана. Она идентифицирует эти внешние сущ

ности, а также, как правило, единственный процесс, отражающий главную цель или природу системы, насколько это возможно. И хотя контекстная диаграмма выглядит тривиальной, несомненная ее полезность заключается в том, что она устанавливает границы анализируемой системы.

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

Мини-спецификация (МС) используется для описания функционирования процесса в случае отсутствия необходимости детализировать его с помощью DFD. Фактически МС представляют собой алгоритмы описания задач, выполняемых процессами: множество всех МС является полной спецификацией системы. МС содержат номер и (или) имя процесса, списки входных и выходных данных и тело (описание) процесса, являющееся спецификацией алгоритма, или операции, трансформирующей входные потоки данных в выходные.

Решение о завершении детализации процесса с помощью DFD и использовании для этой цели МС принимается исходя из следующих критериев: наличия у процесса относительно небольшого количества входных и выходных потоков данных; возможности описания преобразования данных процессом в виде последовательного алгоритма; выполнения процессом единственной логической функции преобразования входной информации в выходную; возможности описания логики процесса при помощи МС небольшого объема.

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

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

В состав языка входят следующие основные символы: глаголы, ориентированные на действие и применяемые к объектам; термины, определенные на любой стадии проекта; предлоги и союзы, используемые в логических отношениях; общеупотребительные математические, физические и технические термины; арифметические уравнения; таблицы, диаграммы, графы и т.п.; комментарии.

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

Ниже приведен пример МС процесса «Покупка лотерейных билетов».

Для каждого клиента выполняются: проверка наличия требуемого числа билетов лотереи; заполнение приходного кассового ордера (Форма 53) и занесение его в накопитель ДОКУМЕНТЫ ДНЯ; прием наличных денег и занесение операции в накопитель БАНКОВСКИЕ ОПЕРАЦИИ (при этом осуществляются проводки: Д-т 54, К-т 207); выдача билетов лотереи.

При построении иерархии DFD каждый процесс более низкого уровня необходимо соотнести с процессом верхнего уровня. Обычно для этой цели используются структурированные номера процессов. Так, например, если мы детализируем процесс номер 2 на диаграмме первого уровня, раскрывая его с помощью DFD, содержащей три процесса, то их номера будут иметь следующий вид: 2.1, 2.2 и 2.3. При необходимости можно перейти на следующий уровень, т.е. для процесса 2.2 получим 2.2.1, 2.2.2. и т.д.

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

Помимо описанной выше функциональной декомпозиции, DFD-технологии регламентируют и декомпозицию данных.

Индивидуальные данные в системе часто являются независимыми. Однако иногда необходимо иметь дело с несколькими независимыми данными одновременно. Например, в системе имеются потоки ЯБЛОКИ, АПЕЛЬСИНЫ и ГРУШИ. Эти потоки могут быть сгруппированы с помощью введения нового потока ФРУКТЫ. Для этого необходимо определить формально поток ФРУКТЫ как состоящий из нескольких элементов-потомков. Такое оп-

2—1599

ределение задается в словаре данных. В свою очередь поток ФРУКТЫ сам может содержаться в потоке-предке ЕДА вместе с потоками ОВОЩИ, МЯСО и др. Такие потоки, объединяющие несколько потоков, получили название групповых. При обратной операции (расщепление потоков на подпотоки) также необходимо формально определить подпотоки в словаре данных.

Важно понимать, что точные определения потоков содержатся в словаре данных, а не на диаграммах. Например, на диаграмме может иметься поток X, расщепляемый на подпотоки Y и Z. Однако это вовсе не означает, что соответствующее определение в словаре данных обязательно должно быть X- У + Z. Это определение может быть следующим: X-A+B + C;Y = A+B; Z -В + С.

Фактически словарь данных представляет собой определенным образом организованный список всех потоков данных системы с их точными определениями, что дает возможность различным категориям пользователей иметь общее понимание структуры и содержимого всех входных и выходных потоков.

Для упрощения бизнес-системы и достижения ясности и понятности ее компонентов и их взаимодействий при построении иерархии DFD целесообразно пользоваться следующими рекомендациями. Размещать на каждой диаграмме от 3 до 6-7 процессов. Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса. Не загромождать диаграммы несущественными на данном уровне деталями. Декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов; эти две работы должны выполняться одновременно, а не одна после завершения другой. Выбирать ясные, отражающие суть дела имена процессов и потоков для улучшения понимаемости диаграмм, при этом стараться не использовать аббревиатуры.

<< | >>
Источник: Калашян А.Н., Калянов Г.Н.. Структурные модели бизнеса: DFD-технологии. 2003

Еще по теме Иерархическая функциональная модель:

  1. Язык описания модели во многом определяется спецификой самого оригинала
  2. 3. Основные черты советской модели экономики
  3. ГЛАВА III. МОДЕЛИ СОЦИОТЕХНИЧЕСКОЙ СИСТЕМЫ
  4. Теоретические модели политической органиэации: эволюция и типы
  5. Стратегия и иерархические уровни в механизме государственного управления
  6. Процесс принятия государственных решений: модели, способы и основные этапы
  7. ТРАДИЦИОННАЯ ФИНАНСОВАЯ МОДЕЛЬ БУХГАЛТЕРСКОГО УЧЕТА
  8. 2. Влияние федеративного устройства государства на организационную и функциональную структуру государственного управления
  9. Системно-структурные методы и модели
  10. Общая характеристика методов и моделей эффективного принятия решений
  11. ЦЕНТРАЛИЗАЦИЯ КАК МОДЕЛЬ ФУНКЦИОНИРОВАНИЯ СТРАХОВОЙ КОМПАНИИ
  12. В. З. Предварительная информационная модель ARIS
  13. Иерархическая функциональная модель
  14. Концептуальные модели данных
- Cвязи с общественностью - PR - Бренд-маркетинг - Деловая коммуникация - Деловое общение и этикет - Делопроизводство - Интернет - маркетинг - Информационные технологии - Консалтинг - Контроллинг - Корпоративное управление - Культура организации - Лидерство - Литература по маркетингу - Логистика - Маркетинг в бизнесе - Маркетинг в отраслях - Маркетинг на предприятии - Маркетинговые коммуникации - Международный маркетинг и менеджмент - Менеджмент - Менеджмент организации - Менеджмент руководителей - Моделирование бизнес-процессов - Мотивация - Организационное поведение - Основы маркетинга - Производственный менеджмент - Реклама - Сбалансированная система показателей - Сетевой маркетинг - Стратегический менеджмент - Тайм-менеджмент - Телекоммуникации - Теория организации - Товароведение и экспертиза товаров - Управление бизнес-процессами - Управление знаниями - Управление инновационными проектами - Управление качеством товара - Управление персоналом - Управление продажами - Управление проектами - Управленческие решения -
Яндекс.Метрика