Структурный анализ и проектирование

Структурный анализ и проектирование (англ. Structural Analysis and Design, SAD) — это дисциплина в области системной инженерии и разработки программного обеспечения, занимающаяся формализованным описанием и моделированием структуры системы до начала её физической реализации. Методология объединяет совокупность графических нотаций, методов и правил, позволяющих разбить сложную систему на составные части (модули, компоненты, подсистемы), определить связи между ними и спроектировать архитектуру, удовлетворяющую заданным требованиям. В отличие от объектно-ориентированного подхода, структурный анализ фокусируется на функциях, потоках данных и иерархии, а не на объектах и их поведении.

История

Предпосылки возникновения

В 1960-х — начале 1970-х годов разработка программного обеспечения столкнулась с «кризисом программирования»: сложность систем росла быстрее, чем способность инженеров их контролировать. Проекты часто срывались из-за непонимания требований, хаотичной архитектуры и отсутствия единой методологии. В ответ на это возникла идея структурного программирования (Эдсгер Дейкстра, 1968), которая требовала отказа от оператора безусловного перехода GOTO и использования только трёх базовых управляющих конструкций (следование, ветвление, цикл). Однако для анализа и проектирования целых систем этого было недостаточно.

Формирование методологии (1970-е — 1980-е)

Ключевой вклад в развитие структурного анализа и проектирования внесли:

• Ларри Константайн и Эдвард Йордон — в 1975 году опубликовали книгу «Structured Design», где ввели понятие структурной карты (structure chart) — диаграммы, показывающей иерархию модулей, вызовы и передачу данных между ними. Они сформулировали принципы связности (cohesion) и сцепления (coupling) как меры качества модульной архитектуры.
• Том Демарко — в 1978 году выпустил книгу «Structured Analysis and System Specification», где предложил использовать диаграммы потоков данных (DFD) и словари данных для описания требований к системе. DFD показывали, как данные перемещаются между процессами, хранилищами и внешними сущностями.
• Крис Гейн и Триш Сарсон — в 1979 году развили нотацию DFD, добавив к ней спецификации процессов (мини-спецификации) и правила балансировки уровней.

В 1980-е годы методология получила широкое распространение в США и Европе, особенно в проектах, связанных с автоматизацией бизнес-процессов, военными системами и телекоммуникациями. Были разработаны CASE-инструменты (Computer-Aided Software Engineering), поддерживающие структурные нотации (например, Excelerator, Teamwork).

Упадок и трансформация (1990-е — настоящее время)

С середины 1990-х годов популярность структурного подхода пошла на спад под влиянием объектно-ориентированного анализа и проектирования (OOAD), а также языка UML. Однако элементы структурного анализа (DFD, структурные карты) продолжают использоваться в узких областях: при проектировании встраиваемых систем, в реинжиниринге бизнес-процессов, а также в некоторых методологиях разработки (например, в методологии IDEF0). В современной практике структурный анализ часто комбинируется с другими подходами, например, в рамках метода SSADM (Structured Systems Analysis and Design Method), который применяется в государственных проектах Великобритании.

Основные концепции

Модульность

Центральное понятие структурного проектирования — модуль. Модуль — это функционально завершённый элемент системы, который имеет чётко определённые входы и выходы. Качество модульной архитектуры оценивается двумя метриками:

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

Иерархия и декомпозиция

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

Потоки данных

Диаграммы потоков данных (DFD) — основной инструмент структурного анализа. Они состоят из четырёх типов элементов:

• Внешние сущности (прямоугольники) — источники или приёмники данных (например, пользователь, другая система).
• Процессы (круги или овалы) — преобразования данных.
• Потоки данных (стрелки) — движение данных между процессами, хранилищами и сущностями.
• Хранилища данных (открытые прямоугольники) — места хранения данных (базы данных, файлы).

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

Основные этапы методологии

1. Анализ требований

На этом этапе строится контекстная диаграмма — DFD нулевого уровня, на которой система представлена как один процесс, связанный с внешними сущностями. Определяются границы системы и её основные входы/выходы.

2. Построение логической модели

