Проектирование автоматизированных систем обработки информации и управления (АСОИУ)

3.4 Проектирование информационной базы при различных способах реализации

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

1. Определение информационной потребности каждой задачи. Результат - перечень входящих и выходящих документов.

2. Определение периодичности решения задач. Результат - список задач с указанием периодичности решения.

3. Составление списка файлов. Результат - полный перечень имен файлов.

4. Определение содержания файла. Результат - содержание полей каждого файла.

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

6. Выбор логической организации файла. Результат - таблицы описаний логической организации файла.

7. Выбор носителей и физической организации файла. Результат - таблицы описания и физической организации файла.

Проектирование БД имеет свои особенности на всех стадиях и этапах проектирования. Так на предпроектной стадии выполняются следующие работы:

1. Определение экономической целесообразности и технической возможности создания БД.

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

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

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

5. Предварительные оценки вариантов разработки БД.

6. Оценка возможностей применения СУБД и выбор СУБД.

ТЗ на проектирование ИС должно иметь в своем составе сведенья, касающиеся проектирования БД, а именно к информационному обеспечению. Требования:

1. Назначение БД

2. Основные требования к БД

3. Технико-экономические показатели эффективности использования БД

4. Состав, содержание и организация проектных работ по созданию БД

5. Порядок приемки БД в промышленную эксплуатацию

На этапе технического проектирования выполняются следующие работы:

1. Составление уточненной инфологической модели.

2. Логическое проектирование, т.е. разработка концептуальной схемы.

3. Физическое проектирование, т.е. распределение частей БД по уровням памяти, выбор метода доступа, определение размеров файлов и т.д.

4. Проектирование и представление данных для приложения.

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

На этапе рабочего проектирования выполняются следующие работы:

1. Разработка оригинальных программных средств и сервисных программ;

2. Настройка СУБД и ППП в соответствии с выбранными параметрами;

3. Разработка контрольного примера;

4. Разработка должностных технологических инструкций по ведению и взаимодействию с БД.

3.5 Проектирование экранных форма электронных документов

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

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

Различают несколько видов форм:

1. Формы, предназначенные для сбора данных, ввода их в БД с последующей их обработкой.

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

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

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

1. Вносить элементы настройки типа персонифицированных командных кнопок с сохранением базового варианта формы.

2. Быстро имитировать бумажные формы.

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

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

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

К первым средствам создания электронных документов можно отнести средства MS Office.

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

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

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

В процессе проектирования и программирования макета электронного документа принято делить экранное поле на две части:

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

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

Информационная часть должна отвечать следующим требованиям:

1. Иметь хороший обзор.

2. Не должна быть перегружена справочными реквизитами, значение которых следует выдавать на экран только по необходимости.

3. Значения группировочных признаков следует выдавать на экран из справочников при переходе курсора в данное поле или при наборе неправильных значений этих признаков.

4. Каждое поле должно быть снабжено подсказкой, которое следует выдавать на экран при неправильных действиях пользователя.

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

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

7. Текущее время и дата должно проставляться автоматически.

8. Общий цвет информационной части должен быть спокойных тонов.

9. Цвет активного поля должен отличаться от основного цвета информационной части и от цвета этого поля в пассивном состоянии.

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

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

4.1 Проектирование процессов получения первичной информации

В состав операций, выполняемых при получении первичной информации, входят:

1. Съем информации;

2. Регистрация информации;

3. Сбор информации;

4. Передача информации.

1. Съем информации

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

1. Ручной съем

2. Полуавтоматический съем

3. Автоматический съем

2. Регистрация первичной информации

Регистрация первичной информации - нанесение количественных характеристик и/или признаков на какой-либо носитель.

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

Для обеспечения достоверности информации при выполнении регистрации применяют следующие методы:

1. Визуальный контроль на экране регистратора.

2. Двойной ввод информации.

3. Контроль идентификатора по списку.

4. Контроль вводимой информации по формату.

