Средства структурного анализа и проектирования систем

Среди всех этапов ЖЦ ПО этап анализа считается самым ответственным, поскольку именно на нем производятся фундаментальные решения относительно системы, которые будут уточняться на последующих этапах. Этап анализа является первой фазой разработки ПО, на которой конкретизируются, формализуются и документируются требования заказчика. Список требований к системе содержит следующие пункты:

• совокупность эксплуатационных условий (аппаратные и программные ресурсы, внешние условия функционирования системы, состав людских ресурсов, работы, связанные с системой);
• описание функций, выполняемых системой;
• ограничивающие факторы, влияющие на разработку системы (директивные сроки окончания этапов; ресурсные ограничения, меры по защите информации и т.п.).

Главной целью анализа является преобразование этих неточных требований на точные определения. На этом этапе вырабатываются:
• архитектура и функции системы, требования к внешней среде, распределение функций между ПО и аппаратными средствами;
• интерфейсы и распределение функций между человеком и программной системой;
• требования к компонентам программной системы - программных и информационных, в частности к БД; требования к аппаратным ресурсам; физические характеристики компонентов ПО и их интерфейсы.

Структурный анализ предполагает такой подход к изучению системы, начинают с общего обзора ее, а затем постепенно переходят к более детальным уровней, образуя иерархию описаний. Главными принципами структурного анализа является принцип разделения на отдельные части и принцип иерархического упорядочивания. Кроме того, в этом анализе воплощаются принципы: абстрагирования, формализации, сокрытие несущественных деталей на каждом уровне; концептуального единства со всеми этапами ЖЦ; полноты и контроля относительно присутствия лишних элементов; непротиворечивости элементов, независимости логического проектирования от физического; структурирование данных; непосредственного доступа пользователя к БД.

Этап анализа предполагает разработку совокупности моделей, отражающих различные аспекты проблемы. Процессы и потоки информации, протекающих между ними, отображаются диаграммами потоков данных (DFD), информационные потребности разрабатываемой системы - диаграммами «сущность-связь» (ERD), временные аспекты функционирования - диаграммами переходов состояний (STD). Этап завершается формированием предыдущей архитектуры системы из совокупности моделей. Описания всех элементов моделей сосредотачиваются в словаре данных. В результате получают:
• модель ПО, представляющий собой совокупность моделей DFD, ERD и STD;
• словарь данных с описанием всех элементов моделей: потоков данных, хранилищ данных, процессов (в виде спецификаций), сущностей и их атрибутов, а также связей между сущностями (с описанием характера этих связей), состояний и переходов;
• план тестирования;
• предварительную архитектуру системы.

Полученная информация называется структурной спецификации на ПО и отображает требования к его разработке.

Структурное проектирование начинается с анализа предыдущей архитектуры, сформированной на этапе анализа. Анализ основывается на критериях качества, определенных для архитектуры. Архитектура системы носит логичный характер в том смысле, что она не привязана к конкретным языкам программирования, операционных систем и особенностей компьютера. Дальнейшая работа заключается в учете этих особенностей, благодаря чему получают физическую архитектуру. На этом же этапе проектируются БД и интерфейс пользователя. В результате получают:
• архитектуру системы в виде структурных карт, на которых отображена программные модули и связи между ними;
• проект БД и интерфейса пользователя;
• словарь данных, содержащий описание системных данных;
• спецификации модулей с описанием их назначения и особенностей;
• проект архитектурных тестов (в которых модули рассматриваются как «черный ящик» без учета их внутренней структуры).

Эта информация передается на последующие этапы создания ПО.
Среди разнообразия средств структурного анализа и проектирования центральное место занимают диаграммы потоков данных (DFD) вместе со словарями данных и спецификациями процессов, или мини-спецификациями, диаграммы «сущность-связь» (ERD) и диаграммы переходов состояний (STD).

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

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

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

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

Процессы предназначены для показа обработки данных, в результате которой на основе входных потоков образуются выходные. Имя процесса отражает действие, в нем происходит, и состоит из глагола в неопределенной форме и приложения (например, РАССЧИТАТЬ ОСТАТОК МАТЕРИАЛОВ). Каждому процессу должен быть присвоен уникальный номер внутри диаграммы. Вместе с номером диаграммы этот номер образует уникальный индекс процесса во всей модели.

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

