автореферат диссертации по информатике, вычислительной технике и управлению, 05.13.17, диссертация на тему:Методы системного проектирования, управления конфигурацией и тестирования программных средств при реализации CASE-технологий

р Г Б ОД 1 6 ГГнВ гп

Министерство науки и технической политики Российской " Федерации ■ ••■.,».

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

На правах рукописи

Позин Борис Ароновнч

УДК G81.3.0G

МЕТОДЫ СИСТЕМНОГО ПРОЕКТИРОВАНИЯ, УПРАВЛЕНИЯ КОНФИГУРАЦИЕЙ И ТЕСТИРОВАНИЯ ПРОГРАММНЫХ СРЕДСТВ ПРИ РЕАЛИЗАЦИИ CASE - ТЕХНОЛОГИЙ

Специальность 05.13.17 - теоретические основы информатики

Диссертация на соискание ученой степени доктора технических наук (в форме научного доклада)

Москва - 1994

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

Официальные оппоненты: член-корреспондент РАН,доктор

технических наук, профессор Иванников В.П. доктор технических наук, профессор Варанюк В.В. доктор технических наук, профессор

Вагин В.Н.

Ведущая с.)' -анизация: Институт проблем информатики РАН

Защита состоится часов

на заседании специализированного Совета Д064.48.01 при Российском научно-исследовательском институте инф рма иконных технологий и систем автоматизированного проектироьлця по адресу:

129090, Москва, ул.Щепкина.22

С диссертацией можно ознакомиться в научно-техннче-<ой библиотеке института

Автореферат разослан " : 994 г.

Ученый секретарь 1лк'ци;1ли:)нроианного сонет т.н . нрофессир

А/I/

&

А.А.Штрик

ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ

Актуальность работы. Вычислительная техника все глубже проникает в различные отрасли народного хозяйства. В настоящее время создание программных средств (ПС) размером в несколько сотен тысяч строк исходного текста становится достаточно обычной задачей не только для оборонных областей, как в 80-х годах, но в коммерческих, банковских системах, управлении предприятиями, производственными процессами и т.п. По разным данным, опубликованным в конце 1980-х - начале 1990-х годов, производительность труда при разработке подобных систем оценивалась в 2-5 команд в человекодень, в зависимости от размера и сложности ПС. Повышение уровня аппаратной оснащенности, широкое внедрение языков третьего поколения, интегрированных средств автоматизации разработки прикладных систем, не приводит к резкому повышению производительности труда при решении полного комплекса вопросов создания ПС ,

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

Проблеме обоснования методов проектирования прикладных систем и создания средств автоматизации проектирования информационных систем разных классов посвящены работы А.П.Ершова, Я.М.Барздиня, И.В.Вельбицкого, В.П.Иванникова, Б.М.Конорева, Л.Н.Королева,

Е.М Лавришевой. В.В.Липаева, Э.З.Любимского, А.И.Никитина;_$

Л.Д.Райкова, А.А.Щтрика, М.Р.Шура-Бура и других.

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

' CASE - сокращение от Computer-Aided Software/System Engineering ■ автоматизированное проектирование ПС и информационных систем

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

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

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

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

Для достижения этой цели в работе решаются следующие основные задачи:

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

• разработка объектно-операционно-переходной модели описание технологических процессов программной инженерии кан системотехнической основы для реализации CASE-технологии;

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

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

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

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

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

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

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

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

при описаниях моделей обьектно-ог.ерационно-пе.реходной и управлен*■>. конфигурацией При формировании объектно-олерационно-переходн'.м

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

Научная новизна Научной новизной обладают слелукт,."' результаты проделанного исследования

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

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

• впервые н о: ечественнои практике реализована схема диалог,'.;, основанная на общении пользователи с технологической системой ч терминах объектен проекта ПС и операций над ними;

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

■ выявлены условия реализуемости сборочного программирования л..я ПС различных типов,

■ впервые определены области применения методов тестирования к объектам ПС. с учетом возможностей методов, а также структурных особенностей объектов тестирования и их технологических свойств, разработаны оригинальные математические модели сложности и эффективности тестирования; получены результаты экспериментальных исследований сложности и эффективности тестирования для широкогп класса структур программ, позволяющие выработать рекомендации • выбору стратегии структурного тестирования в зависимости от структ\ программы и приняты* критериев тестирования.

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

Практическая значимость работы определяется использованием результатов при создании автоматизированных технологий ПРОТВА ;3 версии), РУЗА (3 версии), ТДИС, САБЕ-Ш, используемых в народном хозяйстве. На основе результатов работы в течение 4 лет читался ку.ч лекций в Московском институте инженеров железнодорожного транспорта для сгудентоь по . пегиалыюстп А1'.У

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

ПРОТВА, АСГК. 20002 • 0) регистрационный номер СФАП Алгоритм 2521440 от 01.02.85 (3 версии) для разработки двухъя.чыковых комплексов программ реального времени на ЕС-подобных ЭВМ (около 200 организаций); РУЗА, АСГК.30026-01, регистрационный номер 2521435 oí 30.06.84 (3 версии) - интегрированная настраиваемая кросс-система, функционирующая на ЕС ЭВМ (около 250 организаций);

ТАИС - функционирующее на IBM PC - совместимых ЭВМ новое поколение интегрированных программных и аппаратно-программных кросс-систем для создания программ встроенных ЭВМ на базе микропроцессоров К1810 ВМ86, Электроника 60 (сдана в ГосФЛП, внедрена в НИИАА и НПО АП);

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

- выполнены НИР "Цикл", "Лимфа-АН", Метод, 4GL. Политика-95 и

др.

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

По результатам работы на кафедре АСУ МИИТ в 1988-1991 г г автором прочитан курс "Автоматизация проектирования АСУ" Научные результаты диссертационной работы являются обобщением научно-производственной деятельности автора и выполнены в соответствии с планами научно-исследовательских работ в период 1979-1992 гг. в рамках реализации научно-технических программ ПРОМЕТЕЙ-2, ПРОМЕТЕЙ-П Минрадиопрома СССР, программ "Информатизация России" и "Перспективные информационные технологии в высшей школе". "Мелкосерийная и малотоннажная наукоемкая продукция" Миннауки РФ.

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

Первая Всесоюзная конференция "Технология программирования" (Киев, 1979), Всесоюзная научная конференция "Синтез, тестирование, верификация и отладка программ" (Рига, 1981). Всесоюзная конференция "Программное обеспечение АСУ" (Калинин, 1980, 1983, 1984), IX Международная научно-техническая конференция "Программное обеспечение ЭВМ Интерсофт-87"(Калинин, 1987), Всесоюзная конференция "Программное обеспечение вычислительных сетей и систем реального времени " (Киев, 1981), Всесоюзная научно-техническая конференция "Пути повышения качества программного обеспечения (Севастополь. 1984). Всесоюзная научная конференция "Проблемы совершенствования синтеза, тестирования. верификации и отладки программ (Рига. 1986). Республиканская конференция "Надежность и качество программной, обеспечения" (Львон, 1985). 2-я /Международная конференция "Технология поограммировния 90-х" (Киев. 1991), 111 Всесоюзный семинар "Качество программного обеспечения" (Дагомыс, 1991 i. Российская научно

практическая конференция "Информационно-аналитическая-,

статистическая и компьютерная поддержка экономической реформы н России" (Н.Новгород, 1992), Международная научно-практическая конференция "Рыночные механизмы и управление в социально экономических системах" (Воронеж, 1992), Российское совещание-семинар "Оптимальное проектирование технических устройств и автоматизированных систем" (Бердянск, 1991), семинары "CASE-технология" и "Открытые системы", проходившие под научным руководством автора (Москва, 1992, 1993), научно-технические семинарь1 в/ч Gl 168 (Москва,1991,1992). ГРЛУ (Москва,1991).

Системы ТАИС и C.ASE-RT, разработанные под руководством и при участии автора, экспонировались на международных выставках. CeBIT'91,94 (Ганновер,ФРГ); Информатика '91,92,93'; СофТул '90,91.92; Электро'92; Нефть и газ '92.

Публикации, По теме диссертации опубликовано 43 печатные работы, в том числе одна монография: Липаев В.В., Позин Б.А., Штрик A.A. Технология сборочного программирования, 1992.

Основные положения, представляемые к защите, На зашит1 выносятся следующие основные научные и подтверждающие ил практические результаты, составляющие основу диссертации:

-объектно-операционно-переходная модель описания технологических процессов создания и сопровождения ПС;

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

-критерии реализуемости сборочного программирования; •модели, алгоритмы и методы структурного тестирования; •автоматизированные системы ПРОТВА, РУЗА, ТАИС, CASE-RT.

Современное состояние CASE-технологии. В течение последних 15-20 лет в связи с появлением опыта создания сложных комплексов программ, прежде всего в интересах обороны, велись активные теоретические и прикладные исследования по поиску путей значительного снижения трудозатрат на создание сложных информационных систем различного назначения. В результате работ отечественных и зарубежных ученых и коллективов специалистов к настоящему времени сформировалось научно-техническое направление CASE (Computer - Aidée; Sottware/System Engineering) - автоматизированное проектирование программных средств и информационных систем (ИС). CASE-технология представляет собой новый уровень развития технологии создания и сопровождения программных средств, основанный на применении методов программной инженерии, на базе которых становится возможным в значительной мере автоматизировать все более широкий круг видов деятельности специалистов • разработчиков ИС, а также новый уровень комплексной автоматизации все большего объема этапов и операции технологического процесса, использующий широкие возможности современной вычислительной техники. Характерные для современных ЭВМ

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

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

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

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

■ управление конфигурацией проектов информационных систем и ПС:

• повторное использование компонент как метод снижения затрат на создание ПС;

• тестирование и испытание программ и информационных систем.

Данная диссертационная работа посвящена разработке научного-

методического обоснования технических и технологических основ комплексной автоматизации технологий создания и сопровождения ПС как базы для реализации высоко автоматизированных CASE • и интегрированных инструментальных систем создания Г1С и ИС. Внедрение таких технологий позволяет в несколько раз снизить трудоемкость создания ПС. Работа обобщает результаты исследований, проведенных автором, при ею участии или под его руководством п течение 1950-х ■ начала 1990-х годов в рамках научно технических программ Минрадиопрома СССР (ПРОМЕТЕЙ П. ПРОМЕТЕЙ 2), ГКВТИ СССР, Миннауки РФ (Информатизация России, Перспективные информационные технологии для высшей школы, Мелкосерийная и малотоннажная наукоемкая продукция"), а также научно-технических программ Роскоминформа.

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

Одна из важных особенностей CASE-средстп состоит в автоматизации scvx этапов жизненного цикла ПС и прежде ncern начальных, в отделении проектирования ПС от кодирования и

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

Различают два поколения CASE-средств (Рис.1). Первое поколение. ! или первая генерация характеризуется наличием разобщенных средств, повышающих производительность труда и улучшающих качество проектирования на отдельных этапах или операциях разработки. В настоящее время реализация CASE-средств направлена на создание интегрированной среды комплексной автоматизации процессов проектирования, разработки и сопровождения, реализующих некоторую методологию проектирования ПС. Это направление названо второй генерацией CASE. В средствах этой генерации охватываются не только традиционные процессы проектирования и разработки, но и работы с.с анализу готового ПС ireen^ineenng) с целью устранения ошибоь п. главное, оптимизации характеристик, а также и по укрупненному описанию готового ПС с целью проектирования нового по прототипу уже созданного (reverse engineering) Эти процессы в первую очередь ) традиционны для сопровождения и модификации ПС. ""Л

