авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 2 | 3 || 5 |

«ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ Государственное образовательное учреждение высшего профессионального образования «ТОМСКИЙ ПОЛИТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ» ЮРГИНСКИЙ ...»

-- [ Страница 4 ] --

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

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

Многоуровневая архитектура «Клиент-сервер» создается для территориально-распределенных предприятий. Для нее в общем случае характерны отношения «многие ко многим» между клиентскими рабо чими станциями и серверами приложений, между серверами приложе ний и серверами баз данных. Такая организация позволяет более рацио нально организовать информационные потоки между структурными подразделениями в процессе выполнения общих деловых процессов.

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

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

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

• синхронный режим, когда тиражируемые данные обновляются по мере возникновения необходимости одновременно на серверах баз данных во всех копиях. Требуемое быстродействие каналов для син хронного режима – единицы Мбит в секунду;

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

Направление тиражирования между серверами баз данных может быть:

• равноправным, т.е. в обоих направлениях;

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

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

Рассмотрим технологическую сеть техно-рабочего проектирова ния трехуровневой клиент-серверной КЭИС (рис. 6.3).

1. Разработка общей структуры корпоративной информационной системы (П1) Эта операция выполняется на основе описания предметной облас ти D1 и технического задания D4, а также универсумов сетевых опера ционных систем и технических платформ (U1), серверов БД (U2), про граммных средств разработки КЭИС (U3). Выходом данной технологи ческой операции служат описание выбранной конфигурации техниче ских средств и сетевой операционной системы D3, описание выбранно го сервера БД – D2, описание выбранных программных средств разра ботки КЭИС – D5, описание функциональной структуры КЭИС – D6.

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

Рис. 6.3. Технологическая сеть техно-рабочего проектирования клиент-серверной КЭИС: D1 – описание предметной области;

D2 – описание выбранного сервера БД;

D3 – описание выбранной конфи гурации технических средств и сетевой операционной системы;

D4 – техническое задание;

D5 – описание выбранных программных средств разработки КЭИС;

D6 – описание функциональной структуры КЭИС;

D8 – права доступа различным категориям пользователей КЭ ИС;

D9 – журнал заполнения областей БД;

D10 – сопровождающая до кументация;

U1 – универсум сетевых операционных систем и техниче ских платформ;

U2 – универсум серверов БД;

U3 – универсум программ ных средств разработки КЭИС;

G1 – вычислительная сеть;

G2 – СУБД;

G5 – SQL описание БД с управляющими элементами;

G6 – программное обеспечение сервера;

G7 – приложения клиентских мест Выбор сетевых операционных систем во многом зависит от тех нической платформы вычислительных средств. При использовании платформы INTEL наиболее распространенными сетевыми ОС являют ся WINDOWS 95, 98, NT 2000. При использовании других платформ, таких, как IBM, SUN, HP и других, применяют ОС UNIX различных версий для соответствующих платформ.

Выбор сервера БД для КЭИС основывается на анализе рынка сер веров БД по различным критериям:

• независимость от типа аппаратной архитектуры;

• независимость от программно-аппаратной платформы;

• поддержка стандарта открытых систем;

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

• оптимальное хранение распределенных данных;

• поддержка WEB-серверов и работа с Интернет;

• поддержка вторичных индексов;

• непрерывная работа;

• защита от сбоев;

• простота использования.

В качестве примера рассмотрим сравнение по вышеназванным критериям серверов БД ORACLE 7.0, MS SQL SERVER и ADABAS D.

Сравнительный анализ серверов БД представлен в табл. 6.1.

Выбор программных средств разработки КЭИС определяется тре бованиями применяемой технологии проектирования КЭИС.

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

• функций сервера БД;

• функций серверов приложений;

• функций клиентских мест;

• информации, которая необходима для выполнения этих функ ций;

• распределения серверов и клиентских мест по узлам вычисли тельной сети;

• прав доступа пользователей к КЭИС.

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

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

Таблица 6. Сравнительный анализ серверов БД Критерий MS SQL ADABAS ORACLE7. сравнения SERVER D Независимость от типа Да Да Да аппаратной архитектуры Независимость от программно Да Нет Да аппаратной платформы Поддержка стандарта открытых Да Да Да систем Поддержка многопроцессорной и параллельной обработки Да Да Да данных Оптимальное хранение распре Да Нет Да деленных данных Поддержка WEB серверов и ра Да Да Да бота с Интернет Поддержка вторичных индек Да Нет Да сов Непрерывная работа Да Да Да Защита от сбоев Да Нет Да Простота использования Нет Да Да • права на доступ к объектам схемы базы данных КЭИС. Такие права задаются администратором сервера БД с помощью инструментов серверной СУБД. Процесс задания прав заключается в назначении раз личным категориям пользователей возможности выполнения над объек тами схемы БД функций чтения редактирования, записи. Например, пользователю с именем manager 1 доступны объекты, представленные в табл. 6.3.

