Принцип сперматозоида - Учебное пособие (Литвак М.Е.)

Создание функциональных моделей и диаграмм

Сбор информации

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

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

чтение документов;

наблюдение за выполняемыми операциями;

анкетирование;

использование собственных знаний;

составление описания.

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

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

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

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

Еще одна полезная стратегия – придумать описание и дать его экспертам для корректировки. Придуманные описания могут дать альтернативные схемы функционирования системы – схемы.

Типы опроса

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

опросы для сбора фактов;

опросы для определения проблем;

совещания для принятия решений;

диалоги автор/читатель.

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

Процесс опроса

Приведем несколько советов, которые позволяют понять основные шаги в процессе опроса:

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

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

Умение проводить хорошие опросы так же важно, как и умение строить хорошие диаграммы и модели.

Дополнения к диаграммам и моделям

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

SADT-диаграммы могут быть дополнены информацией в виде текстов, рисунков и глоссариев.

Текст обычно представляет собой рассказ об одной из частей диаграммы.

Рисунки – это картинки, поясняющие отдельные моменты.

Глоссарий – набор определений объектов и функций, представленных на диаграмме. 

Рассмотрим составление глоссария на примере процесса "подготовить рабочее место" в экспериментально-механическом цехе (рис. 25).

Рис. 25. SADT-диаграмма процесса "подготовить рабочее место".

 

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

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

 

Рис. 26. Пример глоссария для процесса "подготовить рабочее место".

 

Оценка и выбор CASE-средств

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

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

оценка нескольких CASE-средств и выбор одного или более из них;

оценка одного или более CASE-средств и сохранение результатов для последующего использования;

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

 

Рис. 27. Процесс выбора CASE-средства.

 

Как видно из рисунка 27, входной информацией для процесса оценки является:

определение пользовательских потребностей;

цели и ограничения проекта;

данные о доступных CASE-средствах;

список критериев, используемых в процессе оценки.

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

Элементы процесса включают:

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

потребности пользователей, отражающие количественные и качественные требования пользователей к CASE-средствам;

критерии, определяющие набор параметров, в соответствии с которыми производится оценка и принятие решения о выборе;

формализованные результаты оценок одного или более средств;

рекомендуемое решение (обычно либо решение о выборе, либо дальнейшая оценка).

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

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

Определение списка критериев основано на пользовательских требованиях и включает:

выбор критериев для использования из приведенного далее перечня;

определение дополнительных критериев;

определение области использования каждого критерия (оценка, выбор или оба процесса);

определение одной или более метрик для каждого критерия оценки;

назначение веса каждому критерию при выборе.

Критерии оценки и выбора

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

числовые меры в широком диапазоне значений, например, объем требуемой памяти;

числовые меры в ограниченном диапазоне значений, например, простота освоения, выраженная в баллах от 1 до 5;

двоичные меры (истина/ложь, да/нет), например, способность генерации документации в формате Postscript;

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

Типичный процесс оценки и/или выбора может использовать набор критериев различных типов.

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

Рис. 28. Функциональные характеристики.

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

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

 Проектная среда:

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

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

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

ПО/технические средства:

требуемые технические средства. Оборудование, необходимое для функционирования CASE-средства, включая тип процессора, объем оперативной и дисковой памяти.

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

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

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

Технологическая среда:

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

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

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

поддерживаемые языки. Все языки, используемые CASE-средством. Примерами таких языков являются языки программирования (Кобол, Ада, С), языки баз данных и языки запросов (DDL, SQL), графические языки (Postscript, HPGL), языки спецификации проектных требований и интерфейсы операционных систем (языки управления заданиями).

2. Функции, ориентированные на фазы жизненного цикла

Моделирование:

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

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

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

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

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

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

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

проектирование архитектуры ПО. Проектирование логической структуры ПО – структуры модулей, интерфейсов и др.

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

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

генерация экранных форм. Возможность генерации экранных форм на основе спецификаций требований и/или проектных спецификаций.

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

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

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

автоматизированное проектирование отчетов.

Реализация:

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

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

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

компиляция кода.

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

анализ надежности. Возможность количественно оценивать параметры надежности ПО, такие, как количество ошибок и др.

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

реструктуризация исходного кода. Возможность модификации формата и/или структуры существующего исходного кода.

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

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

Тестирование:

Критерии тестирования включают следующее:

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

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

автоматический запуск тестовых примеров.

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

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

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

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

анализ исключительных ситуаций в процессе тестирования.

динамическое моделирование среды. В частности, возможность автоматически генерировать моделируемые входные данные системы.

3. Общие функции

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

Документирование:

редактирование текстов и графики. Возможность вводить и редактировать данные в текстовом и графическом формате.

редактирование с помощью форм. Возможность поддерживать формы, определенные пользователями, вводить и редактировать данные в соответствии с формами.

возможности издательских систем.

поддержка функций и форматов гипертекста.

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

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

Управление конфигурацией:

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

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

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

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

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

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

Управление проектом:

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

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

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

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

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

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

Silverrun

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

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

Silverrun имеет модульную структуру и состоит из четырех модулей:

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

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

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

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

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

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

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

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

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.

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

ERwin – средство концептуального моделирования БД, использующее методологию IDEF1X (ERD). 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 (SADT).

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.

База данных проекта реализована в формате СУБД 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 формируются следующие документы:

диаграммы классов;

диаграммы состояний;

диаграммы сценариев;

диаграммы модулей;

диаграммы процессов;

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

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

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

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

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