Case средства designer2000 developer20005 3 designer2000 developer2000


Содержание

CASE-средство Designer/2000

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

Designer/2000 представляет собой семейство методологий и поддерживающих их программных продуктов. Базовая методология Designer/2000 (CASE Method) — структурная методология проектирования систем, охватывающая полностью все этапы жизненного цикла ИС.

Designer/2000 обеспечивает графический интерфейс при разработке различных моделей (диаграмм) предметной области. В процессе построения моделей информация о них заносится в репозиторий. В состав Designer/2000 входят следующие компоненты:

Ø Repository Administrator — средства управления репозиторием (создание и удаление приложений, управление доступом к данным со стороны различных пользователей, экспорт и импорт данных);

Ø Repository Object Navigator — средство доступа к репозиторию, обеспечивающие многооконный объектно-ориентированный интерфейс доступа ко всем элементам репозитория;

Ø Process Modeller — средство анализа и моделирования деловой деятельности, основывающееся на концепциях реинжиниринга бизнес-процессов (BPR — Business Process Reengineering) и глобальной системы управления качеством (TQM — Total Quality Management);

Ø Systems Modeller — набор средств построения функциональных и информационных моделей проектируемой ИС, включающий средства для построения диаграмм «сущность-связь» (Entity Relationship Diagrammer), диаграмм функциональных иерархий (Function Hierarchy Diagrammer), диаграмм потоков данных (Data Flow Diagrammer) и средство анализа и модификации связей объектов репозитория различных типов (Matrix Diagrammer);

Ø Systems Designer — набор средств проектирования ИС, включающий средство построения структуры реляционной базы данных (Data Diagrammer), а также средства построения диаграмм, отображающих взаимодействие с данными, иерархию, структуру и логику приложений, реализуемую хранимыми процедурами на языке PL/SQL (Module Data Diagrammer, Module Structure Diagrammer и Module Logic Navigator);

Ø Server Generator — генератор описаний объектов БД ORACLE (таблиц, индексов, ключей, последовательностей и т.д.). Помимо продуктов ORACLE, генерация и реинжиниринг БД может выполняться для СУБД Informix, DB/2, Microsoft SQL Server, Sybase, а также для стандарта ANSI SQL DDL и баз данных, доступ к которым реализуется посредством ODBC;

Ø Forms Generator (генератор приложений для ORACLE Forms). Генерируемые приложения включают в себя различные экранные формы, средства контроля данных, проверки ограничений целостности и автоматические подсказки. Дальнейшая работа с приложением выполняется в среде Developer/2000;

Ø Repository Reports — генератор стандартных отчетов, интегрированный с ORACLE Reports и позволяющий русифицировать отчеты, а также изменять структурное представление информации.

Генерация приложений, помимо продуктов ORACLE, выполняется также для Visual Basic.

Designer/2000 можно интегрировать с другими средствами, используя открытый интерфейс приложений API (Application Programming Interface). Кроме того, можно использовать средство ORACLE CASE Exchange для экспорта/импорта объектов репозитория с целью обмена информацией с другими CASE-средствами.

Среда функционирования Designer/2000 — Windows 3.x, Windows 95, Windows NT.

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

Методология ARIS

Аббревиатура ARIS расшифровывается как «Архитектура интегрированных информационных систем». Понятие «архитектура» обычно используется в строительстве. В области информационных технологий (ИТ) оно служит для описания:

Ø функциональных свойств,

Ø взаимоотношений между отдельными «кирпичиками» информационной системы.

DESIGNER/2000 — новое поколение CASE- продуктов фирмы ORACLE

DESIGNER/2000 — новое поколение CASE- продуктов фирмы ORACLE

О.Горчинская, НПВП ФОРС

Одним из уже сложившихся направлений деятельности фирмы ORACLE стала разработка методологических основ и производство инструментальных средств для автоматизации процессов разработки сложных прикладных систем, ориентированных на интенсивное использование баз данных.
Основу CASE-технологии и инструментальной среды фирмы ORACLE [1-5] составляют:

  • методология структурного нисходящего проектирования, при которой разработка прикладной системы представляется в виде последовательности четко определенных этапов (рис.1);
  • поддержка всех этапов жизненного цикла прикладной системы, начиная с самых общих описаний предметной области до получения и сопровождения готового программного продукта;
  • ориентация на реализацию приложений в архитектуре «клиент-сервер» с использованием всех особенностей современных серверов баз данных, включая декларативные ограничения целостности, хранимые процедуры, триггеры баз данных, и с поддержкой в клиентской части всех современных стандартов и требований к графическому интерфейсу конечного пользователя;.
  • наличие централизованной базы данных, репозитария, для хранения спецификаций проекта прикладной системы на всех этапах ее разработки. Такой репозитарий представляет собой базу данных специальной структуры, работающую под управлением СУБД ORACLE;
  • возможность одновременной работы с репозитарием многих пользователей. Такой многопользовательский режим почти автоматически обеспечивается стандартными средствами СУБД ORACLE. Централизованное хранение проекта системы и управление одновременным доступом к нему всех участников разработки поддерживают согласованность действий разработчиков и не допускают ситуацию, когда каждый проектировщик или программист работает со своей версией проекта и модифицирует ее независимо от других;
  • автоматизация последовательного перехода от одного этапа разработки к следующему. Для этого предусмотрены специальные утилиты, с помощью которых можно по спецификациям концептуального уровня (модели предметной области) автоматически получать первоначальный вариант спецификации уровня проектирования (описание структуры базы данных и состава программных модулей), а по последним после всех необходимых уточнений и дополнений автоматически генерировать готовые к выполнению программы;
  • автоматизация различных стандартных действий по проектированию и реализации приложения: предусматривается генерация многочисленных отчетов по содержимому репозитария, обеспечивающих полное документирование текущей версии системы на всех этапах ее разработки; с помощью специальных процедур предоставляется возможность проверки спецификаций на полноту и непротиворечивость и т.д.
Стратегия
Анализ
Проектирование
Реализация Документирование
Внедрение
Поддержка
Designer/2000
Анализ деятельности Моделирование Генерация приложений
Репозитарий
Отчеты Графика
Экранные формы
Developer/2000

Первая версия CASE-инструментария фирмы ORACLE, ORACLE*CASE 5.0 появилась в 1989 году для сервера ORACLE/6 с ориентацией на символьный режим для конечного пользователя. Существенные изменения потребовались в следующей версии, ORACLE*CASE 5.1 (1993г.), в связи с реализацией нового сервера ORACLE/7 и перехода к графическому интерфейсу конечного пользователя. В настоящее время завершена работа по выпуску в промышленную эксплуатацию новой CASE-среды под названием DESIGNER/2000, работающей в среде MS WINDOWS. Этот продукт вместе со средствами разработки DEVELOPER/2000 реализуют новый подход фирмы ORACLE к общей среде создания и сопровождения прикладных систем (рис. 2).

Общая архитектура и основные компоненты DESIGNER/2000

В соответствии с общей архитектурой CASE-системы DESIGNER/2000, изображенной на рис.3, выделяются следующие основные этапы процесса разработки системы: моделирование и анализ деловой деятельности, разработка концептуальных моделей предметной области, проектирование прикладной системы и реализация.

Первый этап связан с моделированием и анализом процессов, описывающих деятельность организации, технологические особенности работы. Целью является построение моделей существующих процессов, выявление их недостатков и возможных источников усовершенствования. Этот этап не является обязательным в случае, когда существующая технология и организационные структуры четко определены, хорошо понятны и не требуют дополнительного изучения и реорганизации. В состав DESIGNER/2000 входят удобные средства поддержки этого этапа, позволяющие строить наглядные представления процессов и взаимосвязей между ними и анализировать их с использованием средств мультимедиа.
На втором этапе разрабатываются детальные концептуальные модели предметной области, описывающие информационные потребности организации, особенности функционирования и т.д. Результатом являются модели двух типов — информационные, отражающие структуру и общие закономерности предметной области, и функциональные, описывающие особенности решаемых задач.
На следующей стадии, этапе проектирования, на основании концептуальных моделей вырабатываются технические спецификации будущей прикладной системы — определяется структура и состав базы данных, специфицируется набор программных модулей. Первоначальный вариант проектных спецификаций может быть получен автоматически с помощью специальных утилит на основании данных концептуальных моделей.
И наконец, на этапе реализации создаются программы, отвечающие всем требованиям проектных спецификаций. Использование генераторов приложений, входящих в состав DESIGNER/2000, позволяет полностью автоматизировать этот этап, существенно сократить сроки разработки системы и повысить ее качество и надежность.
В соответствии с общей архитектурой инструментальные средства, входящие в состав DESIGNER/2000, разбиваются на следующие компоненты (рис. 4):

  • средства доступа к репозитарию
  • средства управления репозитарием
  • средства анализа деловой деятельности
  • средства концептуального моделирования
  • средства проектирования системы
  • генераторы приложений
  • Анализ деловой деятельности
  • Концептуальное моделирование
  • Проектирование системы
  • Генерация приложений
Информация Процессы
  1. навигатор объектов репозитария
  2. матричный диаграммер
  3. средства администрирования
  4. средства моделирования процессов
  5. диаграммер ER-моделей
  6. диаграммер иерархии функций
  7. диаграммер потоков данных
  8. диаграммер структуры приложения
  9. навигатор параметров
  10. навигатор процедурной логики
  11. диаграммер баз данных
  12. диаграммер модулей
  13. генератор сервера
  14. генератор форм
  15. генератор отчетов

Репозитарий — централизованная база данных проекта

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

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

Моделирование, анализ и реорганизация деловой деятельности

Средства анализа деловой деятельности — новый компонент, не имеющий аналогов в предыдущих версиях CASE — продуктов фирмы ORACLE. Он предназначен для описания и анализа деятельности организации или компании, визуального представления основных технологических процессов, способов коммуникации и т.п. Включение этого компонента в общую интегрированную среду DESIGNER 2000 связано с быстро развивающимся в последние годы новым направлением менеджмента, известным под названием анализ и реорганизация деловой деятельности (Business Process Reengineering)[6].
В рамках этого направления решаются задачи анализа деятельности предприятия или фирмы, перепроектирования и реорганизации основных технологических процессов с целью повышения эффективности, сокращения затрат, увеличения прибыли и др. Основой для этого служат модели деловой деятельности или модели процессов, отражающие различные аспекты работы производственного или коммерческого предприятия, включая организационные структуры, распределение работ, загрузку и занятость персонала и т. д.
При этом особые требования предъявляются к наглядности, выразительности таких моделей, их простоте для восприятия управленческим персоналом, не обязательно обладающим технической подготовкой и навыками работы с формальным аппаратом.
Входящие в состав DESIGNER 2000 средства моделирования процессов полностью отвечают этим требованиям. Использование средств мультимедиа, включая визуализацию, звуковое сопровождение, видеоизображение, анимацию, позволяет дополнительно повысить выразительность моделей процессов и обеспечивает возможность исследовать их динамические характеристики.
Общая модель деловой деятельности представляется в виде совокупности диаграмм, каждая из которых описывает отдельный процесс в виде его разбиения на взаимосвязанные друг с другом шаги или подпроцессы (рис.6).

  1. базовый процесс;
  2. шаг процесса;
  3. поток данных;
  4. хранилище данных;
  5. организационная единица;

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

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

Кроме того для каждого типа объектов или для отдельного индивидуального объекта можно задать целый спектр разнообразных количественных параметров, включая, например, временные затраты и ресурсы, необходимые для выполнения того или иного шага процесса или для реализации некоторого потока. После этого с помощью специальной процедуры анимации можно «оживить» диаграмму, увидеть поведение модели в динамике с учетом введенных временных задержек и затрат ресурсов, заданных для отдельных составляющих. Такое «имитационное» моделирование наглядно показывает, как распределяется процесс по времени, а также дает представление о динамической зависимости между различными подпроцессами. В случае параллельных шагов процессов специальный механизм «анализ критических участков» выявляет «узкие» места в технологических цепочках и определяет возможные способы усовершенствования деятельности.
Вся информация, вводимая в модель, может быть экспортирована в стандартные пакеты электронных таблиц, такие как Microsoft Excel и Lotus-1-2-3. Это оказывается полезным для более глубокого сложного анализа временных и стоимостных затрат, для представления результатов в виде специальных графиков и диаграмм.

Концептуальное описание предметной области