5. Контроль по сумме сообщений.

6. Контрольные суммы по каждому сообщению.

3. Сбор первичной информации

Сбор первичной информации - операция получения пакета сообщений (пачки первичных документов или файла на машинном носителе) для последующей передачи и обработки.

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

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

4.2 Проектирование процессов загрузки и ведения информационной базы

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

Проектирование системы загрузки и ведения информационной базы производится по следующим процедурам:

1. Загрузка и актуализация данных

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

3. Обеспечение защиты данных

4. Обеспечение надежности хранения данных

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

1. Обеспечить контроль вводимой информации при выполнении процедур загрузки и актуализации.

2. Обеспечить защиту хранимых данных от несанкционированного доступа.

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

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

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

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

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

В самом общем случае схема проектирования процедуры загрузки БД при ручном способе ввода данных первичных документов включает следующие операции:

1. Определение особенностей подготовки данных и формирование требований к системе загрузки данных.

2. Определение состава операций технологического процесса загрузки информационной базы.

3. Выбор инструментального средства разработки программ загрузки информационной базы.

4. Настройка стандартных средств автоматизации или разработка оригинальной программы загрузки информационной базы.

5. Комплексная отладка программы загрузки информационной базы.

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

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

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

Контроль на уровне записи сводится к контролю числа полей, их последовательности и длины записи.

Контроль на уровне поля включает в себя контроль типа и формата.

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

Арифметический контроль осуществляется следующими методами:

1. Контрольные суммы по документу

2. Контрольные суммы по отдельной записи

3. Контрольные числа по файлу

Логический контроль применяется для реквизитов признаков и оснований с использованием следующих методов:

1. Контроль на конкретное значение

2. Контроль на диапазон значений

3. Контроль путем сравнения с некоторой постоянной

4. Контроль зависимости значений реквизитов

5. Контроль по списку значений, т.е. справочников

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

Процесс проектирования процедуры актуализации информационной базы включает следующие операции:

Разработка системы организации актуализации данных в информационной базе.

Разработка технологического процесса внесения изменений.

Выбор метода и инструментального средства разработки процедуры.

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

Комплексная отладка.

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

1. Выбор метода хранения и восстановления

2. Разработка программы восстановления

3. Разработка контрольного примера и отладка

4. Разработка технологии восстановления данных

5. Разработка системы учета эксплуатации файлов в информационной базе

6. Разработка программы ведения статистики обращений к файлам

7. Отладка программ и составление программной документации

8. Разработка технологии смены носителей или копирования файлов

4.3 Проектирование процессов автоматизированного ввода бумажных документов

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

1. Определение состава функций, которые должна выполнять система

2. Выбор технических средств выполнения этих функций

3. Выбор и настройка ПО

4. Разработка технологической документации

Соответственно автоматизация чтения и ввод документов объединяет в себе три стадии:

1. Подготовка документов к сканированию

2. Получение изображения документа

3. Распознавание и ввод данных, содержащихся в документе, в БД

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

1. Персональные - низкоскоростные (20-40 строк в минуту)

2. Настольные офисные - среднескоростные (40-60 строк в минуту)

3. Высокопроизводственные потоковые (90-185 строк в минуту)

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

Довольно распространенной системой обработки форм (распознавание графических образов или перевод графических образов в текстовый формат) является российская система производственного (потокового, поточного) ввода документов Cognitive Forms, работающая под управлением Windows и Mac OS. Эта система позволяет осуществлять поточную обработку в условиях локальной сети с производительностью распознавания до 14 тысяч строк формата А4.

Внедрение системы позволяет обеспечивать ускорение ввода стандартных форм документов в 5-10 раз по сравнению с ручным вводом.

4.4 Проектирование процессов обработки данных в пакетном режиме

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

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

1. Метод структурного проектирования

2. Метод модульного проектирования

3. Метод проектирования «сверху - вниз»

4. Метод структурного программирования

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

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

