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

198
Чтобы написать программу, которая должна быть легко видоизме- няемой, можно выделить те аспекты задачи, которые подвержены изме- нениям, и сделать их элементами легко изменяемых таблиц – объектов, состоящих из конечного числа элементов, образующих строки и столб- цы. Строки и (или) столбцы имеют имена или номера (индексы), и по- ложение элемента в таблице однозначно определяется указанием столб- ца и строки.
Таблицы решений состоят из условий, данных и действий, т.е. из ос- новных элементов всех программ, и поэтому могут использоваться как гибкий инструмент для описания не только данных, но и значительной части логики любой программы. Таблицы используются обычно для описания конечных функций, конечных отношений, табличных струк- тур данных (например, матрицы в алгебре, двумерные массивы в языках программирования, документы в сфере административно - хозяйствен- ного управления и др.).
В табличном описании конечной функции F(X
i
, Х
j
, ..., Х
n
) строка
(или столбец) таблицы состоит из значений аргументов и соответст- вующего значения функции, имена столбцов (или соответственно строк)
– это имена аргументов и самой функции. Язык таблиц решений, оче- видно, специализирован "по средствам" и может применяться в самых различных областях. Кроме того, его можно считать языком програм- мирования, так как таблицы решений легко и эффективно реализуются.
Средства описания конечных функций являются существенной частью ряда универсальных языков спецификаций, например, CIP-L и VDM, где определены специальные операции над конечными функциями.
В табличном описании конечного отношения R(X
i
, Х
j
, ..., Х
n
), где X
i
,
.... Х
n
– имена компонент (аргументов или областей) отношения, стро- кой таблицы является кортеж элементов. Конечные отношения играют главную роль в языках описания и манипулирования данными реляци- онных баз данных. В некоторых реляционных языках определен ряд операций над отношениями. Табличные структуры данных, не интер- претируемые явно как функции или отношения, используются в про- граммировании давно, в частности в форме двумерных массивов многих языков программирования. По существу, одним из первых языков спе- цификации является РПГ, в основе которого лежит табличное описание задач генерации отчетов. Матрицы и операции над ними используются, естественно, при спецификации пакетов программ для задач линейной алгебры, а также в языке АПЛ. Разного рода таблицы - одна из основ- ных форм представления данных в языках, ориентированных на задачи обработки административных и экономических документов. Это делает таблицы удобным средством специфицирования очень многих задач.
5.2.2. Структурный подход представления спецификаций
В структурном подходе используются в основном две группы средств, описывающих функциональную структуру системы и отноше- ния между данными. Каждой группе соответствуют определенные виды

199 моделей (диаграмм), наиболее распространенными, среди которых яв- ляются [7, 8]:
DFD (Data Flow Diagrams) – диаграммы потоков данных;
SADT (Structured Analysis and Design Technique – метод структурно- го анализа и проектирования) – модели и соответствующие функ- циональные диаграммы;
ERD (Entry – Relation Diagrams) – диаграммы “сущность - связь”.
Методологии структурного анализа и проектирования, основанные на моделировании потоков данных, обычно используют комплексное представление программного обеспечения в виде совокупности этих моделей, дополненных спецификаций процессов; и словарем терми- нов. Взаимосвязь элементов такой обобщенной модели показана на рис.
5.4.
Конкретный вид диаграмм и интерпретация их конструкций зависят от стадии жизненного цикла программной системы. На стадии форми- рования требований к программной системе SADT и DFD используются для построения моделей ”AS IS” и “TO BE”, отражая, таким образом, существующую и предлагаемую структуру бизнес-процессов, которые необходимо автоматизировать с помощью программной системы. Ис- пользование SADT-моделей, как правило, ограничивается только дан- ной стадией, поскольку они первоначально не предназначались для про- ектирования программных систем. С помощью ERD-диаграмм выпол- няется описание используемых в разрабатываемой программной систе- ме данных на концептуальном уровне, не зависимом от средств реали- зации баз данных (СУБД).
Рис. 5.4. Комплексное представление программного обеспечения в виде совокупности моделей DFD, SADT и ERD