Важнейшим этапом разработки прикладной системы является построение концептуальных моделей, как можно более полно описывающих особенности предметной области, характер решаемых задач, информационные потребности и ресурсы, технологические ограничения и т.д. В результате должны быть построены модели двух типов — информационная, отражающая существующие информационные структуры и взаимосвязи между ними, и функциональная, описывающая технологию и способы обработки информации, используемые в данной области.
В качестве стандартного средства информационного моделирования в современных CASE- методологиях используется в том или ином виде аппарат моделей «сущность-связь» или ER- моделей (Entity Relationship Model). Этот формализм позволяет представлять информационные потребности в виде, наглядном и удобном для восприятия, что делает их хорошим средством коммуникации между проектировщиками и пользователями в процессе уточнения постановки задач.
Теоретической основой этого подхода является известная модель «сущность-связь», введенная Ченом в 1976 году [7] и получившая широкое развитие и распространение в качестве средств концептуального проектирования баз данных. В основе модели Чена лежит представление о том, что предметная область состоит из отдельных объектов, находящихся друг с другом в определенных связях. Объекты описываются различными параметрами или атрибутами; однотипные объекты описываются одним и тем же набором параметров и объединяются в множества или классы; такие классы называются сущностями. Конкретные объекты, составляющие класс , называются экземплярами соответствующей сущности. Между сущностями специфицируются взаимосвязи различного вида: один к одному, один ко многим и др.
В CASE-методологии фирмы ORACLE используется некоторый специальный вид модели Чена, близкий к бинарной ER-модели. В этом случае взаимосвязи могут быть определены только между двумя сущностями. Кроме того, для взаимосвязей нельзя задавать атрибутов.
Для наглядного представления общей структуры предметной области все такие спецификации изображаются в графическом виде — в виде ER-диаграммы. На этой диаграмме объекты изображаются прямоугольниками, а связи — линиями, соединяющими соответствующие прямоугольники. Задание типа связи («один к одному», «многие к одному» и т.д.) означает введение некоторого семантического ограничения. На диаграмме для каждого типа взаимосвязи используется свое графическое изображение: если любой экземпляр сущности A может быть связан с несколькими экземплярами сущности B, то со стороны прямоугольника-сущности A линия, выражающая взаимосвязь, дополняется специальным символом (рис. 9). Кроме того, для связи можно указать, является ли она обязательной для входящих в нее сущностей. Если любой экземпляр сущности A обязательно должен быть связан с каким-либо экземпляром сущности B, то прилегающая к прямоугольнику «A» половина линии — сплошная, в противном случае она — пунктирная.

Например, на рис.9 для сущностей «СЛУЖАЩИЙ» и «ОТДЕЛ», определена взаимосвязь, описывающая распределение людей по отделам . В данном случае диаграмма моделирует следующие семантические ограничения:

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

На рис. 10 приводится более сложный пример , иллюстрирующий дополнительные возможности ER-диаграмм: моделирование подтипов и исключающих взаимосвязей. В данном примере каждый сотрудник может принимать участие в некотором (не более чем одном) проекте или заниматься преподаванием одного учебного курса. При этом существует дополнительное правило: никто не может одновременно участвовать в проекте и преподавать. Такие исключающие друг друга взаимосвязи изображаются на диаграмме линиями, объединенными дугой (рис. 10). Кроме того, при изображении сущности «ПРОЕКТ» учитывается, что любой проект может быть одним из двух видов — исследованием или разработкой (каждый из этих подтипов описывается своим набором атрибутов).

Кроме самой диаграммы для каждой сущности необходимо специфицировать описывающие его параметры, различные характеристики каждого параметра (тип, возможные значения, уникальность и др.). Вся эта информация и составляет информационную модель концептуального уровня.
Функциональные аспекты предметной области описываются с помощью диаграмм иерархии функций и потоков данных. Эти диаграммы отражают деятельность существующих организационных структур, технологические особенности процессов переработки информации и строятся по методологии проектирования «сверху вниз». Начиная с самой общей функции, описывающей деятельность всей организации в целом, аналитик последовательно разбивает это описание на более детальные функции, в совокупности составляющие исходную; в дальнейшем этот процесс продолжается применительно к новым, полученным на предыдущем уровне функциям. Такая декомпозиция функций завершается, когда функции, полученные на самом нижнем уровне иерархии, не поддаются дальнейшему разложению, т.е. являются элементарными. Для них специфицируется, с какими объектами они работают, какие типы действий при этом производятся (создание, удаление, модификация) как на уровне объектов, так и на уровне отдельных их параметров. Кроме этого, могут быть описаны события, вызывающие выполнение той или иной функции.
Дополнительно к иерархии функций для описания функционирования организационных структур и принятой технологии обработки информации используется еще один вид диаграмм — диаграммы потоков данных. Эти диаграммы служат для представления движения данных в процессе работы организационных структур и являются широко распространенным средством моделирования, знакомым многим системным аналитикам, проектировщикам, а иногда и пользователям. Для каждой неэлементарной функции строится диаграмма, на которой изображаются информационные взаимосвязи между составляющими эту функцию «под-функциями», указываются источники и приемники данных, места промежуточного временного накопления информации.
Входящие в состав DESIGNER/2000 средства концептуального моделирования представляют собой совокупность графических редакторов, обеспечивающих поддержку информационных и функциональных моделей концептуального уровня. В состав этих средств входят (рис. 4):

  • графический редактор ER-диаграмм
  • графический редактор иерархии функций
  • графический редактор диаграмм потоков данных

Каждый из этих редакторов (диаграммеров) обеспечивает удобные средства работы с диаграммами определенного типа, отвечающие всем требованиям современного графического интерфейса (рис. 11 — 13).

Кроме собственно изображения диаграммы каждый из редакторов позволяет вводить дополнительную уточняющую информацию об отдельных элементах диаграммы. Например, для любой сущности, представленной на ER-диаграмме прямоугольником с названием, можно вызвать специальное окно для задания всевозможных характеристик этой сущности, включая атрибуты, первичные ключи, уникальные идентификаторы, ограничения или правила проверки для значений атрибутов, частотные характеристики и т.д. Аналогично, для любой взаимосвязи можно специфицировать, является ли она идентифицирующей (входит в состав какого-либо уникального идентификатора), переносимой ( можно динамически переопределять для любого экземпляра сущности типа «деталь», какому экземпляру «мастера» он подчиняется) и т.д.
Существенно, что в отличие от предыдущих версий ER-редакторов, здесь можно изображать непосредственно на диаграмме многие из таких дополнительных характеристик. Так, часто удобно бывает видеть на ER-диаграмме не только название сущности, но и определяющие ее атрибуты с указанием, какие из них являются ключевыми, какие — обязательными и т.д. (рис.11).
Дополнительно повышает наглядность и выразительность концептуальных моделей широкие возможности использования цвета и различных шрифтов для обозначения названий отдельных элементов.
Для одного и того же приложения предусматривается возможность построения нескольких ER- диаграмм и нескольких иерархий функций: это может быть полезно для сложных задач с огромным количеством объектов и связей. В этом случае естественно декомпозировать общую задачу и для каждой части рисовать свою ER-диаграмму.
Кроме средств ввода данных и построения графических изображений каждый редактор предоставляет возможность выполнять различные семантические проверки построенных диаграмм на полноту и корректность, а также генерировать разнообразные отчеты для документирования концептуального уровня разработки. Развитые средства вывода позволяют получить на бумаге любую диаграмму с помощью плотера или любого PostScript-принтера.

Проектирование прикладной системы

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

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

С помощью утилиты автоматической генерации проекта базы данных по ER-диаграмме будут построены спецификации будущей базы данных — ее состав таблиц, перечень столбцов каждой из них, уточнение характеристик столбцов, описание ограничений целостности и т.д.
При генерации схемы базы данных по ER-модели каждой сущности ставится в соответствие таблица, атрибутам — столбцы таблиц, а для каждой связи создаются дополнительные столбцы и определяются ограничения целостности типа внешних ключей (foreign key constraint). Подтипы сущностей в ER-модели реализуются в схеме базы данных в виде одной общей таблицы или в виде совокупности нескольких — по одной на каждый подтип.
По иерархии функций и диаграммам потоков данных могут быть автоматически сгенерированы спецификации программных модулей прикладной системы, описывающие общие характеристики модулей, с какими таблицами работает каждый из них, возможные действия с этими таблицами и т.д. При этом анализируется диаграмма иерархии функций и для каждой элементарной функции (нижней в иерархии) создается спецификация модуля. Тип модуля устанавливается по определенным правилам в соответствии с указанным для функции способом работы с сущностями. Например, если известно, что функция использует сущности только для чтения информации, то считается, что ей должен соответствовать модуль типа отчет. Предусмотрена также возможность «объединять» некоторые однотипные функции, т.е. создавать один модуль сразу для нескольких различных элементарных функций. Основой для такого «объединения» служит также характер использования функциями сущностей — если две функции работают с одними и теми же сущностями и одинаково их используют, то это может считаться основанием для создания для них одного общего модуля. Разработчику предоставляется возможность регулировать уровень «объединения» функций путем выбора одного из имеющегося набора критериев.
Для работы со всевозможными спецификациями уровня проектирования в DESIGNER/2000 предусмотрен целый набор графических редакторов, каждый из которых ориентирован на спецификации определенного типа.
Использование на этом уровне графических моделей — диаграмм, является важной новой особенностью CASE-средств фирмы ORACLE. В предыдущих версиях, как и во многих CASE- системах других фирм, графические диаграммы используются обычно только на концептуальном уровне для ER-моделей, функциональных иерархий и т.д. В то же время, опыт практической деятельности в области CASE-технологий показывает, что использование графических изображений полезно и для представления структуры базы данных, схем взаимодействия программных модулей и т.д.
В DESIGNER/2000 для этой цели предусмотрены:

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

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

По внешнему виду диаграмма схемы БД похожа на ER-диаграмму. В простейших случаях, например, когда в ER-диаграмме не используются конструкции подтипов, соответствующая полученная по умолчанию диаграмма базы данных может почти совпадать с ER-диаграммой. Однако, даже и в этом случае в результате дальнейшего проектирования первоначальный вариант структуры БД может дополняться представлениями и другими дополнительными деталями, что приводит к изменению диаграммы.
Диаграмма взаимосвязей между модулями дает наглядное представление о структуре приложения с точки зрения взаимодействия между различными программными модулями. По внешнему виду диаграмма близка к иерархии функций, но семантически они различаются. Иерархия функций моделирует декомпозицию функций, начиная с более общих и кончая элементарными; иерархическое подчинение функций некоторой заданной означает, что они нужны для выполнения этой последней. В случае диаграммы взаимосвязей между модулями иерархическое подчинение означает вызов одних программных модулей из других в процессе работы приложения. Диаграмма взаимосвязей между модулями служит источником для генерации первоначального варианта главного меню прикладной системы.
Схема модуля представляет собой диаграмму, описывающую структуру отдельного программного модуля с точки зрения использования им данных.
Как и на диаграмме базы данных, в виде прямоугольников здесь изображаются таблицы, используемые в модуле, а с помощью соединительных линий — связи между таблицами. Такая связь может определяться при наличии в одной из базовых таблиц соответствующего внешнего ключа и на данной диаграмме эта связь означает, что в результирующем модуле, экранной форме или отчете, между двумя таблицами должно поддерживаться соотношение «мастер-деталь» (если таблицы имеют вертикальное относительное расположение) или одна из таблиц играет роль просмотровой или «lookup»-таблицей (таблицы в этом случае должны располагаться на одной горизонтали). Дополнительно, с помощью внешних линий можно задавать относительное расположение информационных блоков на экране.
На рис. 15 приводится пример использования диаграммы структуры модуля.

На диаграмме определяется модуль типа экранной формы, в которой в одном окне должны высвечиваться данные из таблицы «ОТДЕЛЫ» и данные из таблицы «СОТРУДНИКИ», синхронизированные друг с другом (при переходе на новую строку в первом блоке соответственно меняются данные во втором блоке и т.п.). Кроме того, для таблицы «СОТРУДНИКИ» определена дополнительная просмотровая таблица для выбора и задания для каждого сотрудника его начальника. Результирующая сгенерированная экранная форма приведена на рис. 16.

Кроме трех графических редакторов системного проектирования, в Designer/2000 включено специальное средство для определения программных модулей типа процедуры, написанной на языке PL/SQL (универсальный процедурный язык программирования, включающий в себя операторы языка SQL). Это средство, так называемый навигатор процедурной логики, представляет собой синтаксически-ориентированный редактор, позволяющий создавать программные тексты на языке PL/SQL по технологии «найди-и-выбери». Это означает, что вместо непосредственного набора текста операторов создание программы сводится к выбору нужной конструкции или объекта из «каталога». Особенность этого средства — его объектно- ориентированный интерфейс, существенно упрощающий процесс работы: «каталог» возможных конструкций языка PL/SQL и объектов базы данных представлен в виде иерархии типов с набором удобных средств просмотра и поиска необходимых элементов.

Входящие в состав DESIGNER/2000 генераторы разбиваются на две группы:

  • генератор сервера
  • генераторы клиентской части

