Структурный метод разработки программного обеспечения

Сущность структурного подхода к разработке АИС заключает­ся в ее декомпозиции (разбиении) на автоматизируемые функ­ции: система разбивается на функциональные подсистемы, ко­торые в свою очередь делятся на подфункции, подразделяемые на задачи, и т.д. Процесс разбиения продолжается вплоть до кон­кретных процедур. При этом об автоматизируемой системе со­храняется целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы «снизу вверх» от отдельных задач к всей системе целостность теряется,

89

возникают проблемы при информационной стыковке отдельных компонентов.

Все методологии структурного анализа базируются на ряде об­щих принципов, часть из которых регламентирует организацию работ на начальных этапах жизненного цикла, а часть использует­ся при выработке рекомендаций по организации работ [16]. В ка­честве двух базовых используются принципы «разделяй и властвуй» и иерархического упорядочивания. Первый является принципом решения трудных проблем путем их разбиения на множество мень­ших независимых задач, более легких для понимания и решения. Второй принцип декларирует, что устройство этих частей также существенно для понимания. Уровень уяснения проблемы резко повышается при представлении ее частей в виде древовидных иерархических структур, т. е. система может быть понята и постро­ена по уровням, каждый из которых добавляет новые детали.

Выделение двух базовых принципов инженерии ПО не означа­ет, что остальные принципы являются второстепенными. Игно­рирование любого из них может привести к непредсказуемым последствиям (в том числе и к неуспеху всего проекта). Отметим основные из таких принципов.

1. Принцип абстрагирования заключается в выделении суще­ственных с некоторых позиций аспектов системы и отвлечении от несущественных с целью представления проблемы в простом об­щем виде.

2. Принцип формализации состоит в необходимости строгого методического подхода к решению проблемы.

3. Принцип «упрятывания» заключается в упрятывании несу­щественной на конкретном этапе информации: каждая часть «зна­ет» только необходимую ей информацию.

4. Принцип концептуальной общности означает следование единой философии на всех этапах жизненного цикла (структур­ный анализ — структурное проектирование — структурное про­граммирование — структурное тестирование).

5. Принцип полноты заключается в контроле за отсутствием лишних элементов.

6. Принцип непротиворечивости состоит в обоснованности и согласованности элементов.

7. Принцип логической независимости означает концентрацию внимания на логическом проектировании для обеспечения неза­висимости от физического проектирования.

8. Принцип независимости данных заключается в том, что мо­дели данных должны быть проанализированы и спроектированы независимо от процессов их логической обработки, а также от их физической структуры и распределения.

9. Принцип структурирования данных состоит в том, что данные должны быть структурированы и иерархически организованы.

90

10. Принцип доступа конечного пользователя заключается в том, что пользователь должен иметь средства доступа к БД, которые он может использовать непосредственно (без программирования).

Соблюдение указанных принципов необходимо при организа­ции работ на начальных этапах жизненного цикла независимо от типа разрабатываемого ПО и используемых при этом методоло­гий. Руководствуясь всеми принципами в комплексе, можно на более ранних стадиях разработки понять, что будет представлять из себя создаваемая система, обнаружить промахи и недоработ­ки, что, в свою очередь, облегчит работы на последующих этапах жизненного цикла и понизит стоимость разработки.

В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой, и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распро­страненными среди которых являются:

• SADT (Structured Analysis and Design Technique) — модели и соответствующие функциональные диаграммы;

• DFD (Data Flow Diagrams) — диаграммы потоков данных;

• ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь»;

• STD (State Trasition Diagrams) — диаграммы переходов состо­яний.

На стадии проектирования ИС модели расширяются, уточня­ются и дополняются диаграммами, отражающими структуру ПО: архитектуру, структурные схемы программ и диаграммы экран­ных форм.

Перечисленные модели в совокупности дают полное описание АИС независимо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы.

Методология SADT. Методология SADT была разработана Д. Россом. На ее основе создана, в частности, известная методо­логия IDEFO (icam DEFinition), которая является основной час­тью программы ICAM (Интеграция компьютерных и промышлен­ных технологий), проводимой по инициативе ВВС США. Методо­логия SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной мо­дели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т. е. осуществляемые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следую­щих концепциях:

• графическое представление блочного моделирования. Графи­
ка блоков и дуг SADT-диаграммы отображает функцию в виде
блока, а интерфейсы входа/выхода представляются дугами, со-

91

ответственно входящими в блок и выходящими из него. Взаимо­действие блоков друг с другом описывается посредством интер­фейсных дуг, выражающих «ограничения», которые в свою оче­редь определяют, когда и каким образом функции выполняются и управляются;

• строгость и точность. Выполнение правил SADT требует до­статочной строгости и точности, но в то же время не накладывает чрезмерных ограничений на действия аналитика.

Правила SADT включают:

