">
Прикладные науки Технология
Информация о работе

Тема: Анализ CASE-технологии системного проектирования

Описание: Основы проектирования. Структурный подход. Общая характеристика и классификация. Описание некоторых средств. Жизненный цикл. Каскадная (водопадная, последовательная), спиральная модель. Методологии и технологии. Требования. Быстрая разработка. Моделирование потоков.
Предмет: Прикладные науки.
Дисциплина: Технология.
Тип: Курсовая работа
Дата: 31.08.2012 г.
Язык: Русский
Скачиваний: 27
Поднять уникальность

Похожие работы:

Курсовая работа

на тему: Анализ CASE-технологии системного проектирования

Содержание

Введение3

CASE-технологии: определение и описание.4

Основы проектирования ИС5

Жизненный цикл ПО ИС5

Модели жизненного цикла ПО ИС7

Каскадная (водопадная, последовательная) модель7

Спиральная модель8

Методологии и технологии проектирования ИС9

Общие требования к методологии и технологии9

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

Структурный подход к проектировании ИС.11

Методология функционального проектирования SADT11

Моделирование потоков данных (DFD)12

Методология моделирования ARIS15

Методология IDEF и семейство ее стандартов17

IDEF017

IDEF319

CASE-средства. Общая характеристика и классификация21

Описание некоторых CASE-средств23

BPwin, Erwin, S-designor24

Введение

Развитию автоматизированного проектирования ИС способствовали следующие факторы:

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

многие системы состоят из отдельных частей, выполняющих определенные задачи;

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

необходимо объединять существующие приложения с заново созданными;

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

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

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

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

CASE-технологии: определение и описание.

CASE – набор методов и средств проектирования ИС с интегрированными автоматизированными инструментами, которые могут быть использованы в процессе разработки ПО для управления такой системой.

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

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

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

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

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

репозиторий – БД для хранения рез-тов деят-ти разработчиков.

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

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

Основы проектирования ИС

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

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

Технология проектирования ИС – это совокупность методологии и средств проектирования ИС, а также методов и средств его организации.

Предметом любой технологии проектирования должно служить отражение взаимосвязанных процессов проектирования на всех стадиях ЖЦ (жизненный цикл) ИС. К выбираемой технологии предъявляются следующие требования:

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

максимальное отражение всех этапов ЖЦ проекта;

обеспечение минимальных трудовых и финансовых затрат на проектирование и сопровождение проекта;

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

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

надежность процесса проектирования и эксплуатации проекта;

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

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

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

требуемую производительность системы;

безотказную работу системы в требуемом режиме;

простоту эксплуатации и поддержки системы.

Жизненный цикл ПО ИС

Жизненные цикл ПО ИС начинается с формирования решения проектирования до вывода из эксплуатации.

Процессы ЖЦ делятся на четыре группы*:

*Согласно стандартам ISO/IEC 12207:2008, ГОСТ Р ИСО/МЭК 12207-2010, ISO/IEC 12207:1995, ГОСТ Р ИСО/МЭК 12207-99, ГОСТ Р ИСО/МЭК 15288-2005, ISO/IEC 15288:2002.

основные процессы: приобретение, передача, разработка и эксплуатация ПО;

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

организационные процессы: управление проектом, инфраструктурой, персоналом, усовершенствование процессов;

адаптация описываемых процессов под нужды конкретного проекта.

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

Модели ЖЦ ПО ИС

Все стандарты не определяют единственное решение задач процессов ЖЦ ПО ИС, а дают общие рекомендации к их применению.

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

Каскадная (водопадная, последовательная) модель

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

Достоинства:

полная и согласованная проектная документация на каждом этапе разработки;

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

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



Недостатки:

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

ошибки в любом этапе проявляются в последующем, из-за чего необходимо возвращаться назад;

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

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

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

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

В реальности разработка ПО выглядит след. образом:



Для преодоления этих проблем была разработанная спиральная модель.

Спиральная модель

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



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

Методологии и технологии проектирования ИС

Общие требования к методологии и технологии

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

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

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



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

Методология RAD (Rapid Application Development, быстрая разработка приложений)

Используется спиральная модель разработки ПО ИС. Под RAD понимается процесс разработки ПО, включающий три составляющие:

небольшую команду программистов (от 2 до 10 человек);