Метод модульного проектирования поддерживается методов проектирования «сверху - вниз». Проектирование методом «сверху - вниз» позволяет свести процесс разработки программы к выполнению двух операций: логической разработки с одновременным интегрированием и кодирования с отладкой, т.е. разрабатывается логическая структура программы в виде дерева программных модулей с установлением всех типов связи между ними.

Структурное программирование основывается на выполнении нескольких ограничений:

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

Вторым является ограничение на типы используемых операторов и структур. Рекомендуется использование линейной структуры, иерархической структуры с оператором «if» и циклических или кольцевых структур с использованием оператора «do while»; и, напротив, рекомендуется использование оператора «go to».

4.5 Проектирование технологических процессов в диалоговом режиме

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

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

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

В первом случае (односторонняя, со стороны ЭВМ) диалог называется активным со временем ожидания до двух секунд, а во втором - пассивным, когда время ожидания может достичь трех минут.

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

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

Диалоговые системы классифицируются по ряду оснований:

1. По назначению

2. По наличию приоритета в организации взаимодействия

2.1 С приоритетом (со стороны компьютера или пользователя)

2.2 Без приоритета

3. По типу общения

3.1 Активная

3.2 Пассивная

4. По типу сценария

4.1 С гибким сценарием

4.2 С жестким сценарием

5. По форме общения

5.1 Меню

5.2 Запрос - ответ

5.3 Директивы

5.4 Шаблоны

5.5 Подсказки

5.6 Смешанное

6. По типу базового языка

6.1 Естественные языки общения

6.2 Формализованные языки общения

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

1. Задач, обрабатываемых в диалоговых режимах

2. Задач, обрабатываемых в пакетном режиме

3. Задач, решаемых с использованием смешанного режима

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

Далее следует осуществить выбор метода проектирования и инструментального средства проектирования. Наличие инструментальных средств проектирования или их отсутствие позволяет применить метод оригинального проектирования с помощью таких средств программирования, как СУБД, языки Pascal, C или автоматизированного проектирования с использование соответствующей диалоговой оболочки или генератора диалога.

5. Автоматизированное проектирование ИС (CASE-средства)

Термин CASE (Computer Aided System / Soft Engineering) используется в довольно широком смысле. Первоначальное значение термина CASE было связано с вопросами автоматизации разработки лишь ПО. В настоящее время этот термин приобрел новый смысл, охватывающий процесс разработки ИС в целом.

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

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

Преимущества CASE-технологий:

1. Улучшение качества разрабатываемого ПО за счет автоматизированного контроля и регенерации.

2. Возможность повторного использования компонентов разработки.

3. Поддерживание адаптивности и сопровождения ИС.

4. Снижение времени создания ИС за счет получения и прототипа на ранних стадиях проектирования.

5. Освобождение разработчиков от рутинной работы по документированию.

6. Возможность коллективной разработки ИС в режиме реального времени.

Таблица 3. Фирмы-поставщики CASE-средств

Наименование средства	Фирма-поставщик и адрес в Internet	Партнеры на территории Российской Федерации и их адреса в Internet
Silverrun	Silverrun Technologies Inc.	Аргуссофт АйТи
Oracle Designer	Oracle	ФОРС Интерфейс
BPwin Erwin	PLATINUM Technology	Интерфейс ФОРС АйТи
Rational Rose	Rational Software Corporation	Аргусофт АйТи Интерфейс
Paradigm Plus	PLATINUM Technology	Интерфейс ФОРС
Power Designer	Sybase	Интерфейс

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

Рисунок 9. Архитектура CASE-средств

Ядром системы (CASE-средств) является БД проекта, т.е. репозитарий. Он представляет собой специализированную БД, предназначенную для отображения состояния проектируемой ИС в каждый момент времени. Репозитарий содержит информацию об объектах проектируемой ИС и взаимосвязях между ними, и все подсистемы обмениваются данными с ними. В репозитарии хранятся описания следующих объектов:

· Проектировщиков и их прав доступа к нему

· Организационных структур

· Диаграмм

· Компонентов диаграмм

· Связей между диаграммами

· Структур диаграмм

· Программных модулей

· Библиотек модулей и т.д.

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

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

1. Создавать элементы диаграмм и взаимосвязи между ними

2. Задавать описание элементов диаграмм

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

4. Редактировать элементы диаграмм, их взаимосвязи и описание

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

1. Мониторинг правильности построения диаграмм

2. Диагностика и выдача сообщений об ошибках

3. Выделение на диаграмме ошибочных элементов

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

1. Инициализация проекта

2. Задание начальных параметров проекта

3. Назначение и изменение прав доступа к элементам проекта

4. Мониторинг выполнения проекта

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

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

В общем случае, при выборе CASE-средств необходимо учитывать следующие аспекты:

1. Наличие графических средств поддержки методологии проектирования

2. Наличие многопользовательского режима

3. Наличие интерфейса с другими CASE-средствами

4. Наличие возможности экспорта - импорта

5. Возможность расширения новыми методологиями

6. Возможность планирования и управления проектом

7. Возможность автоматической генерации отчетов о проектных решениях

8. Возможность генерации кодов программ

5.1 Функционально-ориентированное и объектно-ориентированное проектирование ИС

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

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

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

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

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

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

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

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

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

5.2 Функционально-ориентированное проектирование ИС

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

1. Декомпозиция всей системы на некоторое множество иерархически подчиненных функций

2. Представление всей информации в виде графической нотации

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

1. Диаграммы бизнес-функций (BFD)

2. Диаграммы потоков данных (DFD)

3. Диаграммы переходов состояний (STD)

4. ER-модели данных предметной области (информационно-логические модели сущность - связь) (ERD)

5. Диаграммы структуры программного приложения (SSD)

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

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

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

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

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

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

5.3 Объектно-ориентированное проектирование ИС

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

В настоящее время для объектно-ориентированного моделирования проблемной области широко используется унифицированный язык моделирования UML, который разработан группой ведущих компьютерных фирм мира и фактически является стандартом по объектно-ориентированных технологиям. Язык UML реализован многими фирмами - производителями ПО при создании CASE-технологий.

Система объектно-ориентированных моделей в соответствии с нотациями UML включает в себя следующие виды диаграмм:

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

2. Диаграммы классов объектов (отображают структуру совокупности взаимосвязанных классов объектов).

3. Диаграммы состояний (отображают динамику состояний объектов одного класса и связанных с ними событий).

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

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

6. Диаграммы пакетов (отображают распределение объектов по функциональным и обеспечивающим подсистемам).

7. Диаграммы компонентов (отображают физические модули программного кода).

8. Диаграммы размещения (отображают распределение объектов по узлам вычислительной сети).

5.4 Прототипное проектирование ИС (RAD-технология)

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

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

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

К числу приемов RAD-технологии, обеспечивающей сокращение сроков и трудоемкости разработки ИС с одновременным повышением ее качества относятся следующие:

1. Обязательное вовлечение пользователя в процесс разработки ИС

2. Высокая параллельность работ

3. Повторное использование частей проекта

4. Необходимое применение CASE-средств

5. Использование автоматических генераторов (мастеров)

6. Использование прототипирования, позволяющего полнее выяснить и удовлетворить потребности пользователя

7. Тестирование и развитие проекта, осуществляемое одновременно с разработкой нескольких версий прототипа

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

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

1. Инструменты быстрой разработки приложения в развитых СУБД (класс Developer)

2. Интегрированные инструменты быстрой разработки приложения (класс Builder)

К инструментам этих классов можно отнести средства 4GL, т.е. генераторы компонентов приложений, в том числе:

1. Генераторы таблиц БД

2. Генераторы форм ввода/вывода

3. Генераторы запросов

4. Генераторы отчетов

5. Генераторы меню