1) ограничение количества блоков на каждом уровне декомпо­зиции (как правило, три-шесть блоков);

2) связность диаграмм (номера блоков);

3) уникальность меток и наименований (отсутствие повторя­ющихся имен);

4) синтаксические правила для графики (блоков и дуг);

5) разделение входов и управлений (правило определения роли данных);

6) отделение организации от функции, т. е. исключение влия­ния организационной структуры на функциональную модель.

Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим тре­бованиям и реализует эти функции. Для уже существующих си­стем SADT может быть использована для анализа функций, вы­полняемых системой, а также для указания механизмов, посред­ством которых они осуществляются.

Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы — это главные компо­ненты модели, все функции ИС и интерфейсы на них представле­ны как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода — с правой. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рис. 7.1). Одной из наиболее важных особенностей методо­логии SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель.

Построение SADT-модели начинается с представления всей системы в виде простейшего компонента — одного блока и дуг, изображающих интерфейсы с функциями вне системы. Посколь­ку единственный блок представляет всю систему как единое це­лое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг: они также представляют полный набор вне­шних интерфейсов системы в целом.

9/

Механизм Рис. 7.1. Функциональный блок и интерфейсные дуги

Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью несколь­ких блоков, соединенных интерфейсными дугами. Эти блоки пред­ставляют основные подфункции исходной функции. Данная де­композиция выявляет полный набор подфункций, каждая из ко­торых представлена как блок, границы которого определены ин­терфейсными дугами. Каждая из этих подфункций может быть де­композирована подобным образом для более детального представ­ления.

Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Кроме того, мо­дель не может опустить какие-либо элементы, т.е., как уже отме­чалось, так называемый родительский блок и его интерфейсы обеспечивают контекст. К нему нельзя ничего добавить и из него не может быть ничего удалено.

Модель SADT представляет собой серию диаграмм с сопрово­дительной документацией, разбивающих сложный объект на со­ставные части, которые представлены в виде блоков. Детали каж­дого из основных блоков показаны в виде блоков на других диа­граммах. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы (рис. 7.2 и 7.3).

Дуги, входящие в блок и выходящие из него на диаграмме верх­него уровня, являются точно теми же самыми, что и дуги, входя­щие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы.

Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же один конец остается неприсоединенным. Неприсоединенные дуги соответствуют входам, управлениям и пыходам родительского блока. Источник или получатель этих по­граничных дуг может быть обнаружен только на родительской диаграмме. Неприсоединенные концы должны соответствовать дугам на исходной диаграмме. Все граничные дуги должны про­должаться на родительской диаграмме, чтобы она была полной и i ^противоречивой.

На SADT-диаграммах явно не указаны ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы

 

Рис. 7.2. Структура SADT-модели (декомпозиция диаграмм): а — общее представление; б — детальное представление

и перекрывающиеся (по времени) функции могут быть изобра­жены с помощью дут. Обратные связи могут выступать в виде ком­ментариев, замечаний, исправлений и т.д.

Как было отмечено, механизмы (дуги с нижней стороны) по­казывают средства, с помощью которых осуществляется выпол­нение функций. Механизм может быть человеком, компьютером или любым другим устройством, которое помогает выполнять дан­ную функцию.

94

Рис. 7.3. Иерархия диаграмм:

а — детальная диаграмма; б — родительская диаграмма

Каждый блок на диаграмме имеет свой номер. Блок любой диа­граммы может быть далее описан диаграммой нижнего уровня, которая в свою очередь может быть далее детализирована с помо­щью необходимого числа диаграмм. Таким образом, формируется иерархия диаграмм.

Для того чтобы указать положение любой диаграммы или бло­ка в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграм­ме А2. Аналогично, А2 детализирует блок 2 на диаграмме АО, ко­торая является самой верхней диаграммой модели.

Одним из важных моментов при проектировании ИС с помо­щью методологии SADT^ является точная согласованность типов связей между функциями. Различают по крайней мере семь типов связывания. Далее каждый тип связи кратко определен и проил­люстрирован с помощью типичного примера из SADT (табл. 7.1).

(0) Тип случайной связности. Наименее желательный. Случай­ная связность возникает, когда конкретная связь между функция­ми мала или полностью отсутствует. Это относится к ситуации, когда имена данных на SADT-дугах в одной диаграмме имеют малую связь друг с другом.

95

Таблица 7.1

Типы связности для функций и данных

 

