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

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

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

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

Рис. 2.8. Принципы структурного подхода к разработке ИС

К базовым принципам можно отнести:

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

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

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

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

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

· непротиворечивости – заключается в обоснованности и согласованности элементов;

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

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

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

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

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

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

· архитектуру;

· структурные схемы программ;

· диаграммы экранных форм.

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

SADT-технологии создания ИС

Методология SADT разработана Дугласом Россом и получила дальнейшее развитие. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.

Методология SADT – представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области.

Функциональная модель SADT – отображает функциональную структуру объекта, то есть производимые им действия и связи между этими действиями.

Основные элементы этой методологии основываются на следующих концепциях:

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

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

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

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

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

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

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

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

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

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

Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга.

Диаграммы – это главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги.

Место соединения дуги с блоком определяет тип интерфейса.

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

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

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

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

На рис. 2.10, где приведены четыре диаграммы и их взаимосвязи, показана структура SADT-модели. Каждый компонент модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует «внутреннее строение» блока на родительской диаграмме.

Рис. 2.10. Структура SADT-модели. Декомпозиция диаграмм

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

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

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

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

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

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

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

На рис. 2.11 - 2.13 представлены различные варианты выполнения функций и соединения дуг с блоками.

Рис. 2.11. Одновременное выполнение

Рис. 2.12. Соответствие должно быть полным и непротиворечивым

Рис. 2.13. Пример обратной связи

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

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

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

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

Например, как это изображено на рис. 2.14.

Рис. 2.14. Пример механизма

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

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

На рисунке 2.15 показано типичное дерево диаграмм.

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

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

№ связи Тип связи Относительная значимость

1 случайная 0

2 логическая 1

3 временная 2

4 процедурная 3

5 коммуникационная 4

6 последовательная 5

7 функциональная 6

Ниже каждый тип связи кратко определен и проиллюстрирован с помощью типичного примера из SADT.

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

Рис. 2.16. Случайная связность

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

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

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

Рис. 2.17. Процедурная связность

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

Рис. 2.18. Коммуникационная связность

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

Рис. 2.19. Последовательная связность

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

Рис. 2.20. Функциональная связность

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

C = g(B) = g(f(A))

Ниже в табл. 2.1 представлены все типы связей, рассмотренные выше. Важно отметить, что уровни 4-6 устанавливают типы связностей, которые разработчики считают важнейшими для получения диаграмм хорошего качества.

Таблица 2.1

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

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

Одной из наиболее распространенных в мире электронных методологий является методология DATARUN. В соответствии с методологией DATARUN жизненный цикл ИС разбивается на стадии, которые связываются с результатами выполнения основных процессов, определяемых стандартом ISO 12207.

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

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

Основные результаты этой стадии:

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

· требования к системе, включая требования по сопряжению с существующими ИС;

· исходный бизнес-план.

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

1. детальный анализ первичных данных и уточнение концептуальной модели данных;

2. проектирование архитектуры системы. Архитектура включает в себя разделение концептуальной модели на обозримые подмодели;

3. оценивается возможность использования существующих ИС и выбирается соответствующий метод их преобразования;

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

5. на стадии спецификации приложений продолжается процесс создания и детализации проекта;

6. концептуальная модель данных преобразуется в реляционную модель;

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

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

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

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

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

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

Стадия развития фактически является повторной итерацией стадии разработки.

Методология DATARUN опирается на две модели или на два представления:

· модель организации;

· модель ИС.

Методология DATARUN базируется на системном подходе к описанию деятельности организации.

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

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

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

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

Любая ИС (рис. 2.21) представляет собой набор модулей, исполняемых процессорами и взаимодействующих с БД.

БД и процессоры могут располагаться централизованно или быть распределенными. События в системе могут инициироваться внешними сущностями, такими как клиенты у банкоматов или временные события (конец месяца или квартала).

Все транзакции осуществляются через объекты или модули интерфейса , которые взаимодействуют с одной или более БД.

Рис. 2.21. Модель ИС

Подход DATARUN преследует две цели:

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

2. спроектировать ИС на основании модели данных.

Объекты, формируемые на основании модели данных, являются объектами БД, обычно размещаемыми на серверах в среде «клиент-сервер».

Объекты интерфейса, определенные в архитектуре компьютерной системы, обычно размещаются на клиентской части.

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

На рис. 2.22 представлена последовательность шагов проектирования ИС.

Рис. 2.22. Последовательность шагов проектирования системы

На рис. 2.23 определены модели, создаваемые в процессе разработки ИС.

Рис. 2.23. Модели, создаваемые с помощью подхода DATARUN,

Где: BPM (Business Process Model) - модель бизнес-процессов;
PDS (Primary Data Structure) - структура первичных данных;
CDM (Conceptual Data Model) - концептуальная модель данных;
SPM (System Process Model) - модель процессов системы;
ISA(Information System Architecture) - архитектура информационной системы;
ADM (Application Data Model) - модель данных приложения;
IPM (Interface Presentation Model) - модель представления интерфейса;
ISM (Interface Specification Model) - модель спецификации интерфейса.

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