<<
>>

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

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

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

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

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

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

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

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

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

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

6. Принцип непротиворечивости — заключается в обо­снованности и согласованности элементов.

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

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

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

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-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих "ограничения", которые, в свою очередь, определяют, когда и каким образом функции выполня­ются и управляются;

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

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

♦ ограничение количества блоков на каждом уровне де­композиции (правило 3—б блоков);

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

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

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

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

♦ отделение организации от функции, т.

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

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

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

Одной из наиболее важных особенностей методологии БАОТ является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель.

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

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

Управление

Функция
Входы

-► Выходы

Механизм

Рис. 1.6.1. Функциональный блок и интерфейсные дуги

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

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

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

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

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

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

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

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

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

Рис. 1.6.2. Структура БАБТ-модели (декомпозиция диаграмм) 166

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

Одним из важных моментов при проектировании ИС с помощью методологии БАОТ является точная согласованность типов связей между функциями. Различают по крайней мере семь типов связывания:

Тип связи Относительная значимость
Случайная 0
Логическая 1
Временная 2
Процедурная 3
Коммуникационная 4
Последовательная 5
Функциональная 6

Ниже каждый тип связи кратко определен и проиллюс­трирован с помощью типичного примера из БАБТ (табл. 1.6.1).

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

последовательными

функциями

6 Функциональная Функции, объединяемые для выполнения одной функции Данные, связанные с одной функцией

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

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

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

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

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

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

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

Моделирование потоков данных (процессов)

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

Для изображения БГБ традиционно используются две различные нотации: Йодана (Уоигс1оп) и Гейна Сарсона (Оапе- Багеоп) — рис. 1.6.4.

Нотация Йодана Нотация Гейна-Сарсона
поток данных процесс

хранилище внешняя сущность

имя имя
[ имя \ \номер ) номер имя
имя имя
имя имя
Рис. 1.6.4. Представление нотаций Йодана и Гейна-Сарсона

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

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

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

♦ системы/подсистемы;

♦ процессы;

♦ накопители данных;

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

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

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

♦ "Ввести сведения о клиентах";

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

♦ "Проверить кредитоспособность клиента".

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

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

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

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

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

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

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

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

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

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

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

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

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

Миниспецификация является конечной вершиной иерар­хии БЕБ. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком, исходя из следующих критериев:

♦ наличия у процесса относительно небольшого количе­ства входных и выходных потоков данных (2—3 пото­ка);

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

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

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

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

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

Моделирование данных

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

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

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

Методология IDEF1

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

<< | >>
Источник: Балдин К. В., Уткин В. Б.. Информационные системы в экономике: Учебник. — 5-е изд. — М.: Издательско-торго- вая корпорация «Дашков и К0», — 395 с.. 2008

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

  1. 3 .РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ АРМ «ВАЛЮТНЫЙ КАССИР» В СОСТАВЕ СИСТЕМЫ «ОБМЕННЫЙ ПУНКТ»
  2. Программное обеспечение
  3. 2.1.4 . Программное обеспечение АБС
  4. 8.2.6.2. Выбор стандартного программного обеспечения
  5. Подсистема «Программно-математическое обеспечение АИС»
  6. 6.4. Программное обеспечение финансовых решений
  7. 2.4.3. Используемое программное обеспечение
  8. Программное обеспечение системы.
  9. 1.6.1. Жизненный цикл программного обеспечения информационной системы
  10. 1.1.3. Место информационных и расчетных задач в составе программного обеспечения ЭВМ
  11. 1.6.4. Методологии проектирования программного обеспечения
  12. 8.3. Программное обеспечение бухгалтерского учета
  13. 8.3. Программное обеспечение автоматизированных информационных технологий аудиторской деятельности
  14. 1.2. Основы проектирования элементов программного обеспечения информационных систем
  15. 7.8. Совершенствование программно-целевых методов бюджетного планирования