Исторический контекст моделирования ИС
Исторический контекст нужен не ради дат и фамилий, а ради понимания, почему в моделировании существует несколько традиций. Одни подходы выросли из описания алгоритмов и процедур, поэтому хорошо показывают последовательность действий. Другие возникли вокруг данных и хорошо объясняют структуру хранения. Третьи появились из анализа бизнес-процессов и организационных взаимодействий.
На ранних этапах разработки программ основное внимание уделялось алгоритмам. Нужно было понять, какие шаги выполняет программа и в каком порядке. Для этого хорошо подходили блок-схемы и псевдокод. Такой подход полезен до сих пор, но он плохо описывает сложную организационную среду: роли, документы, правила, данные и внешние системы.
Затем усилился структурный анализ. Он рассматривал систему как набор функций, потоков данных и хранилищ. Диаграммы потоков данных и семейство IDEF помогали описывать, какие функции выполняются, какие данные входят и выходят, какие механизмы участвуют. Эта традиция хорошо подходит для анализа деятельности организации, но не всегда удобно выражает объектную структуру программной реализации.
Отдельной линией развивалось моделирование данных. ER-подходы помогли описывать сущности, атрибуты и связи, то есть то, что позже должно храниться и поддерживать целостность. Для информационных систем это критично: заказ, клиент, платёж, документ, заявка или справочник часто важны не меньше, чем функции обработки.
Бизнес-процессная традиция появилась как ответ на необходимость описывать работу организации, а не только программы. EPC, ARIS и BPMN позволяют говорить о событиях, действиях, участниках, документах и развилках процесса. Для курса по проектному моделированию ИС это особенно важно: прежде чем рисовать классы или компоненты, нужно понять, как вообще выполняется работа.
Объектно-ориентированный анализ и проектирование предложили смотреть на систему через объекты, их состояние, поведение и взаимодействия. В 1990-е годы существовало несколько конкурирующих объектных методов, и UML появился как попытка унифицировать основные способы объектного моделирования. Поэтому UML содержит разные виды диаграмм: классы, объекты, взаимодействия, состояния, компоненты, развёртывание и другие.
Из этой истории следует практический вывод: UML не обязан заменять все остальные артефакты. Он хорошо фиксирует многие проектные решения, но не заменяет интервью, словарь предметной области, таблицу требований, текстовую спецификацию сценария или краткую ADR-запись. Современное проектирование обычно сочетает несколько форм описания, потому что разные проблемы требуют разных языков.
Для курса это означает, что мы используем UML не как изолированный набор картинок, а как часть более широкой практики моделирования информационных систем. Сначала важно понять предметную область, процессы, требования и данные. Затем уже выбирается диаграмма, которая лучше всего фиксирует нужный аспект решения.
Практическая польза исторического контекста в том, что он помогает выбирать инструмент под задачу. Если нужно описать порядок вычисления, достаточно алгоритмического представления. Если нужно понять, какие документы ходят между подразделениями, полезнее процессная или функциональная модель. Если нужно объяснить хранение и целостность данных, уместна модель данных. Если нужно показать ответственность программных объектов и их взаимодействие, появляется смысл использовать UML.
Поэтому смешение подходов само по себе не является ошибкой. Ошибка начинается тогда, когда выбранный язык не соответствует вопросу. UML-диаграмма классов плохо объяснит мотивацию стейкхолдера, а таблица требований плохо покажет параллельные ветви процесса. Исторически разные подходы и появились потому, что одна форма описания не закрывала все вопросы проектирования.