Такие генератора существуют во всех современных СУБД как персональных (Paradox, FoxPro, Access), так и в состав промышленных серверов БД (Oracle, Informix, ADOBase и т.д.).

Отличительной чертой класса Builder является то, что инструменты данного класса легко интегрируются с CASE-системами и представляют собой единую среду быстрой разработки приложения. К интегрированным инструментам класса Builder относят:

1. Delphi (Borland)

2. Builder C++

3. Builder Enterprise (Power Soft)

5.5 Основные понятия и классификация методов типового проектирования (ТП)

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

ТПР также называют тиражированным продуктом. В зависимости от уровня декомпозиции ИС методы ТП различаются следующим образом:

1. Элементный

2. Подсистемный

3. Объектный

Элементный метод в качестве типового элемента проектирующей системы использует ТПР по задаче (их комплексу) или по отдельному виду обеспечения задачи.

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

ТПР для функциональных подсистем реализуется в виде пакетов прикладных программ (ППП).

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

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

Адаптивность объектного метода проектирования зависит от используемого подхода:

1. При параметрической настройке типов ИС (ППП «Галактика», «Парус», «Босс») возникают проблемы привязки типов проекта к конкретному объекту управления. Обычным способом решения проблемы адаптации ТП ИС является либо изменение структуры организационно-экономической системы объекта внедрения в соответствии с требованиями ТП, било существенная доработка ТП с помощью специальных инструментальных средств ТП.

2. Используется альтернативный подход - модельно-ориентированная реализация объектного метода ТП ИС. Такие методы реализованы BAAN, R/3.

Особенность этого подхода заключается в настройке ТП на особенности объекта управления путем привязки модели проблемной области к модели типовой системы.

5.6 Параметрически-ориентированное проектирование ИС. Настройка и адаптация ППП

При проектировании ИС на основе параметрической настройки ППП, последней рассматривается как «черный ящик»:



Рисунок 10. Представление ППП в виде «черного ящика»

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

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

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

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

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

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

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

Существует до 10 групп критериев (в каждой группе от 3 до 10 критериев):

1. Назначение и возможности ППП

2. Требования к техническим и программным средствам

3. Факторы финансового порядка

4. Помощь поставщика ППП

5. Перспективы развития ППП

Настройка сводится к заданию:

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

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

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

5.7 Модельно-ориентированное проектирование ИС. Базовая, референтная и проектная модель объекта автоматизации

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

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

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

1. Базовую модель функциональной типовой системы (в терминологии системы R/3, ссылочная модель)

2. Типовые модели определенных классов ИС (в терминологии BAAN - референтные модели).

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

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

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

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

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

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

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

Рис. 11. Конфигурация ИС на основе модельно-ориентированной технологии

5.8 Специфика управления проектированием ИС

Причины, обусловившие сложность процессов разработки ИС:

1. Взаимосвязь различных по своей природе элементов ИС

2. Длительность процесса проектирования ИС

3. Количественных характер труда многих специалистов различного профиля и квалификации

4. Индивидуальность проекта, обусловленная спецификой объекта проектирования

Главной целью управления проектированием ИС является получение проекта с заданными пользователем параметрами.

Ограничениями выступают сроки проектирования, требуемые ресурсы и т.д.

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

Специфика управления проектированием ИС:

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

2. Пользователь на этапе разработки ИС может изменить требования к качеству системы и ее функциям.

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

5.9 Типы схем организации

Состав участников процесса проектирования ИС:

1. Пользователь - организация или группа подразделений, которые используют результаты функционирования ИС

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

3. Администратор - ответственное лицо, которое выполняет эксплуатацию программно-технических средств ИС.

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

Рисунок 12. Схема организации работ для небольших проектов ИС

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

Рисунок 13. Схема организации работ для более сложных проектов ИС

В том случае, если заказчик - большая организация, которая курирует разработку нескольких ИС, применяют следующую схему.



Рисунок 14

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

Рисунок 15

Размещено на Allbest.ru

...