Генератор серверной части автоматически строит по спецификациям базы данных тексты программ на языке SQL, используя все средства определения баз данных, включая триггеры, хранимые процедуры и т.д.
Генераторы клиентской части обеспечивают автоматическое формирование текстов программных модулей по их спецификациям, записанным в репозитарии. Все модули приложения классифицируются по типам, основными из которых являются экранные формы, отчеты, процедуры. Для каждого типа имеется свой генератор, результатом работы которого является программа, написанная на языке, соответствующем этому типу: генератор форм создает приложения для ORACLE/Forms, генератор отчетов позволяет получать процедуры на PL/SQL либо приложения для ORACLE/Report.
Исходной информацией для работы любого генератора служат спецификации таблиц базы данных и спецификации модулей. В спецификации модуля указываются такие его параметры, как наименование, тип, некоторые характеристики внешнего представления (заголовки, параметры). Кроме того, перечисляются используемые таблицы базы данных и для каждой из них специфицируется, какие операции к ней могут применяться (выборка, ввод записей, корректировка, удаление), какие ее столбцы и каким образом участвуют в работе модуля.
Каждый используемый столбец может описываться разнообразными описателями, включая форматы вывода, способы упорядочения, основные типы операций над данными, возможность автоматической генерации значений при вводе новых записей и др. В простейших же случаях можно использовать их стандартные значения, задаваемые по умолчанию, что существенно сокращает время на получение первоначальной версии работающей программы.
Кроме этой информации об особенностях модуля генератор использует спецификации таблиц базы данных и взаимосвязей между ними. Это позволяет при описании в репозитарии собственно модуля не заботится об указании, каким образом связаны используемые таблицы, из каких таблиц берутся данные для заполнения того или иного столбца, какие дополнительные действия необходимо выполнить при изменении содержимого данной таблицы, чтобы не нарушить целостность всей базы данных (так, при удалении записи из таблицы может потребоваться проверка, не ссылаются ли на нее записи из других таблиц) и т.п.
Например, если мы хотим создать экранную форму для таблицы СОТРУДНИКИ, то нет необходимости включать в число используемых таблиц ОТДЕЛЫ в качестве источника для заполнения столбца ОТДЕЛ в таблице СОТРУДНИКИ. Генератор, анализируя структуру базы данных, автоматически создаст правильный список возможных значений и включит в текст программы все необходимые проверки на правильность вводимых данных. Такой принцип работы генераторов особенно существенен для поддержки прикладной системы: при необходимости изменения схемы базы данных (добавилась новая таблица, логически связанная с уже существующими, или изменился тип некоторой взаимосвязи между базовыми таблицами и т.п.) можно не вносить никаких изменений в старые спецификации модулей, а лишь перегенерировать их и все необходимые изменения в тексты программ будут внесены автоматически.
Несмотря на то, что спецификации модуля в репозитарии описывают его лишь в самом общем виде без уточнения различных деталей внешнего представления форм и отчетов, особенностей функционирования, существует возможность дополнительной «настройки» с помощью многообразных параметров, управляющих работой генераторов. Более четырехсот таких параметров, тщательно классифицированных, позволяют получать по одной и той же спецификации работающие программы, различающиеся внешними представлениями, особенностями функционирования, стилем оформления исходного текста и т.д.
При необходимости сгенерированный текст программы можно дополнительно доработать и дополнить, пользуясь непосредственно соответствующими инструментальными средствами разработки «нижнего уровня», входящими в состав DEVELOPER/2000. В этом случае появляется некоторая опасность несоответствия конечной версии программы спецификациям проекта, что особенно неудобно при возможных изменениях проекта, например схемы базы данных. Такое изменение требует перегенерации модулей с учетом новых таблиц и взаимосвязей, а с другой стороны выполнение повторной генерации «уничтожит» старую версию программы со всеми введенными «вручную» дополнительными фрагментами. Для такой ситуации в DESIGNER/2000 предусмотрен специальный режим работы генераторов — регенерация. При регенерации происходит не замена старого программного текста на новый, а его «редактирование», когда по возможности вносятся лишь необходимые изменения и не корректируются отдельные фрагменты. При этом можно управлять уровнем изменений и запретить модифицировать определенные фрагменты программы (например, все, относящееся к описанию расположения полей или триггеры заданного типа и т.п.).
Из дополнительных средств, входящих в состав генераторов, особый интерес представляют утилиты, позволяющие использовать DESIGNER/2000 не только для новых разработок, начинающихся с этапа постановки задачи, но и для готовых прикладных систем, которые были спроектированы и реализованы без использования CASE-средств. Для такой ситуации предусмотрена возможность реинженигинга системы — автоматического создания по работающей версии приложения его описания в репозитарии, т.е. спецификаций структуры базы данных, программных модулей типа экранных форм и отчетов, ER-модели. Полученные описания могут быть использованы для анализа возможностей и выявления недостатков существующей версии приложения, а впоследствии модифицированы в соответствии с новыми требованиями и условиями функционирования системы. На основе отредактированных спецификаций производится генерация новой версии системы.

CASE средство Designer/2000

рпз_прис.docx

1 Теоретическая часть. CASE средство Designer/2000………………………. 5

2.2 Анализ предметной области……………………………… ………………….9

2.3 Функциональная модель по стандарту IDEF0 и методологии SADT…. 11

2.4 Модель данных по стандарту IDEF1X диаграммы “сущность-связь”…. 13

2.5 Описание таблиц базы данных…………………………………………. 14

2.5 Описание таблиц базы данных……………………………………………. 16

2.7 Схема взаимосвязей модулей и массивов данных ………………………..17

2.8Алгоритм работы модуля dati……………………………… ………………..18 2.9 Инструкция пользователя……………………………………………… …. 19

2.10 Способы и результаты тестирования программного продукта………….20

Список использованных источников…………………………………………. 24

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

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

Данная курсовая работа посвящена теоретическому изучению CASE-средства Designer/2000 фирмы ORACLE и разработке информационной системы для автоматизации учета ремонта жилищного фонда в муниципальном жилищно-ремонтном эксплуатационном предприятии.

Задачи, поставленные в курсовой работе:


— изучение назначения и основных характеристик case средства Designer/2000;

— анализ предметной области для разработки ИС;

— определение целей и задач системы;

— построение моделей данных;

— разработка БД и клиентского приложения;

— закрепление и развитие теоретических знаний по проектированию ИС;

— приобретение практических навыков разработки ИС.

При разработке системы будет применяться структурно-функциональный подход. Для разработки клиентского приложения ИС был выбран язык программирования Borland Delphi 7.0 Enterprise, в связи с имеющимся опытом разработки ИС с помощью данного средства. С помощью Borland Delphi 7.0 Enterprise легко реализуется технология “файл-сервер”, путем прямого доступа к таблицам БД, так и с помощью языка запросов SQL. СУБД выбран MS Access.

1 Теоретическая часть. CASE средство Designer/2000

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

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

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

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

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

Designer/2000 обеспечивает графический интерфейс при разработке различных моделей (диаграмм) предметной области. В процессе построения моделей информация о них заносится в репозиторий. В состав Designer/2000 входят следующие компоненты:

Repository Administrator — средства управления репозиторием (создание и удаление приложений, управление доступом к данным со стороны различных пользователей, экспорт и импорт данных);

Repository Object Navigator — средства доступа к репозиторию, обеспечивающие многооконный объектно-ориентированный интерфейс доступа ко всем элементам репозитория;

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

Systems Modeller — набор средств построения функциональных и информационных моделей проектируемой ИС, включающий средства для построения диаграмм «сущность-связь» (Entity-Relationship Diagrammer), диаграмм функциональных иерархий (Function Hierarchy Diagrammer), диаграмм потоков данных (Data Flow Diagrammer) и средство анализа и модификации связей объектов репозитория различных типов (Matrix Diagrammer);

Systems Designer — набор средств проектирования ИС, включающий средство построения структуры реляционной базы данных (Data Diagrammer), а также средства построения диаграмм, отображающих взаимодействие с данными, иерархию, структуру и логику приложений, реализуемую хранимыми процедурами на языке PL/SQL (Module Data Diagrammer, Module Structure Diagrammer и Module Logic Navigator);

Server Generator — генератор описаний объектов БД ORACLE (таблиц, индексов, ключей, последовательностей и т.д.). Помимо продуктов ORACLE, генерация и реинжиниринг БД может выполняться для СУБД Informix, DB/2, Microsoft SQL Server, Sybase, а также для стандарта ANSI SQL DDL и баз данных, доступ к которым реализуется посредством ODBC;

Forms Generator — генератор приложений. Генерируемые приложения включают в себя различные экранные формы, средства контроля данных, проверки ограничений целостности и автоматические подсказки. Дальнейшая работа с приложением выполняется в среде Developer/2000;

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

Репозиторий Designer/2000 представляет собой хранилище всех проектных данных и может работать в многопользовательском режиме, обеспечивая параллельное обновление информации несколькими разработчиками. В процессе проектирования автоматически поддерживаются перекрестные ссылки между объектами словаря и могут генерироваться более 70 стандартных отчетов о моделируемой предметной области. Физическая среда хранения репозитория — база данных ORACLE.

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

Designer/2000 можно интегрировать с другими средствами, используя открытый интерфейс приложений API (Application Programming Interface). Кроме того, можно использовать средство ORACLE CASE Exchange для экспорта/импорта объектов репозитория с целью обмена информацией с другими CASE-средствами.

Developer/2000 обеспечивает разработку переносимых приложений, работающих в графической среде Windows, Macintosh или Motif. В среде Windows интеграция приложений Developer/2000 с другими средствами реализуется через механизм OLE и управляющие элементы VBX. Взаимодействие приложений с другими СУБД (DB/2, DB2/400, Rdb) реализуется с помощью средств ORACLE Client Adapter для ODBC, ORACLE Open Gateway и API.

Среда функционирования Designer/2000 и Developer/2000 — Windows 3.x, Windows 95, Windows NT.

2 Проектная часть

2.1 Постановка задачи

ИС должна содержать следующую информацию:

  • Сведения обо всем, жилищном фонде, обслуживаемом муниципальным жилищно-ремонтным эксплуатационным предприятием (МЖРЭП). Основные характеристики жилья (адрес, тип дома, тип и площадь крыши, наличие лифта и т.д.)
  • Сведения о жильцах проживающих в жилищном фонде (ответственный квартирообладатель и т.д.)
  • Сведения о видах ремонтных работ (с их стоимостью), которые может осуществлять МРЭП (вид работы, стоимость за единицу и т.д).
  • Сведения о выполненных ремонтах жилищного фонда (Даты проведения, объем работ, общая стоимость, где проводилась и т.д.).
  • Сведения о заявках на ремонт от квартирообладателей с предполагаемой датой их выполнения. (Дата заявки, предполагаемая дата выполнения, кто делал заявку и т.д.).
  • Сведения о невыполненных заявках с указанием причины их невыполнения (заявка, причина отказа и т. д.).

ИС должна обеспечивать:

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

пользователя (только администратора).

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

2.2 Анализ предметной области

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

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

Пользователями разрабатываемой системы будут:

— Администратор (доступны все возможности, предусмотренные в программе)

— Работник (имеет доступ к работе с заявками, назначению работ по заявкам, а также имеет возможность просматривать отчетность)

-Гость (Может подать заявку и просмотреть отчет о выполненных ремонтах жилых объектах )

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

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

Входными документами в разрабатываемой ИС будут являться:

— Паспортные данные жильцов

— Заявление на проведение ремонтных работ

Выходными документами для разрабатываемой ИС будут являться:

— Отчет об отремонтированных жилых объектах

— Отчет об изменении стоимости ремонтных работ за период

— Отчет обо всех своевременно не обеспеченных заявках на текущую дату с указанием причины

2.3 Функциональная модель по стандарту IDEF0

Функциональная модель по стандарту IDEF0 и методологии SADT была разработана с помощью CASE — средства BPwin v. 2.5. Модель разрабатываемой ИС по стандарту IDEF0 представлена в приложении А.

Введение в базы данных

Алексей Федоров, Наталия Елманова

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

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

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

Роль проектирования данных в жизненном цикле информационных систем

Жизненный цикл информационной системы в общем случае начинается в момент принятия решения о ее создании и заканчивается в момент выведения ее из эксплуатации. Основными его этапами (если опустить детали) обычно являются:

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

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

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

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

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

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

Многие современные СУБД содержат визуальные средства (нередко входящие в состав утилит администрирования), позволяющие создать новую схему базы данных или просмотреть уже имеющуюся. Существуют также и утилиты (поставляемые отдельно от СУБД), позволяющие разрабатывать или редактировать метаданные. Однако в последнее время все более популярными становятся CASE-средства (Computer-Aided System Engineering). Существует несколько типов CASE-средств, но для создания баз данных чаще всего используются те из них, что содержат в своем составе инструменты для создания диаграмм «сущность-связь» и проектирования данных.

Ниже мы рассмотрим процесс проектирования данных с помощью подобных инструментов.


Составные части процесса проектирования данных

Процесс проектирования данных можно условно разделить на два этапа: логическое моделирование и физическое проектирование. Результатом первого из них является так называемая логическая (или концептуальная) модель данных, выражаемая обычно диаграммой «сущность-связь» или ER (Entity-Relationship) диаграммой, которая представлена в одной из стандартных нотаций, принятых для отображения подобных диаграмм. Результатом второго этапа является готовая база данных либо DDL-скрипт для ее создания.

Логическое моделирование

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

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

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

Связь с логической точки зрения представляет собой соотношение между сущностями, которое нередко может быть выражено обычными фразами, например: «Клиент размещает заказ» («A customer places an order» — этой фразой вполне можно описать связь, изображенную на рис. 1), где существительными являются названия связанных между собой сущностей.

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

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

Ряд публикаций проводит градацию категорий логических моделей по степени детализации описания сущностей, атрибутов и связей. Модель, обсуждаемая с заказчиком, являющимся обычно экспертом в подлежащей автоматизации предметной области, а не программистом или аналитиком, должна содержать, например, основные сущности и связи, но не обязана иметь их детальную техническую проработку (в частности, описания алгоритмов обработки нарушений ссылочной целостности). В то же время модель, служащая основой технического задания на разработку клиентских приложений, обязана содержать детальное представление структуры данных, ключевых атрибутов, их текстовое описание, а также представлять сущности в нормализованном виде (иногда такая модель называется полной атрибутивной моделью). Иными словами, нормализация модели данных обычно происходит на этапе логического проектирования (подробнее о нормализации рассказано в первой статье данного цикла, опубликованной в КомпьютерПресс № 3’2000).

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