С целью применения адекватных проблемно-ориентированных технологий и комплексов автоматизации разработки ПС (или CASE-средств) целесообразно классифицировать ПС, как объект технологии, по следующим показателям [24]:

- область применения и социальное назначение программ в народном хозяйстве;

• степень связи решаемых задач с реальным масштабом времени •\:-м допустимая длительность ожидания результатов решения задачи;

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

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

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

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

- предполагаемый тираж производства и применения программ;

- степень документированное™ программ.

В данной работе внимание сосредоточено преимущественно на ПС. разрабатываемых как продукция производственно-технически! о назначения

Технологию разработки ПС предлагается характеризовать;

- типом и размером разрабатываемых с их помощью ПС;

- составом, степенью охвата и уровнем автоматизации этапов разработки;

■ типами ЭВМ, на которых разрабатывается (технологическая ЭВМ) и функционирует (реализующая ЭВМ) создаваемое ПС;

- степенью ориентации на использование имеющихся готовых программных компонент;

■ языками проектирования (в том числе графическими) ИС или ПС на разных этапах разработки;

- операционной средой разработки, имеющейся на технологической

ЭВМ;

• размером и уровнем квалификации коллектива разработчиков;

- требуемым уровнем управляемости и регламентации типового технологического процесса.

Автоматизированные технологические процессы, в зависимости от соотношения архитектур реализующей и технологической ЭВМ, подразделяются на три класса:

-резидент-технологии, когда системы команд технологической и реализующей ЭВМ полностью тождественны;

■кросс-технологии, когда между системами команд технологической и реализующей ЭВМ имеются различия;

■смешанные технологии, когда некоторые этапы работ выполняются на технологических и реализующих ЭВМ с различающимися, а другие с совпадающими системами команд.

В период формирования результатов данной работы при создании технологий всех трех классов для автоматизации проектирования ПС систем реального времени [21,24,27] сформулированы основные принципы построения интегрированных технологий:

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

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

• формирование структуры хранилища данных на основе результатов проектирования конфигурации создаваемого ПС;

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

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

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

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

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

• описание набора этапов и операций по созданию ПС в последовательности их выполнения и взаимосвязи;

- регламентация требований к результатам выполнения операций по разработке ПС и критериев контроля их правильности;

• разделение труда между специалистами разной квалификации;

- ориентация ТТП на эффективную разработку определенных классов и типов ПС.

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

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

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

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

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

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

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

Операция представляет собой преобразование одного или нескольких объектов в другой (другие) с получением нового качества (проектирование

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

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

Субъектами ТП являются специалисты, участвующие в разработке ПС, а правила их работы обычно зависят от ограничений на ресурсы разработки: опыт системных аналитиков, оснащенность машинным временем и средствами автоматизации, опыт работы в прикладной области, опыт программирования, в том числе на конкретных языках и i операционной среде Размер ПС, оснащенность, количество и опыт субъектов разработки определяют структуру коллектива разработчиков • и как следствие связь с операциями тех или иных субъектов ТП. Степень участия субъектов в выполнении операций также может быть различной' руководство выполнением операции или их совокупности, собственно выполнение, участие п выполнении или контроль результатов.

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

Подробное описание ТТП, -спроектированного на основании операционно-переходной модели для резидент- и смешанной технологий сделано в различных версиях системы автоматизации разработки ПРОТВ.А (1-3]. Три версии этой системы МСГК.20002-01, АСГК.20002-02. АСГК.20002-03) в 1982-1985 гг. сданы в Фонд алгоритмов и программ (АрмНПО ВТИ) и проданы более чем в 200 организаций. По данным пользователей, использование системы ПРОТВА снижает трудоемкость создания ПС в 2-3 раза. Автоматизированная схема ТТП реализована в системе ТАИС (30].

3. Разработка информационно-логической модели управления конфигурацией ПС в процессе разработки, сопровождения и распространения.

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

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

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

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

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

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

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

технических аспектов управления конфигурацией. Управление конфигурацией ПС осуществляется в течение всего его жизненного цикла.

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

Разработано семейство моделей УК ПС [27|, охватывающих процессы конфигурационного учета, идентификации и контроля. Они описывают интерпретацию указанных процессов на фазах разработки, распространения и сопровождения ПС. Модели включают в качестве элементов как само ПС, так и документацию на него.

Центральными для моделей являются представления о структуре ПС, характере появления и распространении изменений в нем. При построении модели за основу взята структура ПС, соответствующая принятым в Минрадиопроме СССР отраслевым стандартам, разрабатывавшимся при участии автора как ответственного исполнителя, а требования к документации • ГОСТ ЕСПД. Схема структуры ПС показана на рис 2. Изменение, вносимое в отдельную компоненту ПС, приводит к модификации составных частей и компонент. Каждое представление составной части или компоненты (спецификации требований, исходные, объектные или загрузочные тексты программ) в процессе проектирования может иметь несколько модификаций. Для проведения комплексной отладки и испытаний модификации составных частей объединяют в версию ПС.

Для систематического описания модификаций и версий, расчета и проектирования средств автоматизации УК в модели предложено новое базовое понятие объект УК (рис.3). Объекты выбираются на фазе конфигурационной идентификации с целью решения задачи УК в полном объеме. В качестве объекта УК выступает собственно объект и совокупность его состояний. Собственно объект является частью ПС (проекта, программы или документации). Объект является логическим понятием в проекте ПС (или ИС). Физическая природа и исходный способ представления (графический объект, текст, таблица) не имеют существенного значения • могут изменять только тип объекта. Состояние объекта определяется проведенными изменениями. Каждое новое изменение в принципе изменяет состояние объекта, в этом смысле объекты могут быть изолированными или связанными В последнем случае изменение в одном объекте может вызвать (в принципе) изменение в другом объекте, поэтому различаются изолированные и связанные состояния объектов. С позиций конфигурационного учета между объектами и состояниями существуют отношения типа "подлежит учету" или "не подлежит учету" и т.п. С позиций конфигурационного контроля объект может характеризоваться атрибутами связей по управлению и информации. Наличие атрибутов позволяет автоматизировать ряд процедур конфигурационного контроля [27]. Стратегия выбора схем учета объектов и состояний, их изолированности и связанности целиком определяется необходимым уровнем автоматизации интегрированной системы, то есть

Рис.2. Структура ПС как объекта управления конфи гурацией

щфигураци

онная ;нтификация

СтаЭД№аза)

Конфигурационный контроль

[ Состав объектов • ГП

Версия ПС

Схема связей объектов по типам

т

; Объе)д 1

Г Схема учета н объектов и

состоянии

Хранилище

нфигураци-онный учет

Операции по стадиям и типам

жязвшэв

СА8Е/инстру-ментальная система

ю.З. Общая схема информационно-логической модели управления конфигурацией

составом функций, автоматизируемых в ней, и в частности состав/ решаемых в ней задач конфигурационного учета. Состав учитываем! объектов УК, их состояний и атрибутов определяет объем базы данных (Б/ или хранилища, средств автоматизации УК и оперативность интегрированн системы п целом Вместе с тем от чтлх данных и значительной степе! зависит логическая схема хранилища, отражающая уровень автоматизац: проектирования, программирования, отладки и сопровождения. Подавляющ большинство логических (функциональных) объектов хранили! одновременно являются и объектами УК. Количество объектов, учитываем! их состояний, глубина учета связанных состояний определяют степе подробности описания истории распространения модификаций. Ош разработок показывает, что учет и хранение большого количества объектов их состояний оказывается неэффективным как по трудоемкое обслуживания, так и по объему памяти. Разработку ПС удобно вес версиями, отличающимися составом функций (компонент) и степенью I отработки. С точки зрения УК переход к новой версии ПС означает, что д, каждого объекта, включенного в нее, текущее состояние принимается качестве исходного. Однако отношения между объектами и состояниями разных версиях могут отличаться

Для разных фаз жизненного цикла: разработка, сопровождение распространение ПС - объекты и цели УК различны. Соответственно разньи являются и БД • как по составу, так и по интенсивности их использования каждой из них хранятся данные, отражающие степень влияния изменений I объекты ПС при решении задач УК на соответствующих стадиях жизненно цикла. Задачи, решаемые при разработке, сопровождении и распространени отличаются; тем не менее предложенная информационно - логическая моде, позволяет адекватно описать процессы, протекающие на этих фазах [27, 3 34!.

Средства конфигурационного учета в интегрированной cиcтe^ фактически создают некоторое виртуальное описаие объектов проекта и,; конкретной версии. Это описание характеризует, какие объекты и состоят учтены в интегрированной системе, когда и где они располагаются хранилище. Тип объекта определяет, какие операции из предусмотренных интегрированной системе могут проводиться над ним. Таким образе пользователь системы, в том числе системный аналитик, к: непрофессиональный программист, может работать с ней в терминах объект! проекта и операций над ними. Такой способ ведения диалога сокраща/ трудоемкость работы специалистов с системой и упорядочивав идентификацию объектов разработки. Вместе с тем необходимость постанов! объектов на конфигуационный учет приводит к преимущественно нисходяще схеме разработки, целесообразность и эффективность которой многократ! подчеркивалась в литературе

Практическая реализуемость предложенного подхода апробирована п[ создании версий интегрированной системы ТАИС (30], внедренных в НИИА

и НПО АП для создания встроенных систем на базе микророцессоров К1 в 10 ВМ86 и LSI/11

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

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

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

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

- накопление в средствах конфигурационной идентификации сведений об архитектуре проектируемого ПС (ИС) - объектах УК и связях между ними

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

- реализация диалога с пользователем системы в терминах объектов УК и функций обработки объектов;

- отслеживание состояния версий объектов УК и ПС (ИС);

- работа с объектами ПС (ИС) и подсистемами интегрированной системы как с элементами гипертекста.

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

процессом. Практически количество версий может оцениваться как 1 - 5 для интегрированных систем и 3 • 8 для интегрированных CASE • систем. Оценка рационального числа модификаций проводилась на основе экспериментальных исследований [27). Проведен анализ двух выборок модулей для оценки интенсивности обнаружения первичных ошибок на разных этапах технологического процесса. Получены статистические оценки распределения среднего размера модулей в сложных ПС, позволяющие спрогнозировать начальный размер хранилища, без учета модификаций. Получены также статистические оценки интенсивности обнаружения первичных ошибок, позволяющие спрогнозировать среднее число модификаций в модулях для версий ПС на этапах автономных работ, комплексной отладки (1,5 - 2 ош/ модуль в год) и сопровождения (не более 1 ош/ модуль в год). При выборе стратегии конфигурационного учета полученные данные позволяют оценить потребный объем хранилища или правильно выбрать вычислительную технику как технологическую базу создания ПС. Полезно использовать полученные данные при оценках объема хранилища по методике, приведенной в (25).

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

выполнить <имя функции интегрированной систсмы> над <имя объекта УК>,<номер еерсии>,<номер модификации> Для серии запросов в течение сеанса диалога номер версии практически не меняется; слабо подвержен изменению и номер модификации. Задав в начале сеанса, практически их можно не изменять в его ходе. Таким образом, общая схема диалога основана на отношении "имя функции" • "имя объекта УК", причем инициатором диалога является интегрированная система, предлагающая набор операций для выполнения. Изменение состояния объекта УК в ходе выполнения операции также регистрируется с помощью средств УК, что позволяет автоматически осуществлять отслеживание состояния версий и модификаций. Размещение всех данных в хранилище интегрированной системы позволяет "задаром", то есть без затрат усилий персонала, получить сводные данные о состоянии конфигурации ПС. Реализация описанного подхода проведена при создании системы ТАИС (две версии). Протокол диалога с ТАИС осваивается пользователем практически с первого сеанса. Предложенный подход соответствует и потребностям CASE-систем второго поколения, не требует принципиальных изменений средств и методов конфигурационного учета, предложенных в работе.

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

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

Решение последней из перечисленных задач основывается на следующем. В процессе проектирования пользователь нуждается в произвольном доступе к данным разных типов: текстово • графические, текстовые, программы ИС (ПС), программы подсистем интегрированной или CASE-системы, проектная и программная документация. Средства управления хранилищем CASE-системы должны обеспечивать доступ к данным по содержательным и довольно гибким запросам. Естественно рассматривать информационную базу с установленными ссылками как гипертекст, а виртуальную часть системы как средство интерпретации гипертекста. —>

Проект ИС (ПС) можно представить в виде мультиграфа ' G(E,F,Rl,D,R2,X,Y), где в скобках приведены списки множеств вершин графа G:

{Е}- внешние объекты ПС;

{F}- объекты (функции) проекта ПС;

{R1)- отношения между объектами проекта;

{D}- объекты базы данных проекта;

{R2}- отношения между объектами из {D);

{X)- процедуры и программные модули;

{Y}- глобальные информационные модули проекта.

Мультиграф G - многовходовой и многовыходной, в котором между вершинами разных типов могут быть установлены различные отношения, или связи, Элементы множеств, являющихся вершинами мультиграфа, могут быть представлены в видах графическом, текстово-графическом, программ, проектной и программной документации. В CASE- средствах при анализе проекта, контроле конфигурации, генерации кода или вызове библиотечных процедур возникают задачи анализа или интерпретации аннотированного мультиграфа G. Эти задачи могут касаться подграфов, выделяемых между двумя или несколькими элементами множеств одно- или разнотипных объектов • в зависимости от видов анализа. Точки входа подграфов и сами подграфы могут быть выбраны произвольно. Количество видов интерпретации обычно ограничено. Оно может быть представлено в виде библиотеки процедур. CASE- или интегрированная система по существу является

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

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

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

Снижения трудоемкости, стоимости разработки и сопровождения ПС добиваются разными методами.; Одним из наиболее эффективных является • сборочное программирование • метод создания сложных ПС на базе однажды \ разработанных и многократно используемых программных компонент '^(повторно используемых компонент-ПИК [271)...'Этот метод применим при некоторых условиях и технологии создания ПС. В несколько упрощенном ;- виде с констуктивных позиций идея повторного использования программ состоит в следующем. Каждое ПС имеет внутренние и внешние интерфейсы. Внутренние интерфейсы описывают связи между элементами, или " составными частями ПС. Внешние интерфейсы представляют собой совокупность связей между ПС и средой его использования - людьми или абонентами сети (в которой работает ПС), базами данных, системными \ программами, с которыми оно взаимодействует.

' Унификация и стандартизация интерфейсов, характерных для разных ПС, создает условия для того,чтобы нужные составные части ПС или целые ПС можно было переносить или повторно использовать в новом ПС или ИС. Этой идее служат созданные мировым сообществом стандарты, протоколы и интерфейсы типов ЭВМ-ЭВМ или элемент сети - элемент сети (например TCP/IP и др.); программа-программа (операционная система UNIX SVR4, API, SQL, СУБД Sybase, Informix, Oracle и др..переносимые на разные ЭВМ); человек - программа (Windows, Open Look и др.). Однако вопросы повторного использования не исчерпываются только созданием условий для него. Требуется развитие специальных технологий повторного использования для ПС разных классов. Именно поэтому в работе развивается метод сборочного программирования, причем в его рамках рассматривается не только технология создания ПС из ПИК, но и условия, при которых такой способ ' создания ПС реализуем с позиций различных свойств ПИК и ПС. г- В общей постановке сборочное программирование можно представить в ■ следующем виде. Пусть есть проблемная область, состоящая из объектов и отношений между ними. Объектами могут быть информационные объекты различной структуры, а отношениями - действия над объектами и (или) семантические связи между ними. Сборочное программирование программных

средств в данной проблемной области можно рассматривать состоящим ни двух процессов:

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

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

Эти два процесса взаимосвязаны, так что первый из них позволяет систематизировать базис объектов и отношений проблемной области, из ,. которых целесообразно проектировать разные ПС, решающие разнообразные / функциональные задачи в рамках этой проблемной области. При разработке" | различных ПС уровень детальности описания объектов и отношений может быть разным и определяет различные уровни абстракции при сборочном программировании. В зависимости от связности объектов и степени общности используемых отношений возможны следующие ситуации:

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

- все объекты и отношения из нового ПС использовались в ПС, разработанных раньше (хотя возможно и не в полном объеме);

• лишь некоторые объекты и отношения из числа включаемых в новое ПС использовались в ранее разработанных ПС;

- существует набор реализованных объектов и отношений, но еще не создавалось ни одно ПС _ '

Первая ситуация ■ полное функциональное различие ПС ■ приводит к ч необходимости проектирования ПС с "нуля", т.е. к традиционным методам -разработки ПС (ПИК).

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

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

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

Такая модель возникает при функциональном рассмотрении проблемной области без учета конструктивных ограничений, трудоемкости, стоимости и длительности разработки. Учет разного рода ограничений приводит к различным методикам и Технологиям сборочного программирования в зависимости от наличия ресурсов реализующей ЭВМ, а также от опыта, аппаратной и программной оснащенности коллективов специалистов-разработчиков ПС. Возможность и целесообразность применения сборочного программирования определяет'ся функциональными, конструктивными и технологическими условиями реализуемости (рис.4). I Функциональные условия определяют принципиальную возможность

создания разных ПС из ПИК в заданном функциональном базисе. Здесь и далее будем считать, что на некотором уровне абстракции отношение в модели проблемной области реализуется в виде ПИК, которой соответствует некоторая функция, реализуемая ею. Совокупность функций, общих для нескольких ПС, реализуемых в этой проблемной области, представляет собой : область подобия этих ПС.

Степень подобия двух или более ПС можно оценить количеством общих функций или реализующих их ПИК, или доле в составе нового ПС. Оценка степени подобия по доле ПИК одновременно отражает и реализуемость задачи сборки нового ПС из готовых ПИК. Степень подобия 0,6-0,9 можно, видимо, считать достаточно высокой и приемлемой, поскольку в этом случае для каждого нового ПС приходится реализовывать вновь меньшую его часть. Уровень 0,6 определяется прежде всего тем, что трудоемкость комплексирования ПС составляет обычно 10-15% общей трудоемкости. Сборка ПС из меньшего количества ПИК становится нерентабельной как по трудоемкости, так и по срокам разработки. Предельно достигнутая степень подобия по зарубежным и отечественным данным составляет в настоящее время 0,85-0,96.

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

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

Рис.4. Условия реализуемости сборочного программирования

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

Для проблемной области АСУ реального времени существу/ классификация объектов, так что частная функция из описания проблемж области может зависить от количества и/или типов объектов обслуживани управляющих объектов, операций управления или их характеристик.

На разных уровнях детальности для различных функций сост; параметров и значения их характеристик отличаются. Уровни детальное можно сопоставить с уровнями абстракции при сборочном программировани В этом случае на каждом уровне абстракции отношения отображаются конструктивные составные части ПС или в типы ПИК, а объекты • информационные элементы: интерфейсы, массивы, файлы и т.п. В частност для АСУ реального времени это могут быть массивы, посвященные разнь управляемым объектам, или интерфейсы с разными источниками информаци Параметрами на более детальных уровнях описания могут быть размерное массивов, предельные значения характеристик объектов (наприме максимальное удаление управляемого объекта от пункта наблюдения) и т. На каждом уровне детальности модель проблемной области должна бы сопряжена как по функциям, так и по составу и значениям параметр функций.

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

I Конструктивные условия определяют возможность решения задачи условиях конкретных технических ограничений: соотношения потребной реальной емкостей памяти и производительности реализующих ЭВМ; архитектур; операционной среды для функционирования ПС; структурно построения ПС. От этих ограничений зависит и достижимая степень подоб ПС.

Для обеспечения переносимости создаваемых программ из одного ПС другое при конструировании этих ПС (для реализующих ЭВМ с одинаковы! системами команд) должны быть решены четыре основные задачи унификации конструктивных решений:

• унификация интерфейса прикладных программ с используемой разных ПС операционной системой (ОС) • одной или несколькими;

- унификация информационных связей в разных ПС;

- унификация структурного построения компонент ПС;

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

Для ряда областей сложились так называемые "де факто'стандар оформления экрана, как например GUI. Однако для каждого класса систе»* учетом спецификации их функционирования требуется глубок систематическая проработка унифицированного человеко-машиннс интерфейса. Эффективное решение этой задачи в значительной ме повышает степень подобия ПС.

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

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

Наполнение базы данных связано с решением нескольких задач; озданием -классификатора данных, включаемых в БДСП, в терминах роблемной области; регламентацией порядка ввода компонент в БДСП с бязательным их индексированием по классификационным признакам, а акже комментированием по установленным правилам. При этом добиваются ого, чтобы было сохранено взаимно однозначное соответствие индексов омпонент в БДСП и в конфигурации использующего ее ПС. Наполнение ДСП должно вестись администратором базы данных или - при большой ее мкости - соответствующей службой. Каждая компонента при этом должна опровождаться сертификатом (паспортом) качества для оценки возможности е включения в БДСП. Однако хранение только сертификата качества при овторном использовании компоненты, видимо, недостаточно. Пользователь сегда испытывает определенное недоверие к объявленным свойствам омпоненты. Поэтому в БДСП следует хранить и набор тестов для егрессионного тестирования, обеспечивающего формирование "чувства Ьверия". Оформление этих тестов и порядок их запуска должны быть ггламентированы для всех компонент БДСП.

Управление конфигурацией многоверсионного ПС осуществляется как ри его разработке, так и при формировании БДСП. Разработку ПС ведут )азу как . многоверсионного,- поэтому в базе данных хранят разные одификации компонент, отличающиеся степенью их функциональной 1вершенности и отлаженности. Доступ к компонентам, принадлежащим ¡зным версиям ПС, разрешен только специалистам, отвечающим за армирование и отработку (отладку, испытания) версии (версий). При этом в 1зе данных проектирования не только хранятся соответствующие )мпоненты ПС, но и осуществляется учет их состояний; наличие того или юго представления компоненты (спецификаций требований, исходного.

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

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

.— Эффективность сборочного программирования достаточно просто оценить исходя из модели, предложенной в работе J.E.Gafiney, Jr., T.A.Durek I Software reuse - key to enhanced productivity some quantitative models • Information and Software Technology, V.31, N5, June 1989, pp.258-267 В этой ; модели принято, что общие затраты на разработку ПС складываются из затрат на разработку новых программ плюс затраты на ПИК, включенные в этот проект. Если обозначить R долю ПИК в данном проекте, a b -относительные затраты на включение (интеграцию) ПИК в данный проект (очевидно, b < или = I), тогда полные относительные затраты на создание ПС равны

С = (1 - R)*1 + R*b Если R стремится к 1, т.е. ПС полностью построено из ПИК, затраты на его создание ограничиваются затратами на интеграцию этих ПИК (С = b)

С тем чтобы модель затрат была ближе к реальности, она учитывает затраты не только на интеграцию ПИК, но и на их разработку в составе предыдущих программных проектов. Если ввести относительные затраты на разработку ПИК Е (очевидно, Е >= I) и величину п • количество применений ПИК, включая и в данном ПС), тогда полные относительные затраты на создание ПС равны

С = (1- R) *! + R (Ь + Е/п).

На рис.5 представлены графики последней функции при изменении трех параметров: Е • от 1 до 3, b от 0,1 до 0,5 и п от 2 до 10. Анализ графиков показывает, что сборочное программирование при высокой технологичности программирования ПИК (Е не более 1,5, b не более 0,5)

Рис.5 Относительные затраты на создание ПС при сборочном программировании

выгодно практически при любом тираже ПИК. Даже при высокой стоимости разработки модулей как ПИК (Е=3) при большом тираже модулей (>10) сборочное программирование оказывается экономически выгоднее разработки модулей для каждого ПС заново. Снижение относительной стоимости объединения ПИК Ь за счет улучшения конструктивных и технологических характеристик разработки приводит к высокой эффективности сборочного \ программирования. 41 Нисходящий и восходящий технологические процессы при сборочном ^программировании. Сборка .ПС из ПИК занимает важное место при создании / ПС методом сборочного программирования. В зависнмо-сти от роли и места 1 сборки в общем технологическом процессе создания ПС в работе предложено \два типовых технологических процесса: восходящий и нисходящий.

Восходящий технологический процесс применяют в тех случаях, когда размер ПС не очень большой и разработчик хорошо знает состав ПИК. При ' этом подходе, как правило, неходят из того, что существует прототип , собираемого ПС; соглашения, принятые при разработке прототипа, распространяются и на новое ПС. Предполагается и функциональное подобие нового ПС и прототипа. При этом подходе разработка ПС осуществляется итерационным путем. Вначале оценивают состав имеющихся ПИК, пытаются собрать версию ПС, состоящую из них, выбирают направления и объекты доработок. Доработки, как правило, касаются изменения функциональных возможностей, интерфейсов разных видов при смене оборудования или операционной системы, изменений эргономических требований или модификации дисциплины обмена с абонентами сети или вычислительной системы. Доработки не всегда удается сделать так,чтобы полностью удовлетворить требованиям ТЗ Поэтому по завершении доработок в какой-то части осуществляется повторная сборка ПС и оценка полноты реализации требований технического задания. Этот цикл работ может повторяться в зависимости от соотношения потребных и завершенных доработок, особенно в условиях сжатых сроков разработки. Тем не менее при степени подобия 0,6 и более такой процесс завершается быстрее, чем при полностью новой разработке /Итерации, завершающиеся сборкой (блоки 5-7 на рис.6), осуществляют с I целью распараллеливания работ по доработке компонент и по комплексной I отладке ПС в целом.(На рис,6 показана только одна итерация). Восходящий технологический процесс применяют обычно в коллективах, в течение ряда лет разрабатывающих однотипные ПС.

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

Разработка и

испытания ПС-прототипа гу

±

Отбор ПИК или вер сий ПС

X

Разработка ТЗ и спецификаций на новое ^

Реализуемо

I

Оценка реализуемости нового ПС, из готовых ПИК 4

Нужны

ополнительные компоненты

Оценка целесообразности сборочного программирования

I

Нецелесообразно

Разработка и автономная отладка новых компонент

I

Выбор направлений доработки

г

Разработка ПС по традиционной технологии р^

Сборка и комплексная отладка ПС

1

Испытания ПС

Рис.6. Восходящий технологический процесс сборочного программирования

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

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

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

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

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

19 ♦ Комплексная отладка

1

10 Выпуск документации

1 1 Наполнение базы данных СП

новыми компонентами

,--Рис.7. Нисходящий технологический процесс сборочного программирования

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

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

Сборочное программирование это не частный тактический метод, позволяющий решать локальные задачи одной конкретной разработки. Это стратегическая линия, на которую должно сориентироваться предприятие, осуществляющее разработку ПС в некоторой проблемной области, линия, ориентированная на 10-15 лет. Именно поэтому она требует значительных начальных затрат, рассчитанных на создание нормативно-технической базы, наращивание аппаратной и программной оснащенности, обучение специалистов, с тем, чтобы на 10-15 лет обеспечить существенный рост производительности труда и, что характерно, значительное сокращение сроков разработки и отладки ПС. За этот период может произойти смена вычислительной базы как технологической, так и объектной ЭВМ, смениться поколение разработчиков. Совокупность организационно-технических мероприятий по реализации сборочного программирования должна обеспечивать высокую стабильность технико-экономических показателей по всем планируемым разработкам, мало зависящую от влияния указанных факторов.

6. Теоретическое и экспериментальное обоснование методов и алгоритмов автоматизации тестирования компонент

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

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

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

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

Структурные модели дают систематическое описание'как укрупненной, так и детальной структур программного средства (ПС) и его компонентов. Наиболее приемлемыми с позиций использования при тестировании представляются комбинированные многоуровневые модели ПС, состоящие из структурной графовой модели (потока управления, или схемы выловов) и теоретико-множественной модели преобразования данных (потока данных) Комбинированные модели отражают взаимодействие этих потоком с необходимой степенью детальности. При структурном тестировании имеет смысл рассмотрение двухуровневой комбинированной модели. Модель первого уровня (М1) (рис.8а) представляет собой схему управляющих связей между модулями в группе взаимодействующих программ, а также схему информационных связей между этими компонентами как через параметры, так и через глобальные данные. Группа программ интерпретируется ориентированным мультиграфом, имеющим два типа вершин и три типа дуг Вершина первого типа соответствует программным модулям, а вершина второго - информационным модулям. Связи первого типа соответствуют передачам управления между модулями, связи второго типа передачам информации, связи третьего типа временным и условным связям. При решении различных задач вершины и дуги мультиграфа могут быть ненагруженными или нагруженными весовыми коэффициентами или условиями, соответствующими природе решаемых задач. Эту модель целесообразно использовать для автоматизированного статического контроля правильности взаимодействия по управлению и данным независимо разработанных компонентов ПС. Модель второго уровня ( М2 ) ( рис 86 ) представляет собой детальные схемы внутримодульных взаимодействие по управлению и данным между линейными участками программ. Модель :-<тогс вида представляет собой "почти" двудольный граф (мультиграф), "левая" лоля которого (см. рис.8 ) отображает поток управления программного модуля (граф программы 0(Х,П), а "правая" элементы потока данных. Дуги вттри "левой" доли представляют связи между линейными участками программы

а)

36

(ГШ)

комплекс программ

• точка контроля передачи управления о точка контроля передачи информации

б)

структурная графовая модель

теоретико-множественная модель

входные данные

промежуточные данные

жонстанты ) : выходные данные •

поток данных

Рис.8 Комбинированные двухуровневые модели ПС структурного тестирования

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

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

Общность структурных моделей для программ, написанных на разных языках, позволяет использовать единые критерии полноты тестирования Таким образом, создается возможность применения общих методов для структурного тестирования разноязыковых программ. Вместе с тем для языков более высокого уровня структурная модель может быть дополнена семантическими отношениями в вершинах или на дугах графа М1 или Л\2 (аннотирована). Соответственно может быть расширен и класс статических и формально-логических методов, используемых при тестировании программ

Объекты, критерии, методы и этапы структурного тестирования, В процессе тестирования проверке подвергаются различные свойства программ. При структурном тестировании проверке подвергаются состав и связи составных частей ПС, а также отношения, определенные на них. Основным условием, обеспечивающим высокий уровень автоматизации тестирования, является систематическое описание ПС. обеспечивающее построение по нему моделей М1 и М2.

Объектами структурного тестирования являются состав ПС и его составных частей,'• связи между ними, конфигурация ПС. соглашения о написании программ (рис.9). При этом под объектами понимаются чак спецификации требований к ПС или его составным частям, так и реальные программы, соответствующие этим спецификациям. Спецификации требований содержат информацию, необходимую для того, чтобы постр итъ модель М1 как эталон для последующего контроля.

