А.М.Вендров, Центральный банк РФ
Традиционно при обсуждении проблемы выбора СП (в особенности CASE-средств) большое
внимание уделялось особенностям реализации той или иной методологии анализа предметной
области (E-R, IDEF0, IDEF1Х, Gane/Sarson, Yordon, Barker и др.). Безусловно, богатство
изобразительных и описательных средств дает возможность на этапах стратегического
планирования и анализа построить наиболее полную и адекватную модель предметной области. С
другой стороны, если говорить о конечных результатах - базах данных и приложениях, то
обнаруживается, что часть описаний в них практически не отражается, оставаясь чисто
декларативной (на выходе мы в любом случае получим описание БД в табличном представлении с
минимальным набором ограничений целостности и исполнимый код приложений, большую часть
которых составляют экранные формы, не выводимые непосредственно из моделей предметной
области). Опытные аналитики и проектировщики всегда с большими или меньшими
трудозатратами придут к нужному конечному результату независимо от того, какая конкретно
методология или ее разновидность реализована в данном инструменте. Это, конечно, не означает,
что методология не важна, напротив, отсутствие или неполнота описательных средств могут с
самого начала значительно затруднить работу над проектом. Однако, зачастую на первом плане
оказываются другие критерии, невыполнение которых может породить гораздо большие
трудности.
Может создаться впечатление, что если можно сформировать необходимую аппаратную
платформу из компонентов различных фирм-производителей, то так же просто можно выбрать и
скомплексировать разные инструментальные средства, каждое из которых является одним из
мировых лидеров в своем классе. Однако в случае инструментальных средств в настоящее время, в отличие от оборудования, отсутствуют международные стандарты на основные свойства конечных продуктов (программ, баз данных и их сопряжение). Однако, поскольку составные части проекта должны быть интегрированы в единый продукт, следовательно, имеет смысл рассматривать не любые, а только сопряженные инструментальные средства, которые в принципе могут быть ориентированы - даже внутри одного класса - на разные методологии; при этом необходимо отбирать в состав комплекса СП средства, поддерживающие по крайней мере близкие методологии, если не одну и ту же.
Исходя из перечисленных выше соображений, примем в качестве основных критериев выбора СП следующие критерии:
Поддержка полного жизненного цикла ИС с обеспечением эволюционности ее
развития.
Полный жизненный цикл ИС должен поддерживаться "сквозной" технологической цепочкой
средств разработчика, обеспечивающей решение следующих задач:
Обеспечение целостности проекта и контроля за его состоянием.
Данное требование означает наличие единой технологической среды создания, сопровождения и
развития ИС, а также целостность базы проектных данных (репозитория). Единая технологическая
среда должна обеспечиваться за счет использования единственной CASE-системы для поддержки
моделей ИС, а также за счет наличия программно-технологических интерфейсов между
отдельными инструментальными средствами, сертифицированных и поддерживаемых фирмами-
разработчиками соответствующих средств. В частности, интерфейс между CASE-системой и
средствами разработки приложений должен выполнять две основные функции: а)
непосредственный переход в рамках единой среды от описания логики приложения,
реализованного CASE-системой, к разработке пользовательского интерфейса (экранных форм); б)
перенос описания БД из репозитория CASE-системы в репозиторий средства разработки
приложений и обратно. Вся информация о проекте должна автоматически помещаться в базу
проектных данных, при этом должны поддерживаться согласованность, непротиворечивость,
полнота и минимальная избыточность проекта, а также корректность операций его
редактирования. Это может быть достигнуто при условии исключения или существенного
ограничения возможности актуализации репозитория различными средствами. Должны также
обеспечиваться возможности для централизованного сбора, хранения и распределения
информации между различными этапами проекта, группами разработчиков и выполняемыми
операциями. Поддержка базы проектных данных может быть реализована собственными
средствами СП или средствами целевой СУБД (второй вариант предпочтительнее, поскольку
упрощается технология ведения репозитория).
Невыполнение требования целостности в условиях разобщенности разработчиков и временной
протяженности крупного проекта может означать утрату контроля за его состоянием.
Независимость от программно-аппаратной платформы и СУБД.
Требование определяется неоднородностью среды функционирования ИС. Такая независимость
может иметь две составляющих: независимость среды разработки и независимость среды
эксплуатации приложений. Она обеспечивается за счет наличия совместимых версий СП для
различных платформ и драйверов соответствующих сетевых протоколов, менеджеров транзакций
и СУБД.
Один из дополнительных факторов, который при этом следует учитывать - это способ
взаимодействия с СУБД (прямой или через ODBC), поскольку использование ODBC может
заметно ухудшить производительность и надежность интерфейса.
Поддержка одновременной работы групп разработчиков.
Развитые СП должны обладать возможностями разделения полномочий персонала разработчиков
и объединения отдельных работ в общий проект. Должна обеспечиваться одновременная работа
проектировщиков БД и разработчиков приложений (разработчики приложений в такой ситуации
могут начинать работу с базой данных, не дожидаясь полного завершения ее проектирования
CASE-средствами). При этом все группы специалистов должны быть обеспечены адекватным
инструментарием, а внесение изменений в проект различными разработчиками должно быть
согласованным и корректным. Каждый разработчик должен иметь возможность работы со своим
личным репозиторием, являющимся фрагментом или копией общего репозитория. Должны
обеспечиваться содержательная интеграция всех изменений, вносимых разработчиками, в общем
репозитории, одновременная доступность для разработчика общего и личного репозиториев и
простота переноса объектов между ними.
Помимо перечисленных основных критериев, предварительный анализ при выборе СП должен
учитывать следующие аспекты:
Возможность разработки приложений "клиент-сервер" требуемой конфигурации.
Подразумевается сочетание наличия развитой графической среды разработки приложений
(многооконность, разнообразие стандартных графических объектов, разнообразие используемых
шрифтов и т.д.) с возможностью декомпозиции (partitioning) приложения на "клиентскую" часть,
реализующую пользовательский экранный интерфейс и "серверную" часть. При этом должна
обеспечиваться возможность перемещения отдельных компонентов приложения между "клиентом"
и "сервером" на наиболее подходящую платформу, обеспечивающую максимальную
эффективность функционирования приложения в целом, а также возможность использования
сервера приложений (менеджера транзакций).
Открытая архитектура и возможности экспорта/импорта.
Открытая и общедоступная информация об используемых форматах данных и прикладных
программных интерфейсах должна позволять интегрировать инструментальные средства третьих
фирм и относительно безболезненно переходить от одной системы к другой. Возможности
экспорта/импорта означают, что спецификации, полученные на этапах анализа, проектирования и
реализации для одной ИС, могут быть использованы для проектирования другой ИС. Повторное
проектирование и реализация могут быть обеспечены при помощи средств экспорта/импорта
спецификаций в различные СП.
Качество технической поддержки в России, стоимость приобретения и поддержки, опыт
успешного использования.
Имеется в виду наличие квалифицированных дистрибьюторов и консультантов, быстрота
обслуживания пользователей, высокое качество технической поддержки и обучения продукту и
методологии его применения для больших коллективов разработчиков (наличие сведений о
практике использования системы, качество документации, укомплектованность примерами и
обучающими курсами, наличие прототипных проектов). Затраты на обучение новым технологиям
значительны, однако потери от использования современных сложных технологий необученными
специалистами могут оказаться значительно выше.
Кроме того, фирмы-поставщики инструментальных средств должны быть устойчивыми, так как
технология выбирается не на один год, а также должны обеспечивать хорошую поддержку на
территории России (горячая линия, консультации, обучение, консалтинг), возможно, через
дистрибьюторов.
Что касается стоимости, следует учитывать возможность получения бесплатной пробной лицензии
(trial license), стоимость лицензии на одно рабочее место СП, скидки, предоставляемые фирмой в случае приобретения большого количества лицензий, необходимость приобретения run-time версий для эксплуатации приложений и т.д. В то же время стоимость продукта должна рассматриваться не сама по себе, а с учетом ее соответствия возможностям продукта.
Простота использования.
Учитываются следующие характеристики:
Обеспечение качества проектной документации.
Это требование относится к возможностям СП анализировать и проверять описания и
документацию на полноту и непротиворечивость, а также на соответствие принятым в данной
методологии стандартам и правилам (включая ГОСТ, ЕСПД). В результате анализа должна
формироваться информация, указывающая на имеющиеся противоречия или неполноту в
проектной документации. Должна быть также обеспечена возможность создавать новые формы
документов, определяемые пользователями.
Использование общепринятых, стандартных нотаций и соглашений.
Для того, чтобы проект мог выполняться разными коллективами разработчиков, необходимо
использование стандартных методов моделирования и стандартных нотаций, которые должны
быть оформлены в виде нормативов до начала процесса проектирования. Несоблюдение данного
требования ставит разработчиков в зависимость от фирмы-производителя данного средства,
делает затруднительным формальный контроль корректности используемых нотаций и снижает
возможности привлечения дополнительных коллективов разработчиков, поскольку число
специалистов, знакомых с данным методом (нотацией) может быть ограниченным.
В идеальном случае (что, конечно же, далеко не всегда возможно) окончательный выбор может
быть произведен по результатам тестирования в соответствии с заданным планом, которое должно
включать имитацию проектирования реальной БД и разработки приложений и состоять из
следующих шагов:
Современные СП могут быть разделены на две большие категории. Первую составляют CASE-
системы (как независимые (upper CASE), так и интегрированные с СУБД), обеспечивающие
проектирование БД и приложений в комплексе с интегрированными средствами разработки
приложений "клиент-сервер" (например, Westmount I-CASE+Uniface,
Designer/2000+Developer/2000). Их основное достоинство заключается в том, что они позволяют
разрабатывать всю ИС целиком (функциональные спецификации, логику процессов, интерфейс с
пользователем и базу данных), оставаясь в одной технологической среде. Инструменты этой
категории, как правило, обладают существенной сложностью, широкой сферой применения и
высокой гибкостью.
Вторую категорию составляют собственно средства проектирования БД, реализующие ту или
иную методологию, как правило, "сущность-связь" ("entity-relationship") и рассматриваемые в
комплексе со средствами разработки приложений. К средствам этой категории можно отнести
такие, как SILVERRUN+JAM, ERwin/ERX+PowerBuilder и др.
Помимо указанных категорий, СП можно классифицировать по следующим признакам:
Westmount I-CASE представляет собой интегрированный программный продукт, обеспечивающий
выполнение следующих функций:
Uniface 6.1 представляет собой среду разработки крупномасштабных приложений "клиент-сервер"
и имеет следующую компонентную архитектуру:
СП | West-mount I-CASE + Uniface | Designer/2000+Developer/2000 | SILVER-RUN + JAM | ERwin/ERX + PowerBuilder |
Поддержка полного жизненного цикла ИС | + | + | + | + |
---|---|---|---|---|
Обеспечение целостности проекта | + | + | - | - |
Независимость от платформы | + (ORACLE, Informix, Sybase, Ingres и др., dbf-файлы) | - (целевая СУБД - только ORACLE) | + (ORACLE, Informix, Sybase, Ingres и др.) | + (ORACLE, Informix, Sybase, поддержка ODBC) |
Одновременная групповая разработка БД и приложений | + | - *) | - *) | - *) |