CASE-технологии. Современные методы и средства проектирования информационных систем

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

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

Особенности пилотного проекта

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

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

· Процессы в пилотном проекте в чем-либо отличаются от процессов во всей организации.

· Квалификация группы пилотного проекта не отражает квалификацию остальных специалистов организации.

· Ресурсы, выделенные на выполнение проекта, отличаются от тех, которые выделяются для обычных проектов.

· Предметная область или масштаб проекта не соответствуют другим проектам.

Выгода от использования CASE-средств

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

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

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

Принятие решения о внедрении

Возможным решением должно быть одно из следующих:

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

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

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

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

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

4.4 Переход к практическому использованию CASE-средств

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

Разработка плана перехода

План перехода должен включать следующее:

· Информацию относительно целей, критериев оценки, графика и возможных рисков, связанных с реализацией плана.

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

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

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

· Определение стандартных процедур использования средств.

Цели, критерии оценки, график и риски, связанные с планом перехода

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

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

· График перехода к практическому использованию средства в отдельных проектах, который включает необходимую подготовку к его широкому использованию.

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

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

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

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

Приобретение, установка и настройка средств

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

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

· Механизм получения новых версий.

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

· Лицо или подразделение, ответственное за установку, интеграцию, настройку и эксплуатацию средства.

· План конвертирования данных и снятия старых средств с эксплуатации.

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

Интеграция средства с существующими средствами и процессами

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

· Наименования и версии существующих средств, с которыми должно интегрироваться новое средство.

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

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

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

· Определение способа внедрения данного средства в деятельность по совершенствованию существующих процессов.

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

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

Обучение и ресурсы, используемые в течение и после завершения процесса перехода

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

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

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

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

· Частота обучения.

· Виды и доступность поддержки.

Определение стандартов и процедур использования средств

План перехода должен определять следующие стандарты и процедуры использования средств:

· Руководства по моделированию и проектированию.

· Соглашения по присвоению имен.

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

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

· Процедуры интеграции с существующими средствами и базами данных.

· Процедуры совместного использования данных и контроля целостности БД.

· Стандарты и процедуры обеспечения секретности.

· Стандарты документирования.

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

Реализация плана перехода

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

Периодические экспертизы

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

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

Текущая поддержка

Текущая поддержка необходима для следующего:

· Ответов на вопросы, связанные с использованием средств.

· Передачи информации о достигнутых успехах и полученных уроках другим специалистам организации.

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

· Интеграции новых средств с существующими и сопровождение интегрированных средств по мере появления новых версий.

· Помощи новым сотрудникам в освоении средств и связанных с ними процедур.

· Планирования и контроля обновления версий.

· Планирования внедрения новых возможностей средств в организационные процессы.

Действия, выполняемые в процессе перехода

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

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

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

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

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

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

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

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

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

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

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

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

· Сложностью средств,

· Частотой появления новых версий,

· Взаимодействием между средствами и внешней средой.

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

Оценка результатов перехода

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

· Определения степени совершенствования процессов,

· Упреждения возможных стратегических просчетов,

· Своевременного отказа от использования устаревшей технологии.

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

· Использованное время,

· Время, выделенное персонально для конкретных специалистов,

· Размер, сложность и качество ПО,

· Удобство сопровождения.

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

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

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

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

5. Характеристики CASE-средств

5.1 Silverrun+JAM

5.1.1 Silverrun

CASE-средство Silverrun американской фирмы Сomputer Systems Advisers, Inc. (CSA) используется для анализа и проектирования ИС бизнес-класса [22] и ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм "сущность-связь").