Физическое проектирование данных

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

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

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

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

Как правило, современные средства проектирования данных поддерживают несколько типов СУБД (например, ERwin фирмы Computer Associates поддерживает более 20 различных СУБД). Уровень поддержки той или иной платформы в разных средствах проектирования данных может быть различен. Например, конкретное средство может поддерживать или не поддерживать для данной СУБД такие особенности, как создание хранимых процедур, генерация объектов физической памяти (табличных пространств, сегментов отката и др.), задание местоположения объектов базы данных в физических объектах и т.д. Поэтому, выбирая средство проектирования данных для решения конкретной задачи, стоит поинтересоваться, каковы его возможности с точки зрения поддержки особенностей той или иной платформы — при удачном раскладе можно сэкономить немало времени на «ручное» доведение создаваемой базы данных (или DDL-скрипта для ее генерации) до необходимого состояния. При этом, естественно, чем больше возможностей и платформ поддерживает конкретное средство проектирования данных, тем дороже оно стоит (следует отметить, что CASE-средства вообще относятся к не самым дешевым программным продуктам — цены на них составляют обычно от одной до нескольких десятков тысяч долларов).

Отметим, что физическое проектирование может включать и дополнительную «ручную» работу по доведению базы данных или скрипта для ее генерации до «товарного» вида. Например, нередко в скрипт также включаются SQL-предложения для заполнения некоторых таблиц, данные которых более или менее постоянны, таких, например, как список субъектов Российской Федерации или справочник телефонных кодов различных стран, а также нестандартные триггеры и процедуры.

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

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

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

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

Наиболее популярные средства проектирования данных

Итак, кратко рассмотрим особенности наиболее популярных CASE-средств, применяемых для проектирования данных. Их список приведен в таблице.

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

Designer/2000 (Oracle)

Designer/2000 (предыдущие версии продукта назывались Oracle*CASE) представляет собой универсальное CASE-средство, позволяющее моделировать бизнес-процессы, создавать диаграммы потоков данных и функциональные модели. Средство проектирования данных и создания ER-диаграмм является лишь одной из составных частей этого довольно сложного продукта и предоставляет возможность сохранять созданные модели данных и описанные бизнес-правила в предназначенном для этого репозитарии.

Designer/2000, предназначенный для использования главным образом с Oracle 8, поддерживает все особенности данной СУБД, включая объектные типы данных (CLOB, Arrays, вложенные таблицы и др.), равно как и специфические особенности физической реализации базы данных Oracle. Для Oracle 7 и Oracle 8 это CASE-средство позволяет создать определения ролей, сгенерировать триггеры, реализующие бизнес-логику, которая описана в моделях, используемых при генерации базы данных, а также cгенерировать объекты для распределенных базы данных. Кроме того, с помощью Designer/2000 можно создавать физические модели и осуществлять обратное проектирование и для других СУБД — Oracle RDB, DB2, Microsoft SQL Server, Sybase, ODBC-источников данных, а также осуществлять обратное проектирование на основании DDL-сценариев, если они соответствуют стандарту ANSI SQL.

Весьма привлекательной особенностью Designer/2000 является возможность генерации форм Oracle Developer/2000, проектов Visual Basic, классов C++, отчетов Oracle Reports, приложений для Oracle Web Application Server.

Дополнительная информация доступна на Web-сайте по адресу: http://www.oracle.com/tools/designer/.

ERwin (Computer Associates)

ERwin разработан компанией Logic Works, которая в 1988 году была приобретена фирмой Platinum Technologies, а ее, в свою очередь, приобрела компания Computer Associates. Этот продукт в течение последних десяти лет занимает лидирующие позиции среди средств проектирования данных.

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

ERwin не ориентирован на какую-то конкретную СУБД и поддерживает более 20 типов СУБД, включая СУБД всех ведущих производителей серверов баз данных (Oracle, Sybase, Microsoft, IBM, Informix), а также все популярные форматы настольных СУБД (включая dBase, Clipper, FoxPro, Access, Paradox), кроме, возможно, самых последних версий. Дело в том, что новые версии ERwin не выпускались уже довольно давно — как минимум год не было обновлений имеющейся версии и более двух лет не выпускались новые версии этого продукта. Поэтому при использовании ERwin с последними версиями некоторых СУБД могут возникнуть проблемы (например, некоторые типы данных SQL Server 7.0 это CASE-средство поддерживает не совсем корректно). Тем не менее ERwin остается одним из самых популярных в мире продуктов этого класса благодаря поддержке большого количества платформ, простоте интерфейса и, что немаловажно, поддержке специфических особенностей организации физической памяти наиболее популярных серверных СУБД. Например, для СУБД Oracle, Microsoft SQL Server, Sybase этот продукт позволяет изменять местоположение и параметры хранения индексов, почти для всех популярных серверных СУБД создавать кластеризованные индексы 2 и для многих из них — указывать характеристики табличных пространств и сегментов отката.

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

ERwin поддерживает обмен моделями с репозитарием Designer/2000 и Microsoft Repository, а также генерацию клиентских приложений для Visual Basic и PowerBuilder.

Помимо однопользовательской работы ERwin может выступать в роли клиентского приложения для другого CASE-средства — ModelMart, которое позволяет организовать коллективную разработку моделей данных, предоставляя для этой цели разделяемый репозитарий, хранящийся в одной из серверных СУБД.

Недавно компанией Computer Associates был выпущен новый продукт — ERwin Examiner, представляющий собой инструмент проверки баз данных и DDL-скриптов с целью выявления ошибок проектирования данных, сказывающихся на целостности данных и производительности сервера, таких, например, как ошибки нормализации, противоречивые ключи и т.д. В результате проверки ERwin Examiner предлагает способы устранения найденных ошибок, генерируя соответствующие DDL-скрипты. На нашем CD-ROM вы можете найти статью Сергея Маклакова, посвященную этому продукту. Ознакомительные версии ERwin, ModelMart и ERwin Examiner вы также можете найти на нашем CD-ROM.

Дополнительная информация доступна на Web-сайте по адресу: http://www.cai.com/products/alm/erwin.htm.

PowerDesigner (Sybase)

PowerDesigner (бывший S-Designor, принадлежавший компании PowerSoft) представляет собой инструмент, в состав которого входят средство создания концептуальных (то есть логических) моделей, средство создания физических моделей и средство объектно-ориентированного моделирования, используемое при генерации клиентских приложений. Средство создания физических моделей представляет собой отдельный продукт — PowerDesigner PhysicalArchitect. В состав продукта PowerDesigner DataArchitect входят средства создания концептуальных и физических моделей, в состав PowerDesigner Developer — средства объектно-ориентированного моделирования и создания физических моделей, а в состав PowerDesigner ObjectArchitect — все три средства.

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

Помимо серверных СУБД производства Sybase (Adaptive Server Enterprise 12.0, Sybase SQL Anywhere) PowerDesigner DataArchitect способен работать с любыми ODBC-источниками. Как и ERwin, он поддерживает генерацию триггеров серверных СУБД, осуществляющих стандартную обработку событий, связанных с нарушениями ссылочной целостности.

PowerDesigner Developer и PowerDesigner ObjectArchitect могут генерировать код клиентских приложений для PowerBuilder, а также классы Java и компоненты JavaBeans. Возможно и обратное проектирование диаграмм классов из исходных текстов Java, байт-кодов и архивов Java. Поддерживается также генерация кода Web-приложений и объектов для Sybase Enterprise Application Server на основе физической модели.

PowerDesigner DataArchitect может импортировать логические и физические модели ERwin.

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

Отметим, что PowerDesigner DataArchitect весьма популярен на российском рынке, причем не только среди пользователей СУБД и средств разработки Sybase.

Ознакомительную версию PowerDesigner DataArchitect вы сможете найти на нашем CD-ROM.

ER/Studio (Embarcadero Technologies)

ER/Studio менее известен в нашей стране, чем ERwin и PowerDesigner DataArchitect. Однако возможности этого продукта также заслуживают внимания.

По своему назначению этот продукт сходен с ERwin — он представляет собой специализированное средство проектирования данных и не содержит в своем составе инструментов для объектно-ориентированного моделирования или моделирования бизнес-процессов. Список поддерживаемых СУБД у этого продукта достаточно широк и включает все наиболее популярные серверные и настольные СУБД. В отличие от ERwin последняя версия этого продукта корректно поддерживает новые типы данных SQL Server 7.

ER/Studio поддерживает написание макросов на SAX Basic (клон Visual Basic for Applications). Этот язык позволяет создавать макросы для выполнения однотипных операций, например добавления стандартных полей к вновь создаваемым сущностям. С помощью этого же языка можно генерировать стандартные триггеры и хранимые процедуры для вставки, удаления, изменения записей. Код на этом языке можно даже отлаживать и обращаться к свойствам сущностей для конструирования серверного кода. Однако, в отличие от ERwin, ER/Studio не позволяет добавить к каждой таблице свои шаблоны триггеров или просмотреть код конкретного триггера в процессе разработки модели — чтобы получить код одного триггера, нужно сгенерировать скрипт для всей модели.

Модели ER/Studio можно сохранить не только в виде DDL-скрипта, но и в формате XML. Можно также создать репозитарий для их хранения в любой серверной СУБД. ER/Studio может импортировать модели ERwin, но при импорте теряются связи шаблонов серверного кода с конкретными таблицами, и не все макросы ERwin корректно преобразуются в макросы SAX Basic.

ER/Studio позволяет сгенерировать Java-классы для клиентских приложений.

Отметим, что ER/Studio является COM-сервером, что позволяет использовать его в других приложениях, предоставляя им возможность просмотра и редактирования моделей данных, а также создавать другие решения на его основе.

Ознакомительную версию ER/Studio вы сможете найти на нашем CD-ROM.

System Architect (Popkin Software)

System Architect 2001 представляет собой универсальное CASE-средство, позволяющее осуществить не только проектирование данных, но и структурное моделирование. Средство проектирования данных и создания ER-диаграмм является одной из составных частей этого продукта.

Этот продукт поддерживает СУБД практически всех ведущих производителей, включая Oracle (Oracle 8), Sybase, DB2, SQL Server, IBM (AS400, DB2), Informix, Sybase, Access, dBASE, Paradox и др.

В процессе логического моделирования можно проверить модель на соответствие правилам проектирования данных (например, на соответствие ее первой, второй или третьей нормальным формам). При генерации DDL-скрипта можно сгенерировать триггеры (в том числе и нестандартные).

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

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

System Architect обладает встроенным Visual Basic for Application, что позволяет создавать разнообразные решения на базе этого продукта, включая автоматическую генерацию моделей и проектной документации.

System Architect 2001 позволяет генерировать код клиентских приложений для Visual Basic, Delphi и PowerBuilder (на сегодняшний день это практически единственное CASE-средство, поддерживающее генерацию кода Delphi), классы C++, а также код и текстовые экранные формы COBOL.

Ознакомительную версию System Architect вы сможете найти на нашем CD-ROM.

Дополнительная информация доступна на Web-сайте по адресу: http://www.popkin.com/products/sa2001/data/data.htm.

Visible Analyst (Visible Systems Corporation)

Visible Analyst — весьма популярный продукт компании Visible Systems Corporation. Широко известны также ранее производимые этой компанией CASE-средства EasyER и EasyCASE — предшественники Visible Analyst.

Этот продукт выпускается в трех редакциях: Visible Analyst DB Engineer, который включает средства проектирования данных, Visible Analyst Standard, который кроме проектирования данных позволяет осуществлять структурное моделирование, и Visible Analyst Corporate, который помимо указанных выше возможностей позволяет осуществлять также объектно-ориентированное моделирование.

Visible Analyst поддерживает довольно широкий спектр СУБД с точки зрения генерации серверного кода, включая Oracle 7, Sybase SQL Server (System 10 и 4.x); Informix, DB2, Ingres. Последние версии многих серверных СУБД (Oracle 8, Microsoft SQL Server 6.5/7/2000, последние версии серверов Sybase) в этом списке пока отсутствуют.

Для Informix и DB2 указанный продукт позволяет генерировать DDL-скрипты, учитывающие специфические особенности организации физической памяти наиболее популярных серверных СУБД, такие как управление табличным пространством, размером экстентов, режимами блокировки данных, степенью заполнения данными (fill factor), а также создавать кластеризованные индексы и генерировать триггеры для выполнения стандартных операций. Из этих же СУБД можно производить непосредственно обратное проектирование. Помимо этих двух СУБД обратное проектирование можно производить также из DDL-скриптов, сгенерированных для других СУБД, а также на основе кода COBOL.

Модели Visible Analyst можно сохранять в многопользовательском репозитарии, созданном в одной из серверных СУБД.

Кроме того, Visible Analyst позволяет на оcнове созданных моделей генерировать код для Visual Basic, С++ и COBOL.


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

