1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• размещать на каждой диаграмме от 3 до 6—7 процессов (ана­ логично SADT). Верхняя граница соответствует человечес­ ким возможностям одновременного восприятия и понима­ ния структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаг­ раммой, содержащей всего один или два процесса;

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

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

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

Первым шагом при построении иерархии DFD является построение контекстных диаграмм. Обычно при проектирова­ нии относительно простых систем строится единственная кон­ текстная диаграмма со звездообразной топологией, в центре ко-

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

•нет необходимости (по крайней мере, на стадии формирова­ ния требований) определять метод реализации этого преоб­ разования;

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

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

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

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

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

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

•термины, определенные на любой стадии проекта ПО (на­ пример, задачи, процедуры, символы данных и т.п.);

•предлоги и союзы, используемые в логических отношениях;

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

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

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

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

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

При использовании структурированного естественного языка приняты следующие соглашения:

•логика процесса выражается в виде комбинации последова­ тельных конструкций, конструкций выбора и итераций;

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

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

ленно.

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

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

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

Для проведения количественного анализа диафамм IDEFO и DFD используются следующие показатели:

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

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

•число стрелок, соединяющихся с /-м блоком диаграммы - Af. Данный набор показателей относится к каждой диаграмме

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

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

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

Количественная оценка сбалансированности диафаммы мо­ жет быть выполнена с помощью коэффициента сбалансирован­ ности:

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

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

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

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

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

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

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

Жесткие офаничения SADT, запрещающие использовать бо­ лее 6—7 блоков на диафамме, в ряде случаев вынуждают искус­ ственно детализировать процесс, что затрудняет понимание мо­ дели заказчиком, резко увеличивает ее объем и, как следствие.