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

В обеспечения разработке программного структурный анализ (SA) и структурированное проектирование (SD) — это методы анализа бизнес- требований и разработки спецификаций для преобразования практик в компьютерные программы , конфигурации оборудования и соответствующие ручные процедуры.

Структурный анализ и методы проектирования являются фундаментальными инструментами системного анализа . Они возникли на основе классического системного анализа 1960-х и 1970-х годов. ^[2]

Задачи структурированного анализа

Структурированный анализ стал популярен в 1980-х годах и используется до сих пор. ^{[ нужна ссылка ]} Структурный анализ состоит из интерпретации концепции системы (или ситуаций реального мира) в терминологии данных и управления, представленной диаграммами потоков данных . Поток данных и контроля от «пузыря» к хранилищу данных и «пузырю» может быть трудно отследить, а количество «пузырей» может увеличиться.

Один из подходов заключается в том, чтобы сначала определить события из внешнего мира, которые требуют реакции системы, а затем назначить этому событию пузырь. Пузыри, которые должны взаимодействовать, затем соединяются до тех пор, пока система не будет определена. Пузыри обычно группируются в пузырьки более высокого уровня, чтобы уменьшить сложность. Словари данных необходимы для описания потоков данных и команд, а спецификация процесса необходима для сбора информации о транзакциях/преобразованиях. ^[3]

SA и SD отображаются со структурными диаграммами , диаграммами потоков данных и диаграммами моделей данных , вариаций которых было множество, в том числе разработанных Томом ДеМарко , Кеном Орром , Ларри Константином , Воном Фриком , Эдом Юрдоном , Стивеном Уордом, Питером Ченом и другие.

Эти методы были объединены в различных опубликованных методологиях разработки систем , включая метод структурированного системного анализа и проектирования , прибыльную информацию за счет дизайна (PRIDE), структурный анализ и проектирование Nastec, SDM/70 и методологию разработки структурированных систем Spectrum.

История

Структурный анализ является частью серии структурированных методов, которые представляют собой набор методов анализа, проектирования и программирования, которые были разработаны в ответ на проблемы, с которыми столкнулся мир программного обеспечения с 1960-х по 1980-е годы. В этот период большая часть коммерческого программирования выполнялась на Cobol и Fortran , затем на C и BASIC . Руководств по «хорошим» методам проектирования и программирования было мало, а также не было стандартных методов документирования требований и проектов. Системы становились все больше и сложнее, а разрабатывать информационные системы становилось все труднее и труднее». ^[4]

В качестве способа управления большим и сложным программным обеспечением с конца 1960-х годов появились следующие структурированные методы: ^[4]

Структурированное программирование примерно в 1967 году с Эдсгером Дейкстрой - «Перейти к утверждению, считающемуся вредным».
Никлаус Вирт Ступенчатый дизайн в 1971 году.
Диаграмма Насси – Шнейдермана 1972 года.
Диаграмма Варнье/Орра 1974 года - «Логическое построение программ».
HIPO в 1974 году — иерархия IBM «ввод-процесс-вывод» (хотя на самом деле это должен быть вывод-ввод-процесс)
Структурированный дизайн примерно в 1975 году с Ларри Константином , Эдом Юрдоном и Уэйном Стивенсом . ^[5]^[6]
Структурированное программирование Джексона, разработанное Майклом А. Джексоном примерно в 1975 году.
Структурированный анализ примерно в 1978 году с Томом ДеМарко , Эдвардом Юрдоном , Гейном и Сарсоном, МакМенамином и Палмером.
Методика структурного анализа и проектирования (SADT), разработанная Дугласом Т. Россом.
Структурированный метод Юрдона, разработанный Эдвардом Юрдоном .
Структурный анализ и спецификация системы опубликованы в 1978 году Томом ДеМарко .
Метод структурированного системного анализа и проектирования (SSADM), впервые представленный в 1983 году, разработан Управлением Великобритании государственной торговли .
Анализ существенных систем , предложенный Стивеном М. Макменамином и Джоном Ф. Палмером. ^[7]
IDEF0 основан на SADT, разработанном Дугласом Т. Россом в 1985 году. ^[8]
Моделирование Хэтли-Пирбая , определенное в «Стратегиях спецификации систем реального времени» Дерека Дж. Хэтли и Имтиаза А. Пирбая в 1988 году.
Современный структурный анализ , разработанный Эдвардом Юрдоном после публикации «Основного системного анализа» и опубликованный в 1989 году. ^[9]
Инженерия информационных технологий примерно в 1990 году вместе с Финкельштейном и популяризированная Джеймсом Мартином .