Внешняя сущность (терминатор) представляет собой сущность вне контекста системы, что является источником или приемником системных данных. Имя внешней сущности должен содержать существительное (например, поставщиков материалов). Предполагается, что объекты, представленные такими узлами, не принимают участия ни в одной обработке.

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

DFD первого уровня представляет собой декомпозицию процесса, присутствующего на контекстной диаграмме; DFD второго уровня детализируют процессы диаграммы первого уровня и т. д. Этот процесс повторяется до тех пор, пока дальнейшая детализация процессов с помощью диаграмм потоков данных не потеряет смысла. Тогда процессы нижнего уровня описывают с помощью коротких (до одной страницы) мини-спецификаций обработки (спецификаций процессов). Номера процессов, как правило, образуются добавлением к номеру процесса высшего уровня (например, 2.2) порядковых номеров процессов в рамках диаграммы, его детализирует (например, 2.2.1, 2.2.2).

Информационные потоки могут иметь в своем составе несколько независимых потоков; такие потоки называются групповыми. Операции расщепления и объединения потоков данных обозначаются групповым узлом. Для обеспечения декомпозиции данных и некоторых других сервисных возможностей в DFD используются следующие типы объектов:

• узел-предок - предоставляет возможность связывать входящие и исходящие потоки между процессом, детализируется, и DFD, что его детализирует;
• групповой узел - предназначен для расщепления и объединения потоков данных. Иногда он отсутствует, т.е. вырождается в точку слияния / расщепления потоков на диаграмме;
• неиспользуемый узел - применяется для декомпозиции данных, если нужны не все элементы входного потока;
• узел изменении имени позволяет неоднозначно именовать потоки с эквивалентным содержанием. Используется тогда, когда нужно установить идентичность между двумя разноименными потоками. При этом один из них является входным для данного узла, а другой - выходным.

Текст - в произвольном формате используется в любом месте диаграммы.
Для отражения в DFD аспектов управления в системах реального времени используются специальные символы.

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

Управляющее хранилище содержит управляющую информацию, после занесения ее в хранилище может использоваться в любое время и в любом порядке. Имя управляющего хранилища должно соответствовать его содержанию и быть существительным.

Управляющий поток представляет собой «проводник» для управляющей информации. Последняя, ​​как правило, подается дискретными сигналами. Его имя состоит из существительных и прилагательных. Управляющие потоки могут как сообщать управляющему процесса об изменениях внешних условий, так и выполнять команды, которые он генерирует. При этом режим выполнения управляющего процесса зависит от типа управляющего потока. Используются следующие типы управляющих потоков:

• Т-поток (trigger flow) - управляющий поток, который может вызвать выполнение процесса с помощью одной короткой операции. Он действует так же, как выключатель света, единственное нажатие на который вызывает засветки электрической лампы;
• А-поток (activator flow) - управляющий поток, который может изменять исполнение отдельного процесса, а именно: обеспечивать непрерывное выполнение процесса (подпроцесса), пока поток «включен», то есть течет непрерывно, с «выключением» потока выполнения процесса (подпроцесса ) заканчивается. Действительно, как переключатель электрической лампочки, способный работать при ее включения и выключения;
• E / D-поток (enable / disable flow) - поток управления процессом, который может переключать выполнение отдельного процесса. Пока управляющая информация поступает по Е-линии, процесс продолжается, при возбуждении
D-линии - прекращается. Это аналог выключателя с двумя кнопками: одна - для включения света, другая - для выключения. Можно использовать три типа таких потоков: Е-поток, D-поток, E / D-поток.

Узел изменении типа используется для изменения типа управляющего потока, а также для замены типа потока данных на тип управляющего потока и наоборот. При этом содержание потока не меняется.

Построение иерархии диаграмм потоков данных (DFD) полезно осуществлять в такой ослидовности:

• Изучение множества требований и распределение их на несколько основных функциональных групп.
• Идентификация внешних объектов, с которыми предстоит связанная система, и основных видов информации, циркулирующей между объектами и системой.
• Разработка предварительного варианта контекстной диаграммы, на которой основные функциональные группы представляются процессами, внешние объекты - внешними сущностями, основные виды информации - потоками данных между процессами и внешними сущностями.
• Анализ предыдущей контекстной диаграммы и внесение в нее изменений по результатам анализа.
• Построение контекстной диаграммы объединением всех процессов предварительной диаграммы в один процесс, а также группировкой потоков данных.
• Формирование DFD первого уровня на базе процессов предварительной контекстной диаграммы.

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