Значимость	Тип связности	Для функций	Для данных
0	Случайная	Случайная	Случайная
1	Логическая	Функции одного и того же множества или типа (например, «редакти­ровать все входы»)	Данные одного и того же множест­ва или типа
2	Временная	Функции одного и того же периода времени (на­пример, «операции ини­циализации»)	Данные, исполь­зуемые в каком-либо временном интервале
3	Процедурная	Функции, работающие в одной и той же фазе или итерации (например, «первый проход компи­лятора»)	Данные, исполь­зуемые во время одной и той же фазы или итера­ции
4	Коммуника­ционная	Функции, использующие одни и те же данные	Данные, на кото­рые воздействует одна и та же дея­тельность
5	Последова­тельная	Функции, выполняющие последовательные пре­образования одних и тех же данных	Данные, преоб­разуемые после­довательными функциями
6	^Функцио­нальная	Функции, объединяемые для выполнения одной функции	Данные, связан­ные с одной функцией

(1) Тип логической святости. Логическое связывание происхо­дит тогда, когда данные и функции собираются вместе вследствие того, что они попадают в общий класс или набор элементов, но необходимых функциональных отношений между ними не обна­руживается.

(2) Тип временной связности. Связанные по времени элементы возникают вследствие того, что они представляют функции, свя­занные во времени, когда данные используются одновременно или функции включаются параллельно, а не последовательно.

(3) Тип процедурной связности. Процедурно-связанные элементы появляются сгруппированными вместе вследствие того, что они выполняются в течение одной и той же части цикла или процесса.

(4) Тип коммуникационной связности. Диаграммы демонстриру­ют коммуникационные связи, когда блоки группируются вслед-

96

ствие того, что они используют одни и те же входные данные и/или производят одни и те же выходные данные.

(5) Тип последовательной связности. На диаграммах, имеющих последовательные связи, выход одной функции служит входны­ми данными для следующей функции. Связь между элементами на диаграмме является более тесной, чем на рассмотренных ранее уровнях связок, поскольку моделируются причинно-следственные зависимости.

(6) Тип функциональной связности. Диаграмма отражает полную функциональную связность при наличии полной зависимости од­ной функции от другой. Диаграмма, которая является чисто функ­циональной, не содержит чужеродных элементов, относящихся к последовательному или более слабому типу связности. Одним из способов определения функционально-связанных диаграмм явля­ется рассмотрение двух блоков, связанных через управляющие дуги.

Моделирование потоков данных (процессов). Основным сред­ством моделирования функциональных требований АИС являют­ся диаграммы потоков данных (Data Flow Diagrams — DFD). С их помощью эти требования разбиваются на функциональные ком­поненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств — продемонстриро­вать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

Для изображения DFD традиционно используются две различ­ные нотации: Йодана (Yourdori) и Гейна—Сарсона (Gane—Sarson) (рис. 7.4).

Рис. 7.4. Представление нотаций Йодана и Гейна—Сарсона

В соответствии с методологией модель системы определяется как иерархия DFD, описывающих асинхронный процесс преоб­разования информации от ее ввода в систему до выдачи пользова-

телю. Диаграммы верхних уровней иерархии (контекстные диаграм­мы) определяют основные процессы или подсистемы ИС с вне­шними входами и выходами. Они детализируются при помощи диа­грамм нижнего уровня. Такая декомпозиция продолжается, созда­вая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процессы ста­новятся элементарными и детализировать их далее невозможно.

Источники информации (внешние сущности) порождают ин­формационные потоки (потоки данных), переносящие информа­цию к подсистемам или процессам. Те в свою очередь преобразу­ют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям — потребителям информации. Таким образом, основными компонентами диаграмм потоков дан­ных являются:

• внешние сущности;

• системы/подсистемы (см. ранее);

• процессы;

• накопители данных (хранилище);

• потоки данных.

Внешняя сущность представляет собой материальный предмет или физическое лицо, представляющее собой источник или при­емник информации, например заказчики, персонал, поставщи­ки, клиенты, склад. Определение некоторого объекта или систе­мы в качестве внешней сущности указывает на то, что она нахо­дится за пределами границ анализируемой АИС.

Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован разными способами: это может быть подразделение организации (отдел), выполня­ющее обработку входных документов и выпуск отчетов, програм­ма, аппаратно реализованное логическое устройство и т. д. В раз­личных нотациях процесс может изображаться на диаграммах по-разному. Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным недвусмысленным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, полу­чить), за которым следуют существительные в винительном паде­же, например:.

• «Ввести сведения о клиентах»;

• «Выдать информацию о текущих расходах»;

• «Проверить кредитоспособность клиента».

Использование таких глаголов, как «обработать», «модернизи­ровать» или «отредактировать», означает, как правило, недоста­точно глубокое понимание данного процесса и требует дальней­шего анализа.

98

В последнее время принято использовать еще и поле физиче­ской реализации, информация в котором показывает, какое под­разделение организации, программа или аппаратное устройство выполняет данный процесс.

Хранилище {накопитель данных) представляет собой абстракт­ное устройство для хранения информации, которую можно в лю­бой момент поместить туда и через некоторое время извлечь, при­чем способы помещения и извлечения могут быть любыми.