По словам Хэя (1999), « информационная инженерия была логическим продолжением структурированных методов, разработанных в 1970-х годах. Структурное программирование привело к структурированному проектированию, которое, в свою очередь, привело к структурированному системному анализу. Эти методы характеризовались использованием диаграмм : структурные диаграммы для структурированного проектирования и диаграммы потоков данных для структурированного анализа, которые помогают в общении между пользователями и разработчиками, а также повышают дисциплину аналитиков и дизайнеров. В 1980-х годах начали появляться инструменты, которые автоматизировали построение диаграмм. и отслеживал нарисованные объекты в словаре данных ». ^[10] По примеру автоматизированного проектирования и автоматизированного производства (CAD/CAM) использование этих инструментов было названо автоматизированной разработкой программного обеспечения (CASE).

Темы структурированного анализа

Единый механизм абстракции

Структурный анализ обычно создает иерархию, используя единый механизм абстракции. Метод структурированного анализа может использовать IDEF (см. рисунок), основан на процессе и начинается с цели и точки зрения. Этот метод определяет общую функцию и итеративно делит функции на более мелкие функции, сохраняя входные и выходные данные, элементы управления и механизмы, необходимые для оптимизации процессов. Также известный как подход функциональной декомпозиции , он фокусируется на связности внутри функций и связи между функциями, что приводит к структурированным данным. ^[11]

Функциональная декомпозиция структурированного метода описывает процесс без описания поведения системы и диктует структуру системы в виде требуемых функций. Метод определяет входы и выходы, связанные с деятельностью. Одной из причин популярности структурированного анализа является его интуитивная способность передавать процессы и концепции высокого уровня как на уровне отдельной системы, так и на уровне предприятия. Пока неясно, как объекты могут поддерживать функции для коммерчески распространенной объектно-ориентированной разработки. В отличие от IDEF, UML управляется интерфейсом с помощью множества механизмов абстракции, полезных при описании сервис-ориентированных архитектур (SOA). ^[11]

Подход

Структурный анализ рассматривает систему с точки зрения данных, проходящих через нее. Функция системы описывается процессами, преобразующими потоки данных. Структурированный анализ использует преимущества сокрытия информации посредством последовательного анализа декомпозиции (или анализа сверху вниз). Это позволяет сосредоточить внимание на важных деталях и избежать путаницы из-за рассмотрения не относящихся к делу деталей. По мере увеличения уровня детализации объем информации уменьшается. Результатом структурированного анализа является набор связанных графических диаграмм, описаний процессов и определений данных. системы Они описывают преобразования, которые необходимо произвести, и данные, необходимые для удовлетворения функциональных требований . ^[12]

Подход Марко ^[13] состоит из следующих объектов (см. рисунок): ^[12]

Контекстная диаграмма
Схема потока данных
Технические характеристики процесса
Словарь данных

Таким образом, диаграммы потоков данных (DFD) представляют собой ориентированные графы. Дуги представляют данные , а узлы (круги или пузырьки) представляют процессы, преобразующие данные. Процесс можно дополнительно разложить на более подробный DFD, который показывает подпроцессы и потоки данных внутри него. Подпроцессы, в свою очередь, можно дополнительно разложить с помощью другого набора DFD до тех пор, пока их функции не станут легко понятны. Функциональные примитивы — это процессы, которые не требуют дальнейшей декомпозиции. Функциональные примитивы описываются спецификацией процесса (или мини-спецификацией). Спецификация процесса может состоять из псевдокода, блок-схем или структурированного английского языка. DFD моделируют структуру системы как сеть взаимосвязанных процессов, состоящих из функциональных примитивов. Словарь данных представляет собой набор записей (определений) потоков данных, элементов данных, файлов и баз данных. Записи словаря данных секционируются сверху вниз. На них можно ссылаться в других статьях словаря данных и в диаграммах потоков данных. ^[12]