Демонстрационную версию Visible Analyst вы сможете найти на нашем CD-ROM.

Дополнительная информация доступна на Web-сайте по адресу: http://www.visible.com/dataapp/daprods.html.

Visio Enterprise (Microsoft)

Продукт под названием Visio, приобретенный в январе 2000 года корпорацией Microsoft вместе с его разработчиком — компанией Visio Corporation, позиционировался на рынке как одно из самых популярных средств создания схем и диаграмм. То, что один из членов семейства Microsoft Visio 2000 — Visio 2000 Enterprise — содержит в своем составе полноценное CASE-средство, было в определенной степени сюрпризом для пользователей CASE-инструментов. Однако, если вдуматься, появление своих средств проектирования данных, моделирования бизнес-процессов и объектно-ориентированного моделирования у Microsoft — шаг вполне закономерный, поскольку такие средства появляются рано или поздно у большинства производителей популярных серверных СУБД и средств разработки, каковым Microsoft является уже довольно давно.

Как и подавляющее большинство средств проектирования данных, Visio Enterprise позволяет производить прямое и обратное проектирование данных, преобразовывать логическую модель в физическую. Этим средством поддерживаются все ODBC- и OLE DB-источники данных. С его помощью можно создавать триггеры для стандартной обработки нарушений ссылочной целостности в случае, если DDL-скрипт создается для Microsoft SQL Server, и серверные ограничения, если скрипт создается для другой СУБД. Отметим, что Visio при генерации скриптов позволяет указывать параметры организации физической памяти Oracle, Informix, Microsoft SQL Server, DB2 и некоторых других СУБД.

Отметим, что помимо средств проектирования данных Visio включает средства объектно-ориентированного моделирования и генерации кода приложений Visual Basic 6, а также классов C++ и Java. Модели Visio можно сохранять в Microsoft Repository.

Visio, в отличие от специализированных средств проектирования данных, не обладает скриптовым языком, позволяющим создавать серверный код, не связанный с конкретной СУБД. При использовании этого продукта такой код нужно создавать на этапе физического проектирования в уже созданном скрипте. Однако справедливости ради заметим, что и стоимость Visio Enterprise по сравнению с ERwin или PowerDesigner DataArchitect невысока, тем более что Visio в целом представляет собой продукт более широкого назначения, нежели другие рассмотренные выше средства проектирования данных. К тому же этот продукт является сервером автоматизации, обладает весьма обширной объектной моделью и встроенным средством разработки — Visual Basic for Applications, что позволяет, в частности, создавать на его базе разнообразные решения, в том числе и автоматизировать разработку моделей данных.

Подробности о Visio и его использовании вы сможете найти в статье Алексея Федорова «Знакомство с Microsoft Visio 2000», опубликованной в ноябрьском номере нашего журнала.

Дополнительная информация доступна на Web-сайте по адресу: http://www.microsoft.com/office/visio/.

Заключение

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

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

  1. Поддержка создания логических моделей, не зависящих от СУБД, и генерации физических моделей на их основе.
  2. Поддержка нескольких типов СУБД, включая не только серверные, но и настольные.
  3. Поддержка специфических особенностей тех или иных СУБД ведущих производителей (генерация триггеров, управление физическим хранением данных).
  4. Способность осуществлять обратное проектирование на основе либо имеющейся базы данных, либо имеющегося DDL-скрипта.
  5. Возможность генерации отчетов и проектной документации на основе созданной модели.
  6. Возможность сохранения модели в репозитарии, который во многих случаях может быть разделяемым.
  7. Поддержка генерации кода для одного или нескольких средств разработки или языков программирования. Следует отметить, что в этом отношении самым популярным средством разработки является, по-видимому, Visual Basic.

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

Реферат: Примеры комплексов CASE-средств

Ярославский филиал Московского государственного университета

экономики, статистики и информатики

на тему: Примеры комплексов CASE- средств

Студента 4-го курса, группы МЭ-45

Захарикова Павла Алексеевича

2. Общие черты CASE-средств

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

5. Список использованной литературы

В данной работе я попытался привести примеры комплексов программно-технологических средств специального класса — CASE-средств, реализующих CASE-технологию создания и сопровождения ИС. Термин CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.

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

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

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

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

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

Общие черты CASE-средств

Согласно обзору передовых технологий (Survey of Advanced Technology), составленному фирмой Systems Development Inc. в 1996 г. по результатам анкетирования более 1000 американских фирм, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся «полочным» ПО (shelfware). В связи с этим необходимо отметить следующее:

· CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;

· реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

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

· широкое разнообразие качества и возможностей CASE-средств;

· относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;

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

· отсутствие детальных метрик и данных для уже выполненных и текущих проектов;

· широкий диапазон предметных областей проектов;

· различная степень интеграции CASE-средств в различных проектах.

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

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

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

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

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

· мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;

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

· использование специальным образом организованного хранилища проектных метаданных (репозитория).

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты;

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

· графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

· средства разработки приложений, включая языки 4GL и генераторы кодов;

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

· средства управления проектом;

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:

· применяемым методологиям и моделям систем и БД;

· степени интегрированности с СУБД;

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

· средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

· средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

· средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. Книмотносятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

· средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично — в Silverrun;

· средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Вспомогательные типы включают:

· средства планирования и управления проектом (SE Companion, Microsoft Project и др.);

· средства конфигурационного управления (PVCS (Intersolv));

· средстватестирования (Quality Works (Segue Software));

· средства документирования (SoDA (Rational Software)).

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:

· Vantage Team Builder (Westmount I-CASE);


Кроме того, на рынке постоянно появляются как новые для отечественных пользователей системы (например, CASE /4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE), так и новые версии и модификации перечисленных систем.

Silverrun

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

Настройка на конкретную методологию обеспечивается выбором требуемой графической нотации моделей и набора правил проверки проектных спецификаций. В системе имеются готовые настройки для наиболее распространенных методологий: 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 Мб.

Средство разработки приложений JAM (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 является более предпочтительным по сравнению с SCCS, так как позволяет организовать единый архив модулей проекта для всех платформ. Так как JAM на платформе UNIX не имеет прямого интерфейса к архивам PVCS, то выборка модулей из архива и возврат их в архив производятся с использованием PVCS Version Manager. На платформе MS-Windows JAM имеет встроенный интерфейс к PVCS и действия по выборке/возврату производятся непосредственно из среды JAM.

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

Designer/2000 + Developer/2000

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

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

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

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

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


Designer/2000 обеспечивает графический интерфейс при разработке различных моделей (диаграмм) предметной области. В процессе построения моделей информация о них заносится в репозиторий. В состав Designer/2000 входят следующие компоненты:

· Repository Administrator — средства управления репозиторием (создание и удаление приложений, управление доступом к данным со стороны различных пользователей, экспорт и импорт данных);

· Repository Object Navigator — средства доступа к репозиторию, обеспечивающие многооконный объектно-ориентированный интерфейс доступа ко всем элементам репозитория;

· Process Modeller — средство анализа и моделирования деловой деятельности, основывающееся на концепциях реинжиниринга бизнес-процессов (BPR — Business Process Reengineering) и глобальной системы управления качеством (TQM — Total Quality Management);

· Systems Modeller — набор средств построения функциональных и информационных моделей проектируемой ИС, включающий средства для построения диаграмм «сущность-связь» (Entity-Relationship Diagrammer), диаграмм функциональных иерархий (Function Hierarchy Diagrammer), диаграмм потоков данных (Data Flow Diagrammer) и средство анализа и модификации связей объектов репозитория различных типов (Matrix Diagrammer);

· Systems Designer — набор средств проектирования ИС, включающий средство построения структуры реляционной базы данных (Data Diagrammer), а также средства построения диаграмм, отображающих взаимодействие с данными, иерархию, структуру и логику приложений, реализуемую хранимыми процедурами на языке PL/SQL (Module Data Diagrammer, Module Structure Diagrammer и Module Logic Navigator);

· Server Generator — генератор описаний объектов БД ORACLE (таблиц, индексов, ключей, последовательностей и т.д.). Помимо продуктов ORACLE, генерация и реинжиниринг БД может выполняться для СУБД Informix, DB/2, Microsoft SQL Server, Sybase, а также для стандарта ANSI SQL DDL и баз данных, доступ к которым реализуется посредством ODBC;

· Forms Generator (генератор приложений для ORACLE Forms). Генерируемые приложения включают в себя различные экранные формы, средства контроля данных, проверки ограничений целостности и автоматические подсказки. Дальнейшая работа с приложением выполняется в среде Developer/2000;

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

Репозиторий Designer/2000 представляет собой хранилище всех проектных данных и может работать в многопользовательском режиме, обеспечивая параллельное обновление информации несколькими разработчиками. В процессе проектирования автоматически поддерживаются перекрестные ссылки между объектами словаря и могут генерироваться более 70 стандартных отчетов о моделируемой предметной области. Физическая среда хранения репозитория — база данных ORACLE.

Генерация приложений, помимо продуктов ORACLE, выполняется также для Visual Basic.

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

Designer/2000 можно интегрировать с другими средствами, используя открытый интерфейс приложений API (Application Programming Interface). Кроме того, можно использовать средство ORACLE CASE Exchange для экспорта/импорта объектов репозитория с целью обмена информацией с другими CASE-средствами.

Developer/2000 обеспечивает разработку переносимых приложений, работающих в графической среде Windows, Macintosh или Motif. В среде Windows интеграция приложений Developer/2000 с другими средствами реализуется через механизм OLE и управляющие элементы VBX. Взаимодействие приложений с другими СУБД (DB/2, DB2/400, Rdb) реализуется с помощью средств ORACLE Client Adapter для ODBC, ORACLE Open Gateway и API.

Среда функционирования Designer/2000 и Developer/2000 — Windows 3.x, Windows 95, Windows NT.

Локальные средства (ERwin, BPwin, S-Designor, CASE.Аналитик)

ERwin — средство концептуального моделирования БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжиниринг существующей БД. ERwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Версия ERwin/OPEN полностью совместима со средствами разработки приложений PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной БД непосредственно в репозитории данных средств.

Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений.

Сетевая версия Erwin ModelMart обеспечивает согласованное проектирование БД и приложений в рамках рабочей группы.

BPwin — средство функционального моделирования, реализующее методологию IDEF0

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

Название: Примеры комплексов CASE-средств
Раздел: Рефераты по кибернетике
Тип: реферат Добавлен 07:39:10 08 августа 2005 Похожие работы
Просмотров: 4735 Комментариев: 15 Оценило: 27 человек Средний балл: 2.4 Оценка: 2 Скачать
Конфигурация Стоимость, $
ERwin/ERX 3,295
Bpwin 2,495
ERwin/ERX for PowerBuilder, Visual Basic, Progress 3,495
ERwin/ERX for Delphi 4,295
ERwin/Desktop for PowerBuilder, Visual Basic 495
ERwin/ERX for SQLWindows / Designer/2000 / Solaris 3,495 / 5,795 / 6,995
ModelMart 5 / 10 user 11,995 / 19,995
Erwin/OPEN for ModelMart 3,995

S-Designor 4.2 представляет собой CASE-средство для проектирования реляционных баз данных. По своим функциональным возможностям и стоимости он близок к CASE-средству ERwin, отличаясь внешне используемой на диаграммах нотацией. S-Designor реализует стандартную методологию моделирования данных и генерирует описание БД для таких СУБД, как ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server и др. Для существующих систем выполняется реинжиниринг БД.

S-Designor совместим с рядом средств разработки приложений (PowerBuilder, Uniface, TeamWindows и др.) и позволяет экспортировать описание БД в репозитории данных средств. Для PowerBuilder выполняется также прямая генерация шаблонов приложений.

CASE.Аналитик 1.1 является практически единственным в настоящее время конкурентоспособным отечественным CASE-средством функционального моделирования и реализует построение диаграмм потоков данных. Его основные функции:

· построение и редактирование DFD;

· анализ диаграмм и проектных спецификаций на полноту и непротиворечивость;

· получение разнообразных отчетов по проекту;

· генерация макетов документов в соответствии с требованиями ГОСТ 19.ХХХ и 34.ХХХ.

Среда функционирования: процессор — 386 и выше, основная память — 4 Мб, дисковая память — 5 Мб, MS Windows 3.x или Windows 95.

· однопользовательская версия — 605 $;

· многопользовательская версия (одно рабочее место) — 535 $.

База данных проекта реализована в формате СУБД Paradox и является открытой для доступа.

С помощью отдельного программного продукта (Catherine) выполняется обмен данными с CASE-средством ERwin. При этом из проекта, выполненного в CASE.Аналитике, экспортируется описание структур данных и накопителей данных, которое по определенным правилам формирует описание сущностей и их атрибутов.

Объектно-ориентированные CASE-средства (Rational Rose)

Rational Rose — CASE-средство фирмы Rational Software Corporation (США) — предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML — Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант — Rational Rose/C++ — позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

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

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

В составе Rational Rose можно выделить 6 основных структурных компонент: репозиторий, графический интерфейс пользователя, средства просмотра проекта (browser), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для С++, обеспечивающий реинжиниринг — восстановление модели проекта по исходным текстам программ.

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

Средства автоматической генерации кодов программ на языке С++, используя информацию, содержащуюся в логической и физической моделях проекта, формируют файлы заголовков и файлы описаний классов и объектов. Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на языке С++. Анализатор кодов С++ реализован в виде отдельного программного модуля. Его назначение состоит в том, чтобы создавать модули проектов в форме Rational Rose на основе информации, содержащейся в определяемых пользователем исходных текстах на С++. В процессе работы анализатор осуществляет контроль правильности исходных текстов и диагностику ошибок. Модель, полученная в результате его работы, может целиком или фрагментарно использоваться в различных проектах. Анализатор обладает широкими возможностями настройки по входу и выходу. Например, можно определить типы исходных файлов, базовый компилятор, задать, какая информация должна быть включена в формируемую модель и какие элементы выходной модели следует выводить на экран. Таким образом, Rational Rose/С++ обеспечивает возможность повторного использования программных компонент.

В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

· спецификации классов, объектов, атрибутов и операций

· заготовки текстов программ;

· модель разрабатываемой программной системы.

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

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

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

Rational Rose интегрируется со средством PVCS для организации групповой работы и управления проектом и со средством SoDA — для документирования проектов. Интеграция Rational Rose и SoDA обеспечивается средствами SoDA.

Для организации групповой работы в Rational Rose возможно разбиение модели на управляемые подмодели. Каждая из них независимо сохраняется на диске или загружается в модель. В качестве подмодели может выступать категория классов или подсистема.

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

· загрузка подмодели в память;

· выгрузка подмодели из памяти;

· сохранение подмодели на диске в виде отдельного файла;

· установка защиты от модификации;

· замена подмодели в памяти на новую.

Наиболее эффективно групповая работа организуется при интеграции Rational Rose со специальными средствами управления конфигурацией и контроля версий (PVCS). В этом случае защита от модификации устанавливается на все управляемые подмодели, кроме тех, которые выделены конкретному разработчику. В этом случае признак защиты от записи устанавливается для файлов, которые содержат подмодели, поэтому при считывании «чужих» подмоделей защита их от модификации сохраняется и случайные воздействия окажутся невозможными.

Rational Rose функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX).

