Вендров А.М. Проектирование программного обеспечения экономических информационных систем

Подождите немного. Документ загружается.

Методические аспекты проектирования ПО 141

При построении модели сложной системы она может быть

представлена в самом общем виде на так называемой контек-

стной диаграмме в

виде одной

системы

как единого целого, либо

может

быть

декомпозирована на ряд

подсистем.

Подсистема (или система) на контекстной диафамме изобра-

жается так, как она представлена на

рис.

2.19.

luiio пимерв

Поле имени

Поле физической

реализации

1 1

Подсистема

по работе

с физическими лицами

ГНИ

Рис.

2.19.

Подсистема

по работе с

физическими

лицами

(ГНИ

- Государственная налоговая инспекция)

Номер подсистемы служит для ее идентификации. В поле

имени вводится наименование подсистемы в виде предложения

с подлежащим и соответствующими определениями и дополне-

ниями.

Процесс

представляет собой преобразование входных пото-

ков данных в выходные в соответствии с определенным алго-

ритмом. Физически процесс может быть реализован различны-

ми способами: это может быть подразделение организации (от-

дел),

выполняющее обработку входных документов и выпуск от-

четов; программа; аппаратно реализованное логическое устрой-

ство и т.д.

Процесс

на

диаграмме потоков данных изображается, как по-

казано на

рис.

2.20.

миле пимс^ра

Поле имени

Поле физической реализации

^-^ 1

Проверить

плательщика

на задолженность |

Налоговый инспектор

Рис.

2.20.

Графическое изображение процесса

142 Глава 2

Номер процесса служит для его идентификации. В поле име-

ни вводится наименование процесса

виде предложения с актив-

ным недвусмысленным глаголом в неопределенной форме (вы-

числить, рассчитать, проверить, определить, создать, получить),

за которым следуют существительные в винительном падеже,

например: «Ввести сведения о налогоплательщиках», «Вьщать ин-

формацию о текущих расходах», «Проверить поступление денег».

Использование таких глаголов, как «обработать», «модерни-

зировать» или «отредактировать» означает, как правило, недоста-

точно глубокое понимание данного процесса и требует дальней-

шего анализа.

Информация в поле физической реализации показывает, ка-

кое подразделение организации, программа или аппаратное уст-

ройство выполняет данный процесс.

Накопитель данных —

это абстрактное устройство для хране-

ния информации, которую можно в любой момент поместить в

накопитель и через некоторое время извлечь, причем способы

помещения и извлечения могут быть любыми.

Накопитель данных может

быть

реализован физически

виде

микрофиши, ящика

картотеке, таблицы

оперативной памяти,

файла на магнитном носителе и

т.д.

Накопитель данных на диаг-

рамме потоков данных изображается, как показано на

рис.

2.21.

Реестр налогоплательщиков

Рис. 2.21. Графическое изображение накопителя данных

Накопитель данных идентифицируется буквой «D» и произ-

вольным числом. Имя накопителя выбирается из соображения

наибольшей информативности для проектировщика.

Накопитель данных в общем случае является прообразом бу-

дущей базы данных, и описание хранящихся в нем данных долж-

но соответствовать информационной модели (ERM).

Яо/иол:

дая«ба:

определяет информацию, передаваемую через

некоторое соединение от источника к приемнику. Реальный по-

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

между двумя устройствами, пересылаемыми по почте письмами,

магнитными лентами или дискетами, переносимыми с одного

компьютера на

другой,

и т.д.

Методические аспекты проектирования ПО

143

Поток данных

на

диаграмме изображается линией, оканчива-

ющейся стрелкой, которая показывает направление потока (рис.

2.22). Каждый поток данных имеет имя, отражающее его содер-

жание.

Сформировать

отчетность

по подоходному

налогу

Отдел отчетности

Отчетность

по подоходному

Щ Региональная

Рис. 2.22. Поток данных

Построение

иерархии диаграмм потоков данных

Главная цель построения иерархии DFD заключается в том,

чтобы сделать описание системы ясным и понятным на каждом

уровне детализации,

также разбить его на части

точно опреде-

ленными отношениями между

ними.

Для достижения этого целе-

сообразно пользоваться следующими рекомендациями:

• размещать на каждой диаграмме от

3 до

6—7

процессов (ана-

логично SADT). Верхняя граница соответствует человечес-

ким возможностям одновременного восприятия и понима-

ния структуры сложной системы с множеством внутренних

связей, нижняя граница выбрана по соображениям здравого

смысла: нет необходимости детализировать процесс диаг-

раммой, содержащей всего один или два процесса;

• не загромождать диафаммы несущественными на данном

уровне деталями;

• декомпозицию потоков данных осуществлять параллельно с

декомпозицией процессов. Эти две работы должны выпол-

няться одновременно, а не одна после завершения другой;

