Software & Systems

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

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

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

Рассмотрим более подробно, каким образом УС может быть использована при разработке новой ИС. В качестве примера УС возьмем реальную ИС, ориентированную на решение задач бухгалтерского, оперативного, организационно-управленческого учета АСУ предприятия (АСУП). Данная ИС в своей основе была разработана в 1994-1996 г. и представляет собой комплекс работающих в ЛВС автоматизированных рабочих мест, решающих различные задачи. В качестве среды разработки использовалась СУБД Data- Flex 3.01 компании Data Access Corporation. Актуальность перехода на новую ИС обусловлена тем, что с учетом накопленных данных и увеличившегося числа рабочих мест производительность файл-серверной системы оставляла желать лучшего. Также, по ряду объективных причин, стало все более проблематично осуществлять функциональное развитие системы на основе данной устаревшей платформы.

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

Перечислим некоторые задачи, стоящие при разработке новой ИС, на основе УС.

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

Использование CASE-средств. Существуют инструментальные средства по преобразованию данных из одного формата представления в другой с сохранением информационного фонда. Естественно, эта операция осуществима в пределах совместимости возможностей используемых платформ. Например, переход от xBase-совместимой БД к серверной СУБД Oracle можно провести с помощью утилиты Data Migration Wizard, входящей в комплект поставки C++Builder. Кроме того, можно воспользоваться CASE-средством Platinum ERWIN и другими аналогичными средами [2].

В случае с DataFlex возможность использования CASE-средств осложняется нераспространенностью данной СУБД и необходимостью обеспечения доступа к данным (например, приобретение драйверов ODBC).

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

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

Предлагается использовать гибридное проектирование модели данных: основанное на прямом проектировании (forward engineering) с элементами обратного проектирования (reverse engineering), в качестве которого выступают этапы анализа информационного состава УС как на уровне анализа автоматизированных бизнес-процессов обработки данных, так и на уровне анализа структуры данных УС.

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

1. Этап «Анализ бизнес-процессов УС» – выделение и анализ данных обрабатываемых УС с целью ускорения выполнения этапа анализа предметной области, на котором взгляд на данные осуществляется без учета их физической и логической организации в УС.

2. Этапы «Анализ модели данных унаследованной системы» и «Анализ и модификация ЛМ данных новой ИС», позволяющие на основе исследования структуры данных УС учесть специфические особенности в независимо спроектированной логической модели (ЛМ).

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

Унаследование функциональности и архитектуры функциональных элементов. Процесс унаследования функциональности характеризуется прежде всего тем, что нужно реализовать имеющиеся возможности системы на новом технологическом уровне. Новая ИС, как минимум, должна делать свое дело не хуже предшественницы. Задача стоит в реинжениринге УС для достижения системой новых свойств, важнейшим из которых является ее открытость. Представим некоторые признаки открытой системы [3]: отсутствие ограничений по стандартам входящих и выходящих потоков; инвариантность относительно технологий описания системы; отсутствие ограничений с точки зрения эволюции системы; гибкость и самоадаптация при взаимодействии с другими большими системами и информацией различной природы.

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

УС должна использоваться в качестве источника информации для выделения объектов и проведения их классификации. Рассмотрим направления использования объектно-ориентированного проектирования для информационных систем (рис. 2).

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

Верхний уровень – уровень архитектуры. Разработка на основе анализа УС типовых бизнес-объектов системы как взаимодействующих с БД, так и независимых от нее. На рисунке 4 приведены некоторые из выделенных бизнес-объектов для АСУП. Данным подходом обеспечивается и преимущество в создании новых функциональных модулей системы, и достаточная гибкость, и настраиваемость программного обеспечения. В нашем случае ИС включает модули бухгалтерского учета, которые имеют ряд типовых решений. На каждом рабочем месте ведется учет хозяйственных операций (с осуществлением бухгалтерских проводок) в соответствующем журнале; на его основе может быть получен соответствующий выходной документ («Журнал-Ордер» или «Мемориальный ордер» в зависимости от способа ведения бухучета).

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

Особо привлекательной выглядит возможность реализации бизнес-объектов на основе промежуточного программного слоя с использованием промышленных стандартов, например спецификации OMG OMA [4,5].

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

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

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

Проанализируем частоты возможного использования при разработке выделенных на рисунке 3 классов типовых элементов. В качестве объекта анализа выступают подсистемы АСУП. Результаты представлены в таблице 1.

Тмi – трудоемкость разработки фрагмента ПИ i-го типа без использования классов ТЭ;

Ni – количество фрагментов ПИ i-го типа;

Tдi – трудоемкость разработки фрагмента ПИ i-го типа с использованием классов ТЭ;

Tдi = Тмi * Кмi , где Кмi – коэффициент, учитывающий затраты на доработку кода по отношению с обычной разработкой.

Экспертная оценка Кмi для различных типов элементов представлена в таблице 2.

Трудоемкость разработки всех фрагментов ПИ i-го типа без использования классов ТЭ:

Tм = Ni * Тмi

Трудоемкость разработки всех фрагментов ПИ i-го типа с использованием классов ТЭ:

Tд = Ni * Tдi + Tтэi = Ni * Тмi * Кмi + Tтэi, где Tтэi – трудоемкость разработки класса ТЭ i-го типа.

Если принять Tтэi »Тмi, получим следующее выражение:

Tд = Ni * Тмi * Кмi + Tтэi = Ni * Тмi * Кмi + Тмi = Тмi (Ni * Кмi +1).

Относительная эффективность использования классов ТЭ оценивается формулой:

.

Для упрощения оценки примем Тмi = Tмср., тогда имеем:

.

Принимая во внимание, что данным способом перекрывается часть разрабатываемого кода, найдем полную относительную эффективность использования классов ТЭ. Пусть типовыми эле- ментами перекрываем приблизительно 40 % кода Еполн = (0.39+6/4)/(1+6/4)=0,76.

Таким образом, получаем выигрыш по трудоемкости 24%.

Список литературы

1.   Брюхов Д.О., Задорожный В.И., Калиниченко Л.А., Курошев М.Ю., Шумилов С.С. Интероперабельные информационные системы: архитектуры и технологии. // СУБД. - 1995. - №4.

2.   Елманова Н.З. Borland C++ Builder. Версия 3.0. Архитектура "клиент/сервер", многозвенные системы, Internet-приложения. - М.: ДИАЛОГ-МИФИ. - 1998.

3.   Кротов А.А., Лупян Е.А. Обзор методов реструктуризации и интеграции информационных систем. - http://d902.iki.rssi.ru/students/alekro/Dissertation/Papers/Reengineering/my_review.html

4.   Калиниченко Л.А., Когаловский М.Р. Стандарты OMG: Язык определения интерфейсов IDL в архитектуре CORBA. // СУБД. – 1996. - №2.

5.   Ахтырченко К.В., Леонтьев В.В. Распределенные объектные технологии в информационных системах. // СУБД. – 1997. - №5-6.