2. Создание вычислительной сети (ВС) для КЭИС (П2) Создание ВС заданной архитектуры для КЭИС заключается в за купке и монтаже оборудования, а также инсталляции сетевого про граммного обеспечения и СУБД. На основе описания функциональной структуры D6, описания выбранной конфигурации технических средств и сетевой операционной системы D3, описания выбранного сервера БД D2 происходят создание вычислительной сети G1 и установка СУБД G2.

Таблица 6. Задание прав доступа Имя Системный ресурс Расширенные пользователя (диски файлы папки) функции manager1 D:\zapasy\ostatok1.dbf Только чтение D:\zapasy\ostatok.dbf Чтение, редактирование C:\price Только запись Таблица 6. Права доступа к объектам схемы базы данных Имя Объекты БД Расширенные пользо- функции Таблица Поле Образ Отчет Запрос вателя (R-чтение, RW-чтение, запись, W запись) manager1 SPR_M RW KODM RW EI RW V1 R REP1 R ZAPR1 R 3. Создание схемы базы данных (БД) (П3) На основе технического задания D4, описания выбранных про граммных средств разработки D5, описания функциональной структуры КЭИС D6, описания выбранного сервера БД D2 и его СУБД G2, конфи гурации вычислительной сети G1 осуществляются разработка схемы БД с управляющими элементами – G5 и ее документирование D10.

Создание схемы БД сводится к выполнению следующих техноло гических операций (рис. 6.4).

Проектирование структуры распределенной базы данных (П31).

Разработка структуры распределенной базы данных D7 происхо дит на основе описания функциональной структуры КЭИС D6, как пра вило, с помощью CASE-технологии D5 с учетом описания выбранного сервера БД D2 в конкретной программно-технической среде G1 и СУБД G2. В результате строятся модель базы данных и подмодели для раз личных категорий пользователей на основе установления им прав дос тупа к данным.

Рис. 6.4. Технологическая сеть проектирования базы данных в клиент-серверной среде: D2 – описание выбранного сервера БД;

D5 – описание выбранных программных средств разработки КЭИС;

D6 – описание функцио нальной структуры КЭИС;

D7 – структура базы данных;

D10 – сопровождаю щая документация;

G1 – вычислительная сеть;

G2 – СУБД;

G3 – область базы данных;

G4 – SQL описание БД;

G5 – SQL описание БД с управляющими элемен тами Создание области базы данных (П32).

Создание области базы данных G3 заключается в инициализации областей внешней памяти (системной, хранения данных, транзакций, хранения архивных данных). Данная операция выполняется системным администратором БД, который использует для этих целей средства СУБД сервера БД G2 и спроектированную структуру базы данных D7.

Загрузка SQL-описания БД (П33).

Загрузка SQL-описания БД G4 осуществляется системным адми нистратором БД на основе схемы базы данных D7 средствами СУБД сервера БД G2.

Разработка управляющих элементов БД (триггеров, процедур и т. д.) (П34).

Разработка управляющих элементов G5, к которым относятся хранимые процедуры и триггеры, осуществляется на основе структуры базы данных D7 с учетом ее SQL-описания БД G4 и возможностей средств СУБД сервера БД G2. В результате получается готовая для экс плуатации схема базы данных с управляющими элементами, которая документируется в D10.

Хранимая процедура представляет собой вариант программного наполнения базы данных, основная функция которой – функциональное расширение схемы БД. Хранимая процедура выполняет то или иное ло гическое действие. Например, администратор банковской системы соз дает хранимую процедуру, которая реализует функцию «занести на счет номер X сумму Y».

Разработчик приложения пользуется этой процедурой, но не зна ет, как именно она работает. Это дает следующие преимущества:

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

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

• хранимая процедура пишется одним человеком, а используется многими, следовательно, повышаются темпы разработки КЭИС;

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

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

4. Создание сервера БД КЭИС (П4) На основании разработанной схемы БД с управляющими элемен тами G5, описания выбранного сервера БД D2 и его СУБД G2 осущест вляется создание сервера БД, то есть физическое наполнение БД и на стройка программ доступа СУБД. Выходом данной операции служат физическое установление прав доступа различным категориям пользо вателей КЭИС D8, журнал заполнения областей БД D9.

5. Разработка серверов приложений (П5) Исходя из информационных потребностей пользователей D4 и их прав D8, используя программные средства разработки D5, разрабатыва ется сервер приложения G5 и сопровождающая документация D10.

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

6. Разработка клиентских приложений на рабочих станциях (П6) На основе информационных потребностей пользователей D4 и их прав D8, используя программные средства разработки D5, создаются приложения клиентских мест G7, а также сопровождающая документа ция D10. В частности, осуществляется проектирование пользователь ского интерфейса клиентских частей приложений.

6.2. Проектирование систем оперативной обработки транзакций Клиент-серверная архитектура КЭИС упрощает взаимодействие пользователей с информационной системой и между собой в процессе выполнения деловых процессов или длинных транзакций. Под д л и н н о й транзакцией будем понимать совокупность операций делового процесса, требующих обращения к КЭИС, каждая из которых не имеет ценности без выполнения всей совокупности. Под к о р о т к о й транзак цией или просто транзакцией будем понимать отдельное обращение к одному из компонентов КЭИС или обращение клиента к серверу. С по мощью обработки длинных транзакций КЭИС позволяет управлять дос таточно сложными цепочками операций делового процесса как единым целым. Такие информационные системы называют системами опера тивной обработки транзакций (OLTP – OnLine Transaction Processing).

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

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

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

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

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

СУРП создаются на основе использования специального про граммного обеспечения для организации коллективной (групповой – workgroup) работы в локальных вычислительных сетях. В эту систему входят средства электронного обмена сообщениями и маршрутизации, которые позволяют организовывать непосредственный обмен результа тами работы между участниками делового процесса, мониторинг вы полнения делового процесса со стороны руководства предприятия, а также инициировать работу исполнителей по завершении выполнения автоматических процедур. Система управления рабочим потоком может быть реализована на основе специализированного программного обес печения, например Staffware, Workroute, или встроена в контур интег рированной ЭИС, как в системах комплексной автоматизации R/3 и BAAN IV.

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

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

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

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

• обработка событий: временных (deadline) и завершения опера ций, условий (триггеров) подключения процессов;

• наличие средств электронной почты для обмена сообщениями между исполнителями и передача списка заданий от руководителей;

• автоматический контроль исполнения работ и информирование руководителей;

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

• открытые интерфейсы с внутренними и внешними приложения ми, подключение транзакций по Интернету;

• сбор статистики о выполнении деловых процессов;

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

Центральным компонентом СУРП является менеджер рабочих по токов, который выполняет следующие функции:

• создание шагов задания;

• оценку условий выполнения шага заданий;

• обработку возникающих событий и принятие решений по сооб щениям;

• контроль сроков выполнения шагов заданий (события по тайме ру);

• передачу управления между приложениями;

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

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

• ведение журнала операций.

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

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

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

Рис. 6.5. Многоуровневая клиент-серверная архитектура на основе использования СУРП • жесткой маршрутизации;

• свободной маршрутизации;

• гибридной маршрутизации.

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

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

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

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

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

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

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

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

Типичными Интернет-приложениями являются:

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

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

• «предприятие – предприятие», осуществление сделок закупки продажи товаров, выполнение совместных проектов. В первом случае между предприятиями осуществляется обмен документов: договоров, заказов, счетов, накладных, платежных поручений. Причем в отличие от традиционного электронного обмена данными (EDI – Electronic Data In terchange) возможна такая синхронизация транзакций, что два деловых процесса закупки и продажи по сути сливаются в один общий процесс.

В случае осуществления проектов взаимная деятельность предприятий расширяется до проектирования изделий и планирования производства и образования совместных виртуальных предприятий. При этом обычно используется международный стандарт для обмена данными по моделям продукции STEP (Standard for the Exchange of Product model data);

• «работник (подразделение) – работник (подразделение)», при ложения Интранета предполагают применение технологии Интернета для связи между сотрудниками одного предприятия. При этом исполь зуются описанные выше системы управления рабочими потоками.

В корпоративной информационной системе R/3 (SAP) для реали зации распределенных деловых процессов с помощью Интернет приложений разработан специальный механизм Application Link Ena bling (ALE), с помощью которого свободно связываются друг с другом программные компоненты, относящиеся к различным информационным системам. В частности, для взаимодействия программных компонентов предлагается использовать стандартные интерфейсы BAPI (Business Application Programming Interface). В системе R/3 в настоящее время разработано более 25 Интернет-приложений и более 100 BAPI интер фейсов к ним.

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

Представление данных пользователя WEB-сервер ИНТЕРНЕТ SAP-сервер транзакций ИНТЕРНЕТ Интернет приложение Приложение BAPI BAPI BAPI База данных Рис. 6.6. Многоуровневая клиент-серверная архитектура для Интернет-приложений в системе R/ 6.3. Проектирование систем оперативного анализа данных Современные системы поддержки принятия решений и информа ционные системы руководителей основаны на применении специализи рованных информационных хранилищ (ИХ) и технологий оперативного анализа данных (ОLAP).

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

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

