Учебное пособие по выполнению и оформлению курсовых, дипломных и квалификационных работ москва 2002 2 аннотация
 Скачать 0.53 Mb.
|
|
3. АНАЛИЗ ТРЕБОВАНИЙ И ОПРЕДЕЛЕНИЕ СПЕЦИФИКАЦИЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРИ СТРУКТУРНОМ ПОДХОДЕ Спецификации программного обеспечения при структурном подходе Собственно разработка любого ПО начинается с анализа требований к будущему программному продукту. В результате анализа получают спецификации разрабатывае- мого ПО: выполняют декомпозицию и содержательную постановку решаемых задач, уточняют их взаимодействие и эксплуатационные ограничения. В целом в процессе оп- ределения спецификаций строят общую модель предметной области, как некоторой части реального мира, с которой будет тем или иным способом взаимодействовать ПО, и конкретизируют его основные функции. 12 Как уже упоминалось ранее, спецификации представляют собой полное и точное описание функций и ограничений разрабатываемого ПО. При этом часть спецификаций (функциональные), описывают функции разрабатываемого ПО, а другая часть (экс- плуатационные) определяет требования к техническим средствам, надежности, безо- пасности и т.д. Определение отражает главные требования к спецификациям. Применительно к функциональным спецификациям при этом подразумевается, что: * требование полноты означает, что спецификации должны содержать всю сущест- венную информацию, чтобы ничего важного не было упущено, и не должны содержать несущественной информации, например, деталей реализации, чтобы не препятствовать разработчику в выборе наиболее эффективных решений; * требование точности означает, что спецификации должны однозначно воспри- ниматься как заказчиком, так и разработчиком. Последнее требование выполнить достаточно сложно, так как естественный язык для описания спецификаций не подходит: подробные спецификации на естественном языке не обеспечивают необходимой точности. Точные спецификации разрабатываемо- го ПО можно определить, только разработав некоторую формальную модель ПО. Формальные модели, разрабатываемые на этапе определения спецификаций можно разделить на две группы: модели, зависящие от подхода к разработке (структурного или объектно-ориентированного), и модели, не зависящие от него. Так диаграммы пе- реходов состояний, которые демонстрируют особенности поведения разрабатываемого ПО при получении тех или иных сигналов извне и математические модели предметной области используют при любом подходе к разработке. В рамках структурного подхода на этапе анализа и определения спецификаций ис- пользуют три типа моделей: ориентированные на функции, ориентированные на дан- ные и ориентированные на потоки данных, каждый из которых целесообразно исполь- зовать для своего специфического класса программных разработок. На рис. 3.1 показана классификация моделей, используемых в качестве специфика- ций разрабатываемого ПО. Следует иметь в виду, что все функциональные спецификации описывают одни и те же характеристики разрабатываемого ПО: перечень функций и состав обрабатывае- мых данных. Они различаются только системой приоритетов (акцентов), которая ис- пользуется разработчиком в процессе анализа требований и определения специфика- 13 ций. Так диаграммы переходов состояний определяют некоторые аспекты поведения ПО во времени, диаграммы потоков данных – направление и структуру потоков дан- ных, а концептуальные диаграммы классов – отношение между основными понятиями предметной области. Поскольку разные модели описывают проектируемое ПО с разных сторон, реко- мендуется использовать сразу несколько моделей и сопровождать их текстами, допол- няющими соответствующие диаграммы. Так методологии структурного анализа и проектирования, основанные на модели- ровании потоков данных, обычно используют комплексное представление проектируе- мого ПО в виде совокупности моделей: * диаграмм потоков данных (DFD – Data Flow Diagrams), описывающих взаимодей- ствие источников и потребителей информации через процессы, которые должны быть реализованы в системе (см. § 3.4); * диаграмм «сущность-связь» (ERD – Entity-Relationship Diagrams), описывающих базы данных разрабатываемой системы (см. § 3.5); * диаграмм переходов состояний (STD – State Transition Diagrams), характеризую- щих поведение системы во времени (см. § 3.2); * спецификаций процессов; * словаря данных. Взаимосвязь компонент такой обобщенной модели показана на рис. 3.2. Диаграмма переходов состояний Диаграмма переходов состояний является графической формой представления ко- нечного автомата – математической абстракции, используемой для моделирования де- терминированного поведения технических объектов или объектов реального мира. На этапе анализа требований и определения спецификации диаграмма переходов состояний демонстрирует поведение разрабатываемой программной системы при по- лучении управляющих воздействий. Под управляющими воздействиями или сигналами в данном случае понимают управляющую информацию, получаемую системой извне, например, управляющими воздействиями считают команды пользователя и сигналы датчиков, подключенных к компьютерной системе. Получив такое управляющее воз- действие, разрабатываемая система должна выполнить определенные действия, а затем, 14 или остаться в том же состоянии, или перейти в другое состояние, зафиксировав неко- торые изменения в системе. Для построения диаграммы переходов состояний необходимо в соответствие с тео- рией конечных автоматов определить основные состояния, управляющие воздействия (или условия перехода), выполняемые действия и возможные переходы разрабатывае- мого ПО. Условные обозначения, используемые при построении диаграмм переходов состояний, показаны на рис. 3.3. Для интерактивного ПО с развитым пользовательским интерфейсом основные управляющие воздействия – команды пользователя, для ПО реального времени – сиг- налы от датчиков и/или оператора производственного процесса. Общим для этих типов ПО является наличие состояния ожидания, когда система приостанавливает работу до получения очередного управляющего воздействия (рис. 3.4). Для интерактивного ПО наиболее характерно получение команд различных типов, а для ПО реального времени – однотипных сигналов, либо от многих датчиков, либо требующих продолжительной обработки. В отличие от интерактивных систем для систем реального времени обычно уста- новлено более жесткое ограничение на время обработки полученного сигнала. Такое ограничение часто требует выполнения дополнительных исследований поведения сис- темы во времени, например, с использованием сетей Петри или марковских процессов. К ПО, при разработке которого требуется уточнение особенностей поведения по- средством построения диаграммы переходов состояний, относится и ПО, ориентиро- ванное на работу в сети. При этом обычно отдельно строят модели поведения сервера и клиента, представляя сообщения, передаваемые между ними в виде управляющих воз- действий. Пример 3.1. Рассмотрим диаграмму переходов состояний для программы построе- ния таблиц значений и графиков функций одной переменной. Программа должна обеспечивать возможность изменения типа представления, шага и отрезка, а также со- хранения введенных формул. Программа относится к классу интерактивных, соответственно на этапе анализа и определения спецификаций целесообразно уточнить поведение программы на уровне интерфейса с пользователем. Один из возможных вариантов поведения представлен на рис. 3.5. 15 Полученную диаграмму переходов состояний следует согласовать с заказчиком ПО. Функциональные диаграммы Функциональными называют диаграммы, в первую очередь отражающие взаимо- связи функций разрабатываемого ПО. В качестве примера функциональной модели рассмотрим активностную модель, предложенную Д. Россом в составе методологии функционального моделирования SADT (Structured Analysis and Design Technique) в 1973 году. Отображение взаимосвязи функций активностной модели осуществляется посред- ством построения иерархии функциональных диаграмм. Функциональная диаграмма представляет собой схематическое представление взаимосвязей нескольких функций. Каждый блок такой диаграммы соответствует неко- торой функции, для которой должны быть определены исходные данные, результаты, управляющая информация и механизмы ее осуществления – человек или технические средства. Все перечисленные выше связи функции представляются дугами, причем тип связи и ее направление строго регламентированы: дуги, изображающие каждый тип связей, должны подходить к блоку с определенной стороны (рис. 3.6), а направление связи должно указываться стрелкой в конце дуги. Физически дуги трех первых типов представляют собой наборы данных, переда- ваемые между функциями. Дуги, определяющие механизм выполнения функции, в ос- новном используют при описании спецификаций сложных информационных систем, которые включают как автоматизированные, так и ручные операции. Блоки и дуги маркируются текстами на естественном языке. Дуги могут разветв- ляться и соединяться вместе различными способами. Разветвление означает, что часть или вся информация может использоваться в каждом ответвлении дуги. Дуга всегда помечается до ветвления, чтобы идентифицировать передаваемый набор данных. Если ветвь дуги после ветвления не помечена, то непомеченная ветвь содержит весь набор данных. Каждая метка ветви уточняет, что именно содержит данная ветвь (рис. 3.7). Построение иерархии функциональных диаграмм ведется поэтапно с увеличением уровня детализации: диаграммы каждого следующего уровня уточняют структуру ро- дительского блока. Построение модели начинают с единственного блока, для которого 16 определяют исходные данные, результаты, управление и механизмы реализации. Затем он последовательно детализируется с использованием метода пошаговой детализации. При этом рекомендуется каждую функцию представлять не более чем 3–7-ю блоками. Во всех случаях каждая подфункция может использовать или продуцировать только те элементы данных, которые использованы или продуцируются родительской функ- цией, причем никакие элементы не могут быть опущены, что обеспечивает непротиво- речивость построенной модели. Стрелки, приходящие с родительской диаграммы или уходящие на нее нумеруют, используя символы и числа. Символ обозначает тип связи: I – входные, С – управляю- щие, M – механизмы, R – результаты. Число – номер связи по соответствующей сторо- не родительского блока, считая сверху вниз и слева направо. Все диаграммы связывают друг с другом иерархической нумерацией блоков: пер- вый уровень – А0, следующий – А1, А2 и т.п., следующий – А11, А12, А13 и т.д., где первые цифры – номер родительского блока, а последняя – номер конкретного суббло- ка родительского блока. Детализацию завершают при получении функций, назначение которых хорошо по- нятно, как заказчику, так и разработчику. Эти функции описывают, применяя естест- венный язык или псевдокоды. В процессе построения иерархии диаграмм фиксируют всю уточняющую инфор- мацию и строят словарь данных, в котором определяют структуры и элементы данных, показанных на диаграммах. Таким образом, в результате получают спецификацию, которая состоит из иерар- хии функциональных диаграмм, описаний функций нижнего уровня и словаря, имею- щих ссылки друг на друга. Пример 3.2. Разработку функциональных диаграмм продемонстрируем на примере уточнения спецификаций программы построения графиков и таблиц функций одной переменной (см. пример 3.1). Диаграмма, показанная на рис. 3.8, а, является диаграммой верхнего уровня. На ней хорошо видно, что является исходными данными для программы, и получения каких результатов мы ожидаем. Диаграмма, показанная на рис. 3.8, б, уточняет функции программы. На ней пока- заны четыре блока: ввод/выбор и ее разбор, добавление функции в список, построение таблицы значений и построение графика функции. Для каждого блока определены ис- 17 ходные данные, управляющие воздействия и результаты. Согласно правилам обозначе- ния входов/выходов, имеющих продолжение на родительской диаграмме, на диаграмме использованы следующие обозначения: I1 – функция; I2 – отрезок; I3 – шаг; C1 – вид график/таблица; R1 – график функции на отрезке; R2 – таблица значений функции на отрезке. Словарь в этом случае должен содержать описание всех данных, используемых в системе. Функциональную модель целесообразно применять для определения специфика- ций ПО, не предусматривающего работу со сложными структурами данных, так как она ориентирована на декомпозицию функций. Диаграммы потоков данных Диаграммы потоков данных позволяют специфицировать как функции разрабаты- ваемого ПО, так и обрабатываемые им данные. При использовании этой модели систе- му представляют в виде иерархии диаграмм потоков данных, описывающих асинхрон- ный процесс преобразования информации от ее ввода в систему до выдачи пользовате- лю. На каждом следующем уровне происходит уточнение процессов, пока очередной процесс не будет признан элементарным. В основе модели лежат понятия внешней сущности, процесса, хранилища (накопи- теля) данных потока данных. Внешняя сущность – материальный объект или физическое лицо, выступающие в качестве источников или приемников информации, например, заказчики, персонал, по- ставщики, клиенты, банк и т.п. Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Каждый процесс в системе имеет свой номер и связан с исполнителем, который осуществляет данное преобразование. Как в случае функциональных диаграмм, физически преобразование может осуществляться компьютерами, вручную или специальными устройствами. На верхних уровнях иерар- хии, когда процессы еще не определены, вместо понятия «процесс» используют поня- тия «система» и «подсистема», которые обозначают соответственно систему в целом или ее функционально законченную часть. Хранилище данных – абстрактное устройство для хранения информации. Тип уст- ройства и способы помещения, извлечения и хранения для такого устройства не дета- 18 лизируют. Физически это может быть база данных, файл, таблица в оперативной памя- ти, картотека на бумаге и т.п. Поток данных представляет собой процесс передачи некоторой информации от ис- точника к приемнику. Физически процесс передачи информации может происходить по кабелям под управлением программы или программной системы, а также вручную при участии устройств или людей вне проектируемой системы. Диаграмма, таким образом, иллюстрирует как потоки данных, порожденные неко- торыми внешними сущностями, трансформируются соответствующими процессами (или подсистемами), сохраняются накопителями данных и передаются другим внеш- ним сущностям – потребителям информации. В результате мы получаем сетевую мо- дель хранения/обработки информации. Для изображения диаграмм потоков данных традиционно используют два вида но- таций: нотации Йордана и Гейна-Сарсона (табл. 3.1). Над линией потока, направление которого обозначают стрелкой, указывают, какая конкретно информация в данном случае передается (рис. 3.9). Построение иерархии диаграмм потоков данных начинают с диаграммы особого вида – контекстной диаграммы, которая определяет наиболее общий вид системы. На такой диаграмме показывают, как разрабатываемая система будет взаимодействовать с приемниками и источниками информации без указания исполнителей, т.е. описывают интерфейс системы с внешним миром. Обычно начальная контекстная диаграмма име- ет форму звезды. Если проектируемая система содержит большое количество внешних сущностей (более 10), имеет распределенную природу или включает уже существующие подсис- темы, то строят иерархии контекстных диаграмм. Полученную таким образом модель системы проверяют на полноту исходных дан- ных об объектах системы и изолированность объектов (отсутствие информационных связей с другими объектами). На следующем этапе каждую подсистему контекстной диаграммы детализируют при помощи диаграмм потоков данных. В процессе детализации соблюдают правило б а л а н с и р о в к и – при детализа- ции подсистемы могут использоваться компоненты только тех подсистем, с кото- рыми у разрабатываемой подсистемы существует информационная связь (т.е. с кото- рыми она связана потоками данных). Решение о завершении детализации процесса принимают в следующих случаях: 19 * процесс взаимодействует с 2-3 потоками данных; * возможно описание процесса последовательным алгоритмом; * процесс выполняет единственную логическую функцию преобразования входной информации в выходную. На недетализируемые процессы составляют спецификации, которые должны со- держать описание логики (функций) данного процесса. Такое описание может выпол- няться: на естественном языке, с применением структурированного естественного язы- ка (псевдокодов), с применением таблиц и деревьев решений и в виде схем алгоритмов. Для облегчения восприятия процессы детализируемой подсистемы нумеруют, со- блюдая иерархию номеров: так процессы, полученные при детализации процесса или подсистемы «1», должны нумероваться «1.1», «1.2» и т.д. Кроме этого желательно раз- мещать на каждой диаграмме от 3 до 6-7 процессов и не загромождать диаграммы де- талями, не существенными на данном уровне. Декомпозицию потоков данных необходимо осуществлять параллельно с декомпо- зицией процессов. Полная спецификация процессов включает описание структур дан- ных, используемых как при передаче информации в потоке, так и при хранении в нако- пителе (см. § 3.5). Законченную модель необходимо проверить на полноту и согласованность. Под согласованностью модели в данном случае понимают выполнение для всех потоков данных правила сохранения информации: все поступающие куда-либо данные должны быть считаны и записаны. Пример 3.3. Разработать иерархию диаграмм потоков данных системы учета успе- ваемости студентов (см. техническое задание в приложении 1). В качестве внешних сущностей для системы выступают Декан, Заместитель декана по курсу и Сотрудник деканата. Определяем потоки данных между этими сущностями и системой. Декан должен получать: * сводку успеваемости по факультету (процент успеваемости групп, курсов и в це- лом по факультету) на текущий или указанный момент времени; * полные сведения об учебе конкретного студента (успеваемость по всем изучен- ным предметам всех завершенных семестров обучения с учетом пересдач). Заместитель декана по курсу должен получать: 20 * сводку успеваемости по курсу (процент успеваемости по группам) на текущий или указанный момент; * сведения о сдаче экзаменов и зачетов указанной группой; * текущие сведения об успеваемости конкретного студента; * полные сведения об учебе конкретного студента (успеваемость по всем изучен- ным предметам всех завершенных семестров обучения с учетом пересдач); * список задолжников по факультету с указанием несданных предметов и групп. Сотрудник деканата должен обеспечивать: * ввод списков студентов, зачисленных на первый курс; * корректировку списков студентов в соответствии с приказами о зачислении, от- числении, переводе и т.п.; * ввод учебных планов кафедр; * ввод расписания сессии; * ввод результатов сдачи зачетов и экзаменов на основании ведомостей и направ- лений. Кроме того, сотрудник декана должен иметь возможность получать: * справку о прослушанных студентом предметах с указанием часов и итоговых оценок; * приложение к диплому выпускника также с указанием часов и итоговых оценок. В результате получаем контекстную диаграмму, которая изображена на рис. 3.10 (нотации Гейна-Сарсона). Далее детализируем процессы в системе. На рис. 3.11 представлена детализирую- щая диаграмма потоков данных, на которой выделены две подсистемы: Подсистема на- полнения базы и Подсистема формирования отчетов, а также хранилище данных, кото- рое может быть реализовано как с помощью средств СУБД, так и без них. Дальнейшая детализация процессов может не выполняться, так как их сущность для разработчика очевидна. Однако становится ясно, что полная спецификация данной разработки должна включать описание базы данных. Такое описание в виде диаграммы «сущность-связь» будет рассмотрено в § 3.5. Кроме этого, как уже упоминалось в § 3.1, целесообразно выполнить моделирова- ние управляющих процессов в системе. |