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

Пример подхода к структурированному анализу.[1]

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

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

Цели структурного анализа

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

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

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

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

История

Структурированный анализ является частью серии структурированных методов, которые представляют собой набор методов анализа, проектирования и программирования, которые были разработаны в ответ на проблемы, с которыми столкнулся мир программного обеспечения с 1960-х по 1980-е годы. В этот период времени большая часть коммерческого программирования была сделана в Кобол и Фортран, тогда C и БАЗОВЫЙ. Практически не было указаний по "хорошему" дизайну и методам программирования, а также отсутствовали стандартные методы документирования требований и проектов. Системы становились больше и сложнее, а разработка информационных систем становилась все труднее и труднее ".[4]

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

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

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

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

Пример структурированного анализа.[11]

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

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

Подход

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

Подход структурированного анализа позволяет изучить как объекты процессов, так и объекты данных.[12]

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

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

Диаграмма контекста

Пример контекстной диаграммы системы.[14]

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

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

Словарь с данными

Диаграмма отношений сущностей, необходим для проектирования таблиц базы данных, выдержек и метаданных.[16]

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

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

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

Пример диаграммы потока данных.[19]

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

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

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

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

Схема структуры системы конфигурации.[21]

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

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

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

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

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

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

  • структурные диаграммы
  • спецификации модуля
  • словарь с данными.

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

Критика

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

  1. Правильный выбор пузырей
  2. Разделение пузырей осмысленным и взаимно согласованным способом,
  3. Размер документации, необходимый для понимания потоков данных,
  4. Диаграммы потоков данных имеют строго функциональный характер и поэтому часто изменяются.
  5. Хотя «поток данных» подчеркивается, моделирование «данных» - нет, поэтому понимание предмета системы мало.
  6. Заказчикам сложно понять, как концепция отображается в потоках данных и пузырях.
  7. Дизайнеры должны перевести организацию DFD в реализуемый формат.

Смотрите также

использованная литература

  1. ^ Триша Гилберт (2006) Критерии оценки FCS для оценки технологий В архиве 2008-09-18 на Wayback Machine
  2. ^ Эдвард Йордон (1986). Управление структурированными методами: стратегии разработки программного обеспечения в 1990-е годы. Yourdon Press. стр.35.
  3. ^ а б FAA (2000). Справочник по безопасности системы FAA, Приложение D. 30 декабря 2000 г.
  4. ^ а б Дэйв Левитт (2000). «Введение в структурированный анализ и дизайн». в faculty.inverhills.edu/dlevitt. Проверено 21 сентября 2008 г. Больше не в сети, 2017 г.
  5. ^ а б Стивенс, Майерс и Константин 1974.
  6. ^ а б Юрдон и Константин 1979.
  7. ^ McMenamin, Stephen M .; Палмер, Джон Ф. (1984). Важнейший системный анализ. Yourdon Press. ISBN  978-0-13-287905-7.
  8. ^ Гавриэль Салвенди (2001). Справочник промышленной инженерии: технологии и управление операциями.. с.508.
  9. ^ Йордон, Эдвард (1989). Современный структурный анализ. Прентис-Холл. ISBN  978-0-13-598632-5.
  10. ^ Дэвид К. Хэй (1999) Обеспечение соответствия модным словам в объектной ориентации В архиве 2008-10-20 на Wayback Machine Essential Strategies, Inc.
  11. ^ а б c Рабочая группа DoD Architecture Framework (2003). DoDAF 1.5 Том 2, 15 августа 2003 г.
  12. ^ а б c d е ж г Алан Хехт и Энди Симмонс (1986) Интеграция автоматизированного структурированного анализа и проектирования со средами поддержки программирования на Ada НАСА 1986.
  13. ^ Том ДеМарко (1978). Структурированный анализ и спецификация системы. Yourdon Press, Нью-Йорк, 1978.
  14. ^ Управление проектами неразрушающего контроля В архиве 2008-11-07 на Wayback Machine (NPOESS) Веб-сайт по эксплуатации данных. 2008 г.
  15. ^ а б Александр Косяков, Уильям Н. Свит (2003). Системная инженерия: принципы и практика п. 413.
  16. ^ а б c Глоссарий по интеграции данных В архиве 2012-02-18 в Wayback Machine, Министерство транспорта США, август 2001 г.
  17. ^ TechTarget, Поиск SOA, Что такое словарь данных?
  18. ^ Краткое описание практики AHIMA, Рекомендации по разработке словаря данных, Журнал AHIMA 77, № 2 (февраль 2006 г.): 64A-D.
  19. ^ Джон Аззолини (2000). Введение в практики системного проектирования. Июль 2000 г.
  20. ^ В. Стивенс, Г. Майерс, Л. Константин, «Структурированный дизайн», IBM Systems Journal, 13 (2), 115-139, 1974.
  21. ^ а б «Управление конфигурацией» В: Ресурсы IRS Часть 2. Информационные технологии Глава 27. Управление конфигурацией. По состоянию на 14 ноября 2008 г.
  22. ^ Джеймс Мартин, Карма Л. МакКлюр (1988). Структурированные методы: основа кейса. Прентис Холл. стр.56.
  23. ^ Дэвид Вольбер "Структурные диаграммы В архиве 2009-02-19 в Wayback Machine: Дополнительные примечания Структурные диаграммы и реализация снизу вверх: Версия Java.
  24. ^ Пейдж-Джонс 1980.
  25. ^ Belkhouche, B., and J.E. Urban. (1986). «Прямая реализация абстрактных типов данных из абстрактных спецификаций». В: IEEE Transactions по разработке программного обеспечения С. 549-661, май 1986 г.

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

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

внешняя ссылка