Рис. 6.7. Многомерная организация информационного хранилища К особенностям хранимой информации в ИХ относятся:

• интеграция или обобщение данных в ИХ из транзакционных баз данных по всем бизнес-процессам и структурным 7подразделениям предприятия в виде единого многомерного информационного простран ства. Например, организуется хранение показателей объемов производ ства, сбыта, сервиса и т.д. в продуктовом, территориальном, отраслевом, временном и других разрезах;

• произвольность агрегации данных на основе отделения от фак тических данных независимых и равноправных измерений информаци онного пространства (признаков анализа информации, разрезов) в виде иерархий агрегации. Например, региональный признак анализа пред ставляется в виде иерархии агрегации: «область – район – город – село», временной при знак «год – квартал – месяц – день» и т.д.;

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

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

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

С технологической точки зрения к архитектуре ИХ предъявляют ся общие требования [104].

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

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

• Поддержка многопользовательского режима оперативного ана лиза в среде «клиент-сервер».

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

• Автоматическое обновление информации из оперативных баз данных.

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

• Удобный, «интуитивный» интерфейс пользователя, обеспечи вающий простоту манипулирования данными.

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

Рассмотрим состав основных подсистем информационного храни лища.

Подсистема хранения данных Многомерное хранилище данных может быть организовано в виде одной из следующих структур:

• физической структуры, называемой MOLAP (Multidimensional OLAP), в которую с определенной периодичностью загружаются дан ные из файлов-источников, принадлежащих базам оперативных данных (например, один раз в день). Типичным инструментальным средством, поддерживающим MOLAP, являются Oracle Express (Oracle), Power Play (Cognos Corp), DataDirect (INTERSOLV);

• виртуальной структуры, называемой ROLAP (Relational OLAP), которая динамически используется при запросах, вызывающих физиче ское манипулирование с файлами-источниками из реляционных баз оперативных данных (формирование ответа на запрос к ИХ «на лету»).

ROLAP-система рассматривается просто как надстройка над реляцион ными базами данных, обеспечивающая удобный интерфейс пользовате ля. Типичными инструментальными средствами, поддерживающими ROLAP, являются MetaCube (Informix), Business-Objects (BusinessOb jects) и др.;

• гибридной структуры, называемой HOLAP (Hybrid OLAP), кото рая используется при построении многоуровневых информационных хранилищ, применяемых на разных уровнях управления больших кор пораций. Типичным инструментальным средством, поддерживающим HOLAP, является SAS System (SAS Institute).

Рис. 6.8. Архитектура информационного хранилища Сравнительный анализ применения MOLAP и ROLAP хранилищ представлен в табл. 6.5.

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

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

Важнейшей функцией репозитория является представление схем отображения структуры данных файлов-источников на структуре дан ных ИХ, в соответствии с которой осуществляется периодическая за грузка MOLAP-хранилища или непосредственная реализация запросов «на лету» в ROLAP-хранилищах.

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

Через репозиторий осуществляется интерпретация запросов к ИХ на проведение оперативного анализа данных.

Таблица 6. Сравнительный анализ применения MOLAP и ROLAP ИХ Параметры MOLAP ROLAP Объем хранилища 10-50 Гбайт Неограничен Требования к серверу Специализированный OLAP-сервер с высоким SQL-сервер быстродействием Скорость доступа Не зависит от транзакций Зависит от транзакций к хранилищу оперативной оперативной обработки данных обработки данных Скорость ответа Не зависит от Зависит от числа обраба на запрос структуры данных тываемых таблиц Кроссмерные функции над показателями (фор- Встроены Ограничены мульные вычисления) Обновление данных С определенной По мере периодичностью возникновения Реорганизация (модифи- Пересоздание и Реструктуризация кация состава показателей перезагрузка хранилища отдельных таблиц и измерений) Специализация измерений Разрешенный для всех из- Динамическое для показателей мерений гиперкуб или представление специализированные размерности подкубы Отображение данных между источниками данных и ИХ, ИХ и представлением данных осуществляется либо через механизм межуров невого взаимодействия, либо через процедуры преобразования данных.

Подсистема преобразования данных (загрузки хранилища) Подсистема загрузки ИХ создается только для MOLAP-систем.

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

• сбор данных (Data Acquisition);

• очистка данных (Data Cleaning);

• агрегирование данных (Data Consolidation).

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

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

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

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

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

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

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

• Поворот. Добавление нового признака анализа.

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

• Раскрытие (drill-down). Осуществляется декомпозиция признака агрегации на компоненты, например, признак года разбивается на квар талы. При этом автоматически детализируются числовые показатели.

