Файл: Инфрам.pdf

207
Основными компонентами DFD-диаграмм являются: внешние сущности; системы и подсистемы; накопители данных; потоки данных.
Внешние сущности представляют собой материальные объекты или физическое лицо, являющее собой источник или приемник информации, например, заказчик, персонал, поставщик, клиент, склад. Определение некоторого объекта или системы в качестве внешней сущности указы- вает на то, что они находятся за пределами границ анализируемой сис- темы. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой системы, если это необ- ходимо, или, наоборот, часть процессов может быть вынесена за преде- лы диаграммы и представлена как внешняя сущность.
Внешняя сущность обозначается квадратом (рис. 5.12), расположен- ным как бы над диаграммой и бросающим тень для того, чтобы можно было выделить символ среди других обозначений.
Рис. 5.12. Обозначение внешней сущности
При построении модели сложной программной системы она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого, либо может быть декомпозирована на несколько подсистем (рис. 5.13).
Рис. 5.13. Контекстная диаграмма
Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в форме предложения с подлежа- щим и соответствующими определениями и дополнениями.

208
Процесс представляет собой преобразование входных потоков дан- ных в выходные в соответствии с определенным алгоритмом. Физиче- ски процесс может быть реализован различными способами: это может быть подразделение (отдел) организации, выполняющее определенную обработку входных документов и выпуск отчетов, программа, аппарат- но реализованное физическое устройство и т. д. Процесс на диаграмме изображается в виде прямоугольника с закругленными углами (рис.
5.14).
Рис. 5.14. Изображение процесса
Номер процесса служит для ее идентификации. В поле имени вво- дится наименование процесса в виде предложения с активным недву- смысленным глаголом в неопределенной форме (вычислить, проверить, рассчитать, создать и т. п.), за которым следует существительное в ви- нительном падеже (см. рис. 5.14). Использование таких глаголов, как
“обработать”, “модернизировать” или “отредактировать”, означает не- достаточно глубокое понимание данного процесса и требует дальней- шего анализа. Информация в поле физической реализации показывает, какое подразделение, программа или устройство выполняет данный процесс.
Накопитель данных – это абстрактное устройство для хранения ин- формации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлече- ния могут быть любыми. Накопитель данных (хранилище) может быть реализован физически в форме таблицы в оперативной памяти, файла на магнитном диске, ящика в картотеке и т. д. Накопитель данных на диаграмме идентифицируется буквой “D” и произвольным числом. Имя накопителя выбирается из соображений наибольшей информативности для проектировщика (рис. 5.15).
Рис. 5.15. Изображение накопителя данных

209
Накопитель данных в общем случае является прообразом будущей базы данных, описание хранящихся в нем данных должно быть увязано с информационной моделью (ERD). Поток данных изображается стрел- кой и описывает передвижение информации от источника к приемнику.
Реально это может быть информация, передаваемая по кабелю между двумя устройствами, пересылаемые по почте письма, дискеты, переда- ваемые с одного компьютера на другой и т. д. Каждый поток имеет имя, отражающее его содержание (рис. 5.16).
Рис. 5.16. Изображение потоков данных
Ссылки на DFD-диаграммах могут быть разбиты (разветвлены) на части, при этом каждый получившийся сегмент может быть переимено- ван таким образом, чтобы показать декомпозицию данных, переноси- мых некоторым потоком (рис. 5.17). Стрелки могут и соединяться меж- ду собой (объединяться) для формирования комплексных объектов. На- пример, чтобы сформировать адрес налогоплательщика необходимо иметь данные об его элементах (индексе, городе, улице, номере дома и номере квартиры).
Рис. 5.17. Декомпозиция данных
При использовании DFD-диаграмм с целью моделирования функ- циональных требований, предъявляемых к программной системе, для ясности их понимания и удобства работы проектировщика строят ие- рархию диаграмм. При этом целесообразно выполнять следующие ре- комендации [7]:

210 размещать на каждой диаграмме от 3 до 6 – 7 процессов; не загромождать диаграммы несущественными на данном уровне деталями; декомпозицию потоков данных осуществлять параллельно с деком- позицией процессов; выбирать ясные, отражающие суть дела, имена процессов м потоков, стараясь не использовать аббревиатуры.
Первым шагом при построении иерархии диаграмм потоков данных является построение контекстных диаграмм, показывающих, как проек- тируемая система будет взаимодействовать с пользователями и другими внешними системами (некоторый аналог вариантам использования в объектно-ориентированном подходе). При проектировании относитель- но простых систем достаточно одной контекстной диаграммы, имеющей звездную топологию, в центре которой располагается основной процесс, соединенный с источниками и приемниками информации.
Для сложных систем строится иерархия контекстных диаграмм, ко- торая определяет взаимодействие основных функциональных подсистем проектируемой системы как между собой, так и с внешними входными и выходными потоками данных и внешними объектами. При этом кон- текстная диаграмма верхнего уровня содержит набор подсистем, соеди- ненных потоками данных. Контекстные диаграммы следующего уровня детализируют содержимое и структуру подсистем.
После построения контекстных диаграмм полученную модель надо проверить на полноту исходных данных об объектах системы и изоли- рованность объектов (отсутствие информационных связей с другими объектами). Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи DFD-диаграмм.
Каждое событие представляется в виде процесса с соответствующими входными и выходными потоками, накопителями данных, внешними сущностями ссылками на другие процессы для описания связей между этим процессом и его окружением.
Каждый процесс на DFD-диаграмме, в свою очередь, может быть де- тализирован при помощи DFD или (если процесс элементарный) специ- фикации. При детализации должны соблюдаться следующие правила: правило балансировки, означающее, что при детализации подсисте- мы можно использовать только те компоненты (подсистемы, процес- сы, внешние сущности, накопители данных), с которыми она имеет связь на родительской диаграмме; правило нумерации, заключающееся в том, что при детализации процессов должна поддерживаться их иерархическая нумерация

211 наличие у процесса небольшого количества входных и выходных данных (2 – 3 потока); возможности описания преобразования данных процессом в виде последовательного алгоритма; выполнение процессом единственной логической функции преобра- зования входной информации в выходную; возможности описания логики процесса при помощи спецификации небольшого объема (не более 20 – 30 строк).
Спецификации должны удовлетворять следующим требованиям: для каждого процесса нижнего уровня должна существовать одна и только одна спецификация; спецификация должна определять способ преобразования входных потоков в выходные; нет необходимости (по крайней мере на стадии формирования тре- бований) определять метод реализации этого преобразования; спецификация должна стремиться к ограничению избыточности – не следует переопределять то, что уже было определено на диаграмме; набор конструкций для построения спецификаций должен быть про- стым и понятным.
Фактически спецификация представляет собой описание алгоритмов задач, выполняемых процессами. Спецификации содержат номер и/или имя процесса, списки входных м выходных данных и тело (описание) процесса, являющееся спецификацией алгоритма или операции, транс- формирующей входные потоки данных в выходные. Известно большое количество разнообразных методов, позволяющих описать тело процес- са. Соответствующие этим методам языки могут варьироваться от структурированного естественного языка или псевдокода до языков ви- зуального проектирования.
Структурированный естественный язык применяется для читабель- ного, достаточно строгого описания спецификаций процессов. Такой язык состоит из подмножества слов, организованных в определенные логические структуры, арифметических выражений и диаграмм. К управляющим структурам языка относятся последовательная конструк- ция, конструкция выбора и итерация (цикл).
При использовании структурированного естественного языка приня- ты следующие соглашения: логика процесса выражается в виде комбинации последовательных конструкций, конструкций выбора и итераций; глаголы должны быть активными, недвусмысленными и ориентиро- ванными на целевое действие (например, заполнить, вычислить, из- влечь, а не модернизировать, обработать); логика процесса должна быть выражена четко и недвусмысленно.
При построении иерархии диаграмм потоков данных переходить к детализации процессов следует только после определения структур данных, которые описывают содержание всех потоков и накопителей данных. Структуры данных могут содержать альтернативы, условные

212 вхождения и итерации. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Условное вхождение пока- зывает, что данный компонент может отсутствовать в структуре. Итера- ция предусматривает вхождение любого числа элементов из указанного диапазона.
Для каждого элемента может указываться его тип (непрерывный или дискретный). Для непрерывных данных может указываться единица измерения, диапазон значений, точность представления и форма физи- ческого кодирования. Для дискретных данных может указываться таб- лица допустимых значений.
После построения законченной модели системы ее необходимо ве- рифицировать (проверить на полноту и согласованность). В полной мо- дели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы. В согласованной модели для всех потоков данных и накопителей данных должно выполняться пра- вило сохранения информации: все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записа- ны.
5.2.5. Диаграммы переходов состояний
Диаграммы STD (State Transition Diagram) демонстрируют поведение разрабатываемой программной системы при получении управляющих воздействий (извне). В диаграммах такого вида узлы соответствуют со- стояниям системы, а дуги – переходу системы из одного состояния в другое. Узел, из которого выходит дуга, является начальным (промежу- точным) состоянием, а узел, в который входит – следующим состояни- ем. Дуга помечается именем входного сигнала или события, вызываю- щего переход, а также сигналом или действием, сопровождающим пе- реход. Условные обозначения, используемые в SDT-диаграммах, пока- заны на рис. 5.18 (а – терминальное состояние, б – промежуточное со- стояние, в – переход).
Рис. 5.18. Обозначения на STD-диаграммах
На рис. 5.19 приведена диаграмма переходов состояний программы, активно не взаимодействующей с окружающей средой, которая имеет примитивный интерфейс, производит некоторые вычисления и выводит результат.

213
Рис. 5.19. Пример диаграммы переходов и состояний
Другой пример, более сложный, показан на рис. 5.20 – это диаграмма переходов торгового автомата, активно взаимодействующего с покупа- телем.
Рис. 5.20. Диаграммы переходов и состояний торгового автомата
5.3. Анализ требований и определение спецификаций при объ-
ектном подходе
5.3.1. Общие сведения о языке UML как языке моделирования слож- ных систем
В основе объектного подхода к разработке программных системы лежит объектная декомпозиция, т.е. представление разрабатываемого продукта в виде совокупности объектов, в процессе взаимодействия которых через передачу сообщений происходит выполнение требуемых функций. Впервые объектно-ориентированное направление в разработ- ке и дизайне появилось благодаря возможностям компьютерной имита- ции. Главный принцип компьютерной имитации состоит в том, что про- грамма должна моделировать реальный мир. Самый естественный путь к этому заключается в том, чтобы компьютерная программа оперирова- ла с объектами, являющимися отражением сущностей реального мира,

214 которые моделируют их действия и отражают свойства, которой они обладают.
Системное моделирование вносит дополнительную формальность в процессы анализа и проектирования. В процессе разработки системы очень часто используются схемы и рисунки, которые помогают нагляд- но отобразить некоторые аспекты разработки. Системное моделирова- ние формализует это наглядное представление не только с помощью диаграмм, выполненных с использованием стандартных нотаций (син- таксиса), но и обеспечивает среду (средства) для понимания и обсужде- ния идей, связанных с процессом разработки. На практике не существу- ет единственного правильного решения, поэтому модели меняются и развиваются на протяжении этапов разработки. В большинстве случаев модели представляют собой некий визуальный ряд, в котором для ото- бражения информации используются взаимосвязанные диаграммы.
Моделирование в процессах разработки систем дает следующие преимущества [29]: поощряет использование точно определенной терминологии, одно- значность которой поддерживается в рамках разработки всей систе- мы; позволяет с помощью диаграмм получить наглядное представление системных спецификаций и архитектуры системы; позволяет рассматривать различные аспекты взаимодействия систе- мы с различных точек зрения; поддерживает системный анализ; позволяет подтвердить достоверность некоторых аспектов поведе- ния системы с помощью динамических моделей; позволяет постоянно совершенствовать систему посредством уточ- нения архитектуры, поддерживая генерацию тестов и исходного ко- да; позволяет свободно общаться различным организациям между со- бой, используя стандартные нотации.
Объектно-ориентированные подходы моделирования существенно отличаются от структурных подходов. Объекты представляют собой устойчивые и (будем надеяться на это) повторно используемые компо- ненты. Объектно-ориентированные подходы направлены на максимиза- цию повторного использования инженерами объектов при разработке системных требований и спецификаций системы. Таким образом, целью объектно-ориентированного подхода являются: инкапсуляция, т.е. заключение внутрь объектов их поведения (со- стояния и событий), информации (данных) и операций; создание устойчивых объектов, которые могут быть использованы как для разработки требований, так и для разработки спецификаций системы; добавление информации путем большей детализации уже сущест- вующих объектов; создание новых объектов путем детализации (конкретизации) суще- ствующих объектов, а не создание абсолютно новых.