Для работы системы необходимо выполнение следующих требований:

· Платформа Windows — процессор 80386SX или выше (рекомендуется 80486), память8Mб (рекомендуется 12Mб), пространство на диске 8Mб + 1-3Mб для одной модели.

· Платформа UNIX — память 32+(16*число пользователей)Mб, пространство на диске 30Mб + 20 при инсталляции + 1-3Mб для одной модели.

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

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

· средство разработки приложений JAM;

· мост Silverrun-RDM JAM;

· комплекс средств тестирования QA;

· менеджер транзакций Tuxedo;

· комплекс средств планирования и управления проектом SE Companion;

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

· объектно-ориентированное CASE-средство Rational Rose;

· средство документирования SoDA.

Примерами других подобных комплексов являются:

· Vantage Team Builder for Uniface + Uniface (фирмы «DataX/Florin» и «ЛАНИТ»);

· комплекс средств, поставляемых и используемых фирмой «ФОРС»:


· CASE-средства Designer/2000 (основное), ERwin, Bpwin и Oowin (альтернатив-
ные);

· средства разработки приложений Developer/2000, ORACLE Power Objects (ос-
новные) и Usoft Developer (альтернативное);

· средство настройки и оптимизации ExplainSQL (Platinum);

· cредства администрирования и сопровождения SQLWatch, DBVision, SQL Spy, TSReorg и др. (Platinum);

· средство документирования ORACLE Book.

· комплекс средств на основе продуктов фирмы CENTURA:

· CASE-средства ERwin, Bpwin и Oowin (объектно-ориентированный анализ);

· средства разработки приложений SQLWindows и TeamWindows;

· средство тестирования и оптимизации приложений «клиент-сервер» SQLBench (ARC);

· cредства эксплуатации и сопровождения Quest и Crystal Reports.

Список использованной литературы

1. Вендров А.М. Один из подходов к выбору средств проектирования баз данных и приложений. «СУБД», 1995, №3.

2. Зиндер Е.З. Бизнес-реинжиниринг и технологии системного проектирования. Учебное пособие. М., Центр Информационных Технологий, 1996

3. Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). М., «Лори», 1996.

4. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. М., «МетаТехнология», 1995.

5. Международные стандарты, поддерживающие жизненный цикл программных средств. М., МП «Экономика», 1996

6. Создание информационной системы предприятия. «Computer Direct», 1996, N2

7. Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование мира в состояниях. Киев, «Диалектика», 1993.

8. Новоженов Ю.В. Объектно-ориентированные технологии разработки сложных программных систем. М., 1996.

9. Панащук С.А. Разработка информационных систем с использованием CASE-системы Silverrun. «СУБД», 1995, №3.

10. Горчинская О.Ю. Designer/2000 — новое поколение CASE-продуктов фирмы ORACLE. «СУБД», 1995, №3.

11. Горин С.В., Тандоев А.Ю. Применение CASE-средства Erwin 2.0 для информационного моделирования в системах обработки данных. «СУБД», 1995, №3.

12. Горин С.В., Тандоев А.Ю. CASE-средство S-Designor 4.2 для разработки структуры базы данных. «СУБД», 1996, №1.

13. Петров Ю.К. JAM — инструментальное средство разработки приложений в информационных системах архитектуры «клиент/сервер», построенных на базе РСУБД. «СУБД», 1995, №3.

Case средства designer/2000 developer/20005 3 designer/2000 developer/2000

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

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

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

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

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

Designer/2000 обеспечивает графический интерфейс при разработке различных моделей (диаграмм) предметной области. В процессе построения моделей информация о них заносится в репозиторий. В состав Designer/2000 входят следующие компоненты:

  • Repository Administrator — средства управления репозиторием (создание и удаление приложений, управление доступом к данным со стороны различных пользователей, экспорт и импорт данных);
  • Repository Object Navigator — средства доступа к репозиторию, обеспечивающие многооконный объектно-ориентированный интерфейс доступа ко всем элементам репозитория;
  • Process Modeller — средство анализа и моделирования деловой деятельности, основывающееся на концепциях реинжиниринга бизнес-процессов (BPR — Business Process Reengineering) и глобальной системы управления качеством (TQM — Total Quality Management);
  • Systems Modeller — набор средств построения функциональных и информационных моделей проектируемой ИС, включающий средства для построения диаграмм «сущность-связь» (Entity-Relationship Diagrammer), диаграмм функциональных иерархий (Function Hierarchy Diagrammer), диаграмм потоков данных (Data Flow Diagrammer) и средство анализа и модификации связей объектов репозитория различных типов (Matrix Diagrammer);
  • Systems Designer — набор средств проектирования ИС, включающий средство построения структуры реляционной базы данных (Data Diagrammer), а также средства построения диаграмм, отображающих взаимодействие с данными, иерархию, структуру и логику приложений, реализуемую хранимыми процедурами на языке PL/SQL (Module Data Diagrammer, Module Structure Diagrammer и Module Logic Navigator);
  • Server Generator — генератор описаний объектов БД ORACLE (таблиц, индексов, ключей, последовательностей и т.д.). Помимо продуктов ORACLE, генерация и реинжиниринг БД может выполняться для СУБД Informix, DB/2, Microsoft SQL Server, Sybase, а также для стандарта ANSI SQL DDL и баз данных, доступ к которым реализуется посредством ODBC;
  • Forms Generator (генератор приложений для ORACLE Forms). Генерируемые приложения включают в себя различные экранные формы, средства контроля данных, проверки ограничений целостности и автоматические подсказки. Дальнейшая работа с приложением выполняется в среде Developer/2000;
  • Repository Reports — генератор стандартных отчетов, интегрированный с ORACLE Reports и позволяющий русифицировать отчеты, а также изменять структурное представление информации.

Репозиторий Designer/2000 представляет собой хранилище всех проектных данных и может работать в многопользовательском режиме, обеспечивая параллельное обновление информации несколькими разработчиками. В процессе проектирования автоматически поддерживаются перекрестные ссылки между объектами словаря и могут генерироваться более 70 стандартных отчетов о моделируемой предметной области. Физическая среда хранения репозитория — база данных ORACLE.

Генерация приложений, помимо продуктов ORACLE, выполняется также для Visual Basic.

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

Designer/2000 можно интегрировать с другими средствами, используя открытый интерфейс приложений API (Application Programming Interface). Кроме того, можно использовать средство ORACLE CASE Exchange для экспорта/импорта объектов репозитория с целью обмена информацией с другими CASE-средствами.

Developer/2000 обеспечивает разработку переносимых приложений, работающих в графической среде Windows, Macintosh или Motif. В среде Windows интеграция приложений Developer/2000 с другими средствами реализуется через механизм OLE и управляющие элементы VBX. Взаимодействие приложений с другими СУБД (DB/2, DB2/400, Rdb) реализуется с помощью средств ORACLE Client Adapter для ODBC, ORACLE Open Gateway и API.

Среда функционирования Designer/2000 и Developer/2000 — Windows 3.x, Windows 95, Windows NT.

Средства разработки Oracle как инструменты инженерного подхода в создании промышленного программного обеспечения

Средства разработки Oracle как инструменты инженерного подхода в создании промышленного программного обеспечения

Л. Сорокин, Oracle

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

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

    Designer/2000 — Средство описания разрабатываемой системы в виде всеохватывающей модели и генерации на ее основе законченных приложений для различных средств разработки.