Контекстная диаграмма

Контекстные диаграммы — это диаграммы, которые представляют действующих лиц вне системы, которые могут взаимодействовать с этой системой. ^[15] Эта диаграмма представляет собой представление системы самого высокого уровня , аналогичное блок-схеме , показывающее, возможно, программную систему в целом, а также ее входы и выходы от/к внешним факторам.

По словам Косьякова (2003), этот тип диаграммы обычно «изображает систему в центре, без деталей ее внутренней структуры, в окружении всех ее взаимодействующих систем, окружающей среды и деятельности. Цель контекстной диаграммы системы — сосредоточить внимание на внешние факторы и события, которые следует учитывать при разработке полного набора системных требований и ограничений». ^[15] Контекстные диаграммы системы связаны с диаграммой потока данных и показывают взаимодействие между системой и другими участниками, для которых система предназначена. Контекстные диаграммы системы могут быть полезны для понимания контекста, в котором система будет частью разработки программного обеспечения .

Словарь данных

Словарь данных или словарь базы данных — это файл, который определяет базовую организацию базы данных . ^[16] Словарь базы данных содержит список всех файлов в базе данных, количество записей в каждом файле, а также имена и типы каждого поля данных. Большинство систем управления базами данных скрывают словарь данных от пользователей, чтобы предотвратить случайное уничтожение его содержимого. Словари данных не содержат никаких фактических данных из базы данных, а только бухгалтерскую информацию для управления ею. Однако без словаря данных система управления базами данных не может получить доступ к данным из базы данных. ^[16]

Пользователи баз данных и разработчики приложений могут извлечь выгоду из авторитетного документа словаря данных, в котором каталогизирована организация, содержимое и соглашения одной или нескольких баз данных. ^[17] Обычно это включает имена и описания различных таблиц и полей в каждой базе данных, а также дополнительные сведения, такие как тип и длина каждого элемента данных . Не существует универсального стандарта относительно уровня детализации такого документа, но это, прежде всего, дистилляция метаданных о структуре базы данных , а не сами данные. Документ словаря данных также может включать дополнительную информацию, описывающую, как кодируются элементы данных. Одним из преимуществ хорошо продуманной документации словаря данных является то, что она помогает обеспечить согласованность во всей сложной базе данных или в большой коллекции объединенных баз данных . ^[18]

Диаграммы потоков данных

Диаграмма потока данных (DFD) — это графическое представление «потока» данных через информационную систему . системы Она отличается от блок-схемы , поскольку показывает поток данных через процессы, а не через компьютерное оборудование . Диаграммы потоков данных были изобретены Ларри Константином , разработчиком структурированного проектирования , на основе модели вычислений Мартина и Эстрина «график потока данных». ^[20]

Обычной практикой является сначала нарисовать контекстную диаграмму системы , которая показывает взаимодействие между системой и внешними объектами. DFD предназначен для того, чтобы показать, как система разделена на более мелкие части, и выделить поток данных между этими частями. Эта диаграмма потока данных на уровне контекста затем «расчленяется», чтобы показать более подробную информацию о моделируемой системе.

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

Структурная диаграмма

Структурная диаграмма (SC) — это диаграмма, которая показывает разбивку системы конфигурации до самых нижних управляемых уровней. ^[21] Эта диаграмма используется в структурном программировании для организации модулей программы в древовидной структуре. Каждый модуль представлен полем, содержащим названия модулей. Древовидная структура визуализирует связи между модулями. ^[22]