Накопитель данных может быть реализован физически в виде микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т.д. Накопитель данных иденти­фицируется буквой «D» и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика.

Накопитель данных в общем случае является прообразом бу­дущей БД, и описание хранящихся в нем данных должно быть увязано с информационной моделью. Поток данных определяет информацию, передаваемую через некоторое соединение от ис­точника к приемнику. Реальный поток данных может быть ин­формацией, передаваемой по кабелю между двумя устройства­ми, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой, и т.д.

Поток данных на диаграмме изображается линией, оканчива­ющейся стрелкой, которая показывает направление. Каждый по­ток данных имеет имя, отражающее его содержание.

Первым шагом при построении иерархии DFD является по­строение контекстных диаграмм. Обычно при проектировании от­носительно простых АИС строится единственная контекстная диа­грамма со звездообразной топологией, в центре которой находит­ся так называемый главный процесс, соединенный с приемника­ми и источниками информации, посредством которых с систе­мой взаимодействуют пользователи и другие внешние системы. Для сложных АИС строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не един­ственный главный процесс, а набор подсистем, соединенных по­токами данных. Контекстные диаграммы следующего уровня де­тализируют контекст и структуру подсистем.

Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем проектируемой АИС как между собой, так и с внешними входными и выходными потока­ми данных и внешними объектами (источниками и приемниками информации), с которыми взаимодействует АИС.

Разработка контекстных диаграмм решает проблему строгого определения функциональной структуры АИС на самой ранней стадии ее проектирования, что особенно важно для сложных мно-

99

гофункциональных систем, в разработке которых участвуют раз­ные организации и коллективы разработчиков.

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

1) балансировки — означает, что при детализации подсисте­мы или процесса детализирующая диаграмма в качестве внешних источников/приемников данных может иметь только те компо­ненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь детализируе­мая подсистема или процесс на родительской диаграмме;

2) нумерации — означает, что при детализации процессов долж­на поддерживаться их иерархическая нумерация. Например, про­цессы, детализирующие процесс с номером 12, получают номе­ра 12.1, 12.2, 12.3 и т.д.

Мини-спецификация (описание логики процесса) должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу. Мини-спецификация является конечной вершиной иерархии DFD. Ре­шение о завершении детализации процесса и использовании мини-спецификации принимается аналитиком, исходя из следующих критериев:

• наличие у процесса относительно небольшого количества вход­ных и выходных потоков данных (два-три потока);

• возможность описания преобразования данных процессом в виде последовательного алгоритма;

• выполнение процессом единственной логической функции преобразования входной информации в выходную;

• возможность описания логики процесса при помощи мини-спецификации небольшого объема (не более 20 — 30 строк).

При построении иерархии DFD переходить к детализации про­цессов следует только после определения содержания всех пото­ков и накопителей данных, которое описывается при помощи структур данных. Структуры данных конструируются из элемен­тов данных и могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что данный компо­нент, может отсутствовать в структуре. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Ите­рация означает вхождение любого числа элементов в указанном диапазоне. Для каждого элемента данных может указываться его

100

тип (непрерывные или дискретные данные). Для непрерывных дан­ных может указываться единица измерения (килограммы, санти­метры и т.п.), диапазон значений, точность представления и форма физического кодирования. Для дискретных данных может указы­ваться таблица допустимых значений.

После построения законченной модели системы ее необходи­мо верифицировать (проверить на полноту и согласованность). В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы. Вы­явленные недетализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки. В согласованной мо­дели для всех потоков данных и накопителей данных должно вы­полняться правило сохранения информации: все поступающие куда-либо данные должны быть считаны, а все считываемые дан­ные должны быть записаны.

Моделирование данных. Цель моделирования данных состоит в обеспечении разработчика АИС концептуальной схемой БД в форме одной модели или нескольких локальных моделей, которые отно­сительно легко могут быть отображены в любую систему БД.

Наиболее распространенным средством моделирования данных являются диаграммы «сущность—связь» (ERD). С их помощью определяются важные для предметной области объекты (сущно­сти), их свойства (атрибуты) и отношения друг с другом (связи). Диаграммы «Сущность—связь» непосредственно используются для проектирования реляционных БД (см. гл. 11).

Нотация ERD была впервые введена П. Ченом и получила даль­нейшее развитие в работах С. Баркера.

Методология IDEF1. Метод IDEF1, разработанный Т. Рэмеем, также основан на подходе П. Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормаль­ной форме. В настоящее время на основе совершенствования ме­тодологии IDEF1 создана ее новая версия — методология IDEF1X, разработанная с учетом таких требований, как простота изучения и возможность автоматизации. IDEFlX-диаграммы используются в ряде распространенных CASE-средств (в частности, ERwin, Design/IDEF).

⇐ Предыдущая13141516171819202122Следующая ⇒

Поделиться: