Глухова Л.А. Технологии разработки программного обеспечения

Подождите немного. Документ загружается.

151

Из таблицы видно, что при традиционной разработке ПС основные

усилия направлены на кодирование и тестирование, а при использовании

CASE-технологий – на анализ и проектирование, поскольку CASE

предполагают автоматическую кодогенерацию и автоматический контроль

проекта. Сопровождение кодов ПС заменяется сопровождением спецификаций

проектирования.

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

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

средство.

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

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

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

концепции, на основании которых развивается знание в рамках

определенной научной дисциплины.

Метод – это систематическая процедура или техника генерации

описаний компонент ПС.

Нотация – это система обозначений, предназначенная для описания

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

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

языки.

Средства – это инструментарий для поддержки методов, помогающий

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

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

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

Фактически CASE–средство – это тип графически ориентированных

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

К CASE–средствам может быть отнесено любое программное средство,

обеспечивающее автоматическую помощь при разработке ПС, его

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

следующих трех основополагающих принципах [14].

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

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

пользователем.

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

между своими средствами и позволяет управлять всем процессом разработки

ПС через планирование проекта.

3. Локализация всей проектной информации в репозитории

(компьютерном хранилище данных). Исполнителям проекта доступны

соответствующие разделы репозитория, что поддерживает принцип

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

152

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

статистики по проектам организации.

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

средств лежат следующие положения.

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

удобный и экономичный процесс.

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

массовое распространение в других приложениях (СУБД, компиляторы с

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

оболочки экспертных систем и баз знаний, языки четвертого поколения 4GL и

др.).

3. Автоматизированная или автоматическая кодогенерация,

выполняющая несколько видов генерации кодов (преобразование для

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

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

спецификаций ПС; автоматическая сборка модулей из словарей, моделей

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

ранее используемых файлов в форматы новых требований).

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

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

ясной структурой.

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

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

средств, вложенных в приобретение CASE-средства, за счет сокращения сроков

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

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

изменении требований и целей проекта.

6.3. Состав и функциональные

возможности CASE–средств

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

[14]:

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

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

(репозиторий).

2. Средства ввода, предназначенные для ввода данных в репозиторий и

для организации взаимодействия с CASE–пакетом. Эти средства должны

поддерживать различные методологии и использоваться на всем жизненном

цикле различными категориями разработчиков (системными аналитиками,

проектировщиками, инженерами, администраторами и т.д.).

153

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

для планирования и анализа различных описаний и их преобразований в

процессе разработки.

4. Средства вывода, служащие для документирования, управления

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

Все компоненты в совокупности должны обладать следующими

функциональными возможностями.

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

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

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

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

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

В CASE-средствах разрабатываемые ПС представляются схематически

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

различных типов.

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

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

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

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

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

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

диаграммеров:

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

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

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

размеров, масштабирование;

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

размеров;

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

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

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

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

данного типа контроля:

· по синтаксису: любой функциональный компонент программы

должен иметь по крайней мере один входной и один выходной

поток; два элемента данных не могут быть непосредственно

связаны;

154

· по типам: функциональный элемент должен всегда

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

поток данных всегда должен быть представлен компонентом

данных.

b. Контроль полноты и корректности диаграмм – все элементы

диаграмм должны быть идентифицированы и отражены в репозитории.

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

основе различных метрик ПС и частичный семантический контроль (в том

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

модулей).

d. Сквозной контроль диаграмм одного или различных типов на предмет

их состоятельности (корректности) по уровням – вертикальное и

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

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

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

заключаются в обеспечении хранения, доступа, обновления, анализа и

визуализации всей информации по проекту. Репозиторий обычно может

хранить более 100 типов объектов (например, диаграммы, определения экранов

и меню, проекты отчетов, описания данных, модели данных, модели обработки,

исходные коды, элементы данных).

Каждый информационный объект в репозитории обычно описывается

следующими свойствами: идентификатор, имена-синонимы, тип, текстовое

описание, компоненты, место хранения, область значений. Хранятся все

отношения с другими объектами (объекты, в которых данный объект

используется, все перекрестные ссылки), правила формирования и

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

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

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

по проекту, и в частности, отчетов. Основные типы отчетов:

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

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

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

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

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

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

отношений между их компонентами и правил их обработки.

· Отчеты по перекрестным ссылкам – включают ссылки всех

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

имеет доступ конкретный исполнитель проекта; перечень диаграмм,

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

выходу.

155

· Отчеты по результатам анализа – включают данные по

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

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

анализа структуры проекта, списки несогласованных в диаграммах и

репозитории объектов, списки удаленных объектов.

