В разработке программного обеспечения структурный анализ (SA) и структурированное проектирование (SD) — это методы анализа бизнес- требований и разработки спецификаций для преобразования практик в компьютерные программы , конфигурации оборудования и соответствующие ручные процедуры.
Структурный анализ и методы проектирования являются фундаментальными инструментами системного анализа . Они возникли на основе классического системного анализа 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] Подробности см . в разделе «Ларри Константин: структурированный дизайн» . Пейдж-Джонс (1980) предложил свой собственный подход, который состоит из трех основных целей:
Структурная диаграмма призвана показать «иерархию модулей или взаимосвязь последовательности вызовов модулей. Для каждого модуля, показанного на структурной диаграмме, существует спецификация модуля. Спецификации модуля могут состоять из псевдокода или языка разработки программ. Словарь данных подобен структурированному анализу. На этом этапе жизненного цикла разработки программного обеспечения , после выполнения анализа и проектирования, можно автоматически генерировать объявления типов данных» [25] и шаблоны процедур или подпрограмм. [12]
Проблемы с диаграммами потоков данных включали следующее: [3]