Критерии структурного тестирования обеспечивают возможность автоматизации контроля корректности построения компонентов и ПС в целом, а также автоматизацию планирования тестирования и контроля полноты реализации плана Для разных объектов тестирования критерии различны Часть их, направленная на оценку наличия или отсутствия объектов определенного вида, не имеет точного количественного значения. Одна!'..' ас мере конкретизации объектов тестирования и перехода к моделям М1 и М'с

Рис.9. Объекты, критерии и методы тестирования

критерии приобретают количественное выражение. Так, для М2 критерии структурного тестирования выражаются как степень полноты покрытия графе программы или схемы потока данных. Наиболее распространен, в настоящее время рассматриваемый в данной работе критерий С1 • покрытие ветвей графа программы хотя бы по одному разу. Применимость критериев к различным объектам структурного тестирования, а также взаимосвязь методов анализа программ, планирования тестирования и контроля с соответствующими критериями показаны на рис',9. (21,41] В состав критернеа структурного тестирования входят не только количественные, которые могут быть заданы числом или неравенством (см. например, четыре нижних критерия на рис.8). Некоторые критерии задаются правилами Исследование видов правил и способов их задания представляют собой с самостоятельную задачу.

Критерии структурного тестирования по типам можно подразделить на формализуемые (3-7 на рис.9) и слабо формализуемые (1-2) Формализуемые критерии используются а средствах автоматизации для точной оценки или выдачи пользователю достоверных и сводных данных о состоянии тестирования или характеристики объекта тестирования. Слабо формализуемые критерии редко используются в средствах автоматизации как эталоны. В большинстве случаев такие критерии приводят к созданию средств, упорядочивающих информацию для принятия решения человеком (программистом).

По способу обработки программы различают критерии статического анализа и контроля (1-3), планирования тестирования (4-5), контроля полноты проведенного тестирования (6-7) Критерии первой группы в большинстве случаев определены в методиках программирования, поэтому они редко в явном виде используются для автоматического контроля Критерии второй и третьей групп, напротив, пригодны для применения в средствах автоматизации

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

Методы тестирования основаны на преобразовании исходных текстов программ, или таблиц, получаемых при трансляции, в модели М1 или М2 . а

4 и

также на последующем анализе этих моделей. Применимость методов для решения задачи тестирования ПС определяется как ограничениями методов или их пригодностью для тестирования программ, написанных на языках обоих - высокого и низкого, машинно-ориентированного - уровней, так и характеристиками исходных текстов программ (см. табл.1). Последние основаны на анализе выборки, описанной в литературе, а также комплекса программ размером около 300 тыс. строк языка ПЛ/1 и Ассемблера ЕС ЭВМ Ограничения метода символического выполнения - ограниченность типов данных, чувствительность к неявностям по передаче управления и информации - вряд ли позволят эффективно применить его для решения задачи структурного тестирования двухъязыковых программ. Напротив, применение двух других методов, не обладающих подобными ограничениями, возможно. При введении определенных методик написания программ, исключающих неявности (например, при использовании макроязыка вместо ассемблера, при замене непосредственного использования аппарата указателей в языке высокого уровня ПЛ/1 на макроопределения или другие конструкции с явным указанием точек перехода или ссылочных имен данных (1,41), применение этих методов становится эффективным. Подобные решения применяются в языке Ада. Автором, под его руководством и при его участии разработан комплекс методов структурного тестирования, основанный на анализе и преобразованиях модели М2. Эти методы направлены на:

- построение покрытия графа программы М2 маршрутами;

- получение количественных оценок сложности и эффективности тестирования графа М2 для построения плана тестирования;

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

Этап в. структурного тестирования. Тестирование программ при их разработке представляет собой многоэтапный процесс, который начинается с момента появления специфицированных требований к тестируемому ПС и завершается испытаниями этого ПС. Характерна определенная совокупность этапов тестирования [1-3,16,17,19,23,261; предварительный контроль объекта тестирования; планирование тестирования объектов данного вида; построение тестов; контроль выполнения тестов и плана тестирования. Общая схема структурного тестирования состоит в проверке, начиная со спецификаций требований и заканчивая программными модулями, свойств программ, отраженных в их структуре. Попутно можно решать и другие задачи, например, проверку точности вычислений.

Процесс структурного тестирования разбивается на два взаимосвязанных подпроцесса: тестирование групп программ и тестирование модулей. Тестирование групп программ основано на исследовании свойств спецификаций требований и реальных ПМ и ИМ, входящих в группу, с использованием модели М1. Эта модель строится по спецификациям требований или исходным текстам (объектным модулям). Она отражает пропроектируемые (по спецификациям) или реализованные (по исходным тек-

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

Таблица 1

Характеристики исходных текстов программ Язык программирования ПС РВ Ограничения методов тестирования

Ассемблер Макро язык Язык высокого уровня Символическое выполнение Статический анализ Методы основанные на структурных метриках

Количество типов данных порядка к * 10 1 (только целые) к'Ю Ян щввэ

Наличие неяв-ностей по передаче управления 4- ч - та ж

Наличие неяв-ностей по передаче информации + ч - ш

Среднее количество циклов в модуле , 2,2 1 СП

Среднее количество вызываемых модулей 3,1 т

Обозначения :

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

- ч*< >

' ■.% 'г чувствителен к неявностям, их наличие ограничивает г применимость метода

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

ч- частично

0 < к < 2

текстам) связи по управлению и информации. Проверку корректности связей осуществляет человек по функциональным критериям или по критерию соответствия схем на основании предъявляемой ему машиной схемы связей М1 и результатов отладки, "привязанных" к этой схеме автоматизированными методами 126] или при лнялмлг "прущую" Ошибки, кайленные п этой гхгмо. устраняются.

По корректной схеме осуществляется планирование тестирования ГП. С этой целью анализируют метрическую сложность ПМ, оценивая то, на каких свойствах отдельных модулей - структурных или информационных • следует сосредоточиться. Далее с учетом функциональных свойств ГП (поскольку функциональные критерии тестирования на этом этапе становятся определяющими) строят подграфы (т) схемы М1, отображающие состав модулей, участвующих в решении функциональных задач. При реальном выполнении ГП отдельные модули из {т) могут вызываться многократно, однако все они потенциально участвуют в решении функциональной задачи. Совокупность подграфов типа (т) для всех функциональных задач полностью описывает мультиграф М1 (покрывает его вершины и,дуги). Таким образом, задача планирования тестирования групп программ сводится к разбиению М1 на подграфы {т} таким образом, чтобы их число было минимальным, в совокупности они покрывали М1, а также проверяли все реализуемые им функции. Каждый подграф {т} отражает состав программных и информационных модулей необходимых для решения функциональной задачи. Одновременно выявляют все элементы М1, -инцидентные подграфу {т} функциональной задачи. С учетом состава среды и маршрутов выполнения функциональной задачи в подграфе ¡гп) формируют соответствующие тесты, наполняя информационные элементы - реальными модулями или их имитаторами.