200
На стадии проектирования программной системы используются
DFD-диаграммы, описывающие взаимодействия источников и потреби- телей информации через процессы, которые должны быть реализованы в системе. Таким образом, позволяют представлять структуру проекти- руемой программной системы, при этом они могут уточняться, расши- ряться и дополняться новыми конструкциями. Аналогично ERD- диаграммы уточняются и дополняются новыми конструкциями, описы- вающими представление данных на логическом уровне, пригодном для последующей генерации схемы базы данных.
5.2.3. Метод функционального моделирования.
Функциональные диаграммы
Метод SADT разработан Дугласом Россом (SoftTech, Inc) в 1973 го- ду [19]. Данный метод успешно использовался в военных, промышлен- ных и коммерческих организациях США для решения широкого круга задач, таких, как долгосрочное и стратегическое планирование, автома- тизированное производство и проектирование, разработка программно- го обеспечения для оборонных систем, управления финансами и мате- риально-техническим снабжением и др. Метод SADT поддерживается министерством обороны США, которое было инициатором разработки стандарта IDEF0 (Icam DEFination) – подмножества SADT, являющегося основной частью программы ICAM (Integrated Computer Aided Manufac- turing – интегрированная компьютеризация производства), проводимой по инициативе ВВС США. Методология SADT представляет собой на- бор методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области.
Функциональная модель SADT отображает функциональную струк- туру объекта, т.е. производимые им действия и связи между этими дей- ствиями. Основные элементы этой методологии основываются на сле- дующих концепциях [8, 20]: графическое представление блочного моделирования. На SADT- диаграмме функции представляются в виде блока, а интерфейсы входа-выхода – в виде дуг, входящих и выходящих из него; отображение взаимодействия функций друг с другом посредством определенных интерфейсных дуг; следование правилам, определяющим строгость и точность отобра- жения.
Правила SADT включают: уникальность меток и наименований; ограничение количества блоков на каждом уровне детализации; синтаксические правила для графики; связность диаграмм; отделение организации от функции; разделение входов и управлений.
Методология SADT может использоваться для моделирования и раз- работки широкого круга систем, удовлетворяющих определенным тре-

201 бованиям и реализующих требуемые функции. В уже разработанных системах методология SADT может быть использована для анализа вы- полняемых ими функций, а также для указания механизмов, посредст- вом которых они осуществляются.
Диаграммы – главные компоненты модели, все функции программ- ной системы и интерфейсы представлены на них как блоки и дуги. Ме- сто соединения дуги с блоком определяет тип интерфейса. Дуга, обо- значающая управление, входит в блок сверху, в то время как информа- ция, которая подвергается обработке, представляется дугой с левой сто- роны блока, а результат обработки – дугами с правой стороны. Меха- низм (человек, автоматизированная система или другой объект), кото- рый осуществляет операцию, представляется в виде дуги, входящей в блок снизу (рис.5.5).
Блоки на диаграмме размещают по “ступенчатой ” схеме в соответ- ствии с последовательностью их работы или доминированием, которое понимается как влияние, оказываемое одним блоком на другие. В функ- циональных диаграммах SADT различают пять типов влияния блоков друг на друга [8]: вход-выход блока подается на вход блока с меньшим доминировани- ем, т.е. следующего блока (рис. 5.6 а); управление. Выход блока используется как управление для блока с меньшим доминированием (рис. 5.6 б); обратная связь по входу. Выход блока подается на вход блока с большим доминированием (рис. 5.6 в); обратная связь по управлению. Выход блока используется как управляющая информация для блока с большим доминированием
(рис. 5.6 г); выход-исполнитель. Выход блока используется как механизм для другого блока (рис.5.6 д).
Рис. 5.5. Структура блока
На рис. 5.7 приведены четыре диаграммы и их взаимосвязи, показы- вающие структуру SADT-модели. Каждый компонент может быть де- тализирован на другой диаграмме. Детальная диаграмма иллюстрирует внутренне строение блока родительской диаграммы.

202
Рис. 5.6. Типы взаимосвязей блоков
Построение SADT-модели начинается с представления всей системы в виде простейшего компонента – одного блока и дуг, изображающих интерфейсы с внешними по отношению к данной системе функциями.
Имя блока является общим для всей системы. Затем блок, представ- ляющий систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсны- ми дугами. Каждый блок детальной диаграммы представляет собой подфункцию, границы которой определены интерфейсными дугами.
Каждый из блоков детальной диаграммы может быть также детализиро- ван на следующей в иерархии диаграмме (рис. 5.7). На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы.
Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Кроме того, модель не может опустить какие-либо элементы, т.е. родительский блок и его ин- терфейсы обеспечивают контекст. К нему нельзя ничего добавить, и из него ничего не может быть удалено.
Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самими, что и дуги, входящие в диа- грамму нижнего уровня, и выходящие из нее, потому что блок и диа- грамма изображают одну и ту же часть системы.
На рис. 5.8 представлены различные варианты выполнения функций и соединения дуг с блоками. Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же один конец остается непри- соединенным. Неприсоединенные дуги соответствуют входам, управле- ниям и выходам родительского блока. Источник или получатель этих пограничных дуг может быть обнаружен только на родительской диа-

203 грамме. Все граничные дуги должны продолжаться на родительской диаграмме, чтобы она была полной и непротиворечивой (рис. 5.9).
Рис. 5.7. Детализация структуры в иерархии диаграмм
Рис. 5.8. Варианты выполнения функций
На SDT-диаграммах не указывается явно ни последовательность операций, ни время их выполнения. Обратные связи, итерации, продол- жающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений и т. д. (рис. 5.10).

204
Рис. 5.9. Соответствие дуг в иерархии диаграмм
Рис. 5.10. Представление обратных связей
Рассмотрим пример разработки функциональной диаграммы с целью уточнения спецификаций программы сортировки одномерного массива с использованием нескольких методов. Диаграмма, представленная на рис. 5.11 а, является диаграммой верхнего уровня. Она иллюстрирует исходные данные программы и ожидаемые результаты.
Диаграмма на рис. 5.11 б детализирует функции программы. На ней показаны три блока: Меню, Сортировка, Вывод результата. Для каждого блока определены исходные данные, управляющие воздействия и ре- зультаты. На детализирующей диаграмме определены следующие обо- значения: I1 – размер массива, I2 – массив, C1 – выбор метода, R1 – вы- вод описания метода, R2 – вывод отсортированного массива.
Одним из важных моментов при моделировании программных сис- тем с помощью метода SADT является точная согласованность типов связей между функциями. В [7] предлагается различать семь типов свя- зей между блоками (функциями): случайная, логическая, временная,

205 процедурная, коммуникационная, последовательная и функциональная.
При этом считается, что три последних вида связей являются предпоч- тительными для диаграмм хорошего качества. Однако такой подход плохо согласуется с применением метода SADT к структурному проек- тированию программных систем. Дело в том, что блок SADT- диаграммы в этом случае отождествляется с программным модулем.
Рис. 5.11. Пример функциональной диаграммы, специфицирующей сортировку одномерного массива
Известно, что сцепление модулей в программной системе представ- ляет собой меру относительной независимости модулей, которая опре- деляет их читабельность и сохранность. Независимые модули могут модифицироваться без переделки других модулей. Слабое сцепление модулей более желательно, так как это означает высокий уровень их независимости.
В то же время в методологии структурного проектирования про- граммных систем используется понятие связности модуля (внутренней связности его частей). Чем выше связность модулей, тем лучше резуль- тат проектирования [12, 18, 28] . Именно для оценки связности модуля и применяется семь видов внутренней связи между частями модуля, кото- рые в [7] перенесены для характеристики межблочных связей в SADT- диаграммах. То, что в [7] понимается под функциональной связью на самом деле является связью по управлению, в понимании, принятом в публикациях [12, 18, 28].

206
Учитывая все выше сказанное, в SADT-диаграммах в случае их при- менения для поддержки структурного проектирования программных систем целесообразно использовать для характеристики сцепления (свя- зи) блоков (модулей) следующие меры: независимое сцепление (сла- бое), сцепление по данным, по образцу, по общей области, по управле- нию, по внешним ссылкам, по функциям. Последний вид связи блоков возникает в том случае, когда один блок обращается к внутренним функциям другого блока без обращения к его точкам входа. В про- граммном смысле это сцепление модулей возникает тогда, когда для одного модуля доступны внутренние области другого модуля, т.е. два модуля используют общий участок памяти с командами. Такое сцепле- ние характерно для случая, когда модули проектируются как отдельные подпрограммы, путь через которые начинается в различных точках вхо- да, но приводит к общему сегменту кодов.
5.2.4. Диаграммы потоков данных
Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований к проектируемой системе.
С их помощью требования представляются в виде иерархии функцио- нальных компонентов (процессов), связанных потоками данных. Глав- ная цель такого представления – продемонстрировать, как каждый про- цесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Для построения DFD-диаграмм используются две различные нота- ции, соответствующие методам Йордана и Гейна-Сэрсона, которые не- значительно отличаются графическими изображениями символов. Далее при построении примеров будет использоваться нотация Гейна-
Сэрсона. Построение DFD-диаграмм в основном ассоциируется с разра- боткой программных систем и нотация DFD изначально была разрабо- тана для этих целей.
В соответствии с данными методами модель системы определяется как иерархия потоков данных, описывающих асинхронный процесс преобразования информации от ее входа в систему до выдачи пользова- телю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня.
Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор пока не будет достигнут такой уровень декомпо- зиции, на котором процессы становятся элементарными и детализиро- вать их далее невозможно.
Источники информации (внешние сущности) порождают информа- ционные потоки (потоки данных), переносящие информацию к подсис- темам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущно- стям – потребителям информации.