короткий, тщательно проработанный производственный график (от 2 до 6 мес.);

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

ЖЦ ПО включает в себя фазу анализа и планирования требований; фазу проектирования; построения; внедрения.

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

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

Фаза построения. Здесь вып-яется сама быстрая разработка ПО с помощью спиральной модели разработки. Код частично формируется при помощи автоматич. генераторов, получающих инф-цию из репозитория (БД, в кот-й хранится вся и-ия о проекте) CASE-средств. Пользователи оценивают результаты, вносят коррективы. Тестирование осущ-ется непосредственно в процессе разработки.

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

Результат – готовая система, выполняющая все предъявленные требования.

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

RAD неприменима для систем, где нужно написать большой код. Нельзя ее использовать для разработки ПО, от которого зависит безопасность людей (например, управление АЭС), т.к. RAD предполагает, что первые версии ПО могут быть с ошибками.

Методология функционального проектирования SADT

(см.курсач у Некита З.)

Моделирование потоков данных (DFD, Data Flow Diagrams, диаграммы потоков данных)

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

Источники и-ии (внешние сущности) порождают инф-нные потоки (потоки данных). Эти потоки переносят и-ию к подсистемам или процессам, кот-е преобразуют ее и порождают новые потоки, переносящие инф-ию к след. процессам или подсистемам, накопителям данных или внешним сущностям – потребителям и-ии. Т.о., основными компонентами диаграмм потоков данных являются внешние сущности, системы/подсистемы, процессы, накопители данных и потоки данных.

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

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

Подсистема (система). Подсистема (система) имеет поля: «номер»; «имя»; «проектировщик» подсистемы (системы).

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

Процесс. Поля: «номер»; «имя»; «физ. реализация» - какое подразделение орг-ции, программа или аппаратное устройство выполняет данный процесс.

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

Накопитель данных. Поля: «номер» из буквы «D» и числа. Имя назначается такое, чтобы оно было понятно проектировщику.

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

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

Построение иерархии диаграмм потоков данных. Сначала строятся контекстные диаграммы. Для простых систем строится одна контекстная диаграмма со звездообразной топологией: в центре главный процесс, соединенный с приемниками и передатчиками. Для сложных ИС строится иерархия контекстных диаграмм. В контекстной диаграмме содержится не главный процесс, а набор подсистем, соединенных потоками. Каждая подсистема, процесс детализируется при помощи DFD.

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

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



Рис.12. Использование DFD на пример выдачи денег клиенту банка

Методология моделирования ARIS

ARIS (Architecture of Integrated Information Systems) – методология и программный продукт для моделирования бизнес-процессов организаций немецкой компании Software AG.

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

Методология моделирования ARIS

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

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

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

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

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

Для каждого типа создаются модели разных видов, отражающие соответствующие стороны ИС.

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

ARIS позволяет использовать разные уровни описания, что поддерживает ЖЦ ИС, обеспечивая целостность всей системы. В ARIS Toolset используется трехфазовая модель ЖЦ, т.е. каждый из перечисленных аспектов имеет три уровня представления:

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

Уровень проектной спецификации. Определяются основные пути реализации предъявленных требований.

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

Методология IDEF и семейство ее стандартов

IDEF (Icam DEFinition, Integrated DEFinition) – методологии для решения задач моделирования сложных систем.

Министерство обороны США – основной пользователь данной технологии.

В нее входит 15 стандартов, 5 из которых не были до конца разработаны, из них:

IDEF0 (Function Modeling) – создание функциональной модели, являющейся структурированным отображением функций ИС и связывающих их информации и объектов.

IDEF1 (Information Modeling) – построение модели структурированной информации, необходимую для поддержки функций системы.

IDEF3 (Process Description Capture) – используется для сбора информации о состоянии моделируемой системы. Это структурный метод, показывающий причинно-следственные связи и события. Он показывает, как организована работа, какие пользователи работают с ИС. IDEF3 состоит из двух методов. Process Flow Description (PFD) – описание процессов. Описывается, как организована работа между элементами системы. Object State Transition Description (OSTD) – описание переходов состояний объектов. Описываются промежуточные состояния у объектов системы.

IDEF0

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

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

