Учебник Технология программирования. Технология программирования
 Скачать 7.85 Mb.
|
|
Пример 4.2. Разработку функциональных диаграмм продемонстрируем на примере уточнения спецификаций программы построения таблиц/графиков функций одной переменной. Диаграмма, показанная на рис. 4.10, а, является диаграммой верхнего уровня. На ней хорошо видно, что является исходными данными для программы. и каких результатов работы от нее ожидают. Диаграмма, представленная на рис, 4.10. б, уточняет функции программы. На ней показаны четыре блока: Ввод/выбор функции и ее разбор. Добавление функции в список. Построение таблицы значений и Построение графика функции. 114 Для каждого блока определены исходные данные, управляющие воздействия и результаты. Согласно правилам наименования входов/выходов, имеющих продолжение на родительской диаграмме, на диаграмме использованы следующие обозначения: I1 - функция, I2 - отрезок, I3 - шаг, Cl - вид график/таблица, Rl - график функции на отрезке, R2 - таблица значений функции на отрезке. Словарь в этом случае должен содержать описание всех данных, используемых в системе. Функциональную модель целесообразно применять для определения спецификаций программного обеспечения, не предусматривающего работу со сложными структурами данных, так как она ориентирована на декомпозицию функций. 4.4. Диаграммы потоков данных Диаграммы потоков данных позволяют специфицировать как функции разрабатываемого программного обеспечения, так и обрабатываемые им данные. При использовании этой модели систему представляют в виде иерархии диаграмм потоков данных, описывающих асинхронный процесс преобразования информации с момента ввода в систему до выдачи пользователю. На каждом следующем уровне иерархии происходит уточнение процессов, пока очередной процесс не будет признан элементарным. Примечание. Модели потоков данных были независимо предложены сначала Е Йорданом (1975). затем Ч. Генном и Т. Сарсоном (1979). На этих моделях основаны классические методологии структурного анализа и проектирования программного обеспечения соответственно Йордана-Де Марка и Геина-Сарсона. Та же модель используется в методологии структурного анализа и проектирования SSADM (Structured Systems Analysis and Design Method). принятой в Великобритании в качестве национального стандарта разработки информационных систем. В основе модели лежат понятия внешней сущности, процесса, хранилища (накопителя) данных и потока данных. Внешняя сущность - материальный объект или физическое лицо, выступающие в качестве источников или приемников информации, например, заказчики, персонал, поставщики, клиенты, банк и т. п. Процесс - преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. 115 Каждый процесс в системе имеетсвой номер и связан с исполнителем, который осуществляет данное преобразование. Как в случае функциональных диаграмм, физически преобразование может осуществляться компьютерами, вручную или специальными уст- ройствами. На верхних уровнях иерархии, когда процессы еще не определены, вместо понятия «процесс» используют понятия «система» и «подсистема», которые обозначают соответственно систему в целом или ее функционально законченную часть. Хранилище данных - абстрактное устройство для хранения информации. Тип устройства и способы помещения, извлечения и хранения для такого устройства не детализируют. Физически это может быть база данных, файл, таблица в оперативной памяти, картотека на бумаге и т. п. Поток данных — процесс передачи некоторой информации от источника к приемнику. Физически процесс передачи информации может происходить по кабелям под управлением программы или программной системы или вручную при участии устройств или людей вне проектируемой системы. Таким образом, диаграмма иллюстрирует как потоки данных, порожденные некоторыми внешними сущностями, трансформируются соответствующими процессами (или подсистемами), сохраняются накопителями данных и передаются другим внешним сущностям - приемникам информации. В результате мы получаем сетевую модель хранения/обработки информации. Для изображения диаграмм потоков данных традиционно используют два вида нотаций: нотации Йордана и Гейна-Сарсона (табл. 4.1). 116 Над линией потока, направление которого обозначают стрелкой, указывают, какая конкретно информация в данном случае передается (рис. 4.11). Построение иерархии диаграмм потоков данных начинают с диаграммы особого вида - контекстной диаграммы, которая определяет наиболее общий вид системы. На такой диаграмме показывают, как разрабатываемая система будет взаимодействовать с приемниками и источниками информации без указания исполнителей, т. е. описывают интерфейс между системой и внешним миром. Обычно начальная контекстная диаграмма имеет форму звезды. Если проектируемая система содержит большое количество внешних сущностей (более 10-ти), имеет распределенную природу или включает уже существующие подсистемы, то строят иерархии контекстных диаграмм. При разработке контекстных диаграмм происходит детализация функциональной структуры будущей системы, что особенно важно, если разработка ведется несколькими коллективами разработчиков. Полученную таким образом модель системы проверяют на полноту исходных данных об объектах системы и изолированность объектов (отсутствие информационных связей с другими объектами). На следующем этапе каждую подсистему контекстной диаграммы детализируют при помощи диаграмм потоков данных. В процессе детализации соблюдают правило балансировки - при детализации подсистемы можно использовать компоненты только тех подсистем, с которыми у разрабатываемой подсистемы существует информационная связь (т.е. с которыми она связана потоками данных). Решение о завершении детализации процесса принимают в следующих случаях: • процесс взаимодействует с 2-3-мя потоками данных; • возможно описание процесса последовательным алгоритмом; •процесс выполняет единственную логическую функцию преобразования входной информации в выходную. На недетализируемые процессы составляют спецификации, которые должны содержать описание логики (функций) данного процесса. Такое описание может выполняться: на естественном языке, с применением структурированного естественного языка (псевдокодов), с применением таблиц и деревьев решений, в виде схем алгоритмов, в том числе flow-форм и диаграмм Насси-Щнейдермана (см. § 2.4). 117 Для облегчения восприятия процессы детализируемой подсистемы нумеруют. соблюдая иерархию номеров: так процессы, полученные при детализации процесса или подсистемы «I», должны нумероваться «I.I», «1.2» и т. д. Кроме этого желательно размещать на каждой диаграмме от 3-х до 6-7-ми процессов и не загромождать диаграммы деталями, не существенными на данном уровне. Декомпозицию потоков данных необходимо осуществлять параллельно с декомпозицией процессов. Окончательно разработку модели выполняют в два этапа. 1 этап - построение контекстной диаграммы - включаетвыполнение следующих действий: • классификацию множества требований и организацию их в основные функциональные группы - процессы; • идентификацию внешних объектов - внешних сущностей, с которыми система должна быть связана; • идентификацию основных видов информации - потоков данных, циркулирующей между системой и внешними объектами; • предварительную разработку контекстной диаграммы; • изучение предварительной контекстной диаграммы и внесение в нее изменений по результатам ответов на возникающие при изучении вопросы по всем ее частям; • построение контекстной диаграммы путем объединения всех процессов предварительной диаграммы в один процесс, а также группирования потоков. 2 этап - формирование иерархии диаграмм потоков данных - включает для каждого уровня: • проверку и изучение основных требований по диаграмме соответствующего уровня (для первого уровня - по контекстной диаграмме); • декомпозицию каждою процесса текущей диаграммы потоков данных с помощью детализирующей диаграммы или - если некоторую функцию сложно или невозможно выразить комбинацией процессов, построение спецификации процесса; • добавление определений новых потоков в словарь данных при каждом появлении их на диаграмме; • проведение ревизии с целью поверки корректности и улучшениянаглядности модели после построения двух-трех уровней. Полная спецификация процессов включает также описание структур данных используемых как при передаче информации в потоке, так и при хранении в накопителе. Описываемые структуры данных могут содержать альтернативы условные вхождения и итерации. Условное вхождение означает, что соответствующие элементы данных в структуре могут отсутствовать. 118 Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает, что элемент может повторяться некоторое количество раз (см. § 4.5). Кроме того, для данных должен быть указан тип: непрерывное или дискретное значение. Для непрерывных данных могут определяться единицы измерений, диапазон значений, точность представления и форма физического кодирования. Для дискретных - может указываться таблица допустимых значений. Полученную законченную модель необходимо проверить на полноту и согласованность. Под согласованностью модели в данном случае понимают выполнение для всех потоков данных правила сохранения информации: все поступающие куда-либо данные должны быть считаны и записаны. Пример 4.3. Разработаем иерархию диаграмм потоков данных программы построения графиков/таблиц функций. Разработку начнем с построения контекстной диаграммы. Для чего определим внешние сущности и потоки данных между программой и внешними сущностями. У данной системы единственная внешняя сущность Учащийся. Он вводит или выбирает из списка функцию, задает интервал и количество точек, а затем получает таблицу значений функции и ее график. На рис. 4.12 представлена контекстная диаграмма системы. Детализируя эту диаграмму, получаем три процесса: Ввод/выбор функции и ее разбор, Построение таблицы значений функции и Построение графика функции. Для хранения функций добавляем хранилище функций. Затем определяем потоки данных. 119 Если сравнить полученную детализирующую диаграмму потоков данных (рис. 4.13) и функциональные диаграммы для той же системы (см. рис. 4.10). то можно отменить некоторые различия в представлении одной и той же информации. Например, на диаграмме потоков данных можно показать хранилище данных, что очень существенно для систем, включающих базы данных Кроме того, диаграммы потоков данных позволяют точно адресо- вать функции системы при наличии нескольких категорий пользователей, что демонстрирует следующий пример. Пример 4.4. Разработать иерархию диаграмм потоков данных системы учета успеваемости студентов (см. Техническое задание в примере 3.2). О качестве внешних сущности для системы выступают Декан, Заместитель декана по курсу и Сотрудник деканата. Определим потоки данных между ними сущностями и системой. Декан должен получать. (рис. 4.14): • сводку успеваемости по факультету (процент успеваемости групп, курсов и в целом по факультету) на ткущий или указанный момент времени; • полные сведения об учебе конкретного студента (успеваемость по всем изученным предметам всех завершенных семестров обучения с учетом пересдач). 120 Заместитель декана по курсу должен получать: • сводку успеваемости по курсу (процент успеваемости по группам) на текущий или указанный момент; • сведения о сдаче экзаменов и зачетов указанной группой; • текущие сведения об успеваемости конкретного студента; • полные сведения об учебе конкретного студента (успеваемость по всем изученным предметам всех завершенных семестров обучения с учетом пересдач); • список задолжников по факультету с указанием групп и несданных предметов. Сотрудник деканата должен обеспечивать: • ввод списков студентов, зачисленных на первый курс; 121 • корректировку списков студентов в соответствии с приказами о зачислени, отчислении, переводе и т. п.; • ввод учебных планов кафедр; • ввод расписания сессии; • ввод результатов сдачи зачетов и экзаменов на основании ведомостей и направлений. Кроме того, сотрудник декана должен иметь возможность получать: • справку о прослушанных студентом предметах с указанием часов и итоговых опенок; • приложение к диплому выпускника также с указанием часов и итоговых оценок. Далее детализируем процессы в системе. На рис. 4.15 представлена детализирующая диаграмма потоков данных, где выделены две подсистемы: Подсистема наполнения базы данных и Подсистема формирования отчетов, а также хранилище данных, которое может быть реализовано как с помощью средств СУБД, так и без них. Решение о целесообразности использования средств СУБД может быть принято позднее, после анализа структур хранимых данных. Дальнейшую детализацию процессов можно не выполнять, так как их СУЩНОСТЬ для разработчика очевидна. Однако становится ясно, что полная спецификация данной разработки должна включать описание базы данных. Такое описание в виде диаграммы «сущность-связь» будет рассмотрено в § 4.5. Кроме этого, как уже упоминалось в § 4.1. для данной системы целесообразно выполнить моделирование управляющих процессов, что позволит уточнить организацию процесса обработки данных. Моделирование управляющих процессов с помощью диаграмм потоков данных. Для представления управляющих процессов в проектируемых системах можно применить диаграммы переходов состоянии, рассмотренные в § 4.2, или диаграммы управляющих потоков данных, которые используют понятия: управляющий процесс, управляющий поток данных и, возможно, хранилище управляющих данных. 122 Управляющий процесс получает с помощью управляющих потоков некоторую информацию о ситуации в системе и инициирует посредством управляющего потока соответствующие процессы. На диаграммах управляющих потоков данных используют те же обозначения, что и для обычных потоков, но изображают их пунктирной линией. Дополнительно может быть указан тип управляющего потока: • Т-поток (Trigger Flow - тригерный поток) - поток управления, который может только «включать» процесс - следующий управляющий сигнал опять «включит» процесс, даже если процесс уже активен: • А-поток (Activator Flow - активирующий поток) - поток управления. который может как «включать», так и «выключать» управляемый процесс -если процесс включен, то следующий сигнал его выключит: • E / D - ПОТОК (Enable/Disable Flow - переключающий поток) - поток управления, который может включать процесс сигналом по одной (Е) линии и выключать - сигналом по другой (D) линии. При необходимости тип потока данных (управляющий или обычный) можно изменять. Для этого используют специальное обозначение - узел изменения типа потока данных (рис. 4.16). К этому узлу поток подходит как поток данных, а выходит из него как управляющий поток. Пример 4.5. Построим диаграмму потоков управляющих данных для программы построения таблиц/графиков функций и наложим ее на диаграмму потоков данных для этой программы, представленную на рис. 4.13. Для управления процессом исследования функции добавляем процесс Управление программой. Этот процесс получает четыре потока управляющих данных (команды Функция. Отрезок, Шаг и График/Таблица) и генерирует два управляющих потока Т-типа: Изменить функцию и Заменить отрезок или шаг, а также управляющий поток А-типа: Изменить вид результата. Управляющий поток Изменить функцию активизирует процесс Ввода/выбора и разбора функции. Сначала функция проверяется с точки зрения корректности записи. Если функция введена правильно, то она заносится в список и обработка продолжается. если нет, то процесс прекращается с выдачей соответствующего сообщения. Нормальное завершение выполнения первою блока инициирует выполнение второго блока и т. д. При получении команд Изменить отрезок или Изменить шаг генерируется управляющий поток Изменить отрезок или шаг, который отвечает за пересчет таблицы значений функции. При выбранном виде результата График генерируется управляющий поток Построение графика функции. 123 Полученная комбинированная диаграмма потоков обычных и управляющих данных представлена на рис. 4.17. 4.5. Структуры данных и диаграммы отношений компонентов данных Структурой данных называют совокупность правил и ограничений, которые отражаютсвязи, существующие между отдельными частями (элементами) данных. 124 Различают абстрактные структуры данных, используемые для уточнения связей между элементами, и конкретные структуры, используемые для представления данных в программах. Все абстрактные структуры данных можно разделить на три группы: структуры, элементы которых не связаны между собой, структуры с неявными связями элементов - таблицы и структуры, связь элементов которых указывается явно - графы (рис. 4.18). В первую группу входят множества (рис. 4.19, а) и кортежи (рис. 4.19, б). Наиболее существенная характеристика элемента данных в этих структурах — его принадлежность некоторому набору, т. е. отношение вхождения. Данные абстрактные структуры используют, если никакие другие отношения элементов не являются существенными для описываемых объектов. Ко второй группе относят векторы, матрицы, массивы (многомерные), записи, строки, а также таблицы, включающие перечисленные структуры в 125 качестве частей. Использование этих абстрактных типов может означать, что существенным является не только вхождение элемента данных в некоторую структуру, но и их порядок, а также отношения иерархии структур, т. е. вхождение структуры в структуру более высокой степени общности (рис. 4.20). В тех случаях, когда существенны связи элементов данных между собой, в качестве модели структур данных используют графы [55]. На рис. 4.21 показаны различные варианты графовых моделей. Очень существенно, что в реальности возможно вложение структур данных, в том числе и разных типов, а потому для их описания могут потребоваться специальные модели. В зависимости от описываемых типов отношений модели структур данных принято делить на иерархические и сетевые. Иерархические модели позволяют описывать упорядоченные или не упорядоченные отношения вхождения элементов данных в компонент более высокого уровня, т.е. множества, таблицы и их комбинации. К иерархическим моделям относят модель Джексона- Орра, для графического представления которой можно использовать: • диаграммы Джексона, предложенные в составе методики проектирования программного обеспечения того же автора в 1975 г.; • скобочные диограммы Орра, предложеные в составе методики проектирования программного обеспечения Варнье-0рра(1974). 126 Сетевые модели основаны на графах, а потому позволяют описывать связность элементов данных независимо от вида отношения, в том числе комбинации множеств, таблиц и графов. К сетевым моделям, например, относят модель «сущность-связь» (ER - Entity-Relationship), обычно используемую при разработке баз данных. |