В программной инженерии структурный анализ (СА) и структурное проектирование (СД) представляют собой методы анализа бизнес- требований и разработки спецификаций для преобразования практик в компьютерные программы , конфигурации оборудования и связанные с ними ручные процедуры.
Методы структурного анализа и проектирования являются фундаментальными инструментами системного анализа . Они развились из классического системного анализа 1960-х и 1970-х годов. [2]
Структурный анализ стал популярным в 1980-х годах и используется до сих пор. [ необходима цитата ] Структурный анализ заключается в интерпретации концепции системы (или реальных ситуаций) в терминологии данных и управления, представленной диаграммами потоков данных . Поток данных и управления от пузыря к хранилищу данных и обратно может быть трудно отследить, а количество пузырей может увеличиться.
Один из подходов заключается в том, чтобы сначала определить события из внешнего мира, которые требуют реакции системы, а затем назначить пузырек этому событию. Пузыри, которые должны взаимодействовать, затем соединяются, пока система не будет определена. Пузыри обычно группируются в пузыри более высокого уровня для уменьшения сложности. Для описания потоков данных и команд необходимы словари данных , а для сбора информации о транзакциях/преобразованиях необходима спецификация процесса. [3]
SA и SD отображаются с помощью структурных диаграмм , диаграмм потоков данных и диаграмм моделей данных , которые имели множество вариаций, включая разработанные Томом ДеМарко , Кеном Орром , Ларри Константином , Воном Фриком , Эдом Йордоном , Стивеном Уордом, Питером Ченом и другими.
Эти методы были объединены в различных опубликованных методологиях разработки систем , включая метод структурированного системного анализа и проектирования , метод прибыльной информации по проектированию (PRIDE), структурированный анализ и проектирование Nastec, SDM/70 и методологию разработки структурированных систем Spectrum.
Структурный анализ является частью серии структурных методов, которые представляют собой набор методов анализа, проектирования и программирования, которые были разработаны в ответ на проблемы, с которыми сталкивался мир программного обеспечения с 1960-х по 1980-е годы. В этот период большая часть коммерческого программирования выполнялась на Cobol и Fortran , затем на C и BASIC . Было мало руководств по «хорошим» методам проектирования и программирования, и не было стандартных методов документирования требований и проектов. Системы становились больше и сложнее, и разработка информационных систем становилась все труднее и труднее». [4]
В качестве способа управления большим и сложным программным обеспечением с конца 1960-х годов появились следующие структурированные методы: [4]
По словам Хэя (1999), « информационная инженерия была логическим продолжением структурированных методов, которые были разработаны в 1970-х годах. Структурное программирование привело к структурированному проектированию, которое, в свою очередь, привело к структурированному системному анализу. Эти методы характеризовались использованием диаграмм : структурных диаграмм для структурированного проектирования и диаграмм потоков данных для структурированного анализа, как для содействия общению между пользователями и разработчиками, так и для повышения дисциплины аналитиков и проектировщиков. В 1980-х годах начали появляться инструменты, которые автоматизировали рисование диаграмм и отслеживали нарисованные вещи в словаре данных ». [10] После примера автоматизированного проектирования и автоматизированного производства (CAD/CAM) использование этих инструментов было названо автоматизированной разработкой программного обеспечения (CASE).
Структурный анализ обычно создает иерархию, используя единый механизм абстракции. Метод структурного анализа может использовать IDEF (см. рисунок), управляется процессом и начинается с цели и точки зрения. Этот метод определяет общую функцию и итеративно делит функции на более мелкие функции, сохраняя входы, выходы, элементы управления и механизмы, необходимые для оптимизации процессов. Также известный как подход функциональной декомпозиции , он фокусируется на связности внутри функций и связи между функциями, что приводит к структурированным данным. [11]
Функциональная декомпозиция структурированного метода описывает процесс без разграничения поведения системы и диктует структуру системы в форме требуемых функций. Метод определяет входы и выходы как связанные с действиями. Одной из причин популярности структурированного анализа является его интуитивная способность сообщать высокоуровневые процессы и концепции, будь то на уровне отдельной системы или предприятия. Неясно, как объекты могут поддерживать функции для коммерчески распространенной объектно-ориентированной разработки. В отличие от IDEF, UML управляется интерфейсом с несколькими механизмами абстракции, полезными для описания сервисно-ориентированных архитектур (SOA). [11]
Структурный анализ рассматривает систему с точки зрения данных, проходящих через нее. Функция системы описывается процессами, которые преобразуют потоки данных. Структурный анализ использует преимущество сокрытия информации посредством последовательного декомпозиционного (или нисходящего) анализа. Это позволяет сосредоточить внимание на соответствующих деталях и избежать путаницы от просмотра нерелевантных деталей. По мере увеличения уровня детализации объем информации сокращается. Результатом структурного анализа является набор связанных графических диаграмм, описаний процессов и определений данных. Они описывают преобразования, которые необходимо выполнить, и данные, необходимые для удовлетворения функциональных требований системы . [12]
Подход Де Марко [13] состоит из следующих объектов (см. рисунок): [12]
Таким образом, диаграммы потоков данных (DFD) являются направленными графами. Дуги представляют данные , а узлы (круги или пузырьки) представляют процессы, которые преобразуют данные. Процесс может быть далее разложен на более подробную DFD, которая показывает подпроцессы и потоки данных внутри него. Подпроцессы, в свою очередь, могут быть далее разложены с помощью другого набора DFD, пока их функции не будут легко поняты. Функциональные примитивы — это процессы, которые не нуждаются в дальнейшей разложении. Функциональные примитивы описываются спецификацией процесса (или мини-спецификацией). Спецификация процесса может состоять из псевдокода, блок-схем или структурированного английского языка. DFD моделируют структуру системы как сеть взаимосвязанных процессов, состоящих из функциональных примитивов. Словарь данных — это набор записей (определений) потоков данных, элементов данных, файлов и баз данных. Записи словаря данных разбиваются сверху вниз. На них можно ссылаться в других записях словаря данных и на диаграммах потоков данных. [12]
.svg/1280px-NDE_Context_Diagram_(vector).svg.png)
Контекстные диаграммы — это диаграммы, которые представляют действующих лиц вне системы, которые могут взаимодействовать с этой системой. [15] Эта диаграмма представляет собой представление системы самого высокого уровня , похожее на блок-схему , показывающее систему, возможно, основанную на программном обеспечении , в целом и ее входы и выходы от/к внешним факторам.
Этот тип диаграммы, согласно Коссякову (2003), обычно «изображает систему в центре, без подробностей ее внутренней структуры, окруженную всеми ее взаимодействующими системами, средой и действиями. Целью диаграммы контекста системы является сосредоточение внимания на внешних факторах и событиях, которые следует учитывать при разработке полного набора системных требований и ограничений». [15] Диаграммы контекста системы связаны с диаграммой потока данных и показывают взаимодействия между системой и другими субъектами, с которыми система призвана сталкиваться. Диаграммы контекста системы могут быть полезны для понимания контекста, в котором система будет частью разработки программного обеспечения .
Словарь данных или словарь базы данных — это файл, который определяет базовую организацию базы данных . [16] Словарь базы данных содержит список всех файлов в базе данных, количество записей в каждом файле, а также имена и типы каждого поля данных. Большинство систем управления базами данных скрывают словарь данных от пользователей, чтобы они не могли случайно уничтожить его содержимое. Словари данных не содержат никаких фактических данных из базы данных, только бухгалтерскую информацию для управления ею. Однако без словаря данных система управления базой данных не может получить доступ к данным из базы данных. [16]
Пользователи баз данных и разработчики приложений могут извлечь выгоду из авторитетного документа словаря данных, который каталогизирует организацию, содержимое и соглашения одной или нескольких баз данных. [17] Обычно он включает в себя имена и описания различных таблиц и полей в каждой базе данных, а также дополнительные сведения, такие как тип и длина каждого элемента данных . Не существует универсального стандарта относительно уровня детализации в таком документе, но в первую очередь это выжимка метаданных о структуре базы данных , а не сами данные. Документ словаря данных также может включать в себя дополнительную информацию, описывающую, как кодируются элементы данных. Одним из преимуществ хорошо спроектированной документации словаря данных является то, что она помогает установить согласованность во всей сложной базе данных или в большой коллекции федеративных баз данных . [18]
Диаграмма потока данных (DFD) — это графическое представление «потока» данных через информационную систему . Она отличается от системной блок-схемы тем, что показывает поток данных через процессы, а не через компьютерное оборудование . Диаграммы потока данных были изобретены Ларри Константином , разработчиком структурированного дизайна , на основе модели вычислений «графа потока данных» Мартина и Эстрина. [20]
Обычной практикой является рисование сначала диаграммы контекста системы , которая показывает взаимодействие между системой и внешними сущностями. DFD предназначена для того, чтобы показать, как система делится на более мелкие части, и выделить поток данных между этими частями. Затем эта диаграмма потока данных на уровне контекста «разворачивается», чтобы показать больше деталей моделируемой системы.
Диаграммы потоков данных (DFD) являются одной из трех основных перспектив метода структурированного системного анализа и проектирования (SSADM). Спонсор проекта и конечные пользователи должны быть проинформированы и проконсультированы на всех этапах развития системы. С помощью диаграммы потоков данных пользователи могут визуализировать, как будет работать система, что система будет выполнять и как система будет реализована. Диаграммы потоков данных старой системы можно составить и сравнить с диаграммами потоков данных новой системы, чтобы провести сравнения для реализации более эффективной системы. Диаграммы потоков данных можно использовать для предоставления конечному пользователю физического представления о том, где вводимые им данные в конечном итоге влияют на структуру всей системы от заказа до отправки и повторного приготовления. То, как разрабатывается любая система, можно определить с помощью диаграммы потоков данных.
Структурная диаграмма (SC) — это диаграмма, которая показывает разбивку системы конфигурации на самые низкие управляемые уровни. [21] Эта диаграмма используется в структурном программировании для организации модулей программы в древовидной структуре. Каждый модуль представлен блоком, который содержит название модулей. Древовидная структура визуализирует отношения между модулями. [22]
Структурные диаграммы используются в структурном анализе для указания высокоуровневого дизайна или архитектуры компьютерной программы . Как инструмент проектирования, они помогают программисту в разделении и преодолении большой программной проблемы, то есть рекурсивном разбиении проблемы на части, которые достаточно малы, чтобы быть понятыми человеческим мозгом. Процесс называется проектированием сверху вниз или функциональной декомпозицией . Программисты используют структурную диаграмму для построения программы способом, подобным тому, как архитектор использует чертеж для строительства дома. На этапе проектирования диаграмма рисуется и используется как способ общения клиента и различных разработчиков программного обеспечения. Во время фактического построения программы (реализации) диаграмма постоянно упоминается как генеральный план. [23]
Структурированное проектирование (SD) связано с разработкой модулей и синтезом этих модулей в так называемой «иерархии модулей». [24] Для проектирования оптимальной структуры модуля и интерфейсов решающее значение имеют два принципа:
Структурированный дизайн был разработан Ларри Константином в конце 1960-х годов, затем доработан и опубликован с соавторами в 1970-х годах; [5] [6] см. Larry Constantine: Structured Design для получения подробной информации. Пейдж-Джонс (1980) предложил свой собственный подход, который состоит из трех основных объектов:
Структурная схема призвана показать «иерархию модулей или отношение последовательности вызова модулей. Для каждого модуля, показанного на структурной схеме, имеется спецификация модуля. Спецификации модуля могут быть составлены из псевдокода или языка проектирования программ. Словарь данных подобен словарю структурного анализа. На этом этапе жизненного цикла разработки программного обеспечения , после выполнения анализа и проектирования, можно автоматически генерировать объявления типов данных» [25] и шаблоны процедур или подпрограмм. [12]
Проблемы с диаграммами потоков данных включают следующее: [3]