• Свертка (roll-up/drill-up). Операция, обратная раскрытию. При этом значения детальных показателей суммируются в агрегируемый по казатель.

• Сечение (slice-and-dice). Выделение подмножества данных по конкретным значениям одного или нескольких измерений.

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

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

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

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

• прогнозирование развития ситуаций, например прогнозирование цен, объемов продаж, производства.

К основным методам интеллектуального анализа данных относят ся:

• методы многомерного статистического анализа;

• индуктивные методы построения деревьев решений;

• нейронные сети.

Подсистема «Информационная система руководителя»

Информационная система руководителя предназначена для лиц, непосредственно принимающих решения. Поэтому интерфейс таких систем должен быть в наибольшей степени упрощенным. Обычно в ка честве интерфейса руководителям предприятий предлагается набор стандартных отчетов и графиков, настраиваемых на потребности руко водителя через систему меню. Часто в качестве интерфейса предлагают ся диаграммы Ишикава («скелета рыбы»), представляющие собой само разворачивающееся дерево показателей, в котором листья ветвей рас крашиваются в разные цвета, символизирующие характер состояния по казателя (нормальный, тревожный, кризисный). Лист любой ветви дере ва показателей может быть развернут в таблицу значений показателя или график. Подобные диаграммы применяются в таких корпоративных ЭИС, как R/3 и BAAN IV.

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

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

П1. Идентификация проблемной области На основе материалов предпроектного обследования (Д1) осуще ствляется параметризация проекта создания информационного храни лища и выделяются все необходимые материальные, финансовые, люд ские и временные ресурсы на выполнение проектных работ, т.е. состав ляются техническое задание (Д2) и технико-экономическое обоснование проекта (Д3). В частности, в рамках технического задания в разрезе конкретных видов деятельности или бизнес-процессов формулируются цели и задачи, области применения и пользователи ИХ, устанавливают ся источники исходных данных, определяются информационные по требности пользователей.

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

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

• повышение качества и оперативности обоснования управленче ских решений на стратегическом, тактическом и оперативном уровнях;

• упрощение управленческого документооборота для процесса принятия управленческих решений и др.

К важнейшим задачам, которые решаются с помощью ИХ, отно сятся:

• бизнес-планирование – обоснование принятия стратегических решений;

• контроллинг – анализ финансово-хозяйственной деятельности и выявление резервов совершенствования бизнес-процессов предприятия;

• оперативный мониторинг и сравнительный анализ (benchmarking) важнейших показателей деятельности предприятия.

Круг пользователей: руководители;

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

менеджеры функциональных подразделений;

аналитики.

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

Перечень источников данных:

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

• внешние источники: официальные статистические данные о дея тельности отрасли, смежных отраслях, состоянии финансов;

норматив ная государственная информация;

маркетинговая информация о зонди ровании рынка, состоянии конкурентов;

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

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

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

П2. Разработка концептуальной модели ИХ Этап разработки концептуальной модели ИХ соответствует этапу логического проектирования, который выполняется на основе техниче ского задания Д2 и технико-экономического обоснования Д3. На выходе этого этапа получаются логическая структура данных ИХ Д4, схема преобразования данных Д5, логическая структура витрин данных Д6 и схема представления данных Д7.

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

- отбор признаков анализа;

- построение схем агрегации показателей;

- построение схем обобщения признаков;

- определение временного горизонта хранения показателей;

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

- выбор типа логической структуры ИХ;

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

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

Сложность структуры данных показателей предопределяет выбор ее типа: «звезды» с однородной структурой признаков для всех показа телей или «расширенной снежинки» с применением нескольких типов хранилищ показателей. В последнем случае осуществляется распреде ление показателей по типам хранилищ.

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

В частности, на этом этапе осуществляется анализ альтернатив ных источников данных, например выбор из числа коммерческих баз данных, а также устанавливаются схемы преобразований исходных данных в хранимые структуры ИХ. Сложность схем отображения ис точников данных в структуру хранилища предопределяет выбор типа ИХ: MOLAP, ROLAP, HOLAP.

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

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

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

П3. Формализация ИХ Этап формализации завершает техническое проектирование ин формационного хранилища. На основе спроектированной на предшест вующей операции архитектуры ИХ (Д4–Д6) и универсумов программ но-технических средств (U1–U2) осуществляется выбор схемы разме щения ИХ в сетевой вычислительной среде (Д7) и программно технических средств реализации ИХ (U3–U4).

Рис. 6.9. Технологическая сеть проектирования информационного хранилища: Д1 – материалы предпроектного обсле дования;

Д2 – техническое задание;

Д3 – технико – экономическое обоснование проекта;

Д4 – логическая структура данных ИХ;