В зависимости от методики проведения отладки далее поступают одним из двух способов. При первом способе контролируют только динамическую трассу выполнения функции, фиксируя прохождения только точек входа модулей. Этот способ целесообразно сочетать с проблемно-ориентированным комплексным тестированием 123], помогающим разобраться в содержательных аспектах решения задач при отладке. При втором способе, направленном на анализ детальной трассы выполнения ГП (или функциональной задачи), все или некоторые модули, входящие в гп, инструментируют, т.е. включают в точки входа и во все ветви программы средства счетчикового контроля. При этом каждый счетчик фиксирует количество прохождений через ту или иную ветвь при выполнении программы. Того же эффекта можно добиться с помощью программных интерпретаторов системы команд ЭВМ или аппаратных эмуляторов. При обоих способах результатом проверки структуры ГП является протокол ее тестирования, содержащий сведения о степени проверки структуры ГП (всех модулей, входящих в нее), а также степени полноты реализации плана тестирования.

Структурное i eci ириилше ГП должно си'нлигьси с i ее iнрииаппем ПМ Задачей последнего является проверка логики программы, ошибки в которой приводят к наиболее тяжелым последствиям. В некоторых случаях структурное тестирование модулей отдельно не проводят, что приводит к переносу части программных ошибок на более поздние этапы и к росту трудоемкости их обнаружения.

Структурное тестирование модулей основано на анализе логики программы или ее графовой модели М2 с целью проверки ее структурной корректности построением набора маршрутов, покрывающих граф программы (G(X,r) - левая доля модели М2 ) в соответствии с критерием С1 Эти маршруты должны обеспечивать проверку функций модуля, обеспечивать его проверку при имеющейся трудоемкости, а также быть реализуемыми, т е приводить к завершению программы при заданных исходных данных. По синтаксически корректной программе осуществляется статический контроль милкчнл о программе конструкций, нарушающих ее сипзпость ("лишних" и "тупиковых" участков ). Одновременно контролируется корректность использования переменных. По структурно корректной программе строится модель М2 и осуществляется оценка количества маршрутов (тестов), покрывающих граф программы по некоторому критерию (например CI). При этом могут использоваться разные методы построения набора покрывающих маршрутов. Каждый построенный маршрут проверяется на реализуемость, ему сопоставляется цель проверки программы на этом маршруте Формирование тестой удобно осуществлять по текстам маршрутов тестирования. Так, в системе Г1РОТВА построение маршрутов тестирования сопровождается распечаткой, текста программы, соответствующего маршруту По этому тексту составляются все необходимые тесты для проверки как структурных, так и функциональных свойств программы на этом маршруте. В программе на языке высокого уровня автоматически достаточно просто построить перечень входных и выходных переменных программы (правая доля модели М2 ). В результате резко снижается трудоемкость формирования тестов и их достоверность. Так же, как и в случае ГП, структурное тестирование может осуществляться с инструментированием отлаживаемой программы или без него. В результате формируется протокол полноты тестирования как по отдельному модулю, так и совокупно по всем модулям ГП или ПС.

Теоретическое и экспериментальное обоснование планов и алгоритмов структурного тестирования программных модулей. Часть модели М2, отражающая поток управления программного модуля, представляет собой связный или сводимый к нему ориентированный граф. Методы построения и основные свойства графа программы достаточно' хорошо описаны в литературе. Граф программы как объект структурного тестирования представляет особый интерес. Для достаточно широкого класса программ систем реального времени и информационно ■ логических задач (22.27] он является адекватной моделью программного модуля. На этом графе

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

■ сопоставление различных наборов маршрутов по обобщенным хара ктеристикам программы, вычисляемым на основании свойств вершин и ду: графа программы. Решение указанных задач создает научно-методическук основу для планирования тестирования модулей и разработки средств ег< автоматизации.

В отличие от ряда работ по структурному тестированию, здесь и дале( предполагается, что тест предположительно завершим, то есть направлен hí исполнение программы от точки входа до точки выхода, и представляет co6oí тройку

Ti = < 1¡, \i\ , Qi >

|i¡ • маршрут тестирования, т.е. последовательность оператороЕ программы (эквивалентных ей дуг и вершин графа G(X,r)), ведущая и; начальной вершины в конечную;

¡i • множество исходных данных, обеспечивающих выполнение

программы по маршруту jii

Q¡ • множество выходных данных программы при ее выполнении пс маршруту )li.

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

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

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

• по трудоемкости, затрачиваемой на тестирование;

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

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

(на всех возможных маршрутах, отличающихся хотя бы одной дугой или

витком цикла • далее метод в общем случае невозможно На практик стараются использовать наборы тестов, соответствующие покрытию граф;' программы наборами маршрутов, удовлетворяющими некоторым критериям (СО. С1 и т п.)

Разработан метод и алгоритм построении так называемого минимально грубого множества тестов (далее используется обозначение метода 16." обеспечивающие построение планов тестирования с количеством маршрут' : не превосходящим циклом»гической сложности (по МсСаЬс) гря-: • программы. Разработанный алгоритм одновременно осушегтвля-преобразование циклического граоа в ациклический и упорядочение верши ■■ последнего по расстоянию от начальной вершины. Разработана и использована в учебном процессе методика (3/'| построения так называемого

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

Оценка сложности плана тестирования. Трудоемкость тестирования в первом приближении можно оценить суммарным количеством условии, анализируемым при построении тестов для проверки программы, а также пр, анализе ее выполнения на тес "ах Предложена математическая модел; сложности тестирования, представляющая собой нижнюю оценку этсг величины на основе понятия суммлрнои сложности тестирования программ!.: введенного в [12| и равного суммарному количеству ветвлений на все\ маршрутах покрытия. Их

^ = 2 Е

Для экспериментальных исследовании в качестве структур программ обладающих минимальной или максимальной сложностью, выделены тр.-"абстрактных" графа |12] симмеяр.гчныи широкий бинарный .>раф (Г!); грае отображающий последовательную проверку условий (Г2): уякий граф (Г3; При исследовании программ с цщ-лами иг базе этих графов образовывали.' циклы замыканием одной из д\г "вверх" Статистические исследован»»-реальных программ показали',что наиболее часто встречают^-структуры,близкие к Г2

Для ациклических программ различной структуры 10) с ростом

количества вершин ветвления (размера) графа суммарная сложност». тестирования возрастает ¡12). Если при минимальном покрытии она растг: пропорционально (практически линейно) количеству вершил; ветвления. : при линейно независимом лпкоытпч пропорционально квад-.м^*. кс."..■ сс- в,-

(а) Сложность тестирования ациклических графов

I I 1 I ч 0,2 0,4 0,6 0,8 1,0

0,2 0,4 0,6 0,8 1,0

Сложность тестирования графов с циклом

(б) Средняя длина маршрута (в) Относительная

сложность тестирования

Рис.10 Сложность планов тестирования

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

Исследование суммарной сложности тестирования графов программ с циклами 113] показало, что сложность тестирования зависит от несколько параметров: структуры графа, степени охвата его циклом, .-.еста расположения цикла на графе. Исследованы зависимости средней длины маршрута в программе с циклом, а также относительных сложности тестирования и числа маршрутов программы с циклом и без цикла. Средняя длина маршрута в программе с циклом возрастает с ростом степени охва'а ее графа циклом. Для минимального покрытия графов произвольных структур этот рост не более, чем в 2-2,5 раза, в то время как для линейно независимого покрытия средняя длина маршрута возрастает значи■ г:;ьяс быстрее, для узкого графа ГЗ - з 6-20 раз