• выбирать ясные, отражающие суть дела, имена процессов и

потоков, при этом стараться не использовать аббревиатуры.

Первым шагом при построении иерархии DFD является

построение контекстных диаграмм. Обычно при проектирова-

нии относительно простых систем строится единственная кон-

текстная диаграмма со звездообразной топологией, в центре ко-

144 Глава 2

торой находится так называемый главный процесс, соединен-

ный с приемниками и источниками информации, посредством

которых с системой взаимодействуют пользователи и другие

внешние системы. Перед построением контекстной DFD необ-

ходимо проанализировать внешние события (внешние сущнос-

ти),

оказывающие влияние на функционирование системы. Ко-

личество потоков на контекстной диаграмме должно быть по

возможности небольшим, поскольку каждый из них может быть

в дальнейшем разбит на несколько потоков на следующих уров-

нях диаграммы.

Для проверки контекстной диаграммы можно составить спи-

сок событий, который должен состоять из описаний действий

внешних сущностей (событий) и соответствующих реакций сис-

темы на них. Каждое событие должно соответствовать одному

или более потокам данных: входные потоки интерпретируются

как воздействия, а выходные потоки ~ как реакции системы на

входные потоки.

Если для сложной системы офаничиться единственной кон-

текстной диафаммой, то она будет содержать слишком большое

количество источников и приемников информации, которые

трудно расположить на листе бумаги нормального формата, и,

кроме

того,

единственный главный процесс

не

раскрывает струк-

туры такой системы. Признаками сложности (в смысле контекс-

та) могут быть: наличие большого количества внешних сущнос-

тей (десять и более), распределенная природа системы, много-

функциональность системы с уже сложившейся или выявленной

фуппировкой функций в отдельные подсистемы.

Для сложных систем строится иерархия контекстных диаг-

рамм. При этом контекстная диафамма верхнего уровня содер-

жит не единственный главный процесс, а набор подсистем, сое-

диненных потоками данных. Контекстные диафаммы следую-

щего уровня детализируют контекст и структуру подсистем.

Иерархия контекстных диафамм определяет взаимодействие

основных функциональных подсистем между

собой,

с внешними

входными и выходными потоками данных и внешними объекта-

ми (источниками и приемниками информации), с которыми вза-

имодействует система.

Разработка контекстных диафамм решает проблему строгого

определения функциональной структуры системы на самой ран-

ней стадии ее проектирования, что особенно важно для сложных

Методические аспекты проектирования ПО 145

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

разные организации и коллективы разработчиков.

После построения контекстных диаграмм полученную мо-

дель следует проверить на полноту исходных данных об объектах

системы и изолированность объектов (отсутствие информацион-

ных связей

другими объектами).

Для каждой подсистемы, присутствующей на контекстных

диаграммах, выполняется ее детализация при помощи DFD. Это

можно сделать путем построения диафаммы для каждого собы-

тия.

Каждое событие представляется в виде процесса с соответ-

ствующими входными и выходными потоками, накопителями

данных, внешними сущностями и ссылками на другие процессы

для описания связей между этим процессом и его окружением.

Затем все построенные диафаммы сводятся

в одну

диафамму ну-

левого уровня.

Каждый процесс на DFD,

свою очередь, может

быть

детали-

зирован при помощи DFD или (если процесс элементарный)

спецификации. При детализации должны выполняться следую-

щие правила:

•

правило балансировки —

при детализации подсистемы или

процесса детализирующая диафамма в качестве внешних

источников или приемников данных может иметь только те

компоненты (подсистемы, процессы, внешние сущности,

накопители данных), с которыми имеют информационную

связь детализируемые подсистема или процесс на роди-

тельской диафамме;

•

правило нумерации

- при детализации процессов должна

поддерживаться их иерархическая нумерация. Например,

процессы, детализирующие процесс с номером 12, получа-

ют номера

12.1,

12.2, 12.3 и т.д.

Спецификация процесса

должна формулировать его основные

функции таким образом, чтобы в дальнейшем специалист, вы-

полняющий реализацию проекта, смог выполнить их или разра-

ботать соответствующую профамму.

Спецификация является конечной вершиной иерархии DFD.

Решение о завершении детализации процесса и использовании

спецификации принимается аналитиком исходя из следующих

критериев:

• наличия у процесса относительно небольшого количества

входных и выходных потоков данных

(2—3

потока);

146 Глава 2

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

в виде последовательного алгоритма;

• выполнения процессом единственной логической функции

преобразования входной информации в выходную;

• возможности описания логики процесса при помощи спе-

цификации небольшого объема (не более 20-30 строк).

Спецификации должны удовлетворять следующим требова-

ниям:

• для каждого процесса нижнего уровня должна существовать

одна и только одна спецификация;