Д5 – схема преобразования данных;

Д6 – логическая структура данных витрин;

Д7 – схема размещения ИХ в сетевой вы числительной среде;

Д8 – проектная документация;

U1 – универсум программных средств;

U2 – универсум технических средств;

U3 – универсум программных средств реализации ИХ;

U4 – универсум технических средств реализации ИХ;

G1 – ре позиторий;

G2 – настройка или процедуры инструментальных средств;

G3 – наполнение информационного хранилища для MOLAP – структуры;

G4 – модифицированный репозитарий;

G5 – модифицированные настройки или процедуры инстру ментальных средств;

G6 – модифицированное информационное хранилище для MOLAP – структуры Выбор схемы размещения ИХ в сетевой вычислительной среде осуществляется в зависимости от выбранного типа организации и пред полагает определение числа уровней хранения:

• структура данных реализована централизованно на одном MO LAP-сервере;

• структура данных распределена на нескольких серверах в соот ветствии с ROLAP-организацией;

• наиболее оперативные и агрегированные данные хранятся на быстродействующем MOLAP-сервере, а детальные данные в ROLAP хранилище – на менее производительных серверах.

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

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

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

П4. Реализация проекта ИХ Этап реализации проекта ИХ выполняется на основе выбранных программных (U3) и технических средств (U4), а также построенных на этапе концептуального моделирования компонентов ИХ (Д4–Д6) и схе мы размещения ИХ (Д7) путем наполнения репозитория (G1), настрой ки или программирования других инструментальных средств (G2), на полнения информационного хранилища для MOLAP-структуры (G3), создания проектной документации (Д8).

Наполнение репозитория ИХ осуществляется путем ввода опре делений:

• структуры ИХ, источников и витрин данных;

• правил ввода данных в ИХ из одного источника, из нескольких источников, при отсутствии данных;


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

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

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

Наполнение ИХ предполагает автоматическую загрузку инфор мации из источников данных в ИХ с MOLAP-организацией, которая по вторяется с заданной в репозитории периодичностью. Эта операция в последующем предполагает очистку ИХ от ненужных и устаревших данных;

управление данными на различных уровнях хранения;

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

П5. Внедрение и опытная эксплуатация Заключительный этап создания ИХ предполагает комплексное тестирование всех компонентов ИХ (G1–G3) с исправлением всех воз никающих ошибок (G4–G6), последующим обучением пользователей и постоянным администрированием в соответствии с установленными правилами и документацией проекта (Д8).

Вопросы для самопроверки 1. Что понимается под клиент-серверной архитектурой? Что такое сервер и клиент?

2. Какие существуют уровни представления клиент-серверной ар хитектуры?

3. Какие существуют варианты клиент-серверной архитектуры?

4. Какие преимущества обеспечивает клиент-серверная архитек тура?

5. Что такое репликация данных, и какие существуют режимы ее осуществления?

6. Какие операции выполняются на стадии техно-рабочего про ектирования клиент-серверной архитектуры?

7. Какие операции включает проектирование базы данных в кли ент-серверной среде?

8. Что представляет собой система оперативной обработки тран закций (OLTP-система)?

9. Каковы особенности создания систем управления рабочими потоками?

10. Каковы особенности создания Интернет-приложений?

11. Что представляет собой система оперативного анализа данных (OLAP-система)?

12. Каковы особенности организации информации в информаци онных хранилищах?

13. Какие требования предъявляются к архитектуре информаци онных хранилищ?

14. Каковы основные компоненты архитектуры информационного хранилища?

15. Каковы основные технологические операции проектирования информационного хранилища?

Тема 7. АВТОМАТИЗИРОВАННОЕ ПРОЕКТИРОВАНИЕ ЭИС (CASE-ТЕХНОЛОГИЯ) 7.1. Основные понятия и классификация CASE-технологий Термин CASE (Computer Aided System/Software Engineering) ис пользуется в довольно широком смысле. Первоначальное значение тер мина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения, в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ЭИС в целом. С самого начала CASE-технологии развивались с целью преодоления ог раничений при использовании структурной методологии проектирова ния (сложности понимания, высокой трудоемкости и стоимости исполь зования, трудности внесения изменений в проектные спецификации и т.д.) за счет ее автоматизации и интеграции поддерживающих средств.

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

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

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

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

• широкое внедрение и постоянный рост производительности пер сональных ЭВМ, позволяющих использовать эффективные графические средства и автоматизировать большинство этапов проектирования;

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

Преимущества CASE-технологии по сравнению с традиционной технологией оригинального проектирования сводятся к следующему:

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

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

• поддержание адаптивности и сопровождения ЭИС;

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

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

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

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

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

