От функционального моделирования к потокам работ
Ранее мы рассмотрели диаграммы IDEF0. Фактически мы получили инструмент для поддержки следующей цепочки действий: вначале мы выделяем иерархию функций, существующую в компании, а затем, используя IDEF0, описываем взаимосвязи между этими функциями.
Функции — это элементы деятельности, постоянно присутствующие в работе компании. «Отслеживание расписания» выполняется постоянно, «Сборка компьютеров» выполняется постоянно. Однако все эти функции реализуются через действия, которые разворачиваются во времени: когда-то начинаются и когда-то заканчиваются. IDEF0 не позволяет это описать. Зато мы можем описать, как функции связаны между собой: где появляются планы, которые нужно реализовать, где — подготовленные изделия для тестирования. Мы можем детализировать информацию за счёт разветвления стрелок, показывая, например, какие подразделения участвуют в выполнении тех или иных функций.
Эти связи нужны для того, чтобы затем понять, какой информацией они будут сопровождаться. Проектирование информационной системы — это, по сути, выбор информационных потоков, которые необходимо передавать между действиями для поддержки бизнеса.
Диаграммы IDEF3: описание последовательности работ
Чтобы показать, как функции исполняются во времени, используется другой стандарт —
IDEF3. На этих диаграммах тоже есть прямоугольники и стрелки. Смысл прямоугольников похож на IDEF0, но смысл стрелок совершенно другой. Прямоугольники здесь отображают
единицы работы (Unit of Work) — блоки действий, которые существуют во времени и поддерживают выполнение функции. Они начинаются и заканчиваются в определённые моменты, а также могут декомпозироваться на более мелкие элементы.
Единицы работы соединяются тремя видами стрелок:
1.
Сплошная стрелка означает
отношение временного предшествования. Работа слева от стрелки должна быть полностью завершена до того, как начнётся работа справа.
2.
Двойная стрелка обозначает
объектный поток. Она показывает, какие материальные или информационные объекты передаются между действиями (документы, деньги, материалы). Она не определяет последовательность, а лишь фиксирует факт передачи.
3.
Пунктирная стрелка обозначает
нечёткое отношение. Она используется, когда работы выполняются внахлёст. Например, работа слева не обязательно должна быть полностью закончена к началу работы справа.
Пример. Первая работа — выявление изменений, которые необходимо внести в план. Вторая — внесение изменений в план. Если их соединяет сплошная стрелка, это означает, что мы сначала собираем все изменения, а потом вносим их. Если же используется пунктирная стрелка, это означает, что изменения вносятся по мере их поступления: первая и вторая работы какое-то время выполняются параллельно.
Логические соединения (Junctions)
Кроме стрелок, на диаграммах IDEF3 используются
соединения (Junctions), которые бывают двух видов:
И и
ИЛИ. Соединения бывают
асинхронными (действия могут начинаться или заканчиваться в произвольное время) и
синхронными (действия обязаны начаться или закончиться одновременно).
Существует также
исключающее ИЛИ (XOR). Если несколько действий соединяются функцией ИЛИ, может выполняться любая их комбинация. Если используется исключающее ИЛИ, выбор единственный: может выполняться только одно действие из всего набора.
На правильно построенных диаграммах соединения появляются парами:
разворачивающее соединение и соответствующее ему
сворачивающее. Если пары нет, это сигнал о возможной ошибке в модели.
Пример. Рассмотрим функцию «сборка настольного компьютера». После установки материнской платы и винчестера стоит соединение типа ИЛИ. В зависимости от заказа, мы можем установить флоппи-дисковод, CD-ROM или и то, и другое с модемом. После выполнения этих работ сворачивающее соединение ИЛИ показывает, что все выбранные работы должны быть завершены до начала следующей, и позволяет избежать нагромождения стрелок. Далее обязательное действие — инсталляция операционной системы. После неё стоит исключающее ИЛИ, так как мы либо устанавливаем дополнительное ПО, либо завершаем работу.
На диаграмме также могут присутствовать
указатели (Referents) — квадратики, подсоединяемые к единицам работы линиями. Они позволяют вынести дополнительную информацию (например, объединить несколько действий под общим названием) или описать процедуру зацикливания без рисования явной обратной связи.
Диаграммы DFD: моделирование потоков данных
Для построения информационной системы одного описания последовательности работ недостаточно. Необходимо описать потоки данных, циркулирующие при выполнении деятельности. В стандартах IDEF0 и IDEF3 таких средств нет. Они появляются в
диаграммах потоков данных (Data Flow Diagrams,
DFD).
На DFD-диаграммах присутствуют:
•
Процессы — прямоугольники со скруглёнными углами. В отличие от IDEF0 и IDEF3, здесь можно указывать не только действие, но и конкретное подразделение, которое его исполняет (например, «Отдел кадров»).
•
Стрелки — отражают только передачу информации (
потоки данных), а не последовательность или порядок. Потоки данных, как и в других нотациях, могут разветвляться для уточнения состава информации (например, поток «Адрес клиента» может разбиваться на индекс, город и улицу).
•
Внешние сущности (External Entities) — прямоугольники с тенью, которые обозначают объекты, не относящиеся к описываемой системе (например, клиент, банк).
•
Хранилища данных (Data Stores) — вытянутые прямоугольники. Это может быть не только база данных, но и картотека, папка с документами или склад. На этапе анализа важно лишь то, что туда можно что-то поместить и оттуда извлечь.
Правила построения DFD-диаграмм
1.
Одновременная декомпозиция. Декомпозицию потоков данных и процессов (IDEF0) следует осуществлять одновременно. Если разнести эти работы по времени, можно столкнуться с тем, что предыдущее разбиение функций выполнено некорректно, и всю работу придётся переделывать.
2.
Несколько процессов на контекстной диаграмме. В отличие от IDEF0, на контекстной DFD-диаграмме можно отображать несколько основных процессов, если это упрощает понимание сложных потоков данных.
3.
Критерии завершения декомпозиции. Процесс можно не детализировать дальше, если:
o У процесса есть два-три входных/выходных потока.
o Процесс реализует единственную логическую функцию.
o Описание логики процесса укладывается в 20–30 строк.
o Для процесса можно написать лишь одну спецификацию. Если приходится писать «процесс выполняется так-то, или, при других условиях, вот так-то» — это ещё не конец, и нужна дальнейшая декомпозиция.
ER-диаграммы: детальное описание данных
После описания потоков данных необходимо детально определить, что входит в эти потоки и что хранится в хранилищах. Для этого используются
диаграммы «сущность-связь» (Entity-Relationship Diagrams,
ERD). Они позволяют описать информационные характеристики объектов, присутствующих в деятельности.
На ER-диаграммах отображаются
сущности (объекты) и
связи между ними. Для каждой сущности определяются
атрибуты (характеристики), которые могут быть разных типов: строка, число, дата, деньги и т. д. Атрибуты бывают
ключевыми (уникально идентифицирующими объект) и
неключевыми, а также
обязательными и
необязательными.
Существуют различные нотации для ER-диаграмм:
•
Нотация Баркера (Crow's Foot, «вороньи лапки») — позволяет наглядно показать тип связи «один-ко-многим».
•
Нотация Чена — также показывает типы связей и их кардинальность, но использует другие графические обозначения.
Пример. В страховой компании есть сущность «Автомобиль» и сущность «Полис». У одного автомобиля может быть несколько полисов. У сущности «Автомобиль» есть свои атрибуты (номер, модель), у сущности «Полис» — свои (номер, дата, сумма). Эти модели являются основой для проектирования структуры базы данных.
Подходы к проектированию информационных систем
Существует два принципиально разных подхода к организации проектирования:
1.
Каноническое проектирование — создание системы с нуля. Вы проходите полный цикл: от определения требований до программирования, создания базы данных, тестирования и запуска в эксплуатацию.
2.
Типовое проектирование — выбор готового программного продукта (например, 1С, Navision, Axapta), который настраивается под требования. Вы не занимаетесь программированием и созданием базы данных с нуля, а используете то, что уже заложено в системе.
Понимание канонического подхода необходимо для освоения стандартов и рекомендаций, которые полезны при любом способе проектирования.
Краткие итоги
Аналитическое обобщение изложенного материала демонстрирует выстроенную иерархию методов анализа, которая составляет суть структурного подхода к проектированию информационных систем. В основе лежит принцип последовательного погружения от абстрактного описания деятельности к конкретным структурам данных.
Начальной точкой выступает функциональное моделирование, которое фиксирует статику бизнеса: какие постоянные функции существуют и как они связаны. Это создает каркас понимания предметной области, но не отвечает на вопрос, как эти функции реализуются во времени. Данную проблему решает переход к процессному моделированию. Здесь ключевым концептуальным сдвигом является введение единицы работы и, как следствие, возможности описывать логику исполнения: последовательности, параллельности и ветвления. Особую ценность представляет введение нечётких отношений и различных типов логических соединений, позволяющих адекватно отразить реальную сложность бизнес-процессов, где работы часто идут внахлёст, а решения принимаются по множеству сценариев.
Когда динамика процессов становится ясной, возникает практическая задача автоматизации — наполнения модели данными. На этом этапе фокус смещается с управления работами на управление информацией. Методология предлагает диаграммы потоков данных как мост между миром действий и миром данных. Их ценность — в возможности абстрагироваться от физической реализации хранилищ и сфокусироваться на движении информации, что позволяет впоследствии принимать архитектурные решения о том, где данные будут храниться и обрабатываться. Критически важной является практическая рекомендация о синхронной декомпозиции функциональных и информационных моделей, что позволяет избежать каскадных ошибок и дорогостоящих переделок на стыке задач бизнес-аналитика и системного архитектора.
Наконец, для перехода от проекта к действующей системе необходим уровень, пригодный для программирования и настройки баз данных. Для этого вводится моделирование сущность-связь, которое трансформирует информационные потоки и хранилища в строгие структуры — сущности, атрибуты и связи с точно определённой кардинальностью. Этот шаг замыкает технологическую цепочку, преобразуя бизнес-требования в формальные спецификации данных. Финальное сопоставление канонического и типового проектирования показывает, что вся рассмотренная цепочка в большей степени соответствует каноническому методу, но лежащие в её основе принципы структурирования предметной области и логика перехода от функций к данным абсолютно универсальны и применимы при анализе и настройке типовых решений.
Структурное моделирование направлено на последовательное создание описаний, необходимых для проектирования информационной системы. Оно начинается с определения функций — постоянной деятельности компании, и их иерархии. Для их описания и связи используются диаграммы IDEF0. Однако IDEF0 не показывает, как функции исполняются во времени.
Для описания временной последовательности применяется стандарт IDEF3. Здесь прямоугольниками обозначаются единицы работы (Unit of Work) — действия, которые длятся во времени, стартуют и завершаются. Связи между работами показывают три вида стрелок:
• Сплошная — временное предшествование (предыдущая работа должна закончиться до начала следующей).
• Пунктирная — нечёткое отношение (работы могут идти внахлёст).
• Двойная — объектный поток (передача материалов, документов, денег).
Для описания логики ветвления используются соединения (Junctions) двух типов — И и ИЛИ, а также исключающее ИЛИ (XOR). ИЛИ допускает любую комбинацию работ, XOR — только одну. Соединения бывают синхронными (действия должны начаться/закончиться одновременно) и асинхронными. Важно, что на корректных диаграммах соединения используются парами: разворачивающее и сворачивающее. Для дополнительных пояснений или указания циклов служат указатели (Referents).
Следующий шаг к созданию ИС — моделирование информации. Для этого применяются диаграммы потоков данных (DFD). Их элементы:
• Процессы (прямоугольники со скруглёнными углами) — здесь можно указывать не только действие, но и подразделение-исполнитель.
• Потоки данных (стрелки) — показывают только движение информации, а не последовательность.
• Внешние сущности (прямоугольники с тенью) — объекты вне системы (клиенты, госорганы).
• Хранилища данных (вытянутые прямоугольники) — любое место хранения данных (БД, картотека, склад).
Ключевое правило DFD — одновременная декомпозиция с IDEF0. Нельзя сначала детализировать все функции, а потом потоки данных, иначе высок риск несоответствия моделей и переделок. Декомпозиция процесса прекращается, когда у него 2-3 потока, он выполняет одну логическую функцию, а его описание умещается в 20–30 строк и не имеет альтернативных сценариев выполнения.
DFD-диаграммы показывают, какая информация циркулирует, но не её внутреннюю структуру. Для детализации состава данных служат диаграммы «сущность-связь» (ERD). Они описывают:
• Сущности — значимые объекты (Клиент, Договор).
• Атрибуты — их характеристики (Имя, Дата). Атрибуты бывают ключевыми (уникальный идентификатор) и неключевыми, обязательными и необязательными.
• Связи между сущностями с указанием кардинальности (например, «один-ко-многим»). Существуют нотации Баркера («вороньи лапки») и Чена.
ER-диаграммы — это последний этап анализа, создающий фундамент для проектирования базы данных.
Существует два принципиальных подхода к самому проектированию. Каноническое проектирование предполагает создание системы «с нуля», проходя полный цикл от требований до программирования. Типовое проектирование основано на выборе и настройке готового продукта (1С, SAP и т.д.). Несмотря на то, что на практике доминирует типовой подход, понимание полного цикла структурного моделирования важно для грамотного анализа бизнес-процессов и их сопоставления с возможностями настраиваемой системы.
1. Структурный подход к моделированию заключается в последовательном описании функций, процессов, потоков данных и структур данных.
2. Диаграммы IDEF0 служат для моделирования постоянных функций компании и их взаимосвязей, но не отражают временную последовательность.
3. Стандарт IDEF3 вводит понятие «единиц работы», позволяя описывать динамику, последовательность и условия выполнения бизнес-процессов.
4. В IDEF3 сплошная стрелка означает строгое временное предшествование, двойная — объектный поток, а пунктирная — работы, выполняемые внахлёст.
5. Логические соединения (И, ИЛИ, исключающее ИЛИ) моделируют ветвления процессов, а их синхронность/асинхронность определяет требования к одновременности старта/завершения работ.
6. Наличие разворачивающего и сворачивающего соединений в паре — критерий корректности диаграммы IDEF3.
7. Диаграммы DFD предназначены исключительно для моделирования потоков данных и являются связующим звеном между процессами и данными.
8. Хранилище данных на DFD — это логическая абстракция, а не указание на физическую реализацию в виде базы данных.
9. Критически важно проводить декомпозицию IDEF0 и DFD одновременно, чтобы обеспечить непротиворечивость функциональной и информационной моделей.
10. ER-диаграммы завершают этап анализа, предоставляя детальное описание данных, необходимое для проектирования базы данных.
11. Ключевые атрибуты на ER-диаграммах служат для уникальной идентификации экземпляров сущностей в информационной системе.
12. Существует два подхода к проектированию ИС: канонический (разработка с нуля) и типовой (настройка готового решения), при этом методологии анализа предметной области важны для обоих.
1. В чём заключается фундаментальное различие в назначении диаграмм IDEF0 и IDEF3 при описании деятельности организации?
2. Какие три типа стрелок используются в IDEF3 и какой смысл несёт каждый из них? Приведите пример использования нечёткого отношения.
3. Объясните разницу между синхронным и асинхронным логическим соединением. В какой ситуации потребуется синхронное соединение типа И?
4. Почему на корректной диаграмме IDEF3 «разворачивающие» и «сворачивающие» соединения должны появляться парами?
5. В чём состоит ключевое отличие в интерпретации стрелки на диаграммах DFD и на диаграммах IDEF3?
6. Что такое «хранилище данных» на DFD-диаграмме и почему на этапе моделирования неважно, будет ли это базой данных или картотекой?
7. Обоснуйте, почему декомпозицию диаграмм IDEF0 и DFD настоятельно рекомендуется выполнять одновременно, а не последовательно.
8. Перечислите критерии, по которым можно определить, что дальнейшая декомпозиция процесса на DFD-диаграмме не требуется.
9. Каково место и роль ER-диаграмм в общей технологической цепочке структурного проектирования информационной системы?
10. Чем каноническое проектирование информационной системы принципиально отличается от типового с точки зрения процесса создания системы?
11. Какая информация о связях между объектами предметной области отражается на ER-диаграмме с помощью показателей кардинальности?
12. Почему на контекстной DFD-диаграмме допустимо показывать несколько основных процессов, в то время как на контекстной IDEF0-диаграмме — только один?