Каждая из четырех сторон блока имеет определен роль: верхняя сторона – «Управление»; левая – «Вход»; правая – «Выход»; нижняя – «Механизм».

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

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

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

Т.о., хорошо видно, что стандарт IDEF0 схож с методологией SADT.

IDEF3

Стандарт IDEF0 для описания временной последовательности и алгоритмов выполнения работ не подходит. Для этого был разработан стандарт IDEF3.

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



Рис.15. Схема бизнес-процесса в стандарте IDEF3.

В стандарте IDEF3 связи между работами делятся на три типа: Связь Обозначение Описание  Связь предшествования  Вторая работа начинает выполняться после завершения первой работы  Связь отношения  Вторая работа может начаться и закончиться до того, как выполнится первая работа  Связь потоков объектов  Одновременно обозначает временную последовательность работ и материальный либо информационный поток. В данном случае вторая работа начинает выполняться после завершения первой работы. При этом выход первой работы – объект «Документ». Эта связь также обозначает, что объект, порождаемый первой работой, используется в последующих работах.  Логические операторы делятся на несколько типов: «Исключающий ИЛИ», «И» и «ИЛИ».

Существует несколько схем взаимосвязи работ: схемы схождения и схемы расхождения. В схемах схождения к перекресткам подходят стрелки сразу от нескольких работ, в схемах расхождения – наоборот, от одного перекрестка идет несколько стрелок к нескольким работам.

Перекрестки «И» и «ИЛИ» подразделяются на два подтипа – синхронные и асинхронные. Перекрестки синхронного типа: несколько отходящих от перекрестка работ в расходящихся схемах запускаются одновременно после входящей работы. Перекрестки асинхронного типа требований к одновременности не предъявляют. Для сходящихся схем это правило применяется для нескольких входящих работ.

Типы перекрестков в схемах схождения и расхождения: Название

перекрестков Обозначение перекрестков Смысл перекрестков    Схема расхождения Схема схождения  "Исключающий ИЛИ" 

 Только одна последующая работа запускается Только одна предшествующая работа должна быть завершена  "И" Асинхронный 

 Все последующие работы запускаются Все предшествующие работы должны быть завершены   Синхронный 

 Все последующие работы запускаются одновременно Все предшествующие работы должны быть завершены одновременно  "ИЛИ" Асинхронный 

 Одна или несколько последующих работ запускаются Одна или несколько предшествующих работ должны быть завершены   Синхронный 

 Одна или несколько последующих работ запускаются одновременно Одна или несколько предшествующих работ должны быть завершены одновременно  

CASE-средства. Общая характеристика и классификация

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

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

К CASE-средствам относят любое ПО, автоматизирующее совокупность процессов ЖЗ ПО ИС и обладающее следующими хар-рными особенностями:

мощные графические средства для описания и документирования ИС;

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

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

Интегрированное CASE-средство содержит следующие компоненты;

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

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

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

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

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

средства тестирования;

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

средства реинжиниринга.

Существуют следующие типы CASE-средств.:

средства анализа для построения и анализа моделей предметной области (Design/IDEF, BPwin);

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

средства проектирования БД, обеспечивающие моделирование данных и генерацию схем баз (ERwin, S-Designor, DataBase Designer, Vantage Team Builder, Designer/2000, Silverrun и PRO-IV);

средства разработки приложений. (Uniface, JAM, PowerBuilder, Developer/2000, New Era, SQL Windows, Delphi, Vantage Team Builder, PRO-IV, Silverrun);

средства реинжиниринга для анализа программных кодов и схем БД и формирование на их основе моделей и проектных спецификаций (Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor, Rational Rose, Object Team).

Вспомогательные типы:

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

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

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

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

Российские разработки: Vantage Team Builder (Westmount I-CASE), Designer/2000, Silverrun, ERwin+BPwin, S-Designor, CASE.Аналитик, а также CASE /4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE.

Описание некоторых CASE-средств

BPwin, Erwin, S-designor

ERwin – средство концептуального моделирования БД по методологии IDEF1X. Реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД и реинжиниринг существующей БД. Версия ERwin/OPEN совместима со средствами разработки приложений PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной БД непосредственно в репозиторий данных средств.

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

Erwin ModelMart обеспечивает проектирование в рамках рабочей группы.

BPwin – средство функционального моделирования по методологии IDEF0.

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