Создаются детализированные DFD (уровни 1, 2, …), описывающие все процессы, хранилища и потоки данных. Параллельно ведётся словарь данных — формальное описание каждого потока и хранилища (например, тип данных, длина, допустимые значения). Для каждого процесса на нижнем уровне пишется мини-спецификация (структурированный английский, псевдокод или таблица решений).

3. Проектирование архитектуры

На основе логической модели строится структурная карта (structure chart). Она показывает:

• Иерархию модулей (главный модуль, подчинённые модули).
• Передачу данных (стрелки с метками) и управляющих флагов.
• Типы вызовов: последовательный, циклический, условный.

Цель этапа — получить архитектуру с высокой связностью и низким сцеплением.

4. Разработка физической модели

Логическая модель преобразуется в физическую с учётом ограничений выбранной платформы, языка программирования, СУБД и аппаратного обеспечения. Определяются конкретные модули, интерфейсы, форматы данных.

Нотации и инструменты

Основные нотации

• DFD (Data Flow Diagram) — по Демарко или по Гейну-Сарсону (различаются обозначениями: в нотации Демарко процессы — круги, в нотации Гейна-Сарсон — овалы или прямоугольники со скруглёнными углами).
• Структурные карты — по Константайну-Йордону.
• IDEF0 — методология функционального моделирования, используемая для анализа бизнес-процессов (стандарт США FIPS 183). В отличие от DFD, IDEF0 показывает не только потоки данных, но и управление (control) и механизмы (mechanisms).
• ERD (Entity-Relationship Diagram) — диаграммы «сущность-связь», используемые для моделирования данных (часто дополняют структурный анализ).

CASE-средства

Для поддержки структурного анализа и проектирования в 1980-х — 1990-х годах разрабатывались специализированные инструменты:

• IBM Rational Rose (поддерживал структурные нотации в ранних версиях).
• CA ERwin (моделирование данных).
• System Architect (поддерживал DFD, IDEF0, структурные карты).
• BPwin (моделирование бизнес-процессов в нотации IDEF0).

В настоящее время большинство этих инструментов либо переориентированы на UML, либо заменены open-source решениями (например, Dia, Draw.io).

Применение

Разработка программного обеспечения

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

Реинжиниринг бизнес-процессов

Методология IDEF0 и DFD используется для документирования и оптимизации бизнес-процессов в крупных организациях (например, в государственных учреждениях, банках, логистических компаниях). Аналитики строят модели «как есть» (as-is) и «как должно быть» (to-be), чтобы выявить узкие места и дублирование функций.

Обучение и сертификация

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

Критика и ограничения

Недостатки структурного подхода

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

Сравнение с объектно-ориентированным подходом

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

Современное состояние

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

• Встраиваемые системы — где архитектура часто жёстко задана аппаратными ограничениями, а функциональная декомпозиция остаётся эффективной.
• Системы с высокой степенью формализации — например, в авионике (стандарт DO-178C) и медицинских устройствах, где требуется строгое документирование всех функций и потоков данных.
• Реинжиниринг унаследованных систем — для понимания и модернизации старых программных продуктов, написанных на языках COBOL, FORTRAN или C, где изначально использовался структурный подход.

Многие принципы структурного анализа (модульность, декомпозиция, минимизация сцепления) вошли в «золотой фонд» системной инженерии и применяются в современных методологиях, включая Domain-Driven Design (DDD) и Clean Architecture, хотя и в адаптированном виде.

Источники

1. Yourdon E., Constantine L. L. Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. — Yourdon Press, 1979.
2. DeMarco T. Structured Analysis and System Specification. — Prentice-Hall, 1978.
3. Gane C., Sarson T. Structured Systems Analysis: Tools and Techniques. — Prentice-Hall, 1979.
4. Pressman R. S. Software Engineering: A Practitioner’s Approach. — 8th ed. — McGraw-Hill, 2014.
5. Соммервилл И. Инженерия программного обеспечения. — 10-е изд. — Вильямс, 2016.
6. Robertson S., Robertson J. Mastering the Requirements Process: Getting Requirements Right. — 3rd ed. — Addison-Wesley, 2012.