Войти
Пример подхода к структурированному анализу. В программной инженерии, структурированный анализ (SA) и структурированный дизайн (SD) являются методы анализа бизнес - требований и разработка спецификаций для преобразования практики в компьютерных программ, конфигурации оборудования и связанные с ними ручные процедуры.
Структурированный анализ и методы проектирования являются фундаментальными инструментами системного анализа. Они разработаны на основе классического системного анализа 1960-х и 1970-х годов.
Структурированный анализ стал популярным в 1980-х годах и используется до сих пор. Структурированный анализ состоит из интерпретации концепции системы (или реальных ситуаций) в терминологию данных и управления, представленную диаграммами потоков данных. Поток данных и управление от пузыря к хранилищу данных к пузырю может быть трудно отслеживать, и количество пузырей может увеличиваться.
Один из подходов состоит в том, чтобы сначала определить события из внешнего мира, на которые система должна реагировать, а затем назначить этому событию пузырек. Пузыри, которым необходимо взаимодействовать, затем соединяются до тех пор, пока не будет определена система. Пузыри обычно группируются в пузыри более высокого уровня, чтобы уменьшить сложность. Словари данных необходимы для описания потоков данных и команд, а также требуется спецификация процесса для сбора информации о транзакциях / преобразованиях.
SA и SD отображаются со структурными диаграммами, диаграммами потоков данных и диаграммами моделей данных, среди которых было много вариаций, в том числе разработанные Томом ДеМарко, Кеном Орром, Ларри Константином, Воном Фриком, Эд Юрдоном, Стивеном Уордом, Питером Ченом и другие.
Эти методы были объединены в различных опубликованных методологиях разработки систем, включая метод анализа и проектирования структурированных систем, прибыльную информацию по дизайну (PRIDE), структурированный анализ и проектирование Nastec, SDM / 70 и методологию разработки структурированных систем Spectrum.
Структурированный анализ является частью серии структурированных методов, которые представляют собой набор методов анализа, проектирования и программирования, которые были разработаны в ответ на проблемы, с которыми сталкивался мир программного обеспечения с 1960-х по 1980-е годы. В то время большая часть коммерческого программирования выполнялась на Cobol и Fortran, затем на C и BASIC. Практически не было указаний по "хорошему" дизайну и методам программирования, а также отсутствовали стандартные методы документирования требований и проектов. Системы становились больше и сложнее, а разработка информационных систем становилась все труднее и труднее ".
В качестве способа управления большим и сложным программным обеспечением с конца 1960-х годов появились следующие структурированные методы:
Согласно Hay (1999) « информационная инженерия была логическим продолжением структурированных методов, которые были разработаны в 1970-х годах. Структурированное программирование привело к структурированному дизайну, который, в свою очередь, привел к анализу структурированных систем. Эти методы характеризовались использованием диаграмм : структурные диаграммы для структурированного проектирования и диаграммы потоков данных для структурированного анализа, как для помощи в общении между пользователями и разработчиками, так и для повышения дисциплины аналитика и дизайнера. В 1980-х годах начали появляться инструменты, которые одновременно автоматизировали рисование диаграмм., и следил за тем, что нарисовано в словаре данных ". После примера автоматизированного проектирования и автоматизированного производства (CAD / CAM) использование этих инструментов было названо компьютерной инженерией программного обеспечения (CASE).
Пример структурированного анализа. Структурированный анализ обычно создает иерархию с использованием единого механизма абстракции. Метод структурированного анализа может использовать IDEF (см. Рисунок), управляется процессами и начинается с цели и точки зрения. Этот метод идентифицирует общую функцию и итеративно разделяет функции на более мелкие функции, сохраняя входы, выходы, элементы управления и механизмы, необходимые для оптимизации процессов. Также известный как подход функциональной декомпозиции, он фокусируется на связности внутри функций и связи между функциями, что приводит к структурированным данным.
Функциональная декомпозиция структурированного метода описывает процесс без описания поведения системы и диктует структуру системы в виде требуемых функций. Метод определяет входы и выходы, связанные с деятельностью. Одной из причин популярности структурированного анализа является его интуитивная способность передавать высокоуровневые процессы и концепции, будь то на уровне отдельной системы или предприятия. Неясно, как объекты могут поддерживать функции для коммерчески распространенной объектно-ориентированной разработки. В отличие от IDEF, UML управляется интерфейсом с несколькими механизмами абстракции, полезными при описании сервис-ориентированных архитектур (SOA).
Структурированный анализ рассматривает систему с точки зрения проходящих через нее данных. Функционирование системы описывается процессами, преобразующими потоки данных. Структурированный анализ использует преимущество сокрытия информации посредством последовательного декомпозиционного (или нисходящего) анализа. Это позволяет сосредоточить внимание на уместных деталях и избежать путаницы при рассмотрении нерелевантных деталей. По мере увеличения уровня детализации объем информации уменьшается. Результатом структурированного анализа является набор связанных графических диаграмм, описаний процессов и определений данных. Они описывают преобразования, которые должны произойти, и данные, необходимые для удовлетворения функциональных требований системы.
Подход структурированного анализа позволяет изучить как объекты процессов, так и объекты данных. Подход Де Марко состоит из следующих объектов (см. Рисунок):
Таким образом, диаграммы потоков данных (DFD) представляют собой ориентированные графы. Дуги представляют данные, а узлы (кружки или пузыри) представляют процессы, которые преобразуют данные. Далее процесс можно разложить на более подробный DFD, в котором показаны подпроцессы и потоки данных внутри него. Подпроцессы, в свою очередь, могут быть дополнительно разложены с помощью другого набора DFD до тех пор, пока их функции не будут легко поняты. Функциональные примитивы - это процессы, которые не требуют дальнейшей декомпозиции. Функциональные примитивы описываются спецификацией процесса (или мини-спецификацией). Спецификация процесса может состоять из псевдокода, блок-схем или структурированного английского языка. DFD моделируют структуру системы как сеть взаимосвязанных процессов, состоящих из функциональных примитивов. Словарь данных представляет собой набор записей (определения) из потоков данных, элементы данных, файлы и базы данных. Записи словаря данных разделены сверху вниз. На них можно ссылаться в других статьях словаря данных и в диаграммах потоков данных.
Пример контекстной диаграммы системы. Диаграммы контекста - это диаграммы, которые представляют участников вне системы, которые могут взаимодействовать с этой системой. Эта диаграмма является наивысшим уровнем вид в системе, подобной блок - схеме, показывая, возможно, программное обеспечение основе, системы в целом и ее входов и выходов от / к внешним факторам.
Этот тип диаграммы, согласно Коссякоффу (2003), обычно "изображает систему в центре, без деталей ее внутренней структуры, окруженную всеми ее взаимодействующими системами, средой и действиями. Цель диаграммы контекста системы - сосредоточить внимание на внешние факторы и события, которые следует учитывать при разработке полного набора системных требований и ограничений ». Диаграммы контекста системы связаны с диаграммой потока данных и показывают взаимодействия между системой и другими участниками, для которых система предназначена. Диаграммы контекста системы могут быть полезны для понимания контекста, в котором система будет частью разработки программного обеспечения.
Диаграмма отношений сущностей, необходимая для проектирования таблиц базы данных, выдержек и метаданных. А данные словарь или словарь базы данных является файлом, который определяет основную организацию базы данных. Словарь базы данных содержит список всех файлов в базе данных, количество записей в каждом файле, а также имена и типы каждого поля данных. Большинство систем управления базами данных скрывают словарь данных от пользователей, чтобы они случайно не уничтожили его содержимое. Словари данных не содержат фактических данных из базы данных, только бухгалтерскую информацию для управления ею. Однако без словаря данных система управления базой данных не может получить доступ к данным из базы данных.
Пользователи баз данных и разработчики приложений могут извлечь выгоду из авторитетного документа словаря данных, который каталогизирует организацию, содержание и условные обозначения одной или нескольких баз данных. Обычно это включает имена и описания различных таблиц и полей в каждой базе данных, а также дополнительные сведения, такие как тип и длина каждого элемента данных. Не существует универсального стандарта в отношении уровня детализации в таком документе, но это в первую очередь сводка метаданных о структуре базы данных, а не самих данных. Документ словаря данных также может включать дополнительную информацию, описывающую, как кодируются элементы данных. Одно из преимуществ хорошо продуманной документации по словарю данных заключается в том, что она помогает обеспечить согласованность всей сложной базы данных или большой коллекции интегрированных баз данных.
Пример диаграммы потока данных. Диаграмма потоков данных (DFD) представляет собой графическое представление «поток» данных через информационную систему. Она отличается от блок-схемы системы, поскольку показывает поток данных через процессы, а не через компьютерное оборудование. Диаграммы потоков данных были изобретены Ларри Константином, разработчиком структурированного дизайна, на основе модели вычислений Мартина и Эстрина «граф потока данных».
Обычно сначала рисуется контекстная диаграмма системы, которая показывает взаимодействие между системой и внешними объектами. DFD разработан, чтобы показать, как система делится на более мелкие части, и выделить поток данных между этими частями. Эта диаграмма потока данных на уровне контекста затем «разобранная», чтобы показать более подробную информацию о моделируемой системе.
Диаграммы потоков данных (DFD) - одна из трех основных точек зрения метода анализа и проектирования структурированных систем (SSADM). Спонсора проекта и конечных пользователей необходимо будет проинформировать и проконсультировать на всех этапах эволюции системы. С помощью диаграммы потока данных пользователи могут визуализировать, как система будет работать, что она будет выполнять и как система будет реализована. Диаграммы потоков данных старой системы могут быть составлены и сравнены с диаграммами потоков данных новой системы, чтобы провести сравнения для реализации более эффективной системы. Диаграммы потоков данных могут использоваться, чтобы предоставить конечному пользователю физическое представление о том, где данные, которые они вводят, в конечном итоге влияют на структуру всей системы от заказа до отправки и повторной обработки. Как создается любая система, можно определить с помощью диаграммы потока данных.
Схема структуры системы конфигурации. Структурная схема (СК) представляет собой график, который показывает пробую конфигурацию системы до самых низких приемлемых уровней. Эта диаграмма используется в структурном программировании для упорядочивания программных модулей в древовидной структуре. Каждый модуль представлен в виде поля, содержащего названия модулей. Древовидная структура визуализирует отношения между модулями.
Структурные диаграммы используются в структурированном анализе для определения проекта верхнего уровня или архитектуры компьютерной программы. В качестве инструмента проектирования они помогают программисту разделить и решить большую программную проблему, то есть рекурсивно разбить проблему на части, достаточно маленькие, чтобы их мог понять человеческий мозг. Этот процесс называется нисходящим дизайном или функциональной декомпозицией. Программисты используют структурную диаграмму для создания программы аналогично тому, как архитектор строит дом по чертежу. На этапе проектирования диаграмма рисуется и используется как средство общения между клиентом и разработчиками программного обеспечения. Во время фактического построения программы (реализации) диаграмма постоянно именуется мастер-планом.
Структурированный дизайн (SD) связан с разработкой модулей и синтезом этих модулей в так называемой «иерархии модулей». Для разработки оптимальной структуры модуля и интерфейсов решающее значение имеют два принципа:
Структурированный дизайн был разработан Ларри Константином в конце 1960-х, затем доработан и опубликован с соавторами в 1970-х; подробнее см. Ларри Константин: структурированный дизайн. Пейдж-Джонс (1980) предложил свой собственный подход, который состоит из трех основных целей:
В структуре диаграмма призвано показать «иерархию модулей или вызов последовательности отношение модулей. Существует спецификация модуля для каждого модуля, показанного на диаграммах структуры. Характеристики модуля могут состоять из псевдо-коды или языка разработки программ. В словаре данных похож на структурированный анализ. На этом этапе жизненного цикла разработки программного обеспечения, после того, как анализ и проектирование были выполнены, можно автоматически генерировать объявления типов данных », а также шаблоны процедур или подпрограмм.
Проблемы с диаграммами потоков данных включают следующее:
