Ответы на госэкзамен / CASE

7

Здесь Вы найдете ответы на вопросы 9, 10, 13, 14

CASE – технологии

Отличительной особенностью современного этапа развития технологии программирования, кроме изменения подхода, является создание и внедрение автоматизированных технологий разработки и сопровождения программного обеспечения, которые были названы CASE-технологиями (Computer-Aided Software/System Engineering - разработка программного обеспечения (программных систем) с использованием компьютерной поддержки). Без средств автоматизации разработка достаточно сложного программного обеспечения на настоящий момент становится трудно осуществимой: память человека уже не в состоянии фиксировать все детали, которые необходимо учитывать при разработке программного обеспечения. На сегодня существуют CASE-технологии, поддерживающие как структурный, так и объектный (в том числе и компонентный) подходы к программированию.

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

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

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

• ассемблеры, дампы памяти, анализаторы;

• компиляторы, интерпретаторы, трассировщики;

• символические отладчики, пакеты программ;

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

• CASE-средства анализа требований, проектирования спецификаций и структуры, редактирования интерфейсов (1-ая генерация CASE-1);

• CASE-средства генерации исходных текстов и реализации интегрированного окружения поддержки полного ЖЦ разработки ПО (2-ая генерация CASE-II).

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

CASE обладают следующими основными достоинствами:

• улучшают качество создаваемого ПО за счет средств автоматического контроля, прежде всего, контроля проекта;

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

• ускоряют процесс проектирования и разработки;

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

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

• поддерживают технологии повторного использования компонент разработки).

При использовании CASE-технологий изменяются фазы жизненного цикла ПП как показано ниже:

При традиционной технологии: При CASE-технологии:

Анализ Прототипирование

Проектирование Проектирование спецификаций

Контроль проекта

Кодирование Кодогенерация

Тестирование Системное тестирование

Сопровождение Сопровождение

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

Технология	Этапы разработки
	Анализ	Проектирование	Кодирование	Тестирование
традиционная	20%	15%	20%	45%
CASE-1	30%	30%	15%	25%
CASE-11	40%	40%	5%	15%

В следующей таблице сравниваются цели и содержание этапов при традиционной разработке и с применением CASE-средств.

№ п/п	Традиционная разработка	CASE-технология
1	Основные усилия - на кодирование и тестирование	Основные усилия - на анализ и проектирование
2	‘Бумажные’ спецификации	Быстрое итеративное прототипирование
3	Ручное кодирование	Автоматическая кодогенерация
4	Ручное документирование	Автоматическая генерация документации
5	Тестирование кодов	Автоматический Контроль проекта
6	Сопровождение кодов	Сопровождение специфи- каций проектирования

Как Вы помните, модель ЖЦ ПО определяет порядок выполнения этапов, а также критерии перехода от этапа к этапу.

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

CASE-технология базируется на спиральной модели ЖЦ ПП. Эта модель ЖЦ ПП была предложена в 1988 году Барри Боэмом. Модель базируется на лучших свойствах классического ЖЦ и макетирования, к которым добавляется новый элемент – анализ риска.

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

Планирование Анализ риска

2 3

4

1

Линия принятия решения

(продолжать или нет)

7

9 5

Оценивание 6

заказчиком 8 Конструирование

Рисунок 2. Спиральная модель: 1- начальный сбор требований и планирование проекта; 2 - та же работа, что 1, но на основе рекомендаций заказчика; 3 – анализ риска на основе начальных требований; 4 – аа\нализ риска на основе реакции заказчика; 5 – переход к комплексной системе; 6 – начальный макет системы, 7 – следующий уровень макета; 8 – сконструированная система; 9 – оценивание заказчиком.

Четыре квадранта определяют следующие действия:

• планирование – определение целей, вариантов и ограничений;

• анализ риска – анализ вариантов (степень неопределенности требований, выполнение проекта в заданные сроки)

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

• оценивание – оценка заказчиком текущих результатов конструирования.

По мере продвижения от центра к периферии строятся все более полные версии ПО. На первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ рискуа показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование, выполняемое в квадранте конструирования. Для дальнейшего определения проблемных и уточненных требований может быть использовано моделирование. Заказчик оценивает инженерную работу и вносит предложения по модификации (квадрант оценки заказчиком). Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде “продолжать не продолжать”. Если риск слишком велик, проект может быть остановлен.

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

Специалистами отмечаются следующие преимущества спиральной модели:

• накопление и повторное использование программных средств, моделей и прототипов;

• ориентация на развитие и модификацию ПО в процессе проектирования;

• анализ риска и издержек в процессе проектирования.

Чем же принципиально CASE-технология отличается от традиционной?

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

Некоторые из элементов CASE-технологий Вы будете изучать в последующих курсах.

Большинство CASE-технологий основано на парадигме методология/метод/нотация/ средство. Понятия методологии и метода мы с Вами уже давали.

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

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

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

• DFD ( Data Flow Diagrams) - диаграммы потоков данных, совместно со словарями данных и спецификациями процессов или миниспецификациями;

• ERD ( Entity-Relationship Diagrams) - диаграммы ‘сущность -связь’;

• STD (State Transition Diagrams) - диаграммы переходов состояний.

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

• по отношению к школам - Software Engineering (SE) и Information Engineering (IE);

• по порядку построения моделей - процедурно-ориентированные, ориентированные на данные и информационно-ориентированные;

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

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

Информационные системы	Системы реального времени
Управляются данными	Управляются событиями
Сложные структуры данных	Простые структуры данных
Большой объем входных данных	Малое количество входных данных
Интенсивный ввод-вывод	Интенсивные вычисления
Машинная независимость	Машинная зависимость

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

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

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

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