Структурные диаграммы используются в структурном анализе для определения высокоуровневого дизайна или архитектуры компьютерной программы . Как инструмент проектирования они помогают программисту разделить и решить большую программную проблему, то есть рекурсивно разбить проблему на части, которые достаточно малы, чтобы их мог понять человеческий мозг. Этот процесс называется проектированием сверху вниз или функциональной декомпозицией . Программисты используют структурную схему для создания программы аналогично тому, как архитектор использует чертеж для строительства дома. На этапе проектирования диаграмма рисуется и используется как средство общения клиента и различных разработчиков программного обеспечения. Во время фактического построения программы (реализации) диаграмму постоянно называют генеральным планом. ^[23]

Структурированный дизайн

Структурированное проектирование (SD) связано с разработкой модулей и синтезом этих модулей в так называемой «иерархии модулей». ^[24] Для разработки оптимальной структуры модуля и интерфейсов решающее значение имеют два принципа:

Сплоченность , которая «занимается группировкой функционально связанных процессов в определенный модуль». ^[12] и
Соединение относится к «потоку информации или параметров, передаваемых между модулями. Оптимальное соединение уменьшает интерфейсы модулей и, как следствие, сложность программного обеспечения». ^[12]

Структурированный дизайн был разработан Ларри Константином в конце 1960-х годов, затем доработан и опубликован совместно с его коллегами в 1970-х годах; ^[5]^[6] см . в разделе «Ларри Константин: структурированный дизайн» подробности . Пейдж-Джонс (1980) предложил свой собственный подход, который состоит из трех основных целей:

структурные диаграммы
характеристики модуля
словарь данных.

Структурная диаграмма призвана показать «иерархию модулей или взаимосвязь последовательности вызовов модулей. Для каждого модуля, показанного на структурной диаграмме, существует спецификация модуля. Спецификации модуля могут состоять из псевдокода или языка разработки программ. Словарь данных подобен структурированному анализу. На этом этапе жизненного цикла разработки программного обеспечения , после выполнения анализа и проектирования, можно автоматически генерировать объявления типов данных». ^[25] и шаблоны процедур или подпрограмм. ^[12]

Критика

Проблемы с диаграммами потоков данных включали следующее: ^[3]

Правильный выбор пузырьков
Разделение пузырей осмысленным и взаимно согласованным образом,
Размер документации, необходимый для понимания потоков данных,
Диаграммы потоков данных по своей природе очень функциональны и поэтому подвержены частым изменениям.
Хотя поток «данных» подчеркивается, моделирование «данных» — нет, поэтому мало понимания сути системы.
Клиентам сложно понять, как концепция отображается в потоках данных и пузырьках.
Дизайнеры должны перевести организацию DFD в реализуемый формат.

См. также

Ссылки