• спецификация должна определять способ преобразования

входных потоков в выходные;

• нет необходимости (по крайней мере, на стадии формирова-

ния требований) определять метод реализации этого преоб-

разования;

• спецификация должна стремиться к ограничению избыточ-

ности

—

не следует переопределять

то,

что уже было опреде-

лено на диафамме;

• набор конструкций для построения спецификации должен

быть простым и понятным.

Фактически спецификации представляют собой описания

алгоритмов задач, выполняемых процессами. Спецификации со-

держат номер

и/или

имя процесса, списки входных и выходных

данных

тело (описание) процесса, являющееся спецификацией

алгоритма или операции, трансформирующей входные потоки

данных в выходные. Известно большое количество разнообраз-

ных методов, позволяющих описать тело процесса. Соответству-

ющие этим методам языки могут варьироваться от структуриро-

ванного естественного языка или псевдокода

до

визуальных язы-

ков моделирования.

Структурированный естественный язык применяется для

читабельного, достаточно строгого описания спецификаций

процессов. Он представляет собой разумное сочетание строгос-

ти языка программирования и читабельности естественного

языка и состоит из подмножества слов, организованных в опре-

деленные логические структуры, арифметических выражений и

диаграмм.

состав языка входят следующие основные символы:

• глаголы, ориентированные на действие и применяемые к

объектам;

Методические аспекты проектирования ПО 147

• термины, определенные на любой стадии проекта ПО (на-

пример, задачи, процедуры, символы данных и т.п.);

• предлоги и союзы, используемые

логических отношениях;

• общеупотребительные математические, физические и тех-

нические термины;

• арифметические уравнения;

• таблицы, диафаммы, графы и т.п.;

• комментарии.

К управляющим структурам языка относятся последователь-

ная конструкция, конструкция выбора и итерация (цикл).

При использовании структурированного естественного языка

приняты следующие соглашения:

• логика процесса выражается в виде комбинации последова-

тельных конструкций, конструкций выбора и итераций;

• глаголы должны быть активными, недвусмысленными и

ориентированными на целевое действие

(заполнить,

вычис-

лить,

извлечь,

не

модернизировать,

обработать);

• логика процесса должна быть выражена четко и недвусмыс-

ленно.

При построении иерархии DFD переходить к детализации

процессов следует только после определения содержания всех

потоков и накопителей данных, которое описывается при помо-

щи структур данных. Для каждого потока данных формируется

список всех его элементов данных, затем элементы данных объе-

диняются в структуры данных, соответствующие более крупным

объектам данных (например, строкам документов или объектам

предметной области). Каждый объект должен состоять из эле-

ментов, являющихся его атрибутами. Структуры данных могут

содержать альтернативы, условные вхождения и итерации. Ус-

ловное вхождение означает, что данный компонент может отсут-

ствовать в структуре (например, структура «данные о страхова-

нии» для объекта «служащий»). Альтернатива означает, что в

структуру может входить один из перечисленных

элементов.

Ите-

рация означает вхождение любого числа элементов в указанном

диапазоне (например, элемент «имя ребенка» для объекта «слу-

жащий»). Для каждого элемента данных может указываться его

тип (непрерывные или дискретные данные). Для непрерывных

данных могут указываться единица измерения (кг, см

т.п.),

диа-

пазон значений, точность представления и форма физического

кодирования. Для дискретных данных может указываться табли-

ца допустимых значений.

148 Глава 2

После построения законченной модели системы

ее

необходи-

мо верифицировать (проверить на полноту

согласованность). В

полной модели все ее объекты (подсистемы, процессы, потоки

данных) должны быть подробно описаны

детализированы. Вы-

явленные недетализированные объекты следует детализировать,

вернувшись на предьщущие шаги разработки. В согласованной

модели для всех потоков данных и накопителей данных должно

выполняться правило сохранения информации: все поступаю-

щие куда-либо данные должны быть считаны,

а все

считываемые

данные должны быть записаны.

2.3.4.

КОЛИЧЕСТВЕННЫЙ АНАЛИЗ ДИАГРАММ

IDEFO И DFD

Для проведения количественного анализа диафамм IDEFO и

DFD используются следующие показатели:

• количество блоков на диаграмме

—

• уровень декомпозиции диаграммы - L;

• число стрелок, соединяющихся с /-м блоком диаграммы -

Af.

Данный набор показателей относится к каждой диаграмме

модели. Ниже перечислены рекомендации по их желательным

значениям.

Необходимо стремиться к тому, чтобы количество блоков на

диаграммах нижних уровней было бы ниже количества блоков на

родительских

диаграммах,

т.

е. с увеличением уровня декомпози-

ции убывал бы коэффициент N/L, По мере декомпозиции моде-

ли функции должны упрощаться, следовательно, количество

блоков должно убывать.