Относительная сложность тестирования программ с циклом для минимальною покрытия с ростом с:епгнм охвата графа циклом не убывает. а для симметричных графов монотонно возрастает При линейно независимом покрытии для симметричных графов Г1 и ГЗ, не все маршруты которых проходят через цикл, характерно уменьшение относительной сложности тестирования при малой степени охвата графа циклом и рост относительной сложности при увеличении степени охвата графа циклом (от 0,4 до 1) Для узкого графа ГЗ имеются как области убывания, так и области возрастания относительной сложности тестирования при разной степени охвата графа циклом. Характерно то, что ь любом случае рост относительной сложности тестирования происходит ни на порядки, а не более чем в 2-2,7 раза.

Исследовано влияние нереализуемых маршрутов программ па сложность плана ее тестирования Эти исследования показали что количество маршрутов тестирования и суммарная сложность тестирс. зависят от того, учитывается или нет наличие и расположение нереали,-. -'мой дуги графа программы в плане тестирования. Заблаговременное исклю- -мне нереализуемых маршрутов ич планов тестирования может сущест; -in'o снизить сложность тестирования программных модулей для всех ра^мгг-

риваемых методов покрытия (% •

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

Сопоставление планов тестирования по достигаемой с!е.ени отлаженности программ цс,-.есол6ра «но проводить исходя из того, что яу .лим планом тестирования яол«ется тлт, после реализации которого не минимальной вероятность пооянленпя ошибки и программе при произвол нил

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

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

р! = (1 • Яи^))

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

Р! = П ли (1-Яи(^)) = П

¡61 )б1

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

Р = Е Р1= Е П1 П О-Яч^)) . ¡=1 1=1

Следовательно вероятность проявления ошибки при случайных данных на входе

МХ

О = 1 - Р = 1 • Е Л1 П

1=1 161

Эта величина характеризует потери от невыявленных ошибок в

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

Для получения теоретических и практически полезных оценок эффективности тестирования проведено моделирование характеристик эффективности тестирования [14] на "абстрактных" ациклических графах, описанных выше, с учетом некоторых гипотез об изменении вероятности ошибок в дугах графа программы после их проверки.

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

4 V

каждой дуге графа программы. Известно, что для слабо структурированных программ число ошибок, выявляемых в процессе тестирования программныv модулей, составляет 1-2% от числа команд этих модулей. Для слабо структурированных программы обработки информации и управления числе условных переходов составляет око.",о 10% от общего числа команд в модуле т.е. ветвление происходит а среднем после исполнения 10 команд линейных участков. В результате 10-20% л.шеииых участков (дуг о графе программного модуля содержат оыиб-.и перед тестирование v. ч~ соотватствует вероятности С]ij=(\ 1 -i'.2 Использование методов структурно; проектирования и программирования позволяет снизить вероятность ошибо-приблизительно на порядок, т.е до уровня ф)= и,01 Поэтому исследование стратегий тестирования проводились в диапазоне Cjij=0,0l-0,1, чт'-соответствует практически наихудшим и наилучшим значениям.

Анализ планов тестирования наиболее полно проведен дл> ациклических графов. Основными параметрами исследования были стратеги* тестирования, критерии покрытия графа (минимальное и линейн> независимое) и вероятности ветвления Стратегия тестирования понимаете, как способ упорядочения тестов (при н\ применении) по некотором* показателю Практический интечнп оредетзвляют две стратегии упорядочение по убыванию вероятности выбора маршрута при произвольны* исходных данных (S1) и г.о хбыилним сложности маршрутов (S2) Вероятности ветвлений выбирались либо равными (0,5), либо с большой асимметрией <0,9;0,1>

Исследование показало, что для всех графов при обоих метода* покрытия и произвольных вероятностях ветвления стратегия упорядочения " вероятности (S1) является лучшей, чем S2, поскольку обеспечивает пг меньших затратах трудоемкости (меньшей сложности) достижения меньше; уровня проявления остаточной ошибки При этом большая асимметри*. вероятностей ветвления приводит к существенным отличиям в снижение вероятности остаточной ошибки по сравнению с равновероятным!' ветвлениями. Для симметричных графов Г) и ГЗ характерно, что снижение уровня остаточной ошибки :рн <0.'1;0.!> ос-х-щес-вляется значительь быстрее, чем при равновероятных в^твл-ниих В .'симметричном графе Г2 п.--же эффект достигается, когдь большее ¡начения вероятности ветвленн-сосредоточены на коротких маршрутах В ::ротнвном случае эффективное г-тестирования при равновероятных ое-:оения> !<ыше чех; пр.: всих:метр;>. вероятности ветвления

ЗАКЛЮЧЕНИЕ-При решении проблемы научно ■ методического обоснование-технических и технологических осчов комплексной автоматизации CASE технологий создания и сонроиочасм-ни «1С >ta основе использования метод;

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

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

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

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

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

без участия человека, на основании информации об объектах проекта ПС и правил, предписываемых моделями. Такой подход применен автором и его коллегами в 1985-1992 г.г. для создания систем НАРА и ТАИС Независимо аналогичный подход применен в ряде современных зарубежных CAS;:. ■ систем.

б. Принципы метода повторного использовании программ • сборо-п ого программирования, обеспечивающего значительную экономию ресурсов ,ри проектировании и реализации ПС различных классов, конкретизирован-- п. виде методик и типовых технологических процессов восходящей и нисходящего сборочного лрограмуироп.чмия. применимых при разлк • -м опыте разрабатывающего чолле <ти1«а. .-••становках задач сборки, класс.- • и типах создаваемых программных сро ;ств Разработана классифин. .и« ситуаций, определяющих принципиальную возмпмнос-ь использования ме v:a сборочного программирования для >-шданкя lit в автоматизм р>- мое проблемной области: полное функциональное различие, полное или части' :ое функциональное подобие и хорошо структурированная область Сформулированы функциональные, конструктивные и технолоп-нкч -\ие условия реализуемости сборочного программирования, позволяк-щие целенаправленно проектировать технологические процессы сбороч; иго программирования для различных прикладных проблемных областей,

6. Выявлены области наиболее • •»фоктипчого применения мето;,. и алгоритме« структурного тестир-•ааьня ч различным объектам проектируй- т;-ПС, что позволяет адекватно осущеетвлт'ь выбор инструментальных сре.-.ств тестирования для применения на разных этапах технологического проце.-са Разработаны математические модели сложности и эффективности тестирования позволяющие сопоставить различные методы и алгоритмы структурного тестирования, В результате проведенного в ра'Ч;те экспериментального исследования стратегий структурного тестиров.ыич показано, что наиболее эффективной .по трудоемкости является стратегия упорядочения тестов по вероятности их выбора, используя которую ;дп тестирования программ, имеющих структуру несимметричного графа, мо-.не-достигнуть некоторого уровня эффекгив»ссти тестирования при снижении его сложности в несколько раз по сравнени:-- с другими стратегиями

7. Внедрение результате,» работы с.с\ществлеио

7.1. В выполнявшихся ho:: р\'*опо..стоом и при участии автора Ш !•' и НИОКР по научно - техническим программам "Информатизация Рос. -и "Перспективные информационные технологии в высшей ш'--,- ,е" "Мелкосерийная и малотоннажная наукоемкая г.рогукиия" Миннауки Р-'л и заказам нижеперечисленных ерглначдш«

- Миннауки РФ «Meгод Никл 40; t

• Роскомннформа (Прогноз Переход, Политика У5. Пирамида);

- Секции прикладных проблем при Президиуме РАН (Лимфа-АН. Кильватер, Кенон),

■ Министе^гва радиопромышленности СССР (ПРОМЕТЕЙ-2, ПРОМЕ ТЕЙ-П)

7.2. В разработанные вод руководством и при участии автора и внедренные ь »личных организ&цнйл промышленности технологические системы:

• ПРОТВА (3 версии) • для разработки двухъязыковых комплексов программ реального времени на ЕС • подобных ЭВМ, сдана в ГОСФАП (регистрационный помер СФЛП "Л.иоритм" 2521440 от 01.02.85), продана около 200 организациям;