Примером построения контекстной DFD может быть диаграмма процесса автоматизации оприходования материальных ценностей, поступающих на склад от поставщиков


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

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

• описание содержимого потоков и хранилищ, изображенных на DFD;
• описание композиции агрегатов данных (комплексных данных) в составе потоков и хранилищ;
• уточнение значений и областей действия элементарных фрагментов информации в потоках данных и хранилищах;
• описание отношений между хранилищами.

Описание потока данных в словаре содержит имя потока, его тип и атрибуты. Описание состоит из набора статей, каждая из которых начинается с символа «@» и ключевого слова - заголовка статьи.

Информация по типу потока определяет:
• простые (элементарные) и групповые (комплексные) потоки;
• внутренние (существующие внутри системы) и внешние (связывающие систему с другими системами) потоки;
• потоки данных или управляющие потоки;
• непрерывные (приобретаемых любых значений из определенного диапазона) или дискретные (что приобретают лишь определенных значений) потоки.

Атрибуты потока данных могут включать:
• имена-синонимы потока данных в соответствии с узлов изменении имени;
• БНФ (определение в форме Бэкуса-Наура) - определение для групповых потоков;
• единицы измерения потока;
• диапазон значений для непрерывных потоков и список значений и смысл их - для дискретных потоков;
• список номеров диаграмм различных типов, к которым может принадлежать поток;
• список групповых потоков, включающий данный поток (как элемент БНФ-определения);
• комментарий с дополнительной информацией.

Для формального описания раздела и объединения потоков может быть использовано БНФ-определение. При этом важно, чтобы каждый компонент потока-предка был именуемым. Объединяя пидпотокы, не обязательно удалять общие компоненты, а в случае разделения потоков пидпотокы могут иметь одинаковые компоненты.

БНФ-определение хранится в словаре данных в так называемой БНФ-статье. БНФ-статья используется для описания компонентов данных в потоках данных и в хранилищах и имеет следующий синтаксис:

@ БНФ = <простой оператор>! <БНФ-выражение>,
где <простой оператор> - это текстовое описание, взятый в «/», а <БНФ-выражение> является выражением в форме Бэкуса-Наура, который допускает операции отношение, толкуются так:
= - «Композиция из»;
1).
[! ] - «ИЛИ»;
() - Компонент в скобках необязательный;
{} - Повторение компонента в скобках;
«» - Литерал.
При указании количества повторений число перед скобкой указывает нижний предел повторения, а число после скобки - верхнюю. Например:
3 {сигнал} 7 - от 3 до 7 сигналов.
Пример описания потока данных с помощью БНФ:
@ Имя = двоичная цифра;
@ ТИП = дискретный поток;
@ БНФ = "0"! 1.

Спецификации процессов

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

Спецификация процесса начинается с описания входных и выходных данных, после чего указывается ключевое слово, например @ СПЕЦПРОЦ:
@ ВХОД = <имя элемента данных>
@ ВЫХОД = <имя элемента данных>
@ СПЕЦПРОЦ <номер и / или имя процесса>,
где <имя элемента данных> - соответствующее имя из словаря данных.
Если элемент данных одновременно является входным и выходным для процесса, он может быть описан дважды с помощью @ ВХОД и
@ ВЫХОД или единовременно при помощи @ ВХОД / ВЫХОД.
Для описания тела процесса существует много методов, среди которых можно выделить структурированную естественный язык, или псевдокод, визуальные языки проектирования (FLOW-формы и диаграммы Насс-Шнейдермана) и формальные компьютерные языки.

Диаграммы «сущность-связь»

Диаграммы «сущность-связь» (ERD) предназначены для моделирования представления данных в программных системах. С их помощью идентифицируются информационные объекты (сущности) системы, их свойства (атрибуты) и отношения между объектами (связи).
Нотация ERD была разработана Ченом и получила развитие в работах Баркера, Бахмана и других ученых.

Сущность представляет собой множество экземпляров некоторого объекта (реального или абстрактного), которые имеют общие характеристики, или атрибуты. Отношение определяет взаимоотношения двух или более сущностей. Имя отношение включает глагол (например, ВЛАДЕЕТ, ОПРЕДЕЛЯЕТ, МОЖЕТ ИМЕТЬ).

Независимая сущность представляет независимые объекты, всегда присутствуют в системе, которые могут не иметь отношений с другими сущностями. Зависимая сущность представляет данные, зависящие от других сущностей. Ассоциированная сущность представляет объекты, ассоциированные с двумя и более сущностями.

Неограниченное (обязательное) отношение представляет собой безусловное отношение, т.е. отношение, существующее до тех пор, пока существуют сущности, между которыми оно установлено. Ограничено (необязательное) отношение представляет собой условное отношение между сущностями. Существенно ограничено отношение используется, если соответствующие сущности являются взаимозависимыми.

Между отношениями и сущностями в диаграмме устанавливаются связи, направленные от отношения к сущности. Значение связи характеризует количество экземпляров сущности, участвующих в любом отношении («0 или 1», «0 и больше», «1», «1 и более», «p: q»). Пара значений связей отношение определяет тип данного отношения. Основные типы отношений следующие: 1 * 1 (один к одному), 1 * n (один ко многим), n * m (многие ко многим).
Фрагмент ER-диаграммы, отображающий отношение между сущностями системы учета материальных ценностей на складе.

Сущности детализируются при помощи диаграмм атрибутов. Последние включают в себя сущность, детализируется, атрибуты сущности, домены, описывающие области значений атрибутов, и связи. Для обозначения ключевого атрибута его имя подчеркивается.

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

В других нотациях ERD связи между объектами могут изображаться одиночными и сдвоенными стрелками. Необязательный связь может сказываться пунктирной линией, тип соотношение - буквой рядом со связью и т.п.

Основные этапы разработки ERD следующие:
1. Идентификация атрибутов, агрегация сущностей, а также первичных и альтернативных ключей.
2. Нормализация сущностей, т.е. разделение групп атрибутов, устранение неполной функциональной зависимости от ключей, транзитивной зависимости между неключевых атрибутами, множественной зависимости.
3. Идентификация отношений между сущностями и их типов.
4. Проверка ERD на корректность.

Заметим, что этап 2 предусматривает использование теории нормализации Е. Ф. Кодда. Этот ученый установил существование трех типов нормализованных схем - первой, второй и третьей нормальной формы (соответственно, 1НФ, 2НФ, 3НФ) с раскрывающимся степени сложности.

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

В состав STD входят следующие структурные единицы:

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

Исходное состояние - узел STD, который является стартовой точкой для начального системного перехода. STD имеет только один исходное состояние, соответствующее состоянию системы после установки ее перед началом обработки, а также любую конечное количество конечных состояний.

Переход - определяет перемещение системы из одного состояния в другое. Имя перехода идентифицирует некоторое событие (условие), что является причиной перехода и руководит им. Это условие может быть связана с управляющим потоком, возникает внутри системы или поступает извне. Если в условии участвует управляющий поток управляющего процесса-родителя, то имя управляющего потока берется в кавычки (например, ПЕРЕКЛЮЧАТЕЛЬ = «корректно ПАРОЛЬ»).
Кроме условия с переходом может быть связано действие или последовательность действий, выполняемых при переходе. Если это действие касается выбора выходного управляющего потока, то имя этого потока должна быть также взято в кавычки (например, «ВЫБОР ФУНКЦИИ» = TRUE, где ВЫБОР ФУНКЦИИ - выходной поток).

Кроме того, при спецификации управляющих потоков типа А-, Т-, E / D-имя процесса, запускается или переключается, также берется в кавычки. Например:
А: «ПОЛУЧИТЬ ПАРОЛЬ» - активизировать процесс ПОЛУЧИТЬ ПАРОЛЬ.

На STD состояния подаются узлами, а переходы - ориентированными дугами. Условия, либо стимулирующие события, идентифицируются именем перехода. Действия, или отзывы на события, привязываются к переходу и записываются под соответствующим условием. Исходное состояние на диаграмме должен иметь входной переход от стартового узла, который может не изображаться на схеме или подаваться в виде небольшого квадрата.