Метод – это процедура или техника генерации описаний компо нентов ЭИС (например, проектирование потоков и структур данных).

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

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

Рассмотрим архитектуру CASE-средства, которая представлена на рис. 7.1.

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

Репозиторий содержит информацию об объектах проектируемой ЭИС и взаимосвязях между ними, все подсистемы обмениваются дан ными с ним. В репозитории хранятся описания следующих объектов:

• проектировщиков и их прав доступа к различным компонентам системы;

• организационных структур;

• диаграмм;

• компонентов диаграмм;

• связей между диаграммами;

• структур данных;

• программных модулей;

• процедур;

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

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

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

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

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

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

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

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

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

• диагностику и выдачу сообщений об ошибках;

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

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

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

• инициализации проекта;

• задания начальных параметров проекта;

• назначения и изменения прав доступа к элементам проекта;

• мониторинга выполнения проекта.

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

Современные CASE-системы классифицируются по следующим признакам:


1) по поддерживаемым методологиям проектирования: функ ционально (или структурно)-ориентированные, объектно-ориенти рованные и комплексно-ориентированные (набор методологий проекти рования);

2) по поддерживаемым графическим нотациям построения диаграмм, с фиксированной нотацией, с отдельными нотациями и наи более распространенными нотациями;

3) по степени интегрированности: tools (отдельные локальные средства), toolkit (набор неинтегрированных средств, охватывающих большинство этапов разработки ЭИС) и workbench (полностью интег рированные средства, связанные общей базой проектных данных – ре позиторием);

4) по типу и архитектуре вычислительной техники: ориенти рованные на ПЭВМ, ориентированные на локальную вычислительную сеть (ЛВС), ориентированные на глобальную вычислительную сеть (ГВС) и смешанного типа;

5) по режиму коллективной разработки проекта: не поддер живающие коллективную разработку, ориентированные на режим ре ального времени разработки проекта, ориентированные на режим объе динения подпроектов;

6) по типу операционной системы (ОС): работающие под управлением WINDOWS 3.11 и выше;

работающие под управлением UNIX и работающие под управлением различных ОС (WINDOWS, UNIX, OS/2 и др.).

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

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

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

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

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

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

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

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

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

• Многопользовательский режим. Развитые CASE-системы долж ны обладать возможностями разделения полномочий персонала разра ботчиков и объединения отдельных работ в общий проект.

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

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

• Наличие графических средств поддержки методологий проек тирования. Большинство CASE-систем базируется на графическом ото бражении методологий. Графические элементы структурных диаграмм и объекты словаря должны позволять декомпозировать различные ком поненты проекта и детализировать изображения с той степенью, с какой это необходимо для понимания проектных решений.

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

• Автоматическая генерация отчетов о проектных решениях.

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

• Генерация кодов программ. CASE-системы с жесткой ориента цией на конкретные СУБД должны обеспечивать возможность генера ции программ в среде этих СУБД.

• Планирование и управление проектом. Использование CASE систем не исключает потребности в эффективном управлении проектом.

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

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

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

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

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

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

• BFD (Bussiness Function Diagram) – диаграмма бизнес-функций (функциональные спецификации);

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

• STD (State Transition Diagram) – диаграмма переходов состояний (матрицы перекрестных ссылок);

• ERD (Entity Relationship Diagram) – ER-модель данных предмет ной области (информационно-логические модели «сущность-связь»);

• SSD (System Structure Diagram) – диаграмма структуры про граммного приложения.

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

• Функция – некоторое действие информационной системы, необ ходимое для решения экономической задачи;

• Декомпозиция функции – разбиение функции на множество под функций.

Изображение объектов диаграммы иерархии функций представле но в табл. 7.1 в нотациях:

Таблица 7. Изображение объектов диаграммы иерархии функций • Йодана (Yourdon);

• Гейна – Сарсона (Gane – Sarson);

• SADT (Structured Analysis and Design Technique);

• SAG (Software AG).

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

Как видно из рис. 7.2, одной из функций аналитического учета товаров на складе является организация товародвижения. Далее эта функция декомпозируется на следующие подфункции: приемка това ра;

отпуск товара;

ведение БД «Движение товаров»;

инвентарный кон троль.

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

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

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

Определим основные объекты ДПД и их графические изображе ния в различных нотациях (табл. 7.2).

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

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

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

Имя хранилища должно идентифицировать его, а также его содержимое, выражается существительным.

Таблица 7. Графическое отражение объектов ДПД Внешняя сущность (источник/приемник данных) – представляет не который объект вне системы, являющийся внешним объектом.

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

В контекстной диаграмме есть один процесс, с которым связаны внешние сущности.

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

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

• на каждом уровне представлять 3–6 процессов и не более;

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

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