^ Триша Гилберт (2006) Критерии оценки FCS для оценки технологий. Архивировано 18 сентября 2008 г. на Wayback Machine.
^ Эдвард Юрдон (1986). Управление структурированными методами: стратегии разработки программного обеспечения в 1990-е годы . Юрдон Пресс. стр.35.
^ Jump up to: ^а ^б ФАУ (2000). Руководство по безопасности системы ФАУ, Приложение D. 30 декабря 2000 г.
^ Jump up to: ^а ^б Дэйв Левитт (2000). «Введение в структурный анализ и проектирование». на факультете.inverhills.edu/dlevitt . Проверено 21 сентября 2008 г. Больше не в сети в 2017 г.
^ Jump up to: ^а ^б Стивенс, Майерс и Константин, 1974 .
^ Jump up to: ^а ^б Юрдон и Константин 1979 .
^ Макменамин, Стивен М.; Палмер, Джон Ф. (1984). Существенный системный анализ . Юрдон Пресс. ISBN 978-0-13-287905-7 .
^ Гавриэль Салвенди (2001). Справочник по промышленной инженерии: технологии и управление операциями. . стр.508.
^ Юрдон, Эдвард (1989). Современный структурный анализ . Прентис-Холл. ISBN 978-0-13-598632-5 .
^ Дэвид К. Хэй (1999) Достижение соответствия модным словечкам в объектной ориентации. Архивировано 20 октября 2008 г. в Wayback Machine Essential Strategies, Inc.
^ Jump up to: ^а ^б ^с Рабочая группа по архитектуре Министерства обороны США (2003 г.). DoDAF 1.5 Том 2 , 15 августа 2003 г.
^ Jump up to: ^а ^б ^с ^д ^и ^ж ^г Алан Хехт и Энди Симмонс (1986) Интеграция автоматизированного структурного анализа и проектирования со средами поддержки программирования Ada, НАСА, 1986.
^ Том ДеМарко (1978). Структурный анализ и спецификация системы . Юрдон Пресс, Нью-Йорк, 1978.
^ Управление проектом NDE . Архивировано 7 ноября 2008 г. на веб-сайте использования данных Wayback Machine (NPOESS). 2008.
^ Jump up to: ^а ^б Александр Косяков, Уильям Н. Свит (2003). Системная инженерия: принципы и практика с. 413.
^ Jump up to: ^а ^б ^с Глоссарий по интеграции данных. Архивировано 18 февраля 2012 г. в Wayback Machine , Министерство транспорта США, август 2001 г.
^ TechTarget, SearchSOA , Что такое словарь данных?
^ Краткое описание практики AHIMA, Рекомендации по разработке словаря данных , Журнал AHIMA 77, № 2 (февраль 2006 г.): 64A-D.
^ Джон Аззолини (2000). Введение в практику системной инженерии . Июль 2000 года.
^ В. Стивенс, Г. Майерс, Л. Константин, «Структурированный дизайн», IBM Systems Journal, 13 (2), 115–139, 1974.
^ Jump up to: ^а ^б «Управление конфигурацией» В: Ресурсы IRS. Часть 2. Информационные технологии Глава 27. Управление конфигурацией . По состоянию на 14 ноября 2008 г.
^ Джеймс Мартин , Карма Л. МакКлюр (1988). Структурированные методы: основа для дела . Прентис Холл. стр.56.
^ Дэвид Вольбер « Структурные диаграммы, заархивированные 19 февраля 2009 г. на Wayback Machine : Дополнительные примечания. Структурные диаграммы и реализация снизу вверх: версия Java.
^ Пейдж-Джонс 1980 .
^ Белкхуш, Б., и Дж. Э. Урбан. (1986). «Прямая реализация абстрактных типов данных из абстрактных спецификаций». В: IEEE Transactions on Software Engineering, стр. 549–661, май 1986 г.

Дальнейшее чтение

Стивенс, В.П .; Майерс, Дж.Дж .; Константин, LL (июнь 1974 г.). «Структурированный дизайн». IBM Systems Journal . 13 (2): 115–139. дои : 10.1147/sj.132.0115 .
Юрдон, Эдвард ; Константин, Ларри Л. (1979) [1975]. Структурное проектирование: основы дисциплины проектирования компьютерных программ и систем . Юрдон Пресс. ISBN 0-13-854471-9 .
Том ДеМарко (1978). Структурный анализ и спецификация системы . Юрдон. ISBN 0-91-707207-3
Пейдж-Джонс, М. (1980), Практическое руководство по проектированию структурированных систем , Нью-Йорк: Yourdon Press.
Дерек Дж. Хэтли, Имтиаз А. Пирбхай (1988). Стратегии спецификации систем реального времени . Джон Уайли и сыновья, ООО. ISBN 0-932633-04-8
Стивен Дж. Меллор и Пол Т. Уорд (1986). Структурированная разработка для систем реального времени: методы моделирования реализации: 003 . Прентис Холл. ISBN 0-13-854803-X
Эдвард Юрдон (1989). Современный структурированный анализ , Серия вычислений Yourdon Press, 1989, ISBN 0-13-598624-9
Кейт Эдвардс (1993). Структурированные методы реального времени, системный анализ . Уайли. ISBN 0-471-93415-1

Внешние ссылки

Структурный анализ вики
Три взгляда на структурированный анализ CRaG Systems, 2004.

[1] Триша Гилберт (2006) Критерии оценки FCS для оценки технологий. Архивировано 18 сентября 2008 г. на Wayback Machine.

