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

Функции системной поддержки

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

Можно ли адаптировать пакет?

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

Вспомните наше замечание из предыдущего раздела о том, что лучший метод расширения возможностей - использование набора API-подпрограмм, предоставляемых изготовителем продукта. Если же API нет, то что делать? Конечно, вы всегда можете читать и обновлять базовые таблицы и представления приложения непосредственно, но мы не рекомендуем это делать. Тому есть ряд очевидных причин:

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

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

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

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

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

Некоторые изготовители пытаются сделать свои продукты более гибкими не с помощью API, а другими средствами. Например, в Oracle Financials есть такое понятие, как гибкие поля (flex fields). Это запасные столбцы в некоторых главных таблицах приложения, которые можно адаптировать под свои нужды. Их можно использовать как ссылки на другие таблицы, но, по сути, они предназначены только для ввода в таблицу дополнительных описательных полей. Кроме того, многие инструментальные средства разработки их совершенно не поддерживают.

А как насчет внешнего вида продукта? Если его интерфейс построен на базе ГПИ, то разрабатывался ли он по тем же стандартам ГПИ, что и остальные продукты и приложения, которые вы используете? Ответ на этот

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

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

Решая проблему адаптации, нужно сначала определить, в какой степени вам необходимо настроить продукт. Хотите ли вы изменить только его внешний вид или же требуется настроить базовые функции? Может быть, вы собираетесь просто добавить в продукт некоторые элементы, чтобы восполнить дефицит функциональных возможностей. Если это так, то являются ли эти дополнения данными, функциями или и тем, и другим? Конечно, стоит спросить у изготовителя продукта или продавца о том, не хотели бы они сейчас или в будущем учесть ваши требования в базовом продукте. Если они ответят положительно, то вы, возможно, решите избавить себя от хлопот, особенно если при Moscow-анализе (см. главу 1) эти требования были luiac-сифицированы как желательные или возможные, а не как необходимые. Однако не забывайте, что приобретение пакета с целью получения еще не реализованной функции противоречит главной цели приобретения готового приложения - получить что-то, что уже работает.

Подводя итоги, опишем проблемы, связанные с внесением изменений в интегрируемое ПО:

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

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

Проблема больших моделей данных

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