• выбирать ясные, отражающие суть объектов, имена для всех объ ектов ДПД;

• однократно определять функционально идентичные процессы (в других местах просто ссылаться на этот процесс);

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

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

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

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

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

Рис. 7.3. Контекстная диаграмма и диаграмма 1-го уровня в нотации SADT для задачи аналитического учета товаров на складе Таблица 7. Символы STD в различных нотациях Для перехода в состояние нужно какое-либо особое условие – ус ловие перехода. Оно может быть информационным (условие появления информации) или временным. В табл. 7.3 представлены символы ДПС в различных нотациях. Определим основные объекты ДПС.

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

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

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

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

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

Фрагмент диаграммы переходов состояний для задачи аналитиче ского учета товаров на складе в нотации SAG приведен на рис. 7.4.

Как видно из рисунка, текущее состояние системы представлено ожиданием выбора того или иного пункта меню. Выбрали пункт меню – это информационное событие, а сам выбор – действие перехода в сле дующее состояние системы. Переход в состояние системы «Ведение БД «Движение товаров» выполняется по логическому условию ИЛИ, что отражено в триггере. Одно из событий этого перехода является времен ным (дата закрытия периода).

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

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

Рис 7.4. Фрагмент диаграммы переходов состояний для задачи аналитического учета товаров на складе в нотации SAG Таблица 7. Объекты ERD в различных методологиях Продолжение табл. 7. Рис. 7.5. Фрагмент диаграммы «сущность-связь» для задачи труда и ЗП Сущность – представляет собой множество экземпляров реальных или абстрактных объектов, которые обладают общими свойствами (атри бутами).

Отношение – связь между 2 и более сущностями (должны иметь имя в виде глагола).

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

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

Объекты ERD в различных методологиях представлены в табл.

7.4.

Фрагмент диаграммы «сущность-связь» для задачи учета труда и ЗП представлен на рис. 7.5.

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

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

Объекты SSD в различных методологиях представлены в табл. 7.5.

В качестве примера рассмотрим фрагмент системной структурной диаграммы в нотации SAG (рис. 7.6) для задачи аналитического учета то варов на складе. Технологическая сеть проектирования ЭИС на основе использования функционально-ориентированной CASE-технологии представлена на рис. 7.7.

Технологические операции с преобразователями П1, П2, П3, П4, П5, П6, П7 выполняются на стадии технического проектирования.

Преобразователь П1 «Инициализация проекта» используется для инициализации нового проекта ЭИС. На основании документа D «Материалы обследования» создается новый репозиторий G1 для про ектируемой системы.

Преобразователем П2 «Задание начальных параметров проек та» из универсума методологий проектирования U1 выбирается CASE методология проектирования и в рамках выбранной методологии опре деляется нотация на основе универсума U2. Перечень проектировщиков и их прав доступа к проекту D2 служит для описания коллектива разра ботчиков проекта. Результатом выполнения операции является описа ние начальных параметров проекта в репозитории D3.

Таблица 7. Основные объекты SSD и их отображение в различных нотациях Технологические операции с преобразователями П3, П4, П5 и П выполняются последовательно-параллельно и взаимно уточняются в ходе выполнения.

На основе «Материалов обследования» D1 и универсума конст руктивных элементов диаграмм иерархии функций U3 выполняется технологическая операция с преобразователем П3 «Построение диа граммы иерархии функций».

Выполнение преобразователя П3 сводится к выполнению сле дующих работ:

• отображению основной функции;

• декомпозиции основной функции на подфункции;

• дальнейшей декомпозиции подфункций до необходимой степени детализации;

• контролю правильности построенной диаграммы.

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

Входом технологической операции с преобразователем П4 «По строение диаграммы потоков данных» являются:

• материалы обследования (D1);

• диаграмма иерархии функций (D4);

• диаграмма «сущность-связь» (D6);

• универсум конструктивных элементов диаграмм потоков дан ных U4.

Рис. 7.6. Фрагмент SSD-диаграммы в нотации SAG для задачи аналитического учета на складах Построение ДПД можно свести к следующим шагам:

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

2. Идентификация внешних объектов (по отношению к системе).

3. Идентификация информации, которая передается между про цессами.

4. Разработка контекстной диаграммы.

5. Контроль контекстной диаграммы и уточнение, если это нужно.

Рис. 7.7. Технологическая сеть проектирования ЭИС на основе использования функционально оринентированной CASE-технологии: D1 – материалы обследования;

D2 – перечень проектировщиков и прав доступа;

D3 – описание начальных параметров проекта;

D4 – диаграмма функций проекта;

D5 – диаграмма потоков данных;

D6 – диаграмма сущность-связь;



Pages:     | 1 |   ...   | 2 | 3 || 5 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.