[2] Эдвард Юрдон (1986). Управление структурированными методами: стратегии разработки программного обеспечения в 1990-е годы . Юрдон Пресс. стр.35.

[FAA00-3] Jump up to: ^а ^б ФАУ (2000). Руководство по безопасности системы ФАУ, Приложение D. 30 декабря 2000 г.

[DL00-4] Jump up to: ^а ^б Дэйв Левитт (2000). «Введение в структурный анализ и проектирование». на факультете.inverhills.edu/dlevitt . Проверено 21 сентября 2008 г. Больше не в сети в 2017 г.

[FOOTNOTEStevensMyersConstantine1974-5] Jump up to: ^а ^б Стивенс, Майерс и Константин, 1974 .

[FOOTNOTEYourdonConstantine1979-6] Jump up to: ^а ^б Юрдон и Константин 1979 .

[7] Макменамин, Стивен М.; Палмер, Джон Ф. (1984). Существенный системный анализ . Юрдон Пресс. ISBN 978-0-13-287905-7 .

[8] Гавриэль Салвенди (2001). Справочник по промышленной инженерии: технологии и управление операциями. . стр.508.

[9] Юрдон, Эдвард (1989). Современный структурный анализ . Прентис-Холл. ISBN 978-0-13-598632-5 .

[10] Дэвид К. Хэй (1999) Достижение соответствия модным словечкам в объектной ориентации. Архивировано 20 октября 2008 г. в Wayback Machine Essential Strategies, Inc.

[DoDAF_V2-11] Jump up to: ^а ^б ^с Рабочая группа по архитектуре Министерства обороны США (2003 г.). DoDAF 1.5 Том 2 , 15 августа 2003 г.

[HeSi86-12] Jump up to: ^а ^б ^с ^д ^и ^ж ^г Алан Хехт и Энди Симмонс (1986) Интеграция автоматизированного структурного анализа и проектирования со средами поддержки программирования Ada, НАСА, 1986.

[13] Том ДеМарко (1978). Структурный анализ и спецификация системы . Юрдон Пресс, Нью-Йорк, 1978.

[14] Управление проектом NDE . Архивировано 7 ноября 2008 г. на веб-сайте использования данных Wayback Machine (NPOESS). 2008.

[KoSw03-15] Jump up to: ^а ^б Александр Косяков, Уильям Н. Свит (2003). Системная инженерия: принципы и практика с. 413.

[USDT01-16] Jump up to: ^а ^б ^с Глоссарий по интеграции данных. Архивировано 18 февраля 2012 г. в Wayback Machine , Министерство транспорта США, август 2001 г.

[17] TechTarget, SearchSOA , Что такое словарь данных?

[18] Краткое описание практики AHIMA, Рекомендации по разработке словаря данных , Журнал AHIMA 77, № 2 (февраль 2006 г.): 64A-D.

[19] Джон Аззолини (2000). Введение в практику системной инженерии . Июль 2000 года.

[20] В. Стивенс, Г. Майерс, Л. Константин, «Структурированный дизайн», IBM Systems Journal, 13 (2), 115–139, 1974.

[IRT-21] Jump up to: ^а ^б «Управление конфигурацией» В: Ресурсы IRS. Часть 2. Информационные технологии Глава 27. Управление конфигурацией . По состоянию на 14 ноября 2008 г.

[22] Джеймс Мартин , Карма Л. МакКлюр (1988). Структурированные методы: основа для дела . Прентис Холл. стр.56.

[Wol-23] Дэвид Вольбер « Структурные диаграммы, заархивированные 19 февраля 2009 г. на Wayback Machine : Дополнительные примечания. Структурные диаграммы и реализация снизу вверх: версия Java.

[FOOTNOTEPage-Jones1980-24] Пейдж-Джонс 1980 .

[25] Белкхуш, Б., и Дж. Э. Урбан. (1986). «Прямая реализация абстрактных типов данных из абстрактных спецификаций». В: IEEE Transactions on Software Engineering, стр. 549–661, май 1986 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]