Developer/2000 — Многоплатформленное и масштабируемое средство визуального создания промышленных приложений, легко настраиваемых в зависимости от мощности сервера и клиентских компьютеров и переносимых на работу в среду Internet/Intranet.

  • Power Objects — Инструмент для разработки приложений небольшого масштаба, способного работать с разнообразными источниками данных.
  • Programmer/2000 — Набор предкомпиляторов

    для C/C+, заметно упрощающих создание приложений на C/C+ для сервера Oracle7.

  • Mobile Agents — Позволяет разрабатывать приложения для мобильных пользователей или для удаленных систем, работающих через плохие, неустойчивые каналы связи.
  • Необходимо отметить, что в отличие от «универсальных» средств разработок, ориентированных на работу с любыми СУБД (Delphi, Visual Basic, PowerBuilder), «родные» инструменты полностью используют все возможности сервера Oracle7. А именно, поддержка последовательностей и синонимов, работа с механизмом обеспечения секретности на сервере, доступ к хранимым на сервере процедурам и переменным, управление оптимизатором выполнения SQL-команд — использование этих возможностей либо невозможно в универсальных средствах разработок, либо требует большого труда при кодировании.

    На этапе предварительного обследования деятельности предприятия (той деятельности, которую необходимо автоматизировать) используется компонента Designer/2000 — средство построения диаграмм деловых процессов BPR (Business Process Modeler). С его помощь возможно не только построить модель всех процессов, протекающих в ходе повседневной деятельности организации (предприятия), но и произвести ряд анализов, способных выявить узкие места. Даже без последующего создания приложения, такая модель позволяет лучше понять как протекает деятельность организации и найти пути по ее улучшению.

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

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

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

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

    Генерация для клиентской части возможно для целого ряда различных средств разработок. Сейчас поддерживаются :

    1. Oracle Developer/2000
    2. Oracle Power Objects
    3. Oracle WebServer
    4. MS Visual Basic 3.0 и 4.0
    5. Классы C/C+

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

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

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

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

    Другой иллюстрацией подхода корпорации Oracle к обеспечению создания независимых от платформы приложений является Developer/2000. Это инструментарий визуального проектирования клиентских приложений для технологии Клиент-сервер. Developer/2000 полностью переносим на все используемые ныне платформы, начиная от символьных терминалов и кончая графическими средами вроде Windows или Motif. Если при разработке не использовались платформенно зависимые особенности (например компоненты OCX/ActivX для Windows), то перенос приложения на другую платформу не требует никакого кодирования! Рост популярности приложений для Internet/Intranet вызвал необходимость для разработчиков изучения как новых технологий, так и новых сред разработки для Web. Перенос приложения в среду Internet/Intranet означал практически полностью его переписывание на новом средстве разработки. Поэтому многие фирмы-производители инструментальных средств поддержали технологию Netscape Plug-In, которая позволяла определенным способом распространять и вызывать приложения через Web, не сильно их переделывая. Но на самом деле, это только временное решение, т.к. для выполнения приложения необходимо держать на клиентском компьютере полностью Run-Time среду, а само приложение целиком закачивается с Web-сервера.

    Применение Developer/2000 позволяет перенести прикладную систему в среду Internet/Intranet более элегантным способом. Существует возможность разместить Run-Time среду Developer/2000 на Web-сервере, а откомпилированное приложение передается ей безо всякой модификации. Специальный кэтридж Web Developer’а формирует на лету Java Applets, которые передаются на клиентский компьютер в любую программу просмотра Web. Пользователь видит перед собой тот же пользовательский интерфейс, как если бы приложение выполнялось на его компьютере, а работать может даже на DOS-компьютере с 640 КБ памяти!

    Таким образом, наряду с мощными возможностями по созданию полнофункциональных клиентских приложений с богатым пользовательским интерфейсом, Developer/2000 позволяет легко переносить созданные системы на любые существующие ныне платформы и использовать самые передовые технологии не переписывая ни строчки кода!

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

    • Соответствующая международным стандартам техническая поддержка продуктов Oracle, функционирующая на территории СНГ.
    • Возможность ознакомления с пробными (trial) версиями продуктов Oracle, прежде чем принять решения об их закупке и затем возможность предварительного ознакомления с новыми версиями продуктов.
    • Два периодических русскоязычных журнала («Мир Oracle» и «Oracle Magazine — Русское издание»), посвященных продуктам Oracle, содержащих большое число статей для разработчиков.
    • Действующие группы пользователей Oracle, периодические семинары.
    • Большой выбор учебных курсов по продуктам Oracle, как и в представительстве корпорации Oracle в СНГ, так и у его партнеров.


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

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

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

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

    Вид материала Обзор
    Редактор меню
    Взаимодействие с другими средствами
    Интерфейс JAM/CASE
    Групповая работа
    Среда функционирования
    5.2. Vantage Team Builder (Westmount I-CASE) + Uniface 5.2.1. Vantage Team Builder (Westmount I-CASE)
    Тип диаграммы
    Взаимодействие с другими средствами
    Среда функционирования
    5.3. Designer/2000 + Developer/2000
    Структура и функции
    Взаимодействие с другими средствами
    5.4. Локальные средства (ERwin, BPwin, S-Designor, CASE.Аналитик)
    5.5. Объектно-ориентированные CASE-средства (Rational Rose)
    Структура и функции
    Взаимодействие с другими средствами и организация групповой работы
    Среда функционирования
    5.6. Вспомогательные средства поддержки жизненного цикла ПО 5.6.1. Средства конфигурационного управления
    5.6.2. Средства документирования
    5.6.3. Средства тестирования
    .
    Полное содержание

    Подобный материал:

    • Реферат на тему: «case-технологии. Современные методы и средства проектирования информационных, 886.09kb.
    • Вендров А. М. Case-технологии. Современные методы и средства проектирования информационных, 9.59kb.
    • Рабочая программа наименование дисциплины методы и средства проектирования информационных, 238.05kb.
    • Современные case-технологии, 247.63kb.
    • Рабочая программа учебной дисциплины (модуля) case-средства проектирования программного, 143.56kb.
    • Рабочей программы дисциплины Методы и средства проектирования информационных систем, 44.17kb.
    • 11case-средства и их внедрение, 29.06kb.
    • Лекция: Основные понятия технологии проектирования информационных систем (ИС): Предмет, 189.07kb.
    • Методы автоматизированного проектирования системы прогнозирования землетрясений 05., 315.41kb.
    • Разработка case-инструментов как Web-приложений, 90.06kb.

    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]. В соответствии с этой методологией на этапе планирования определяются цели создания системы, приоритеты и ограничения, разрабатывается системная архитектура и план разработки ИС. В процессе анализа строятся модель информационных потребностей (диаграмма «сущность-связь»), диаграмма функциональной иерархии (на основе функциональной декомпозиции ИС), матрица перекрестных ссылок и диаграмма потоков данных.

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

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

    Designer/2000 обеспечивает графический интерфейс при разработке различных моделей (диаграмм) предметной области. В процессе построения моделей информация о них заносится в репозиторий. В состав Designer/2000 входят следующие компоненты:

    • Repository Administrator — средства управления репозиторием (создание и удаление приложений, управление доступом к данным со стороны различных пользователей, экспорт и импорт данных);
    • Repository Object Navigator — средства доступа к репозиторию, обеспечивающие многооконный объектно-ориентированный интерфейс доступа ко всем элементам репозитория;
    • Process Modeller — средство анализа и моделирования деловой деятельности, основывающееся на концепциях реинжиниринга бизнес-процессов (BPR — Business Process Reengineering) и глобальной системы управления качеством (TQM — Total Quality Management);
    • Systems Modeller — набор средств построения функциональных и информационных моделей проектируемой ИС, включающий средства для построения диаграмм «сущность-связь» (Entity-Relationship Diagrammer), диаграмм функциональных иерархий (Function Hierarchy Diagrammer), диаграмм потоков данных (Data Flow Diagrammer) и средство анализа и модификации связей объектов репозитория различных типов (Matrix Diagrammer);
    • Systems Designer — набор средств проектирования ИС, включающий средство построения структуры реляционной базы данных (Data Diagrammer), а также средства построения диаграмм, отображающих взаимодействие с данными, иерархию, структуру и логику приложений, реализуемую хранимыми процедурами на языке PL/SQL (Module Data Diagrammer, Module Structure Diagrammer и Module Logic Navigator);
    • Server Generator — генератор описаний объектов БД ORACLE (таблиц, индексов, ключей, последовательностей и т.д.). Помимо продуктов ORACLE, генерация и реинжиниринг БД может выполняться для СУБД Informix, DB/2, Microsoft SQL Server, Sybase, а также для стандарта ANSI SQL DDL и баз данных, доступ к которым реализуется посредством ODBC;
    • Forms Generator (генератор приложений для ORACLE Forms). Генерируемые приложения включают в себя различные экранные формы, средства контроля данных, проверки ограничений целостности и автоматические подсказки. Дальнейшая работа с приложением выполняется в среде Developer/2000;
    • Repository Reports — генератор стандартных отчетов, интегрированный с ORACLE Reports и позволяющий русифицировать отчеты, а также изменять структурное представление информации.

    Репозиторий Designer/2000 представляет собой хранилище всех проектных данных и может работать в многопользовательском режиме, обеспечивая параллельное обновление информации несколькими разработчиками. В процессе проектирования автоматически поддерживаются перекрестные ссылки между объектами словаря и могут генерироваться более 70 стандартных отчетов о моделируемой предметной области. Физическая среда хранения репозитория — база данных ORACLE.

    Генерация приложений, помимо продуктов ORACLE, выполняется также для Visual Basic.


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

    Designer/2000 можно интегрировать с другими средствами, используя открытый интерфейс приложений API (Application Programming Interface). Кроме того, можно использовать средство ORACLE CASE Exchange для экспорта/импорта объектов репозитория с целью обмена информацией с другими CASE-средствами.

    Developer/2000 обеспечивает разработку переносимых приложений, работающих в графической среде Windows, Macintosh или Motif. В среде Windows интеграция приложений Developer/2000 с другими средствами реализуется через механизм OLE и управляющие элементы VBX. Взаимодействие приложений с другими СУБД (DB/2, DB2/400, Rdb) реализуется с помощью средств ORACLE Client Adapter для ODBC, ORACLE Open Gateway и API.

    Среда функционирования Designer/2000 и Developer/2000 — Windows 3.x, Windows 95, Windows NT.

    5.4. Локальные средства (ERwin, BPwin, S-Designor, CASE.Аналитик)

    ERwin — средство концептуального моделирования БД [24], использующее методологию IDEF1X (см. подраздел 2.5). ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжиниринг существующей БД. ERwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Версия ERwin/OPEN полностью совместима со средствами разработки приложений PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной БД непосредственно в репозитории данных средств.

    Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений.

    Сетевая версия Erwin ModelMart обеспечивает согласованное проектирование БД и приложений в рамках рабочей группы.

    BPwin — средство функционального моделирования, реализующее методологию IDEF0 (см. подраздел 2.2).

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

    Конфигурация Стоимость, $
    ERwin/ERX 3,295
    Bpwin 2,495
    ERwin/ERX for PowerBuilder, Visual Basic, Progress 3,495
    ERwin/ERX for Delphi 4,295
    ERwin/Desktop for PowerBuilder, Visual Basic 495
    ERwin/ERX for SQLWindows / Designer/2000 / Solaris 3,495 / 5,795 / 6,995
    ModelMart 5 / 10 user 11,995 / 19,995
    Erwin/OPEN for ModelMart 3,995

    S-Designor 4.2 представляет собой CASE-средство для проектирования реляционных баз данных [25]. По своим функциональным возможностям и стоимости он близок к CASE-средству ERwin, отличаясь внешне используемой на диаграммах нотацией. S-Designor реализует стандартную методологию моделирования данных и генерирует описание БД для таких СУБД, как ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server и др. Для существующих систем выполняется реинжиниринг БД.

    S-Designor совместим с рядом средств разработки приложений (PowerBuilder, Uniface, TeamWindows и др.) и позволяет экспортировать описание БД в репозитории данных средств. Для PowerBuilder выполняется также прямая генерация шаблонов приложений.

    CASE.Аналитик 1.1 [3] является практически единственным в настоящее время конкурентоспособным отечественным CASE-средством функционального моделирования и реализует построение диаграмм потоков данных в соответствии с методологией, описанной в подразделе 2.3. Его основные функции:

    • построение и редактирование DFD;
    • анализ диаграмм и проектных спецификаций на полноту и непротиворечивость;
    • получение разнообразных отчетов по проекту;
    • генерация макетов документов в соответствии с требованиями ГОСТ 19.ХХХ и 34.ХХХ.

    Среда функционирования: процессор — 386 и выше, основная память — 4 Мб, дисковая память — 5 Мб, MS Windows 3.x или Windows 95.

    Ориентировочная стоимость:

    • однопользовательская версия — 605 $;
    • многопользовательская версия (одно рабочее место) — 535 $.

    База данных проекта реализована в формате СУБД Paradox и является открытой для доступа.

    С помощью отдельного программного продукта (Catherine) выполняется обмен данными с CASE-средством ERwin. При этом из проекта, выполненного в CASE.Аналитике, экспортируется описание структур данных и накопителей данных, которое по определенным правилам формирует описание сущностей и их атрибутов.

    5.5. Объектно-ориентированные CASE-средства (Rational Rose)

    Rational Rose — CASE-средство фирмы Rational Software Corporation (США) — предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации [21]. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML — Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант — Rational Rose/C++ — позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

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

    В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций, определяющих логическую и физическую структуры модели, ее статические и динамические аспекты. В их число входят диаграммы классов, состояний, сценариев, модулей, процессов [21].

    В составе Rational Rose можно выделить 6 основных структурных компонент: репозиторий, графический интерфейс пользователя, средства просмотра проекта (browser), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для С++, обеспечивающий реинжиниринг — восстановление модели проекта по исходным текстам программ.

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

    Средства автоматической генерации кодов программ на языке С++, используя информацию, содержащуюся в логической и физической моделях проекта, формируют файлы заголовков и файлы описаний классов и объектов. Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на языке С++. Анализатор кодов С++ реализован в виде отдельного программного модуля. Его назначение состоит в том, чтобы создавать модули проектов в форме Rational Rose на основе информации, содержащейся в определяемых пользователем исходных текстах на С++. В процессе работы анализатор осуществляет контроль правильности исходных текстов и диагностику ошибок. Модель, полученная в результате его работы, может целиком или фрагментарно использоваться в различных проектах. Анализатор обладает широкими возможностями настройки по входу и выходу. Например, можно определить типы исходных файлов, базовый компилятор, задать, какая информация должна быть включена в формируемую модель и какие элементы выходной модели следует выводить на экран. Таким образом, Rational Rose/С++ обеспечивает возможность повторного использования программных компонент.

    В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

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

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

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

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

    Rational Rose интегрируется со средством PVCS для организации групповой работы и управления проектом и со средством SoDA — для документирования проектов. Интеграция Rational Rose и SoDA обеспечивается средствами SoDA.

    Для организации групповой работы в Rational Rose возможно разбиение модели на управляемые подмодели. Каждая из них независимо сохраняется на диске или загружается в модель. В качестве подмодели может выступать категория классов или подсистема.

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

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

    Наиболее эффективно групповая работа организуется при интеграции Rational Rose со специальными средствами управления конфигурацией и контроля версий (PVCS). В этом случае защита от модификации устанавливается на все управляемые подмодели, кроме тех, которые выделены конкретному разработчику. В этом случае признак защиты от записи устанавливается для файлов, которые содержат подмодели, поэтому при считывании «чужих» подмоделей защита их от модификации сохраняется и случайные воздействия окажутся невозможными.

    Rational Rose функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX).

    Для работы системы необходимо выполнение следующих требований:

    • Платформа Windows — процессор 80386SX или выше (рекомендуется 80486), память8Mб (рекомендуется 12Mб), пространство на диске 8Mб + 1-3Mб для одной модели.
    • Платформа UNIX — память 32+(16*число пользователей)Mб, пространство на диске 30Mб + 20 при инсталляции + 1-3Mб для одной модели.

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

    5.6. Вспомогательные средства поддержки жизненного цикла ПО

    5.6.1. Средства конфигурационного управления

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

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

    Наиболее распространенным средством КУ является PVCS фирмы Intersolv (США), включающее ряд самостоятельных продуктов: PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder и PVCS Notify.

    PVCS Version Manager [18] предназначен для управления всеми компонентами проекта и ведения планомерной многоверсионной и многоплатформенной разработки силами команды разработчиков в условиях одной или нескольких локальных сетей. Понятие «проект» трактуется как совокупность файлов. В процессе работы над проектом промежуточное состояние файлов периодически сохраняется в архиве проекта, ведутся записи о времени сохранения, соответствии друг другу нескольких вариантов разных файлов проекта. Кроме этого, фиксируются имена разработчиков, ответственных за тот или иной файл, состав файлов промежуточных версий проекта и др. Это позволяет вернуться при необходимости к какому-либо из предыдущих состояний файла (например, при обнаружении ошибки, которую в данный момент трудно исправить).

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

    Доступ к архивам PVCS Version Manager возможен не только через сам Version Manager, но и из более чем 50 инструментальных средств, в том числе MS Visual C и MS Visual Basic, Uniface, PowerBuilder, SQL Windows, JAM, Delphi, Paradox и др.

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

    PVCS Version Manager функционирует в среде MS Windows, Windows 95, Windows NT, OS/2, SunOS, Solaris, HP-UX, AIX и SCO UNIX и может исполняться на любом персональном компьютере с процессором 80386 или выше, рабочих станциях Sun, HP и IBM (RS-6000).

    Другим средством конфигурационного управления является PVCS Tracker [19] — специализированная надстройка над офисной электронной почтой, предназначенная для обработки сообщений об ошибках в продукте, доставке их исполнителям и контроля за исполнением. Интеграция с PVCS Version Manager дает возможность связывать с сообщениями те или иные компоненты проекта. Отчетные возможности PVCS Tracker включают множество разновидностей графиков и диаграмм, отражающих состояние проекта и процесса его отладки, срезы по различным компонентам проекта, разработчикам и тестировщикам. С их помощью можно наглядно показать текущее состояние работы над проектом и ее временные тенденции.

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

    • пользователи (Submitters) — имеют ограниченные права на внесение замечаний и сообщений об ошибках в базу данных PVCS Tracker;
    • разработчики (Development Engineers) — имеют право производить основные операции с требованиями и замечаниями в базе данных PVCS Tracker. Если разработчики делятся на подгруппы, то для каждой подгруппы могут быть заданы отдельные списки прав доступа;
    • тестировщики (Quality Engineers) — имеют право производить основные операции с требованиями и замечаниями;
    • сопровождение (Support Engineers) — имеют право вносить любые замечания, требования и рекомендации в базу данных, но не имеют прав по распределению работ и изменению их приоритетности и сроков исполнения;
    • руководители (Managers) — имеют право распределять работы между исполнителями и принимать решения о их надлежащем исполнении. Руководителям разных групп могут заданы различные права доступа к базе данных PVCS Tracker.

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

    Требование или замечание поступающее в PVCS Tracker проходит четыре этапа обработки:

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

    Требования и замечания, поступающие в базу данных PVCS Tracker оформляются в виде специальной формы, которая может содержать до 18 полей выбора стандартных значений и до 12 произвольных текстовых строк. При разработке формы следует определить оптимальный набор информации, характерный для всех записей в базе данных.

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

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

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

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

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

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

    PVCS Tracker поддерживает групповую работу в локальных сетях и взаимодействует с СУБД dBase, ORACLE, SQL Server и SYBASE посредством ODBC.

    PVCS Tracker может быть интегрирован с любой системой электронной почты, поддерживающей стандарты VIM, MAPI или SMTP.

    PVCS Version Manager и PVCS Tracker окружены вспомогательными компонентами: PVCS Configuration Builder и PVCS Notify.

    PVCS Configuration Builder предназначен для сборки окончательного продукта из компонент проекта. PVCS Configuration Builder позволяет описывать процесс сборки как на стандартном языке MAKE, так и на собственном внутреннем языке, имеющем существенно большие возможности. PVCS Configuration Builder позволяет осуществлять сборку программного продукта на основании файлов, хранящихся в репозитории PVCS Version Manager.

    Обычная процедура сборки программного продукта с помощью PVCS Configuration Builder состоит из трех шагов:

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

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

    PVCS Notify обеспечивает автоматическую рассылку сообщений об ошибках из базы данных пакета PVCS Tracker по рабочим станциям назначения. При этом используется офисная система электронной почты cc:Mail или Microsoft Mail. PVCS Notify расширяет возможности PVCS Tracker и используется только совместно с ним.

    PVCS Notify настраивается из среды PVCS Tracker. Настройка включает в себя определение интервала времени, через который PVCS Notify проверяет содержимое базы данных, определение критериев отбора записей для рассылки уведомлений, определение списков адресов для рассылки. После настройки PVCS Notify начинает работу в автономном режиме, автоматически рассылая уведомления об изменениях в базе данных PVCS Tracker.

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

    Результатом работы PVCS Notify являются оформленные в соответствии с одним из стандартов почтовые сообщения, готовые для рассылки посредством системы электронной почты.

    5.6.2. Средства документирования

    Для создания документации в процессе разработки ИС используются разнообразные средства формирования отчетов, а также компоненты издательских систем. Обычно средства документирования встроены в конкретные CASE-средства. Исключением являются некоторые пакеты, предоставляющие дополнительный сервис при документировании. Из них наиболее активно используется SoDA (Software Document Аutomation).

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

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

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

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

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

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

    Среда функционирования SoDA — ОС типа UNIX на рабочих станциях Sun SPARCstation, IBM RISC System/6000 или Hewlett Packard HP 9000 700/800.


    SoDA требует по крайней мере 32 MB оперативной памяти, 100-300 MB для установки и 64 MB рабочего пространства на диске.

    5.6.3. Средства тестирования

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

    Одно из наиболее развитых средств тестирования QA (новое название — Quality Works) [20] представляет собой интегрированную, многоплатформенную среду для разработки автоматизированных тестов любого уровня, включая тесты регрессии для приложений с графическим интерфейсом пользователя.

    QA позволяет начинать тестирование на любой фазе ЖЦ, планировать и управлять процессом тестирования, отображать изменения в приложении и повторно использовать тесты для более чем 25 различных платформ.

    Основными компонентами QA являются:

    • QA Partner — среда для разработки, компиляции и выполнения тестов;
    • QA Planner — модуль для разработки планов тестирования и обработки результатов. Для создания и выполнения тестов в процессе работы QA Planner вызывается QA Partner;
    • Agent — модуль, поддерживающий работу в сети.

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

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

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

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

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

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

    Курсовая работа на тему: Примеры комплексов case- средств

    Название Курсовая работа на тему: Примеры комплексов case- средств
    страница 4/5
    Дата публикации 26.11.2014
    Размер 313.98 Kb.
    Тип Курсовая

    100-bal.ru > Информатика > Курсовая

    Designer/2000 + Developer/2000

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

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

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

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

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

    Designer/2000 обеспечивает графический интерфейс при разработке различных моделей (диаграмм) предметной области. В процессе построения моделей информация о них заносится в репозиторий. В состав Designer/2000 входят следующие компоненты:

    • Repository Administrator — средства управления репозиторием (создание и удаление приложений, управление доступом к данным со стороны различных пользователей, экспорт и импорт данных);
    • Repository Object Navigator — средства доступа к репозиторию, обеспечивающие многооконный объектно-ориентированный интерфейс доступа ко всем элементам репозитория;
    • Process Modeller — средство анализа и моделирования деловой деятельности, основывающееся на концепциях реинжиниринга бизнес-процессов (BPR — Business Process Reengineering) и глобальной системы управления качеством (TQM — Total Quality Management);
    • Systems Modeller — набор средств построения функциональных и информационных моделей проектируемой ИС, включающий средства для построения диаграмм «сущность-связь» (Entity-Relationship Diagrammer), диаграмм функциональных иерархий (Function Hierarchy Diagrammer), диаграмм потоков данных (Data Flow Diagrammer) и средство анализа и модификации связей объектов репозитория различных типов (Matrix Diagrammer);
    • Systems Designer — набор средств проектирования ИС, включающий средство построения структуры реляционной базы данных (Data Diagrammer), а также средства построения диаграмм, отображающих взаимодействие с данными, иерархию, структуру и логику приложений, реализуемую хранимыми процедурами на языке PL/SQL (Module Data Diagrammer, Module Structure Diagrammer и Module Logic Navigator);
    • Server Generator — генератор описаний объектов БД ORACLE (таблиц, индексов, ключей, последовательностей и т.д.). Помимо продуктов ORACLE, генерация и реинжиниринг БД может выполняться для СУБД Informix, DB/2, Microsoft SQL Server, Sybase, а также для стандарта ANSI SQL DDL и баз данных, доступ к которым реализуется посредством ODBC;
    • Forms Generator (генератор приложений для ORACLE Forms). Генерируемые приложения включают в себя различные экранные формы, средства контроля данных, проверки ограничений целостности и автоматические подсказки. Дальнейшая работа с приложением выполняется в среде Developer/2000;
    • Repository Reports — генератор стандартных отчетов, интегрированный с ORACLE Reports и позволяющий русифицировать отчеты, а также изменять структурное представление информации.

    Репозиторий Designer/2000 представляет собой хранилище всех проектных данных и может работать в многопользовательском режиме, обеспечивая параллельное обновление информации несколькими разработчиками. В процессе проектирования автоматически поддерживаются перекрестные ссылки между объектами словаря и могут генерироваться более 70 стандартных отчетов о моделируемой предметной области. Физическая среда хранения репозитория — база данных ORACLE.

    Генерация приложений, помимо продуктов ORACLE, выполняется также для Visual Basic.

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

    Designer/2000 можно интегрировать с другими средствами, используя открытый интерфейс приложений API (Application Programming Interface). Кроме того, можно использовать средство ORACLE CASE Exchange для экспорта/импорта объектов репозитория с целью обмена информацией с другими CASE-средствами.

    Developer/2000 обеспечивает разработку переносимых приложений, работающих в графической среде Windows, Macintosh или Motif. В среде Windows интеграция приложений Developer/2000 с другими средствами реализуется через механизм OLE и управляющие элементы VBX. Взаимодействие приложений с другими СУБД (DB/2, DB2/400, Rdb) реализуется с помощью средств ORACLE Client Adapter для ODBC, ORACLE Open Gateway и API.

    Vantage Team Builder (Westmount I-CASE)

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

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

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

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

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

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

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

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

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

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

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

    Vantage Team Builder поставляется в различных конфигурациях в зависимости от используемых СУБД (ORACLE, Informix, Sybase или Ingres) .

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

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

    Uniface

    Uniface 6.1 — продукт фирмы 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.

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

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

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

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

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

    В список поддерживаемых СУБД входят DB2, VSAM и IMS; PolyServer обеспечивает также взаимодействие с ОС MVS. Среда функционирования Uniface — все основные UNIX — платформы и MS Windows.

    Designer/2000 + Developer/2000

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

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

    Designer/2000 представляет собой семейство методологий и поддерживающих их программных продуктов.

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

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

    В состав Designer/2000 входят следующие компоненты:

    · Repository Administrator — средства управления репозиторием (создание и удаление приложений, управление доступом к данным со стороны различных пользователей, экспорт и импорт данных);

    · Repository Object Navigator — средства доступа к репозиторию, обеспечивающие многооконный объектно-ориентированный интерфейс доступа ко всем элементам репозитория;

    · Process Modeller — средство анализа и моделирования деловой деятельности, основывающееся на концепциях реинжиниринга бизнес-процессов (BPR — Business Process Reengineering) и глобальной системы управления качеством (TQM — Total Quality Management);

    · Systems Modeller — набор средств построения функциональных и информационных моделей проектируемой ИС, включающий средства для построения диаграмм «сущность-связь» (Entity-Relationship Diagrammer), диаграмм функциональных иерархий (Function Hierarchy Diagrammer), диаграмм потоков данных (Data Flow Diagrammer) и средство анализа и модификации связей объектов репозитория различных типов (Matrix Diagrammer);

    · Systems Designer — набор средств проектирования ИС, включающий средство построения структуры реляционной базы данных (Data Diagrammer), а также средства построения диаграмм, отображающих взаимодействие с данными, иерархию, структуру и логику приложений, реализуемую хранимыми процедурами на языке PL/SQL (Module Data Diagrammer, Module Structure Diagrammer и Module Logic Navigator);

    · Server Generator — генератор описаний объектов БД ORACLE (таблиц, индексов, ключей, последовательностей и т.д.). Помимо продуктов ORACLE, генерация и реинжиниринг БД может выполняться для СУБД Informix, DB/2, Microsoft SQL Server, Sybase, а также для стандарта ANSI SQL DDL и баз данных, доступ к которым реализуется посредством ODBC;

    · Forms Generator (генератор приложений для ORACLE Forms). Генерируемые приложения включают в себя различные экранные формы, средства контроля данных, проверки ограничений целостности и автоматические подсказки. Дальнейшая работа с приложением выполняется в среде Developer/2000;

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

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

    Designer/2000 можно интегрировать с другими средствами, используя открытый интерфейс приложений API (Application Programming Interface). Кроме того, можно использовать средство ORACLE CASE Exchange для экспорта/импорта объектов репозитория с целью обмена информацией с другими CASE-средствами.

    Developer/2000 обеспечивает разработку переносимых приложений, работающих в графической среде Windows, Macintosh или Motif. В среде Windows интеграция приложений Developer/2000 с другими средствами реализуется через механизм OLE и управляющие элементы VBX. Взаимодействие приложений с другими СУБД (DB/2, DB2/400, Rdb) реализуется с помощью средств ORACLE Client Adapter для ODBC, ORACLE Open Gateway и API.

    Среда функционирования Designer/2000 и Developer/2000 — Windows 3.x, Windows 95, Windows NT.

    Илон Маск рекомендует:  Разработка интернет-проектов в Берлине, - поддержка русскоязычным в Германии
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL