Основы структурного анализа
Структурный анализ. Структурный анализ является методологической разновидностью системного анализа
Структурный анализ является методологической разновидностью системного анализа. Он был разработан в 60-70-х годах XX века Дугласом Т. Россом в виде методологии SADT (Structured Analysis and Design Technique)— технология структурного анализа и проектирования.
В основе структурного анализа лежат:
· выявление структуры как относительно устойчивой совокупности отношений,
· признание методологического примата отношений над элементами в системе,
· частичное отвлечение от развития объектов.
Основное понятие структурного анализа — это структурный элемент (объект) — элемент, выполняющий одну из элементарных функций, связанных с моделируемым предметом, процессом или явлением.
Структурный анализ предполагает исследование системы с помощью ее графического модельного представления, которое начинается с общего обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней. Для такого подхода характерны:
· разбиение абстракций на уровни с ограничением числа элементов на каждом уровне (обычно от 3 до 9);
· ограниченный контекст, включающий лишь существенные на каждом уровне детали;
· использование строгих формальных правил записи;
· последовательное приближение к конечному результату.
Цель структурного анализа заключается в преобразовании общих, расплывчатых знаний о предметной области в точные модели, описывающие различные подсистемы моделируемой организации.
Декомпозиция (рис. 3.7) является условным приемом, позволяющим представить систему в виде, удобном для восприятия, и оценить ее сложность. В результате декомпозиции подсистемы по определенным признакам выделяются отдельные структурные элементы и связи между ними. Глубина декомпозиции определяется сложностью и размерностью системы, а также целями моделирования.
Заметим, что ни одна отдельно взятая подсистема не обеспечивает моделирование бизнес-процессов полностью. Поэтому для получения целостной картины деятельности организации необходимо взять за основу описание одной из выделенных структур и интегрировать его с остальными. На практике, основой для такой интеграции чаще всего служит функциональная или информационная подсистема.
Организация, как правило, имеет большое количество подсистем, поэтому число структурных элементов и связей между ними весьма велико.
Каждый структурный элемент (или объект) и связь обладают определенными свойствами, которые должны быть описаны (рис. 8). Одной из разновидностей свойств являются атрибуты.
Атрибут — необходимое, существенное, неотъемлемое свойство объекта. Естественно, что разные структурные элементы имеют различные наборы атрибутов.
Рис.3.7. Декомпозиция подсистемы организации на структурные элементы
Объект или связь имеет также набор характеристик (рис. 3.8), при помощи которых можно задать количественные и качественные характеристики моделируемых элементов.
Рис.3.8. Характеристики структурных элементов и связей
В частности, для каждой функции можно задать:
· уникальный код в проекте,
· временные затраты на выполнение данной функции
· стоимостные затраты на выполнение данной функции и т. д.
Характеристики объектов и связей формализованы и используются при проведении анализа или составлении отчета.
Тема 2. Классический подход к разработке программных средств
Оглавление по теме
2.1. Классические методы анализа
Системный анализ проводится с целью:
- выяснения потребностей заказчика;
- оценки выполнимости системы;
- выполнения экономического и технического анализа;
- распределения функций по элементам компьютерной системы (аппаратуре, программам, людям, базам данных);
- определения стоимости и ограничений планирования;
- создания системной спецификации.
В системной спецификации описываются:
- функции;
- характеристики системы;
- ограничения разработки;
- входная и выходная информация.
Анализ требований дает возможность:
- определить функции и характеристики программного продукта;
- обозначить интерфейс продукта с другими системными элементами;
- определить проектные ограничения программного продукта;
- построить модели процесса, данных, а также режимов функционирования продукта;
- создать такие формы представления информации и функций системы, которые можно использовать в ходе проектирования.
Результаты анализа сводятся в спецификацию требований к программному продукту. Анализ требований служит мостом между неформальным описанием требований заказчика и проектированием системы.
Известно два подхода к разработке ПО:
- Функционально-модульный или структурный.
- Объектно — ориентированный подход.
Функционально-модульный подход основан на принципе функциональной декомпозиции. При этом структура системы описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами.
Объектно-ориентированный подход использует объектную декомпозицию.
Классические методы анализа требований ориентированы на процедурную реализацию программных систем.
2.1.1. Структурный анализ
Структурный анализ — один из формализованных методов анализа требований к ПО.
Все известные методы структурного подхода базируются на ряде общих принципов :
- принцип «разделяй и властвуй»;
- принцип иерархического упорядочения — принцип организации составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне;
- принцип абстрагирования — выделение существенных аспектов системы и отвлечение от несущественных;
- принцип непротиворечивости — обоснованность и согласованность элементов системы;
- принцип структурирования данных — данные должны быть структурированы и иерархически организованы.
В структурном подходе используются средства, описывающие функциональную структуру системы и отношения между данными. Им соответствуют следующие виды моделей (диаграмм):
- DFD (Data Flow Diagrams) — диаграммы потоков данных;
- SADT (Structured Analysis and Design Technique) — метод структурног o анализа и проектирования;
- ERD (Entity-Relationship Diagrams) — диаграммы «сущность — связь».
DFD и ERD — наиболее часто используемые в CASE-cредствах виды моделей. Основной элемент структурного анализа — диаграммы потоков данных (DFD-data flow diagrams). Конкретный вид диаграмм и интерпретация их конструкций зависят от стадии разработки ПО. Программное изделие рассматривается как преобразователь информационного потока данных.
Диаграммы потоков данных — графическое средство для изображения информационного потока и преобразований, которым подвергаются данные при движении от входа к выходу системы. Диаграмма может использоваться для представления программного изделия на любом уровне абстракции.
Рис. 1. Элементы диаграммы потоков данных
Рис. 2. Диаграмма потоков данных
Контекстная модель используется для указания внешних связей программного изделия. Для детализации (уточнения системы) вводится диаграмма 1-го уровня. Каждый из преобразователей этой диаграммы — подфункция общей системы. Дальнейшее уточнение приводит к диаграмме 2-го уровня.
- Важно сохранить непрерывность информационного потока и его согласованность.
- Входы и выходы у каждого преобразователя на любом уровне должны оставаться прежними (принцип наследования).
В диаграмме отсутствуют точные указания на последовательность обработки, которые откладываются до этапа проектирования. Диаграмма потоков данных — это абстракция, граф. Для связи графа с проблемной областью (превращения в граф-модель ) надо задать интерпретацию ее компонентов — дуг и вершин.
Описание потоков данных и процессов
Базовые средства диаграммы не обеспечивают полного описания требований к программному изделию. Должны быть описаны стрелки (потоки данных) и преобразователи (процессы). Для этих целей используются словарь требований (данных) – глоссарий и спецификации процессов. Глоссарий содержит описания потоков данных и хранилищ данных. Глоссарий является элементом любого CASE-средства автоматизации анализа.
Структура словаря зависит от особенностей конкретного CASE-средства:
- Имя (основное имя элемента данных, хранилища или внешнего объекта).
- Прозвище (Alias) — другие имена того же объекта.
- Где и как используется объект — список процессов, которые используют данный элемент, с указанием способа использования (ввод в процесс, вывод из процесса, как внешний объект или как память.
- Описание содержания — запись для представления содержания.
- Дополнительная информация — дополнительные сведения о типах данных, допустимых значениях, ограничениях и т. д.
Спецификация процесса — это описание преобразователя.
- ввод данных в преобразователь;
- алгоритм обработки;
- характеристики производительности преобразователя;
- формируемые результаты.
Количество спецификаций равно количеству преобразователей диаграммы.
Рис. 3. Поток данных и процессов
2.1.2. Методы анализа, ориентированные на структуры данных
Элементами проблемной области для любой системы являются потоки, процессы и структуры данных. При структурном анализе активно работают только с потоками данных и процессами.
Методы, ориентированные на структуры данных, обеспечивают:
- определение ключевых информационных объектов и операций;
- определение иерархической структуры данных;
- компоновку структур данных из типовых конструкций — последовательности, выбора, повторения;
- последовательность шагов для превращения иерархической структуры данных в структуру программы.
Наиболее известны два метода: метод Варнье—Орра и метод Джексона .
В методе Варнье-Орра для представления структур применяют диаграммы Варнье. Для построения диаграмм Варнье используют 3 базовых элемента: последовательность, выбор, повторение (Рис. 4).
Рис. 4. Базовые элементы
Как показано на Рис. 5, с помощью этих элементов можно строить информационные структуры с любым количеством уровней иерархии.
Рис. 5. Информционная структура
Как видим, для представления структуры газеты здесь используются три уровня иерархии.
Метод анализа Джексона.
Как и метод Варнье—Орра, метод Джексона появился в период революции структурного программирования. Оба метода решали одинаковую задачу: распространить базовые структуры программирования (последовательность, выбор, повторение) на всю область конструирования сложных программных систем.
Метод Джексона (1975) включает 6 шагов. Три шага выполняются на этапе анализа, а остальные — на этапе проектирования.
- Объект—действие. Определяются объекты — источники или приемники информации и действия — события реального мира, воздействующие на объекты.
- Объект—структура. Действия над объектами представляются диаграммами Джексона.
- Начальное моделирование. Объекты и действия представляются как обрабатывающая модель. Определяются связи между моделью и реальным миром.
- Доопределение функций. Выделяются и описываются сервисные функции.
- Учет системного времени. Определяются и оцениваются характеристики планирования будущих процессов.
- Реализация. Согласование с системной средой, разработка аппаратной платформы.
Шаг объект—действие. Этот шаг начинается с определения проблемы на естественном языке. При выделении объектов и действий возможны ошибки. Но список объектов и действий может модифицироваться в ходе дальнейшего анализа.
Шаг объект—структура. Структура объектов описывает последовательность действий над объектами (в условном времени). Для представления структуры объектов Джексон предложил 3 типа структурных диаграмм. Они показаны на Рис. 6.
В первой диаграмме к объектам применяется такое действие, как последовательность, во второй — выбор, в третьей — повторение.
Принципы структурного анализа
Структурный анализ занимает важное место в общей технологии прикладного системного анализа, обеспечивая решение задачи построения и усовершенствования моделей автоматизируемого объекта при помощи графических нотаций моделирования.
Таким образом, полученные модели являются основой для последующих этапов прикладного системного анализа – проектирования ПС, улучшающего деятельность исследуемого объекта.
Понятно, что от адекватности построенной модели зависит и достижение целей, поставленных перед проектом разработки ИС. Таким образом, построение модели – одна из важнейших задач прикладного системного анализа как инструмента выработки улучшающих вмешательств.
При этом процесс моделирования сложных систем (включая, конечно, и организационные) все еще достаточно далек от того, чтобы быть в полном смысле «технологией» – изученным, понятным и повторяемым процессом, ведущим к гарантированному результату.
В процессе разработки модели необходимо, во-первых, изучить систему, понять ее, а во-вторых, задокументировать полученное знание. Очевидно, что знание, не зафиксированное в виде описания на основе одной из стандартных нотаций моделирования, бесполезно для выработки улучшающего вмешательства, а значит, фактически, оно и не существует с точки зрения прикладного системного анализа.
Следует также помнить, что используемый при создании модели язык должен быть понятен для всех заинтересованных в проекте лиц – стейкхолдеров. Если это условие не выполнить, то у аналитиков возникнет проблема с доведением разработанного вмешательства до стейкхолдеров, они не смогут оценить, насколько оно соответствует их интересам в проблемной ситуации, а значит, будет очень высок риск того, что полученное решение не станет улучшающим вмешательством.
Важным условием адекватности модели является также её соответствие набору языков, терминологии предметной области. Аналитик должен обеспечить отражение в модели при помощи средств выбранной стандартной нотации моделирования понятийного аппарата всех предметных областей, задействованных в проблемной ситуации. Поскольку же аналитик редко является специалистом во всех предметных областях (да это и не является для него необходимым), то при построении структурной модели неизбежно возникает ряд взаимосвязанных проблем:
· аналитику сложно получить исчерпывающую информацию для построения с точки зрения всех стейкхолдеров;
· стейкхолдеры, в свою очередь, не обладают знанием о построении моделей для того, чтобы судить, какая информация для модели существенна, а какая – нет;
· аналитик сталкивается с чрезмерным количеством подробных сведений как о предметной области, так и о новой системе;
· возникает риск, что модель, перегруженная информацией, будет, во-первых, сложной (то есть, ее невозможно обработать за требуемое время), а во-вторых, из-за большого объема, она будет непонятна для клиента и других стейкхолдеров;
· модель, понятная заказчику и стейкхолдерам, может оказаться недостаточной для решения задачи.
Эти проблемы могут быть существенно облегчены за счет следования следующим принципам структурного анализа систем.
· Принцип разбиения (декомпозиции) системы на подсистемы (элементы). Этот принцип эксплуатирует такие свойства систем, как неоднородность и структурированность;
· Принцип выделения в модели уровней абстракции. Данный принцип опирается на утверждение о том, что каждый элемент системы также является системой и, соответственно, может быть разбит на подсистемы. А, следовательно, при выделении соответствующих основании классификации подсистем может быть построена иерархическая классификация системы на подсистемы. В данном случае основание классификации – например, детальность и сложность бизнес-процессов или положение подразделения на уровне управления – и описывает уровень абстракции.
· Принцип ограниченного смыслового контекста, согласно которому каждый уровень абстракции должен включать лишь существенные на этом уровне детали. Данный принцип дополняет предыдущий – разрабатываемая классификация системы на подсистемы не должна содержать нарушений оснований классификации по уровням. Так в организационной структуре нежелательно смешивать на одном уровне управления дирекции с отделами и секторами.
· Принцип ограничения числа элементов (подсистем) на каждом из уровней абстракции (не менее 2-3 и не более 7-8). Минимальное количество определяется соображением здравого смысла – декомпозиция системы на одну подсистему не добавляет в модель новой информации. Максимальное количество определяется соображениями читаемости модели – большее количество элементов уже не воспринимается разумом человека как единая система.
· Принцип иерархического упорядочения объектов модели в ее описании. Данный принцип непосредственно следует из того, что при выделении подсистем в описываемой системе используется иерархическая классификация. Понимание проблемной ситуации резко облегчается, если описание ее частей организовано в древовидные иерархические структуры, то есть она может быть понята и построена по уровням абстракции, каждый из которых добавляет новые детали.
· Принцип двойственности данных и операций над ними. Данный принцип следует из таких свойств системы, как функциональность (она определяет активность каждого элемента, его соответствие операциям), а также эмеджентность системы (свойства системы определяются не только составом элементов, но и отношениями между ними) и ее неразрывность (исключение из рассмотрения части элементов и / или части связей может и, скорее всего, изменит фундаментальные свойства системы). Из этого принципа следует также идея инкапсуляции (упрятывания) несущественной на конкретном этапе информации. Каждая подсистема «распоряжается» только необходимой ей информацией.
· Принцип использования строгих формальных правил записи. Данный принцип вытекает из требований полноты и непротиворечивости построенных моделей, а также их соответствия набору языков проблемной ситуации.
· Принцип концептуальной общности (следующий из предыдущего принципа использования строгих формальных правил записи). Заключается в использовании единого подхода на всех стадиях прикладного системного анализа (структурный анализ проблем – структурное целеполагание – структурное моделирование – структурное проектирование и принятие решений – структурное внедрение).
· Принцип последовательного приближения к конечному результату. Непосредственно вытекает из того, что структурный анализ специально разработан как инструмент работы со сложными системами, а следовательно, как минимум на первых итерациях исследования модель еще не будет адекватной и значит для обеспечения адекватности модели потребуется сбор дополнительной информации и уточнение модели.
· Принцип полноты – заключается в необходимости контроля модели на наличие в ней всех требуемых для адекватности модели элементов и связей.
· Принцип непротиворечивости – заключается в необходимости контроля согласованности элементов на наличие ситуации, когда присутствие одного исключает присутствие другого.
Эти принципы важно понимать потому, что на них строятся все методологии структурного анализа, используемые на разных стадиях жизненного цикла ПО.
Информатика: учебник для студентов всех направлений и специальностей подготовки
ФБГОУ ВПО «Новосибирский государственный технический университет»
Главная страница / 29. Структурное программирование: 29.2. Структурные методы .
29.2. Структурные методы анализа и проектирования ПО
Одной из основных проблем, которые приходится решать при создании больших и сложных систем любой природы, в том числе и ПО, является проблема сложности. Ни один разработчик не в состоянии выйти за пределы человеческих возможностей и понять всю систему в целом. Единственный эффективный подход к решению этой проблемы, который выработало человечество за всю свою историю, заключается в построении сложной системы из небольшого количества крупных частей, каждая из которых, в свою очередь, строится из частей меньшего размера, и т.д., до тех пор, пока самые небольшие части можно будет строить из имеющегося материала. Этот подход известен под самыми разными названиями, среди них такие, как «разделяй и властвуй» (divide et imperd), иерархическая декомпозиция и др. По отношению к проектированию сложной программной системы это означает, что ее необходимо разделить (декомпозировать) на небольшие подсистемы, каждую из которых можно разрабатывать независимо от других. Это позволяет при разработке подсистемы любого уровня иметь дело только с ней, а не со всеми остальными частями системы [18].
Структурные методы являются строгой дисциплиной системного анализа и проектирования. Методы структурного анализа и проектирования стремятся преодолеть сложность больших систем путем расчленения их на части («черные ящики») и иерархической организации этих «черных ящиков». Выгода в использовании «черных ящиков» заключается в том, что их пользователю не требуется знать, как они работают, необходимо знать лишь их входы и выходы, а также назначение (т.е. функции, которые они выполняют).
Таким образом, первым шагом упрощения сложной системы является ее разбиение на «черные ящики», при этом такое разбиение должно удовлетворять следующим критериям:
- каждый «черный ящик» должен реализовывать единственную функцию системы;
- функция каждого «черного ящика» должна быть легко понимаемой независимо от сложности ее реализации;
- связь между «черными ящиками» должна вводиться только при наличии связи между соответствующими функциями системы;
- связи между «черными ящиками» должны быть простыми, насколько это возможно, для обеспечения независимости между ними.
Второй важной идеей, лежащей в основе структурных методов, является идея иерархии. Для понимания сложной системы недостаточно разбить ее на части, необходимо эти части организовать определенным образом, а именно в виде иерархических структур. Все сложные системы Вселенной организованы в иерархии: от галактик до элементарных частиц. Человек при создании сложных систем также подражает природе. Любая организация имеет директора, заместителей по направлениям, иерархию руководителей подразделений, рядовых служащих [18].
Кроме того, структурные методы широко используют визуальное моделирование, служащее для облегчения понимания сложных систем.
Структурным анализом принято называть метод исследования системы, начинающий с ее общего обзора, который затем детализируется, приобретая иерархическую структуру со все большим числом уровней [18].
Для таких методов характерно:
- разбиение системы на уровни абстракции с ограничением числа элементов на каждом из уровней (обычно от 3 до 7);
- ограниченный контекст, включающий лишь существенные на каждом уровне детали;
- использование строгих формальных правил записи;
- последовательное приближение к конечному результату.
В структурном анализе основным методом разбиения на уровни абстракции является функциональная декомпозиция, заключающаяся в декомпозиции (разбиении) системы на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, т.е. на задачи и так далее до конкретных процедур. При этом система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы «снизу вверх» от отдельных задач ко всей системе целостность теряется, возникают проблемы при описании информационного взаимодействия отдельных компонентов.
Все наиболее распространенные методы структурного подхода базируются на ряде общих принципов. Базовыми принципами являются:
- принцип «разделяй и властвуй» – принцип решения трудных проблем путем разбиения их на множество меньших независимых задач, легких для понимания и решения;
- принцип иерархического упорядочения – принцип организации составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к нежелательным последствиям (вплоть до неудачного завершения проекта). Основными из таких принципов являются:
- принцип абстрагирования – выделение существенных аспектов системы и отвлечение от несущественных;
- принцип непротиворечивости – обоснованность и согласованность элементов системы;
- принцип структурирования данных – данные должны быть структурированы и иерархически организованы.
Понятие структурного анализа
Понятие информационной системы. Классификация информационных систем.
Информационная система это автоматизированная система, предназначенная для организации хранения, пополнения, поддержки, представления пользователем информации в соответствии с их запросами.
По типу хранимых данных информационные системы: — фактографические – предназначены для хранения и обработки структурированных данных в виде чисел и текста; -документальные – информация представлена в виде документов состоящих из наименований, описаний, рефератов и текстов. Поиск по неструктурированным данным осуществляется с использованием семантических признаков. Найденные документы предоставляются пользователям, обработка данных в таких системах практически не производится.
Основываясь на степени автоматизации информационных процессов в системе информационные системы делятся на:- ручные – характеризуются отсутствием технических средств обработки информации и выполнения всех операций человеком;- автоматические – все операции обработки информации выполняются без участия человека; -автоматизированные – предполагают участие в процессе обработки информации и человека и технических средств, причем главную роль в выполнении операций обработки информации — компьютеру.
В зависимости от характера обработки данных информационные системы: -информационно-поисковые – производят ввод, систематизацию, хранение и выдачу информации по запросу пользователя без сложных преобразований данных (информационные системы библиотек); — информационно-решающие – кроме того осуществляют операции переработки информации по определенному алгоритму.
По характеру использования выходной информации такие системы принято делить на:- управляющие – результирующая информация трансформируется в принимаемое человеком решение, для этих систем характерны задачи расчетного характера и обработка больших объемов данных (информационные системы бухучета).- советующие – вырабатывают информацию которая принимается человеком к сведению и учитывается при формировании управленческих решений, а не инициирует конкретные действия.
В зависимости от сферы применения различают следующие классы информационных систем: 1. Информационные системы организационного управления предназначены для автоматизации функций управленческого состава. 2. Информационные системы управления технологическими процессами служат для автоматизации функций производственного персонала по контролю и управлению производственными операциями. 3. Информационные системы автоматизированного проектирования (ИСАП) – предназначены для автоматизации функций инженеров-проектировщиков, конструкторов, архитекторов, дизайнеров при создании новой техники или технологии. 4. Корпоративные информационные системы – используются для автоматизации всех функций предприятия и охватывают весь цикл работ от планирования деятельности до сбыта продукции.
Понятие структурного анализа
На этапе анализа требований к системе формализуются, документируются и уточняются требования заказчика. Список требований включает:
— совокупность условий при которых будет эксплуатироваться система;
— написание выполняемых системой функций;
— ограничение на процессы разработки — сроки завершения работ и мероприятия по защите информации.
Особенностью разработки программного обеспечения является то, что наиболее сложные работы выполняются на этапах анализа и проектирования. Последующие этапы имеют значительно меньшую сложность и трудоемкость. Язык, на котором формулируются требования к системе должен быть достаточно простым и понятным.
Системный аналитик должен уметь решать следующие задачи:
— получение исчерпывающей информации для оценки требований к системе;
— уметь выбирать только существенную информацию на предметной области;
— спецификация системы, которую составляет аналитик из-за технических терминов и значительного объема часто непонятны заказчику.
Решение этой проблемы состоит в использовании методов структурного анализа. Для метода структурного анализа характерно разбиение описания системы на уровне абстрактного представления. Метод структурного анализа состоит в том, что исследования системы начинается с общего обзора, а затем выполняется более детальное исследование результаты которого приобретают иерархическую структуру.
Основные принципы структурного анализа:
— решение трудных задач выполняется путем разбиения на множество меньших относительно независимых задач;
— принцип иерархического упорядочивания;
— принцип абстрагирования заключается в выделении наиболее существенных аспектов системы для представления проблемы в простом общем виде;
— принцип формализаций, состоит в необходимости применения строгого методического подхода для решения всех задач;
— принцип упрятывания, заключается в том, что несущественная на конкретном этапе информация скрывается;
— принцип концептуальной общности означает, что на всех этапах жизненного цикла должна использоваться единая методология;
— принцип полноты, заключается в выполнении контроля присутствия в функциях системы лишних элементов;
— принцип непротиворечивости, состоит в проверке обоснованности использования и согласованности всех элементов системы;
— принцип логической независимости, состоит в том, что проектирование выполняющееся на логическом уровне не должно определяться последующим физическим проектированием;
— принцип независимости данных, состоит в том, что модель данных должна быть спроектирована независимо от процесса и их логической обработки;
— принцип структурирования данных;
— принцип доступа конечного пользователя, означает что пользователь должен иметь возможность без программирования изменять значения данных в базе данных.
Средства структурного анализа.
Существует три группы средств структурного анализа которые иллюстрируют:
— функции, которые система должна выполнять — диаграммы потока данных;
— отношение между данными — диаграммы сущности связи;
— поведение системы зависящее от времени — диаграммы переходов состояний.