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

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

6.2. Концептуальные основы Case–средств

Большинство CASE–средств основано на парадигме метод – нотация – средство.

Парадигма – это:

1)система изменяющихся форм некоторого понятия;

2)базовая информационная инфраструктура, предположения или

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

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

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

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

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

сопровождении или деятельности по управлению проектом, базирующееся на следующих трех основополагающих принципах [14].

1.Графическая ориентация. Используется мощная графика для описания

идокументирования систем(ПС) и для улучшения интерфейса пользователем.

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

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

151

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

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

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

2.Широкое использование базовых программных средств, получивших массовое распространение в других приложениях(СУБД, компиляторы с различных языков программирования, отладчики, издательские системы, оболочки экспертных систем и баз знаний, языки четвертого поколения 4GL и

др.).

3. Автоматизированная			или	автоматическая		кодогенер,
выполняющая	несколько	видов	генерации		кодов(преобразование	для

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

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

5.Доступность для разных категорий пользователей.

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

истоимости проектов.

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

6.3.Состав и функциональные возможности CASE–средств

Интегрированный CASE–пакет содержит четыре главныхкомпонента

[14]:

1.Средства централизованного хранения всей информации

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

2.Средства ввода, предназначенные для ввода данных в репозиторий и для организации взаимодействия CASEс –пакетом. Эти средства должны поддерживать различные методологии и использоваться на всем жизненном цикле различными категориями разработчиков(системными аналитиками, проектировщиками, инженерами, администраторами и т.д.).

152

3. Средства анализа, проектирования и разработки, предназначенные

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

1.Поддержка графических моделей.

2.Контроль ошибок.

3.Организация и поддержка репозитория.

4.Поддержка процесса разработки.

6.3.1. Поддержка графических моделей

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

Наиболее широко используются три типа диаграмм:

·диаграммы функционального моделирования;

·диаграммы моделирования данных;

·диаграммы отношений между модулями.

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

·создание иерархически связанных диаграмм;

·создание и редактирование объектов диаграмм;

·создание, перемещение и выравнивание групп объектов, изменение их размеров, масштабирование;

·сохранение связей между объектами при их перемещении и изменении размеров;

·автоматический контроль ошибок.

6.3.2. Контроль ошибок

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

a. Контроль синтаксиса диаграмм и типов их элементов. Примеры данного типа контроля:

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

153

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

b. Контроль		полноты и	корректности диаграмм– все элементы
диаграмм должны быть идентифицированы и отражены в репозитории.
c.	Контроль	декомпозиции	функций– включает оценку качества на
основе	различных	метрик ПС и частичный семантический контроль(в том

числе эффективность декомпозиции с точки зрения связности и сцепления

модулей).
	d. Сквозной контроль диаграмм одного или различных типов на предмет
их	состоятельности (корректности) по	уровням – вертикальное	и
горизонтальное балансирование диаграмм.

6.3.3. Организация и поддержка репозитория

Основные функции средств организации и поддержки репозитория

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

времени его последнего обновления, авторе, номере версии и т.п.

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

·	Отчеты по содержимому – включают совокупности потоков данных
и их	компонентов; совокупности всех пар интерфейсов в диаграммах

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

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

154