Структурный анализ – это систематический пошаговый подход к анализу требований и проектированию спецификаций системы независимо от того, является ли она существующей или создается вновь.
Методология структурного анализа и проектирования определяет шаги работы, которые должны быть выполнены, их последовательность, правила распределения и назначения операций и методов.
В настоящее время успешно используются такие методологии, как структурный системный анализ Гейна–Сарсона, структурный анализ и проектирование Йордана-де Марко, SADT и другие.
1.1. Диаграммы потоков данных
Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компонен- ты (процессы) и представляются в виде сети, связанной потоками дан- ных. Главная цель таких средств – продемонстрировать, как каждый про- цесс преобразует свои входные данные в выходные, а также выявить от- ношения между этими процессами.
Диаграммы потоков данных известны давно. Можно привести сле- дующий пример использования DFD в 20-х годах для реорганизации пе- реполненного клерками офиса. Осуществлявший реорганизацию кон- сультант обозначил кружком каждого клерка, а стрелкой – каждый доку- мент, передаваемый между ними. Используя такую диаграмму, он пред- ложил схему реорганизации, в соответствии с которой двое клерков, об-
менивающиеся множеством документов, были посажены рядом, а клерки с малым взаимодействием были посажены на большом расстоянии. Так родилась первая модель, представляющая собой потоковую диаграмму – предвестника DFD.
Основой данной методологии графического моделирования инфор- мационных систем является специальная технология построения диаграмм потоков данных DFD. В разработке методологии DFD приняли участие многие аналитики, среди которых следует отметить Э. Йордона (Е. Yourdon). Он является автором одной из первых графических нотаций DFD. В настоящее время наиболее распространенной является так назы- ваемая нотация Гейна-Сарсона (Gene-Sarson).
Модель системы в контексте DFD представляется в виде некоторой информационной модели, основными компонентами которой являются различные потоки данных, которые переносят информацию от одной под- системы к другой. Каждая из подсистем выполняет определенные преобра- зования входного потока данных и передает результаты обработки инфор- мации в виде потоков данных для других подсистем.
Основными компонентами диаграмм потоков данных являются:
• внешние сущности;
• накопители данных или хранилища;
• процессы;
• потоки данных;
• системы/подсистемы.
Внешняя сущность представляет собой материальный объект или физическое лицо, которые могут выступать в качестве источника или при- емника информации. Определение некоторого объекта или системы в ка- честве внешней сущности не является строго фиксированным. Хотя внеш- няя сущность находится за пределами границ рассматриваемой системы, в процессе дальнейшего анализа некоторые внешние сущности могут быть
перенесены внутрь диаграммы модели системы. С другой стороны, от- дельные процессы могут быть вынесены за пределы диаграммы и пред- ставлены как внешние сущности. Примерами внешних сущностей могут служить: клиенты организации, заказчики, персонал, поставщики.
Внешняя сущность обозначается прямоугольником с тенью (рис. 1), внутри которого указывается ее имя. При этом в качестве имени рекомен- дуется использовать существительное в именительном падеже. Иногда внешнюю сущность называют также терминатором.
Рис. 1. Изображение внешней сущности на диаграмме потоков данных
Процесс представляет собой совокупность операций по преобразова- нию входных потоков данных в выходные в соответствии с определенным алгоритмом или правилом. Хотя физически процесс может быть реализо- ван различными способами, наиболее часто подразумевается программная реализация процесса. Процесс на диаграмме потоков данных изображается прямоугольником с закругленными вершинами (рис. 2), разделенным на три секции или поля горизонтальными линиями.
Рис. 2. Изображение процесса на диаграмме потоков данных
Поле номера процесса служит для идентификации последнего. В среднем поле указывается имя процесса. В качестве имени рекомендовано
использовать глагол в неопределенной форме с необходимыми дополне- ниями. Нижнее поле содержит указание на способ физической реализации процесса.
Информационная модель системы строится как некоторая иерархи- ческая схема в виде так называемой контекстной диаграммы, на которой исходная модель последовательно представляется в виде модели подсис- тем соответствующих процессов преобразования данных. При этом под- система или система на контекстной диаграмме DFD изображается так же, как и процесс – прямоугольником с закругленными вершинами (рис. 3).
Рис. 3. Изображение подсистемы на диаграмме потоков данных
Накопитель данных или хранилище представляет собой абстрактное устройство или способ хранения информации, перемещаемой между про- цессами. Предполагается, что данные можно в любой момент поместить в накопитель и через некоторое время извлечь, причем физические способы помещения и извлечения данных могут быть произвольными. Накопитель данных может быть физически реализован различными способами, но наи- более часто предполагается его реализация в электронном виде на магнит- ных носителях. Накопитель данных на диаграмме потоков данных изобра- жается прямоугольником с двумя полями (рис. 4). Первое поле служит для указания номера или идентификатора накопителя, который начинается с буквы "D". Второе поле служит для указания имени. При этом в качестве
имени накопителя рекомендуется использовать существительное, которое характеризует способ хранения соответствующей информации.
Рис. 4. Изображение накопителя на диаграмме потоков данных
Наконец, поток данных определяет качественный характер инфор- мации, передаваемой через некоторое соединение от источника к прием- нику. Реальный поток данных может передаваться по сети между двумя компьютерами или любым другим способом, допускающим извлечение данных и их восстановление в требуемом формате. Поток данных на диа- грамме DFD изображается линией со стрелкой на одном из ее концов, при этом стрелка показывает направление потока данных. Каждый поток дан- ных имеет свое собственное имя, отражающее его содержание.
Таким образом, информационная модель системы в нотации DFD строится в виде диаграмм потоков данных, которые графически представ- ляются с использованием соответствующей системы обозначений. В каче- стве примера рассмотрим упрощенную модель процесса получения неко- торой суммы наличными по кредитной карточке клиентом банка. Внеш- ними сущностями данного примера являются клиент банка и, возможно, служащий банка, который контролирует процесс обслуживания клиентов. Накопителем данных может быть база данных о состоянии счетов отдель- ных клиентов банка. Отдельные потоки данных отражают характер пере- даваемой информации, необходимой для обслуживания клиента банка. Со- ответствующая модель для данного примера может быть представлена в виде диаграммы потоков данных (рис. 5).
Важную специфическую роль в модели играет специальный вид DFD
– контекстная диаграмма, моделирующая систему наиболее общим об- разом. Контекстная диаграмма отражает интерфейс системы с внешним
миром, а именно, информационные потоки между системой и внешними сущностями, с которыми она должна быть связана. Она идентифицирует эти внешние сущности, а так же, как правило, единственный процесс, от- ражающий главную цель или природу системы насколько это возможно. И хотя контекстная диаграмма выглядит тривиальной, несомненная ее полезность заключается в том, что она устанавливает границы анализи- руемой системы. Каждый проект должен иметь ровно одну контекстную диаграмму, при этом нет необходимости в нумерации единственного ее процесса.
DFD первого уровня строится как декомпозиция процесса, который присутствует на контекстной диаграмме.
Рис. 5. Пример диаграммы DFD для процесса получения некоторой суммы на- личными по кредитной карте
Построенная диаграмма первого уровня также имеет множество про- цессов, которые в свою очередь могут быть декомпозированы в DFD нижнего уровня. Таким образом, строится иерархия DFD с контекстной диаграммой в корне дерева. Этот процесс декомпозиции продолжается до
тех пор, пока процессы могут быть эффективно описаны с помощью ко- ротких (до одной страницы) миниспецификаций обработки (специфика- ций процессов).
При таком построении иерархии DFD каждый процесс более низкого уровня необходимо соотнести с процессом верхнего уровня. Обычно для этой цели используются структурированные номера процессов. Так, на- пример, если мы детализируем процесс номер 2 на диаграмме первого уровня, раскрывая его с помощью DFD, содержащей три процесса, то их номера будут иметь следующий вид: 2.1, 2.2 и 2.3. При необходимости можно перейти на следующий уровень, т.е. для процесса 2.2 получим 2.2.1, 2.2.2. и т.д.
Проиллюстрируем контекстную диаграмму на примере, используя нотацию Йордана-де Марко. Рассмотрим процесс Сдать экзамен. У нас есть две сущности С тудент и Преподаватель. Опишем потоки данных, которыми обменивается наша проектируемая система с внешними объек- тами (рис. 6). Со стороны сущности Студент опишем информационные потоки. Для сдачи экзамена необходимо, чтобы у Студента была За- четка, а также, чтобы он имел Допуск к экзамену. Результатом сдачи эк- замена, т.е. выходными потоками будут Оценка за экзамен и Зачетка, в которую будет проставлена Оценка.
Со стороны сущности Преподаватель информационные потоки сле- дующие: Экзаменационная ведомость, согласно которой будет известно, что Студент допущен до экзамена, а также официальная бумага, куда бу- дет занесен результат экзамена, т.е. Оценка за экзамен, проставленная в Экзаменационную ведомость.
Теперь детализируем процесс Сдача экзамена. Этот процесс будет содержать следующие процессы (рис. 7): Вытянуть билет {1.1}, Под- готовиться к ответу {1.2}, Ответить на билет {1.3}, Простановка оценки {1.4}.
Рис. 6. DFD-диаграмма процесса «Сдать экзамен»
Рассмотренные методологии фокусируют внимание на потоках дан- ных, их главное назначение – создание базированных на графике докумен- тов по функциональным требованиям.
Рис. 7. Декомпозиция 1-го уровня DFD-диаграммы процесса «Сдать экзамен»
Методологии поддерживаются традиционными нисходящими мето- дами проектирования спецификаций и обеспечивают один из лучших спо- собов связи между аналитиками, разработчиками и пользователями систе- мы.
Модель представления данных в DFD очень хорошо подходит для высокоуровнего моделирования системы. Этот уровень полезен для ком- муникации между руководителем проекта и заказчиком, архитектором и разработчиками. Визуальное представление помогает сломать барьер не- понимания и представить сложные и объемные требования в простом и на- глядном виде.
В настоящее время диаграммы потоков данных используются в не- которых CASE-средствах для построения информационных моделей сис- тем обработки данных. Основной недостаток этой методологии связан с отсутствием явных средств для объектно-ориентированного представления моделей сложных систем, а также для представления сложных алгоритмов обработки данных. Поскольку на диаграммах DFD не указываются харак- теристики времени выполнения отдельных процессов и передачи данных между процессами, то модели систем, реализующих синхронную обработ- ку данных, не могут быть адекватно представлены в нотации DFD. Все эти особенности методологии структурного системного анализа ограничили возможности ее широкого применения.
ЗАДАНИЕ
На основании методических указаний по практике подготовить DFD-диаграмма процесса Составление технического задание на проектирование АСУ ТП
Состав отчёта
Практикум содержит задания на практические работы. Каждая работа должна быть выполнена студентом в установленные сроки. По результатам работы студент формирует отчёт при помощи текстового процессора Microsoft Word. Выполненный и распечатанный отчёт по работе студент защищает у преподавателя.
Отчёт должен содержать следующие составные части:
• Титульный лист;
• Содержание;
• Цель работы;
• Задачи работы;
• Ход работы;
• Выводы;
• Список использованных источников;
• Приложения.
Оформление отчета начинается с титульного листа.
Пример оформленной работы в соответствии ГОСТ 7.32-2017.
Часть «Содержание» включается в отчёт, если он содержит более десяти страниц.
Исходя из названия лабораторной работы и задания на неё, студент самостоятельно формирует цель и задачи, решаемые на данной работе в соответствующей части отчёта.
В части «Ход работы» Студент описывает порядок своих действий при проведении работы, при необходимости сопровождая текст рисунками, таблицами, графиками или листингами. Основные правила оформления отчётов приведены в приложении В.
В части «Выводы» Студент самостоятельно подводит итоги работы и представляет их в сжатом виде. Вывод должен содержать результаты работы, а не простое перечисление выполненных действий.
Часть «Список использованных источников» включается в отчёт в том случае, если помимо учебно-методического комплекса по дисциплине студент использует дополнительные первоисточники или Интернет-ресурсы.
Часть «Приложения» включается в работу только при наличии приложений.