Что отображается на функциональной модели системы

Что отображается на функциональной модели системы

6.8. Назначение и состав DFD

При построении функциональной модели системы альтернативой методологии IDEF0 является методология диаграмм потоков данных (Data Flow Diagrams, DFD). В отличие от IDEF0, предназначенной для проектирования систем вообще, DFD предназначена для проектирования информационных систем. Ориентированность этой методологии на проектирование автоматизированных систем делает ее удобным и более выгодным инструментом при построении функциональной модели «TO-BE».

Как и в IDEF0, основу методологии DFD составляет графический язык описания процессов. Авторами одной из первых графических нотаций DFD (1979 г.) стали Эд Йордан (Yourdon) и Том де Марко (DeMarko). В настоящее время наиболее распространенной является нотация Гейна-Сарсона (Gane-Sarson).

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

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

6.9. Элементы графической нотации DFD

Согласно DFD источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации [17, 19].

При построении диаграмм различают элементы графической нотации, представленные в табл. 6.1.

Таблица 6.1. Элементы графической нотации DFD

Далее в примерах будет использоваться нотация Гейна-Сарсона.

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

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

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

Процесс (в IDEF0 – функция, работа) представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом.

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

— «Ввести сведения о клиентах»;

— «Рассчитать допускаемую скорость»;

— «Сформировать ведомость допускаемых скоростей»

Номер процесса служит для его идентификации и ставится с учетом декомпозиции. В отличие от IDEF0 вложенность процессов обозначается через точку (например, в IDEF0 – «236», в DFD – «2.3.6»).

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

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

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

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

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

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

6.10. Правила и рекомендации построения DFD

Правила и рекомендации построения модели DFD в основном совпадают с принятыми в IDEF0. Часть из них приведена в подразд. 6.9.

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

Каждый накопитель данных также должен иметь как минимум один входящий и один выходящий поток. Наличие только входящих потоков в накопитель означает, что информация накапливается, но не используется.

Наличие только выходящих потоков из накопителя также является ошибкой. Прежде чем использовать данные из накопителя, они должны там появиться в результате работы какого-либо процесса (подсистемы, внешней сущности). Исключением из правил считается случай, когда накопитель является внешней сущностью. Тогда допускается наличие либо только входящих стрелок, либо только выходящих стрелок (см. рис. 6.23, накопитель «БД АРМ-П или СБД-П»).

6.11. Пример построения модели DFD для системы определения допускаемых скоростей

Описание задачи приведено в подразд. 6.6.

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

Рис. 6.23. Контекстная диаграмма системы определения допускаемых скоростей (методология DFD)

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

В то же время в системе оставлена возможность ее ручного ввода и корректировки. Несмотря на то, что БД АРМ-П или СБД-П по отношению к системе являются внешними сущностями, они, в целях лучшего восприятия, показаны в виде накопителя данных.

Дальнейший процесс проектирования состоит в построении диаграмм декомпозиции, которые строятся (показывают устройство) только для процессов или подсистем (систем).

Диаграмма декомпозиции первого уровня проектируемой системы приведена на следующем рисунке.

Рис. 6.24. Диаграмма декомпозиции первого уровня (методология DFD)

На этом рисунке у некоторых потоков данных, связанных с накопителями, отсутствуют имена. Это позволяет устранить дублирование надписей и, как следствие, уменьшить насыщенность диаграммы.

При построении диаграммы декомпозиции блоки системы в одних случаях показаны как процессы (имя начинается с глагола), в других – как подсистемы (имя начинается со слова «подсистема»). Это сделано в целях иллюстрации правил именования блоков. В то же время декомпозицию системы можно было бы представить, либо используя только процессы, либо только подсистемы.

Контекстная диаграмма и диаграмма декомпозиции выполнены с использованием BPwin 4.0.

Решение о завершении детализации процесса и использовании миниспецификации принимается проектировщиком исходя из следующих критериев:

— наличия у процесса относительно небольшого количества входных и выходных потоков данных (2–3 потока);

— возможности описания процессов в виде простого алгоритма;

— возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20–30 строк).

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

6.12. Расширения DFD для систем реального времени

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

Квазинепрерывный поток (лат. quasi – как будто, якобы) – поток данных, непрерывный во времени. Отображается линией с двумя стрелками на конце.

Рис. 6.25. Квазинепрерывный поток

Управляющий процесс – процесс, формирующий сигналы управления на выходе.

Рис. 6.26. Управляющий процесс

Управляющий поток – управляющая информация, запускающая процесс (подсистему) или изменяющая ход его выполнения.

Рис. 6.27. Управляющий поток

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

Накопитель управлений – накопитель управляющих потоков.

Рис. 6.28. Накопитель управления

На рис. 6.29 показан пример использования новых элементов на DFD.

Рис. 6.29. Фрагмент DFD системы реального времени

Вопросы для самопроверки

2. Дайте краткую характеристику моделей AS-IS, «TO-BE» и «SHOULD-BE».

13. Перечислите отличия методологии IDEF0 от DFD.

Источник

Основные методологии обследования организаций. Стандарт IDEF0.

Научитесь видеть и понимать функциональную структуру своего бизнеса!

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

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

В рамках этой статьи мы рассмотрим наиболее часто используемую методологию функционального моделирования IDEF0.

История возникновения стандарта IDEF0

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). Несколько лет назад в России небольшим тиражом вышла одноименная книга, посвящанная описанию основных принципов построения SADT-диаграмм. Исторически, IDEF0, как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing) и была предложена департаментом Военно-Воздушных Сил США. Собственно семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=ICAM DEFinition). В процессе практической реализации, участники программы ICAM столкнулись с необходимостью разработки новых методов анализа процессов взаимодействия в промышленных системах. При этом кроме усовершенствованного набора функций для описания бизнес-процессов, одним из требований к новому стандарту было наличие эффективной методологии взаимодействия в рамках “аналитик-специалист”. Другими словами, новый метод должен был обеспечить групповую работу над созданием модели, с непосредственным участием всех аналитиков и специалистов, занятых в рамках проекта.

В результате поиска соответствующих решений родилась методология функционального моделирования IDEF0. C 1981 года стандарт IDEF0 претерпел несколько незначительных изменения, в основном ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом По Стандарам и Технологиям США (NIST).

Основные элементы и понятия IDEF0

Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия:

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

Рисунок 1. Функциональный блок.

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

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

При построении IDEF0 – диаграмм важно правильно отделять входящие интерфейсные дуги от управляющих, что часто бывает непросто. К примеру, на рисунке 2 изображен функциональный блок “Обработать заготовку”.

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

Рисунок 2.

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

Рисунок 3.

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

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

Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором “А-0”.

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

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

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

Рисунок 4. Декомпозиция функциональных блоков.

Принципы ограничения сложности IDEF0-диаграмм

Обычно IDEF0-модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми, в соответствующем стандарте приняты соответствующие ограничения сложности:

Разумеется, строго следовать этим ограничениям вовсе необязательно, однако, как показывает опыт, они являются весьма практичными в реальной работе.

Дисциплина групповой работы над разработкой IDEF0-модели

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

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

Особенности национальной практики применения функционального моделирования средствами IDEF0

В последние годы интерес в России к методологиям семейства IDEF неуклонно растет. Это я постоянно наблюдаю, просматривая статистику обращений к своей персональной web-странице (http://consulting.psi.ru), на которой кратко описаны основные принципы этих стандартов. При этом интерес к таким стандартам, как IDEF3-5 я бы назвал теоретическим, а к IDEF0 вполне практически обоснованным. Собственно говоря, первые Case-средства, позволяющие строить DFD и IDEF0 диаграммы появились на российком рынке еще в 1996 году, одновременно с выходом популярной книги по принципам моделирования в стандартах SADT.

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

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

При проведении сложных проектов обследования предприятий, разработка моделей в стандарте IDEF0 позволяет наглядно и эффективно отобразить весь механизм деятельности предприятия в нужном разрезе. Однако самое главное – это возможность коллективной работы, которую предоставляет IDEF0. В моей практической деятельности было достаточно много случаев, когда построение модели осуществлялось с прямой помощью сотрудников различных подразделений. При этом, консультант за достаточно короткое время объяснял им основные принципы IDEF0 и обучал работе с соответствующим прикладным программным обеспечением. В результате, сотрудники различных отделов создавали IDEF-диаграммы деятельности своего функционального подразделения, которые должны были ответить на следующие вопросы:

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

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

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

Источник