• РУЗА (3 версии) • интегрированная настраиваемая кросс-система, функционирующая на ЕС ЭВМ, сдана в ГОСФАП (регистрационный номер СФАП "Ал;ори?.\Г 2521435 о* 30 06 84),продана около 250 организациям,

ТА» 'С • 1р1-нкционир, -о шее на 1ВМ РС - совместимых ЭВМ новое поколение интегрированных программных и аппаратно-программных кросс-систем для создания программ встроенных ЭВМ на базе микропроцессоров К1810 ВМБ6 и Электроника-60, сдана в ГосФАП. внедрена в НИИ АА и НПО ЛП;

■ САБЕ-ИТ ■ среда я зыка четвертого поколения для создания программ на языке С Разработанные под руководством и при участии автора системы ТАИС и СА$Е-КТ экспонировались на международных выставках СЕВ1Т91.94 (Ганновер, ФРГ"), Информагика'90,91,92; Электро'92; Нефть и газ'92.

7.3. В учебный процесс

- Московского института инженеров транспорта, где автор в 1988-1991 г г. читал курс лекций по автоматизации проектирования АСУ;

• Института повышения квалификации МРП. где автор в течение ряда лет читал к) рс технологии программирования.

Основные результаты диссертации опубликованы в монографии Липаев ВВ. Позин Б А , Шгрик А.А Технология сборочного программировании • М. 1992 - 272с и в следующих работах.

1 ПРОТВА АСГК 20002 • 01 ¡983, регистрационный номер СФАП Алгоритм 2521440 от 01 02.85

2. ПРОТВА АСГК. 20002 - 02 1984

3 ПРОТВА АСГК 20002 - 03 1985

4 РУЗА АСГК 3002(3-01 1983, регистрационный номер 2521435 от 30.06.84

5 Модульное проектирование комплексов программ. ОСТ 107,460640 И-87

6 Позин Б.А Метод структурного построения тестов для отладки управляющих программ // Программирование - 1980 ^ 2 -с 62-69

7. Позин Б.А. Основные концепции метода структурного построения тестов // Иерархические автоматизированные системы обработки данных • Киев ИК АН УССР • 19S0 • С.38-43

8. Липаев В.В., Позин Б.А., Лаврищева Е.М., Мальгинов E.H. Технология и система автоматизации разработки программного обеспечения реального времени для ЕС ЭВМ ПРОТВА-У.// Программное обеспечение вычислительных сетей и систем реального времени, Киев: ИК АН УССР -1981 - С. 111-112

9. Потапов А.И., Позин Б.А. Стандартизация структуры и технологического процесса разработки программного обеспечения автоматизированных систем управления реального времени.// Программное обеспечение вычислительных сетей и систем реального времени, Киев: ИК АН УССР -1981 - С.135

10. Липаев В.В., Позин Б.А., Блау С.А. Анализ сложности тестирования логики программ / / Кибернетика - 1982 - N2 - С.45-50

11. Позин Б.А., Догадкин Е.Б., Капичникова Е.Н Технология разработки сложных комплексов программ для ЕСЭВМ с применением САРПО ПРОТВА.// Прогрессивные технологии программирования. - М.: МДНТП, 1983, с.45 - 50

12. Липаев В.В., Позин Б.А., Строганова И.Н. Сложность тестирования структуры программных модулей / / Программирование - 1983 - N 6-с. 65-72

13. Липаев В.В.. Позин Б.А. Сложность структурного тестирования программных модулей с циклами / / Программирование - 1984 • N б -с.70- 77

14. Блау С.А,, Липаев В.В., Позин Б,А Эффективность тестирования структуры программных модулей / / Автоматика и телемеханика - 1984 • N 4 • с.139-148

15. Автоматизация проектирования программ для управляющих и микро -ЭВМ на базе технологической системы РУЗА /Каганов Ф.А., Корепанов Б.А., Липаев В.В., Минаев М.А., Позин Б.А., Серебровский Л.А., Штрик A.A. // Автоматика и телемеханика - 1984 - N 7 - с.159 - 168

16. Позин Б.А., Блау CA Технологические методы и средства повышения качества комплексов программ в САРПО ПРОТВА / /Надежность и качество программного обеспечения - Киев' ИК АН УССР - 1935 - С.165-166

17 Блау С А., Евстигнеев Д.Е., Павлова Т.В., Позин Б.А. Методы и средств тестирования .программного обеспечения реального времени/, Промышленное производство программ для систем реального времени Ереван. Материалы Всесоюзного совещания - 1985 • С.130-133

18. Каганов Ф.А.. Минаев М.А., Позин Б.А., Серебровский JI.А., Штрик к./> ПРОМЕТЕЙ-технология проектирования сложных комплексов программ реального времени / / Промышленное производство программ для систе: реального времени - Ереван: Материалы Всесоюзного совещания - 1985 С.76-70

19. Позин В.А., Блау С.А., Елина М.В., Макогонов C.B., Мурадян А. Р Автоматизация структурного тестирования двухъязыковых программ /, Проблемы совершенствования синтеза, тестирования, верификации и отладк программ • Рига, ЛГУ им. Стучки, т.II - 1986 - с.74-76

20. Комплекс систем автоматизации разработки программного обеспечени реального времени - ПРОМЕТЕЙ / Липаев В.В.,.Штрик A.A., Минаев М.А Каганов ФА.. Позин Б.А., Мессих И.Г. // Вычислительная техник социалистических стран. - 1986 • N 19 - с.121 - 128

21. ПРОМЕТЕЙ • технология • промышленная технология и комплекс средст автоматизированной разработки и сопровождения программных средст! /Липаев В.В, Меликян К.А., Позин Б.А., Серебровский Л.А., Штрик A.A./, Ереван. • 1987 - 38 с.

22. Блау С.А., Псзнн Б.А. Анализ планов тестирования программных модуле с учетом нереализуемых маршрутов. // Программирование - 1988 - N4 с.26-34

23. Хейфец В.M . Позин Б.А. Проблемно-ориентированное комплексное тест! рование программ реального времени // УСиМ - 1989 - N3 -с.56-61

24 Липаев В.В , Позин Б.А , Штрик А А , Кокорев С В. Концепции постр< ения и развития индустриальных технологий разработки программных средст / / Программирование, - 1989 - N 4 - с.76 - 90

25. Позин Б.А., Штрик А.А Выбор инструментальных средств автоматизаци разработки программного обеспечения встроенных ЭВМ // Программнь продукты и системы - 1989 • N 3 - с 20 • 30

26. Позин Б.А. Структурные методы тестирования двухъязыковых комплексе программ.// Актуальные вопросы технологии программирования, ЛИИАН 1989 - с.88-93

. Липаев В.В , Позин Б А , Штрих А А Технология сборочного програм-рованни • 1992 ■ 272 с

. Позин Б.A. CASE • технология, методология и принципы // Рыночные .'Ханизмы н управление в социальных и экономических системах, еждународная научно • практическая конференция • Воронеж: Воронежский )лнтехнический институт • 1992 • с. 43-44

1. Позин Б.A. CASE ■ продукты фирмы MD1S. Методология STRADIS / / >!ночные механизмы и управление в социальных и экономических системах еждународная научно - практическая конференция - Воронеж: Воронежский )лнтехнический институт • 1992 - с.104-105

). Гуляев Н.Б , Кокорев С.В , Крюков C.B., Позин Б.А. ТАИС - гехноло-(ческан система разработки программ для микропроцессоре:; ¡8086. Sl/1 i // CASE -технология - M.: ЦРДЗ - 1992 - с.83-86

1 Гуляев 111)., Пизип Б А. Методология создания информационныл систем TRAD1S // CASH -технология - M.: ЦРДЗ - 1992 - с.68-80

2. Позин Б.А. Автоматизация проектирования программных средств / / :ASE - технология - М.: ЦРДЗ • 1992 - с.

3 Гуляев Н.Б., Позин Б.A. CASE - средства для создания информационных истем.// Рабочие станции. - M : ЦРДЗ - 1992. - С.69 - 80

el Позин Г> А Прннкигп,i реализации и направления развития интегрирован-(ых инструментальных CASE - систем. / / Рабочие станции. - М.:ЦРДЗ • 992. - С.80 • 88

Í5 Позин Б.A. CASE и доя? реальность? будущее? / / Оптимальное проектирование технических устройств и автоматизированных систем. - Воронеж -1992 - С. 5-11

30 Позин В Л Нргч'-.-аммнпе n:.,,0r.-i CASE - средства на выставке СеВГГ'93 // CASE - технология - MЦРДЗ-1993 - с.4-9

37. Оценка планов структурного тестирования программ АСУ // Методические указания к дипломному проектированию для студентов специальности 22.04 - М.: МНИТ, 1990 - С 30

Jti IIojhh В А, Ьлау С А Количественное сопоставление стратегий тестирования управляющих программ. / / Программное обеспечение АСУ. -Калинин, 1980

Ii.

39. Познн Б.А., Блау С.А. Количественное сопоставление стратегии тести вания по критериям суммарной сложности тестирования п вероятно* остаточной ошибки // Синтез, тестирование, верификация и o™aj программ. - Рига, 1981 - с. 180-181

40. Блау С.А., Позин Б.А., Строганова И.Н. Сложность и эффективность 1 тировання структуры программных модулей / / Программное обеспече: АСУ. Секция 1. Методы и средства разработки ПО. - Калинин, 1983 - с.

41. Познн Б.А. Структурное тестирование: концепции, методы, алгоритмы. Технология программирования - Политехника, - Ленинград, 1992 - с.72-84.

7 42. Позин Б.А. CASE-средства и языки четвертого поколения для проен рования открытых информационных систем// Развитие и примене открытых систем - Казань - 1994 - с.П8

43. Познн Б.А. Послесловие научного редактора к книге Архангельский Б Черняховский В.В. Поиск устойчивых ошибок в программах. - М.: Ради связь -'1989. - С. 232 -235

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

В работах [1-3,8,9,11| автору принадлежат основные результаты . принципам построения технологических процессов создания компле! программ и структуре САРГ10 Г1РОТВА.

В работах (10, 12, 14, 38 - 40) автор участвовал в формулирова постановки задачи и математических моделей, а также в анализе редульт, моделирования.

В работе [13] автор сформулировал математическую модель и участш в анализе экспериментальных данных.

В работе [30] автор разработал метод построения диалога системь основе модели управления конфигурацией и участвовал в разраб архитектуры и основных алгоритмов системы ТАИС.

В монографии [27] автор написал главы 4, 5 и заключение. Остал! работы, выполненные в соавторстве, содержат результаты, получе* авторами совместно.