Настройка на конкретную методологию обеспечивается выбором требуемой графической нотации моделей и набора правил проверки проектных спецификаций. В системе имеются готовые настройки для наиболее распространенных методологий: DATARUN (основная методология, поддерживаемая Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information Engineering. Для каждого понятия, введенного в проекте имеется возможность добавления собственных описателей. Архитектура Silverrun позволяет наращивать среду разработки по мере необходимости.

Структура и функции

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

Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных (BPM - Business Process Modeler) позволяет моделировать функционирование обследуемой организации или создаваемой ИС. В модуле BPM обеспечена возможность работы с моделями большой сложности: автоматическая перенумерация, работа с деревом процессов (включая визуальное перетаскивание ветвей), отсоединение и присоединение частей модели для коллективной разработки. Диаграммы могут изображаться в нескольких предопределенных нотациях, включая Yourdon/DeMarco и Gane/Sarson. Имеется также возможность создавать собственные нотации, в том числе добавлять в число изображаемых на схеме дескрипторов определенные пользователем поля.

Модуль концептуального моделирования данных (ERX - Entity-Relationship eXpert) обеспечивает построение моделей данных "сущность-связь", не привязанных к конкретной реализации. Этот модуль имеет встроенную экспертную систему, позволяющую создать корректную нормализованную модель данных посредством ответов на содержательные вопросы о взаимосвязи данных. Возможно автоматическое построение модели данных из описаний структур данных. Анализ функциональных зависимостей атрибутов дает возможность проверить соответствие модели требованиям третьей нормальной формы и обеспечить их выполнение. Проверенная модель передается в модуль RDM.

Модуль реляционного моделирования (RDM - Relational Data Modeler) позволяет создавать детализированные модели "сущность-связь", предназначенные для реализации в реляционной базе данных. В этом модуле документируются все конструкции, связанные с построением базы данных: индексы, триггеры, хранимые процедуры и т.д. Гибкая изменяемая нотация и расширяемость репозитория позволяют работать по любой методологии. Возможность создавать подсхемы соответствует подходу ANSI SPARC к представлению схемы базы данных. На языке подсхем моделируются как узлы распределенной обработки, так и пользовательские представления. Этот модуль обеспечивает проектирование и полное документирование реляционных баз данных.

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

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

Взаимодействие с другими средствами

Для автоматической генерации схем баз данных у Silverrun существуют мосты к наиболее распространенным СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase. Для передачи данных в средства разработки приложений имеются мосты к языкам 4GL: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Все мосты позволяют загрузить в Silverrun RDM информацию из каталогов соответствующих СУБД или языков 4GL. Это позволяет документировать, перепроектировать или переносить на новые платформы уже находящиеся в эксплуатации базы данных и прикладные системы. При использовании моста Silverrun расширяет свой внутренний репозиторий специфичными для целевой системы атрибутами. После определения значений этих атрибутов генератор приложений переносит их во внутренний каталог среды разработки или использует при генерации кода на языке SQL. Таким образом можно полностью определить ядро базы данных с использованием всех возможностей конкретной СУБД: триггеров, хранимых процедур, ограничений ссылочной целостности. При создании приложения на языке 4GL данные, перенесенные из репозитория Silverrun, используются либо для автоматической генерации интерфейсных объектов, либо для быстрого их создания вручную.

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

· Система отчетов. Можно, определив содержимое отчета по репозиторию, выдать отчет в текстовый файл. Этот файл можно затем загрузить в текстовый редактор или включить в другой отчет;

· Система экспорта/импорта. Для более полного контроля над структурой файлов в системе экспорта/импорта имеется возможность определять не только содержимое экспортного файла, но и разделители записей, полей в записях, маркеры начала и конца текстовых полей. Файлы с указанной структурой можно не только формировать, но и загружать в репозиторий. Это дает возможность обмениваться данными с различными системами: другими CASE-средствами, СУБД, текстовыми редакторами и электронными таблицами;

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

Групповая работа

Групповая работа поддерживается в системе Silverrun двумя способами:

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

· Сетевая версия Silverrun позволяет осуществлять одновременную групповую работу с моделями, хранящимися в сетевом репозитории на базе СУБД Oracle, Sybase или Informix. При этом несколько разработчиков могут работать с одной и той же моделью, так как блокировка объектов происходит на уровне отдельных элементов модели.

Среда функционирования

Имеются реализации Silverrun трех платформ - MS Windows, Macintosh и OS/2 Presentation Manager - с возможностью обмена проектными данными между ними.

Для функционирования в среде Windows необходимо иметь компьютер с процессором модели не ниже i486 и оперативную память объемом не менее 8 Мб (рекомендуется 16 Мб). На диске полная инсталляция Silverrun занимает 20 Мб.

5.1.2 JAM

Средство разработки приложений JAM [28] (JYACC's Application Manager) - продукт фирмы JYACC (США). В настоящее время поставляется версия JAM 7 и готовится к выходу JAM 8.

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

Структура и функции

JAM имеет модульную структуру и состоит из следующих компонент:

· Ядро системы;

· JAM/DBi - специализированные модули интерфейса к СУБД (JAM/DBi-Oracle, JAM/DBi-Informix, JAM/DBi-ODBC и т.д.);

· JAM/RW - модуль генератора отчетов;

· JAM/CASEi - специализированные модули интерфейса к CASE-средствам (JAM/CASE-TeamWork, JAM/CASE-Innovator и т.д.);

· JAM/TPi - специализированные модули интерфейса к менеджерам транзакций (например, JAM/TPi-Server TUXEDO и т.д.);

· Jterm - специализированный эмулятор X-терминала.

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

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

· редактор экранов. В состав редактора экранов входят: среда разработки экранов, визуальный репозиторий объектов, собственная СУБД JAM - JDB, менеджер транзакций, отладчик, редактор стилей;

· редактор меню;

· набор вспомогательных утилит;

· средства изготовления промышленной версии приложения.

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

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

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

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

Утилиты JAM включают три группы:

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

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

· обслуживание библиотек экранов (традиционные операции с библиотеками).

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

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

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

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

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

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

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

· внешние JPL-модули. Могут поставляться в виде текстовых файлов или в прекомпилированном виде, причем прекомпилированные внешние JPL-модули могут быть как в виде отдельных файлов, так и в составе библиотек экранов;

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

Взаимодействие с другими средствами

Непосредственное взаимодействие с СУБД реализуют модули JAM/DBi (Data Base interface). Способы реализации взаимодействия в JAM разделяются на два класса: ручные и автоматические. При ручном способе разработчик приложения самостоятельно пишет запросы на SQL, в которых как источниками, так и адресатами приема результатов выполнения запроса могут быть как интерфейсные элементы визуально спроектированного внешнего уровня, так и внутренние, невидимые для конечного пользователя переменные. Автоматический режим, реализуемый менеджером транзакций JAM, осуществим для типовых и наиболее распространенных видов операций с БД, так называемых QBE (Query By Example - запросы по образцу), с учетом достаточно сложных взаимосвязей между таблицами БД и автоматическим управлением атрибутами экранных полей ввода/вывода в зависимости от вида транзакции (чтение, запись и т.д.), в которой участвует сгенерированный запрос.

JAM позволяет строить приложения для работы более чем с 20 СУБД: ORACLE, Informix, Sybase, Ingres, InterBase, NetWare SQL Server, Rdb, DB2, ODBC-совместимые СУБД и др.

Отличительной чертой JAM является высокий уровень переносимости приложений между различными платформами (MS DOS/MS Windows, SunOS, Solaris (i80x86, SPARC), HP-UX, AIX, VMS/Open VMS и др.). Может потребоваться лишь "перерисовать" статические текстовые поля на экранах с русским текстом при переносе между средами DOS-Windows-UNIX. Кроме того, переносимость облегчается тем, что в JAM приложения разрабатываются для виртуальных устройств ввода/вывода, а не для физических. Таким образом при переносе приложения с платформы на платформу, как правило, требуется лишь определить соответствие между физическими устройствами ввода/вывода и их логическими представлениями для приложения.

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

При росте нагрузки на систему и сложности решаемых задач (распределенность и гетерогенность используемых ресурсов, количество одновременно подключенных пользователей, сложность логики приложения) применяется трехзвенная модель архитектуры "клиент-сервер" с использованием менеджеров транзакций. Компоненты JAM/TPi-Client и JAM/TPi-Server позволяют достаточно просто перейти на трехзвенную модель. При этом ключевую роль играет модуль JAM/TPi-Server, так как основная трудность внедрения трехзвенной модели заключается в реализации логики приложения в сервисах менеджеров транзакций.

Интерфейс JAM/CASE подобен интерфейсу к СУБД и позволяет осуществить обмен информацией между репозиторием объектов JAM и репозиторием CASE-средства аналогично тому, как структура БД импортируется в репозиторий JAM непосредственно из БД. Отличие заключается в том, что в случае интерфейса к CASE этот обмен является двунаправленным. Кроме модулей JAM/CASEi, существует также модуль JAM/CASEi Developer's Kit. С помощью этого модуля можно самостоятельно разработать интерфейс (т.е. специализированный модуль JAM/CASEi) для конкретного CASE-средства, если готового модуля JAM/CASEi для него не существует.

Мост (интерфейс) Silverrun-RDM <-> JAM реализует взаимодействие между CASE-средством Silverrun и JAM (перенос схемы базы данных и экранных форм приложения между CASE-средством Silverrun-RDM и JAM версии 7.0). Данный программный продукт имеет 2 режима работы:

· прямой режим (Silverrun-RDM->JAM) предназначен для создания объектов CASE-словаря и элементов репозитория JAM на основе представления схем в Silverrun-RDM. В этом режиме мост позволяет, исходя из представления моделей данных интерфейса в Silverrun-RDM, производить генерацию экранов и элементов репозитория JAM. Мост преобразует таблицы и отношения реляционных схем RDM в последовательность объектов JAM соответствующих типов. Методика построения моделей данных интерфейса в Silverrun-RDM предполагает применение механизма подсхем для прототипирования экранов приложения. По описанию каждой из подсхем RDM мост генерирует экранную форму JAM;

· обратный режим (JAM->Silverrun-RDM) предназначен для переноса модификаций объектов CASE-словаря в реляционную модель Silverrun-RDM.

Режим реинжиниринга позволяет переносить модификации всех свойств экранов JAM, импортированных ранее из RDM, в схему Silverrun. На этом этапе для контроля целостности базы данных не допускаются изменения схемы в виде добавления или удаления таблиц и полей таблиц.

Групповая работа

Ядро JAM имеет встроенный интерфейс к средствам конфигурационного управления (PVCS на платформе Windows и SCCS на платформе UNIX). Под управлением этих систем передаются библиотеки экранов и/или репозитории. При отсутствии таких систем JAM самостоятельно реализует часть функций поддержки групповой разработки.

Использование PVCS (см. подраздел 5.6) является более предпочтительным по сравнению с SCCS, так как позволяет организовать единый архив модулей проекта для всех платформ. Так как JAM на платформе UNIX не имеет прямого интерфейса к архивам PVCS, то выборка модулей из архива и возврат их в архив производятся с использованием PVCS Version Manager. На платформе MS-Windows JAM имеет встроенный интерфейс к PVCS и действия по выборке/возврату производятся непосредственно из среды JAM.

Среда функционирования

JAM, как среда разработки, и приложения, построенные с его использованием, не являются ресурсоемкими системами. Например, на платформе MS-Windows достаточно иметь 8MB оперативной памяти и 50 MB дискового пространства для среды разработки. На UNIX-платформах требования к аппаратуре определяются самой операционной системой.

5.2 Vantage Team Builder (Westmount I-CASE) + Uniface

5.2.1 Vantage Team Builder (Westmount I-CASE)

Vantage Team Builder [14] представляет собой интегрированный программный продукт, ориентированный на реализацию каскадной модели ЖЦ ПО и поддержку полного ЖЦ ПО.

Структура и функции

Vantage Team Builder обеспечивает выполнение следующих функций:

· проектирование диаграмм потоков данных, "сущность-связь", структур данных, структурных схем программ и последовательностей экранных форм;

· проектирование диаграмм архитектуры системы - SAD (проектирование состава и связи вычислительных средств, распределения задач системы между вычислительными средствами, моделирование отношений типа "клиент-сервер", анализ использования менеджеров транзакций и особенностей функционирования систем в реальном времени);

· генерация кода программ на языке 4GL целевой СУБД с полным обеспечением программной среды и генерация SQL-кода для создания таблиц БД, индексов, ограничений целостности и хранимых процедур;

· программирование на языке C со встроенным SQL;

· управление версиями и конфигурацией проекта;

· многопользовательский доступ к репозиторию проекта;

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

· экспорт и импорт данных проекта в формате CDIF (CASE Data Interchange Format).

Vantage Team Builder поставляется в различных конфигурациях в зависимости от используемых СУБД (ORACLE, Informix, Sybase или Ingres) или средств разработки приложений (Uniface). Конфигурация Vantage Team Builder for Uniface отличается от остальных некоторой степенью ориентации на спиральную модель ЖЦ ПО за счет возможностей быстрого прототипирования, предоставляемых Uniface. Для описания проекта ИС используется достаточно большой набор диаграмм, конкретные варианты которого для наиболее распространенных конфигураций приведены ниже в таблице.

Тип диаграммы	Обозначение	Vantage Team Builder for ORACLE	Vantage Team Builder for Informix	Vantage Team Builder for Uniface
Сущность-связь	ERD	+	+	+
Потоков данных	DFD	+	+	+
Структур данных	DSD	+	+	+
Архитектуры системы	SAD	+	+	+
Потоков управления	CSD	+	+	+
Типов данных	DTD	+	+	+
Структуры меню	MSD	+
Последовательности блоков	BSD	+
Последовательности форм	FSD		+	+
Содержимого форм	FCD		+	+
Переходов состояний	STD	+	+	+
Структурных схем	SCD	+	+	+

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

При построении DFD обеспечивается контроль соответствия диаграмм различных уровней декомпозиции. Контроль за правильностью верхнего уровня DFD осуществляется с помощью матрицы списков событий (ELM). Для контроля за декомпозицией составных потоков данных используется несколько вариантов их описания: в виде диаграмм структур данных (DSD) или в нотации БНФ (форма Бэкуса-Наура).

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

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

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

Для подготовки проектной документации могут использоваться издательские системы FrameMaker, Interleaf или Word Perfect. Структура и состав проектной документации могут быть настроены в соответствии с заданными стандартами. Настройка выполняется без изменения проектных решений.

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

Процесс проектирования ИС с использованием Vantage Team Builder реализуется в виде 4-х последовательных фаз (стадий) - анализа, архитектуры, проектирования и реализации, при этом законченные результаты каждой стадии полностью или частично переносятся (импортируются) в следующую фазу. Все диаграммы, кроме ERD, преобразуются в другой тип или изменяют вид в соответствии с особенностями текущей фазы. Так, DFD преобразуются в фазе архитектуры в SAD, DSD - в DTD. После завершения импорта логическая связь с предыдущей фазой разрывается, т.е. в диаграммы могут вноситься все необходимые изменения.

Взаимодействие с другими средствами

Конфигурация Vantage Team Builder for Uniface обеспечивает совместное использование двух систем в рамках единой технологической среды проектирования, при этом схемы БД (SQL-модели) переносятся в репозиторий Uniface, и, наоборот, прикладные модели, сформированные средствами Uniface, могут быть перенесены в репозиторий Vantage Team Builder. Возможные рассогласования между репозиториями двух систем устраняются с помощью специальной утилиты. Разработка экранных форм в среде Uniface выполняется на базе диаграмм последовательностей форм (FSD) после импорта SQL-модели. Технология разработки ИС на базе данной конфигурации показана на рисунке 5.1. Структура репозитория (хранящегося непосредственно в целевой СУБД) и интерфейсы Vantage Team Builder являются открытыми, что в принципе позволяет интеграцию с любыми другими средствами.

Среда функционирования

Vantage Team Builder функционирует на всех основных UNIX-платформах (Solaris, SCO UNIX, AIX, HP-UX) и VMS.

Vantage Team Builder можно использовать в конфигурации "клиент-сервер", при этом база проектных данных может располагаться на сервере, а рабочие места разработчиков могут быть клиентами.

Рис. 5.1. Взаимодействие Vantage Team Builder и Uniface

5.2.2 Uniface

Uniface 6.1 [15] - продукт фирмы Compuware (США) - представляет собой среду разработки крупномасштабных приложений в архитектуре "клиент-сервер" и имеет следующую компонентную архитектуру:

· Application Objects Repository (репозиторий объектов приложений) содержит метаданные, автоматически используемые всеми остальными компонентами на протяжении жизненного цикла ИС (прикладные модели, описания данных, бизнес-правил, экранных форм, глобальных объектов и шаблонов). Репозиторий может храниться в любой из баз данных, поддерживаемых Uniface;

· Application Model Manager поддерживает прикладные модели (E-R модели), каждая из которых представляет собой подмножество общей схемы БД с точки зрения данного приложения, и включает соответствующий графический редактор;

· Rapid Application Builder - средство быстрого создания экранных форм и отчетов на базе объектов прикладной модели. Оно включает графический редактор форм, средства прототипирования, отладки, тестирования и документирования. Реализован интерфейс с разнообразными типами оконных элементов управления (Open Widget Interface) для существующих графических интерфейсов - MS Windows (включая VBX), Motif, OS/2. Универсальный интерфейс представления (Universal Presentation Interface) позволяет использовать одну и ту же версию приложения в среде различных графических интерфейсов без изменения программного кода;

· Developer Services (службы разработчика) - используются для поддержки крупных проектов и реализуют контроль версий (Uniface Version Control System), права доступа (разграничение полномочий), глобальные модификации и т.д. Это обеспечивает разработчиков средствами параллельного проектирования, входного и выходного контроля, поиска, просмотра, поддержки и выдачи отчетов по данным системы контроля версий;

· Deployment Manager (управление распространением приложений) - средства, позволяющие подготовить созданное приложение для распространения, устанавливать и сопровождать его (при этом платформа пользователя может отличаться от платформы разработчика). В их состав входят сетевые драйверы и драйверы СУБД, сервер приложений (полисервер), средства распространения приложений и управления базами данных. Uniface поддерживает интерфейс практически со всеми известными программно-аппаратными платформами, СУБД, CASE-средствами, сетевыми протоколами и менеджерами транзакций;

· Personal Series (персональные средства) - используются для создания сложных запросов и отчетов в графической форме (Personal Query и Personal Access - PQ/PA), а также для переноса данных в такие системы, как WinWord и Excel;

· Distributed Computing Manager - средство интеграции с менеджерами транзакций Tuxedo, Encina, CICS, OSF DCE.

Объявленная в конце 1996 г. версия Uniface 7 полностью поддерживает распределенную модель вычислений и трехзвенную архитектуру "клиент-сервер" (с возможностью изменения схемы декомпозиции приложений на этапе исполнения). Приложения, создаваемые с помощью Uniface 7, могут исполняться в гетерогенных операционных средах, использующих различные сетевые протоколы, одновременно на нескольких разнородных платформах (в том числе и в Internet).

В состав компонент Uniface 7 входят:

· Uniface Application Server - сервер приложений для распределенных систем;

· WebEnabler - серверное ПО для эксплуатации приложений в Internet и Intrаnet;

· Name Server - серверное ПО, обеспечивающее использование распределенных прикладных ресурсов;

· PolyServer - средство доступа к данным и интеграции различных систем.

В список поддерживаемых СУБД входят DB2, VSAM и IMS; PolyServer обеспечивает также взаимодействие с ОС MVS.

Среда функционирования Uniface - все основные UNIX - платформы и MS Windows.

5.3 Designer/2000 + Developer/2000

CASE-средство Designer/2000 2.0 фирмы ORACLE [23] является интегрированным CASE-средством, обеспечивающим в совокупности со средствами разработки приложений Developer/2000 поддержку полного ЖЦ ПО для систем, использующих СУБД ORACLE.

Структура и функции

Designer/2000 представляет собой семейство методологий и поддерживающих их программных продуктов. Базовая методология Designer/2000 (CASE*Method) - структурная методология проектирования систем, полностью охватывающая все этапы жизненного цикла ИС [8,9]. В соответствии с этой методологией на этапе планирования определяются цели создания системы, приоритеты и ограничения, разрабатывается системная архитектура и план разработки ИС. В процессе анализа строятся модель информационных потребностей (диаграмма "сущность-связь"), диаграмма функциональной иерархии (на основе функциональной декомпозиции ИС), матрица перекрестных ссылок и диаграмма потоков данных.