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

Сущность структурного подхода

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

Базовыми принципами структурного подхода являются:

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

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

· принцип абстрагирования – выделение существенных аспектов сис­те­мы и отвлечение от несущественных;

· принцип формализации – необходимость строгого методическо­го под­хо­да к решению проблемы;

· принцип непротиворечивости – обоснованность и согласован­ность эле­ментов;

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

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

· DFD (Data Flow Diagrams) – диаграммы потоков данных (процессов);

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

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

1.6.2. Моделирование потоков данных (бизнес-процессов) DFD

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

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

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

Рисунок 1.6.2.1. Внешняя сущность

Система и подсистемы. При построении модели сложной ИС она мо­жет быть представлена в самом общем виде на так называемой кон­текст­­ной диаграмме в виде одной системы как единого целого либо может быть декомпозирована на ряд под­систем (рисунок 1.6.2.2).

Поле номера

Поле имени

Поле имени проектировщика

Рисунок 1.6.2.2. Подсистема

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

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

Поле номера

Поле имени

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

Рисунок 1.6.2.3. Процесс

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

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

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

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

D1	Получаемые счета

Рисунок 1.6.2.4. Накопитель данных

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

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

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

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

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

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

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

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

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

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

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

При детализации дол­жны выполняться следующие правила:

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

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

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

Решение о завершении детализации процесса и использова­нии мини-спецификации принимается аналитиком исходя из сле­дующих критериев:

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

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

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

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

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

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