· Отчеты по декомпозиции объектов – включают совокупности

объектов, входящих в каждый объект, а также объекты, в состав которых

входит каждый объект.

6.3.4. Поддержка процесса проектирования и

разработки

Данная функция базируется на следующих возможностях CASE-

пакетов:

· Покрытие всего жизненного цикла систем или ПС.

· Поддержка прототипирования.

· Поддержка методологий проектирования систем или ПС.

· Автоматическая кодогенерация.

a. Покрытие всего жизненного цикла систем или ПС. Главное внимание

в CASE-средствах уделяется начальным, наиболее критичным этапам

жизненного цикла – анализу требований, проектированию спецификаций и

системы. Спецификации являются основой всего проекта, поэтому их полнота

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

b. Средства поддержки прототипирования наиболее важны на ранних

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

определения системных требований и ответа на вопросы об ожидаемом

поведении системы. Например, генераторы меню, экранов и отчетов позволяют

быстро построить прототипы пользовательских интерфейсов и обеспечивают

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

c. Поддержка методологий проектирования систем или ПС

осуществляется на двух уровнях:

· подготовка документации, графическая поддержка построения

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

функциональных блоков в диаграммах и структур данных на нижних

уровнях;

· корректное использование шагов проектирования в методологиях.

d. Кодогенерация осуществляется на основе информации, хранящейся в

репозитории, и позволяет построить автоматически до 80% исходных кодов на

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

практически все известные языки программирования.

Средства кодогенерации по отношению к полноте целевого продукта

разделяются на:

156

· средства генерации управляющей структуры (каркаса) продукта;

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

В первом случае автоматически строится откомментированная логика

(потоки управления) ПС, коды для базы данных, файлов, экранов, отчетов.

Остальные фрагменты ПС кодируются вручную.

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

документированное ПС, включая исполнимый код, пользовательскую и

программную документацию, наборы тестов.

6.4. Классификация CASE–средств

Все CASE–средства делятся по типам, категориям и уровням [14].

6.4.1. Классификация по типам

Данная классификация отражает функциональную ориентацию CASE–

средств в жизненном цикле ПС.

a. Анализ и проектирование.

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

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

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

и интерфейсов, связывающих эти компоненты, архитектура системы,

технический проект системы и ПС, включая алгоритмы и определения структур

данных. Таким образом, поддерживаются работы 2 – 7 процесса разработки

(см. подразд. 1.2).

К средствам этого типа можно отнести BPwin.

b. Проектирование баз данных и файлов.

Средства этого типа обеспечивают логическое моделирование данных,

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

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

уровне программного кода.

К средствам этого типа можно отнести ERwin.

c. Программирование и тестирование.

Средства этого типа поддерживают программирование и тестирование,

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

документированное ПС. Содержат диаграммеры, средства поддержки работы с

репозиторием, генераторы кодов, анализаторы кодов, генераторы наборов

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

d. Сопровождение и реинженерия.

К данным средствам относятся документаторы, анализаторы программ,

средства реструктурирования и реинженерии (реинженерия, реинженеринг–

reverse engineering - обратное проектирование, например, построение

157

спецификаций или моделей по исходным текстам программ), средства

обеспечения мобильности (в CASE они называются средствами миграции).

Целью средств данной группы является корректировка, изменение, анализ,

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

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

Средства миграции – это трансляторы, конверторы, макрогенераторы и

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

операционное или аппаратное окружение.

Средства реинженерии включают:

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

оценки влияния модификаций (например, «эффекта ряби» - внесение

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

· динамические анализаторы (компиляторы и интерпретаторы со

встроенными отладочными возможностями);

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

документацию при изменении кода;

· редакторы кодов, автоматически изменяющие при редактировании и

все предшествующие коду структуры (например, спецификации);

· средства доступа к спецификациям, их модификации и генерации

нового (модифицированного) кода;

· средства реверсной инженерии, транслирующие коды в спецификации

или модели.

CASE-средство Erwin также содержит в своем составе средства

реинженерии.

e. Окружение.

К данным средствам относятся средства поддержки платформ для

интеграции CASE-средств.

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

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

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

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

6.4.2. Классификация по категориям

Данная классификация определяет уровень интегрированности CASE-

средств по выполняемым функциям.

a. Категория Tool (tool - рабочий инструмент).

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

решающие небольшую автономную задачу в проблеме более широкого

масштаба.

b. Категория ToolКit (toolкit – набор инструментов, пакет разработчика).

CASE-средства данной категории представляют собой совокупность

158

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

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

репозиторий для всей технической и управляющей информации о проекте и

концентрируются, как правило, на поддержке одного этапа разработки ПС.

К CASE-средствам данной категории можно отнести BPwin.

c. Категория Workbench (Workbench – рабочее место).

CASE-средства данной категории обладают более высокой степенью

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

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

средствами окружающей среды, на которой Workbench функционирует.

Средство данной категории можно рассматривать как автоматизированную

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

работ (или их совокупностей) по разработке ПС.

К CASE-средствам данной категории можно отнести Erwin.

6.4.3. Классификация по уровням

Данная классификация связана с областью действия CASE-средств в

пределах жизненного цикла ПС.

a. Верхние (Upper) CASE–средства.

CASE–средства данного уровня называют еще средствами

компьютерного планирования. Их основной функцией является повышение

эффективности деятельности руководителей организации и проекта путем

сокращения затрат на определение политики организации и на создание общего

плана проекта (включая цели и стратегии их достижения). CASE–средства

данного уровня позволяют строить модель предметной области, проводить

анализ различных сценариев (в том числе наилучших и наихудших),

накапливать информацию для принятия оптимальных решений.

b. Средние (Middle) CASE–средства.

CASE–средства данного уровня представляют собой средства поддержки

этапов анализа требований и проектирования спецификаций и структуры ПС.

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

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

Проектирование при использовании средств данного уровня превращается в

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

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

· аналитик документирует эти требования, используя диаграммы и

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

при необходимости модифицирует их;

· аналитик отвечает на эти модификации, изменяя соответствующие

спецификации.

CASE–средства данного уровня обеспечивают возможности быстрого

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

159

К CASE-средствам данного уровня можно отнести BPwin.

c. Нижние (Lower) CASE–средства.

CASE–средства данного уровня поддерживают весь процесс разработки

ПС. Содержат системные словари и графические средства, исключающие

необходимость разработки физических спецификаций. Создаются системные

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

разрабатываемой системы. При этом автоматически генерируется до 80%

кодов. CASE–средства данного уровня выполняют функции тестирования,

управления конфигурацией, формирования документации. Уменьшают время

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

прототипирования (совместно со средними CASE).

К CASE-средствам данного уровня можно отнести ERwin.

6.5. Инструментальные средства

компании Telelogic, предназначенные

для автоматизации жизненного цикла

программных средств и систем

К современным инструментальным средствам, обеспечивающим

эффективную поддержку процессов жизненного цикла программных средств и

систем, относится семейство интегрированных продуктов компании Telelogic.

Основными в данном семействе являются следующие инструментальные

средства.

6.5.1. Telelogic DOORS

Инструментальное средство Telelogic DOORS предназначено для

автоматизации управления требованиями в жизненном цикле программных

средств.

Telelogic DOORS может быть использовано в процессах заказа, поставки

и разработки (см. подразд. 1.2) при выполнении работ и задач, связанных с

анализом требований.

При выполнении процесса заказа это касается работы «Подготовка

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

· описание концепции или потребности в заказе;

· анализ требований к системе;

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

При выполнении процесса поставки это касается работы «Планирование»

и, в частности, задачи «Анализ требований к заказу»

160

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

Telelogic DOORS может использоваться для автоматизации следующих работ и

задач, входящих в состав данных работ (работы в списке указаны слева, задачи

справа):

· анализ требований к системе:

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

к ней;

· проектирование системной архитектуры:

· распределение требований к системе между объектами

технических и программных средств архитектуры и ручными

операциями и дальнейшее уточнение требований;

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

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

· проектирование программной архитектуры:

· распределение требований к программному объекту между его

компонентами и дальнейшее уточнение требований;

· техническое проектирование программных средств:

· распределение технических требований к компонентам между

программными модулями и дальнейшее уточнение требований.

Вышеприведенные работы и задачи непосредственно связаны с

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

и могут быть автоматизированы с помощью Telelogic DOORS. Это позволяет

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

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

требования являются исходными данными. Поэтому структуризация

требований и автоматизация их разработки также повышает качество

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

программных средств в целом.

Telelogic DOORS может быть отнесено к уровню средних (Middle) CASE–

средств категории ToolКit.

6.5.2. Telelogic TAU

Семейство инструментальных средств Telelogic TAU предназначено для

автоматизации работ и задач процесса разработки программных средств и

систем. Данное семейство предоставляет визуальную среду разработки,

основанную на использовании универсального языка моделирования UML, с

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

Использование семейства Telelogic TAU позволяет унифицировать язык

общения между системными аналитиками, проектировщиками,

программистами и другими разработчиками, ускорить и повысить качество