При построении STD рекомендуется строить первую STD на возможно более высоком уровне обобщения DFD, а дальше по возможности детализировать ее. При построении STD следует контролировать определения всех сословий и уникальность их имен, достижимость состояний, наличие выходов во всех состояний, наличие реакции системы на все условия, отображение всех входящих и исходящих потоков управляющего процесса в условиях и действиях на STD.

Структурные карты

В предыдущих подразделах были рассмотрены средства поддержки структурного системного анализа, применяемые для построения логической модели системы, т.е. модели требований. Логическая модель объединяет множество взаимосвязанных диаграмм (DFD, ERD, STD), спецификаций процессов, текстов и словаря данных. Вместе они показывают, что именно будет делать система, но не объясняют, благодаря чему это будет происходить.

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

Техника структурных карт используется на фазе проектирования для построения программной структуры системы. Чаще всего применяются две техники: структурные карты Константайн, предназначенные для отображения отношений между модулями, и структурные карты Джексона, предназначенные для представления внутренней структуры модулей.

Методологии структурного анализа и проектирования систем

Методология структурного анализа и проектирования ПО представляет собой совокупность правил и методов для определения шагов работы при создании ПО и их последовательности, для выбора средств и назначение операций, а также для оценки проекта ПО.

В последнее время среди всех методологий структурного анализа и проектирования наиболее распространенные методологии SADT (Structured Analysys and Design Technique), структурного системного анализа Гейна-Сарсона, структурного анализа и проектирования Йордана-Де Марко, развития систем Джексона, развития структурных систем Варнье-Орра, анализа и проектирование систем реального времени Уорда-Мэллори и Хатли, информационного моделирования Мартина.

Структурные методологии регламентируют фазы анализа требований и проектирования спецификаций и предоставляют точные указания для перехода от спецификаций требований к проекту архитектуры программной системы и проектных спецификаций, предлагают методику трансляции проектных спецификаций в модель реализации, что дальше будет использована при кодогенерации. Кодогенерации выполняется в рамках кодовых стандартов, определяющих формат заголовков подпрограмм, ступенчатый вид вложенных блоков, номенклатуру для спецификации переменных и имен подпрограмм и т.д.

Методологии структурного системного анализа и проектирования используют много разнообразных средств и диаграммных техник. Основные из них:
• диаграммы потоков данных в нотации Йордана-Де Марко или Гейна-Сарсона, обеспечивающие анализ требований и функциональное проектирование информационных систем;
• методики Хатли и Уорда-Мэллори проектирования систем реального времени, основанные на диаграммах переходов состояний, таблицах и деревьях решений, картах и ​​схемах потоков управления;
• диаграммы «сущность-связь» (в нотации Чена или Баркера) или скобочные диаграммы Варнье-Орра для проектирования структур данных, схем БД, форматов файлов;
• структурные карты Джексона и Константайн для проектирования межмодульных структуры программ и внутренней структуры модулей.

Классификация методологий структурного анализа и проектирования

Структурные методологии анализа и проектирования в зависимости от признака классификации подразделяются на следующие группы.

• По принадлежности к школ проектирования систем - на инжиниринг ПО (Software Engineering, SE) и информационный инжиниринг (Information Engineering, IE). Методология SE воплощает нисходящий поэтапный подход к разработке ПО, согласно которым определяются и постепенно детализируются функции системы с созданием иерархически организованной модульной программы. Методология IE представляет сравнительно новую школу, изучающая создание информационных систем и охватывает этапы высокого уровня, такие как стратегическое планирование.

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

Процедурно-ориентированный подход при проектировании основывается на том, что процедуры обработки считаются первостепенными, а структуры данных - второстепенными; требования к данным определяются в результате анализа функциональных требований.

За информационно-ориентированного подхода основное внимание направляется на изучение входов и выходов системы и разработки структур данных, после которого проектируют функциональные процедуры.

Подход, ориентированный на данные, отличается от информационно-ориентированного подхода тем, что позволяет работать только с иерархическими структурами данных.
• По типу целевых систем - на методологии для систем реального времени (СРЧ) и для информационных систем (ИС). Эти типы методологий направленные на поддержку особенностей соответствующих систем.