Диаграммы должны быть сбалансированы. Это означает, нап-

ример, что

любого блока количество входящих стрелок и стре-

лок управления не должно быть значительно больше, чем коли-

чество выходящих. Следует отметить, что данная рекомендация

может не выполняться в моделях, описывающих производствен-

ные процессы. Например, при описании процедуры сборки в

блок может входить множество стрелок, описывающих компо-

ненты изделия, а выходить одна стрелка

—

готовое изделие.

Количественная оценка сбалансированности диафаммы мо-

жет быть выполнена с помощью коэффициента сбалансирован-

ности:

Методические аспекты проектирования ПО 149

Kb^\l.Ai/N-m?ix{A^)\.

Необходимо стремиться к тому, чтобы значение

А^

для диаг-

раммы было минимальным.

2.3.5.

СРАВНИТЕЛЬНЫЙ АНАЛИЗ SADT-МОДЕЛЕЙ

И ДИАГРАММ ПОТОКОВ ДАННЫХ

Сравнительный

анализ

данных методов структурного анализа

проводится по следующим параметрам^:

• адекватность средств решаемым задачам;

• согласованность

с другими

средствами структурного анализа;

• интефация с другими процессами ЖЦ ПО (прежде всего с

процессом проектирования).

Адекватность средств решаемым задачам. Модели SADT

(IDEFO) традиционно используются для моделирования органи-

зационных систем (бизнес-процессов). С другой стороны, не су-

ществует никаких принципиальных ограничений на использова-

нии DFD в качестве средства моделирования бизнес-процессов.

Следует отметить, что метод SADT успешно работает только при

описании хорошо специфицированных и стандартизованных

бизнес-процессов в зарубежных корпорациях, поэтому он и при-

нят в CI1IA

качестве типового. Например, в Министерстве обо-

роны США десятки лет существуют четкие должностные

инструкции и методики, которые жестко регламентируют дея-

тельность, делают ее высокотехнологичной и ориентированной

на бизнес-процесс. Достоинствами применения моделей SADT

для описания бизнес-процессов являются:

• полнота описания бизнес-процесса (управление, информа-

ционные и материальные потоки, обратные связи);

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

детализации потоков данных и управления (разделение и

слияние стрелок);

• жесткие требования метода, обеспечивающие получение

моделей стандартного вида;

• соответствие подхода к описанию процессов стандартам

ISO 9000.

^ Калашян

Л,Н.,

Каляное

Г.Н.

Структурные модели бизнеса: DFD-техно-

логии. - М.: Финансы и статистика,

2003.

150 Глава 2

В большинстве российских организаций бизнес-процессы

начали формироваться и развиваться сравнительно недавно, они

слабо типизированы, поэтому разумнее ориентироваться на мо-

дели, основанные на потоковых диафаммах. Кроме того, на

практике

большинства моделей SADT отмечается ряд недостат-

ков,

в частности:

• сложность восприятия (большое количество стрелок);

• большое количество уровней декомпозиции;

• трудность увязки нескольких процессов, представленных в

различных моделях одной и той же организации.

Если же речь идет не о системах вообще, а о ПО ИС, то здесь

DFD вне конкуренции. Практически любой класс систем успеш-

но моделируется при помощи DFD-ориентированных методов.

SADT-диафаммы оказываются значительно менее выразитель-

ными и удобными при моделировании ПО. Так, дуги в SADT

жестко типизированы (вход, выход, управление, механизм).

то

же время применительно к ПО стирается смысловое различие

между входами и выходами, с одной стороны, и управлениями и

механизмами, с другой: входы, выходы и управления являются

потоками данных

правилами их преобразования. Анализ систе-

мы при помощи потоков данных и процессов, их преобразую-

щих, является более прозрачным и недвусмысленным.

SADT вообще отсутствуют выразительные средства для мо-

делирования особенностей ИС. DFD же с самого начала создава-

лись как средство проектирования ИС (тогда как SADT

—

как

средство моделирования систем вообще) и имеют более богатый

набор элементов, адекватно отражающих специфику таких сис-

тем (например, хранилища данных являются прообразами фай-

лов или баз данных, внешние сущности отражают взаимодей-

ствие моделируемой системы с внешним миром).

Наличие в DFD спецификаций процессов нижнего уровня

позволяет преодолеть логическую незавершенность SADT (а

именно, обрыв модели на некотором достаточно низком уровне,

когда дальнейшая ее детализация становится бессмысленной) и

построить полную функциональную спецификацию разрабаты-

ваемой системы.

Жесткие офаничения SADT, запрещающие использовать бо-

лее 6—7 блоков на диафамме, в ряде случаев вынуждают искус-

ственно детализировать процесс, что затрудняет понимание мо-

дели заказчиком, резко увеличивает ее объем и, как следствие.