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

о Ой

г * я® 939

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

_ ПАНТЕЛЕЕВ Петр Анатольевич

УДК 691.3.06

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

Специальность 05.13.11 "Математическое и программное обеспечение вычислительных машин, комплексов, систем

и сетей"

АВТОРЕФЕРАТ

диссертации на соискание ученой степени кандидата технических наук

САНКТ-ПЕТЕРБУРГ 1998

Работа выполнена в Санкт-ПетерОургском

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

Научный руководитель: профессор кафедры

Информационных и управляющих систем, кандидат технических наук Котляров В.П.

Официальные оппоненты:- доктор технических наук, профессор Александров A.M., кандидат технических наук, доцент Журава В.М.

Ведущая организация: АООТ "Информационные телекоммуникационные технологии"

Защита состоится " // "ок^аи-Л!999 г. в часов на заседании диссертационного совета К 063.38.07 в Санкт-ПетерОургском государственном техническом

университете по адресу: 195251, С-Петербург, Политехническая ул., д.29, 3_ уч. корп., ауд.

С диссертацией можно ознакомиться • Фундаментальной библиотеке университета.

Автореферат разослан * Ю " 199 9

г.

Ученый секретарь Попов С.С.

диссертационного

совета

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

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

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

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

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

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

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

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

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

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

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

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

3. Дано теоретическое обоснование разрабатываемой методики.

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

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

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

1. Проведены исследования по применению методики на

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

Научиу» коаиану представляют предложенные автором:

________1. _ -Формальная 'модель корректного многовходного-

многовыходного модуля.

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

3. Методика конструирования спецификаций с использованием визуальной техники.

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

5. Результаты исследований конкретных проектов, построенных с использованием предложенной методики.

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

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

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

Внвдраииа рваультатоа работы. Разработанные методы и средства' , автоматизации проектирования программного обеспечения внедрены в СПП РАИ, НПФ "Юпитер" (Санкт-Петербург) , ЗАО "Северо-Западная Лаборатория" (Санкт-Петербург) и в учебном цикле "Технология программирования" кафедры "Информационные и управляющие системы" СПбГТУ.

Апробация ' работы. Основные результаты рзОоты докладывались и обсуждались на международной научно-

технической конференции "Информационные технологии в моделировании и управлении" (Санкт-Петербург, 1996), на семинарах кафедры "Информационные и управляющие системы" СПОРТУ, а также на симпозиуме по моделированию в г. Финикс, США.

Публикации по «м диссертации. Основные результаты диссертационной работы опубликованы в 6 научных работах.

Структура и объем диссертации. Диссертация состоит иэ введения, четырех глав, заключения и списка литературы. Основная часть работы изложена на 135 страницах и содержит 35 рисунков и 5 таблиц. Список литературы включает 82 наименования.

СОДЕРЖАНИЕ РАБОТЫ

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

В первой части главы рассмотрены различные подходы к построению программ:

• структурное программирование (п. 1.2),

• модульное программирование (п. 1.3);

• объектно-ориентированное программирование (п. 1.4);

компонентное программирование и его различные реализации (п. 1.5).

Во второй части главы (п. 1.6) рассмотрены характерные особенности этапов сборочной технологии программирования.

Третья часть главы (п. 1.7) посвящена обзору наиболее

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

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

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

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

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

Анализ существующих технологий и инструментальных систем

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

Вторая тлям* содержит формулировку модели сборки программной системы, й рамках которой производится:

• построение и обоснование модели структуры и поведения объекта базиса - многовыходного объекта (п. 2.2);

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

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

• расширение объектов базиса на область многовходных-многовыходных объектов (п. 2.4 и 2.5).

В работах, посвященных вопросам устойчивости (робастости) алгоритма, рассматривался подход к созданию операционных модулей р, сохраняющих свойство устойчивости при любых значениях входных переменных. Формальная модель многовыходного модуля строится с помощью оператора с несколькими управляющими выходами. Для этих целей используется аппарат алгебры детерминированных состояний Айгёвьэй йете^минйройаиный еветаяний памяти над (й, 6Ь где В = мнежеетво ячеек памяти (переменных),' с -

множество значений ячеек памяти (констант), называется пятерка (S,0,+,*,0), где S - множество всех частичных

функций из S в S, элементы S называются состояниями памяти, 0------- ----------

пустое (всюду неопределенное) состояние памяти; +,*,& -операции приоритетного объединения, проекции и вычитания, определенные специальным образом.

Пусть задано бесконечное множество М, элементы которого назовем концевыми метками. Оператором назовем произвольную пятерку р = (р, in(p<), outj(p), М(р), р.), где р - частная функция из S в S; М(р)сМ - непустое конечное множество концевых меток; in(p)cR - множество входных, out(p)s;R - множество выходных ячеек оператора р; р - частичная функция из S в М|р), которая называется.распознавателем оператора р.

Формализация свойств устойчивости и замкнутости вводится на основе модели фундаментального оператора, разработанной В.Э.Иткиным (п. 2.2.2.3). Свойство F0 говорит о пассивности дополнительной информации при вычислении значения функции. Это означает, что исключается влияние внешней или глобальной памяти на работу модуля. Свойство Fj говорит о достаточности входной информации в пределах in(р) для определенности значения функции. Это значит, что входная информация поступает только через входы модуля. Свойство F2 говорит о неизменяемости входной информации вне out(p). Это означает, что внешние вычислительные процессы не имеют доступа к внутренней п.амяти модуля. Результаты вычислений могут быть доступны только через выходы, специфицированные в интерфейсе модуля. Свойства G0 и Gj^ для аналогичны свойствам F0 и Fj для функции,р.

Вводится понятие композиции операторов, которое является

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

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

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

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

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

В п. 3.3 формулируется методика проектирования программного обеспечения.

В п. 3.4 обсуждаются результаты,.. достигаемые с-помощью" применения методики проектирования.

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

Предлагаемая методика включает в себя следующие этапы:

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

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

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

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

Методика основана на использовании алгебры сборки объектов из элементов базиса. Использование формального аппарата алгебры сборки позволяет в значительной степени свести проблему корректности программной системы к корректности базовых элементов. Корректность базовых

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

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

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

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

Для поддержки предложенной методики разработан прототип инструментальной системы. Прототип реализован на языке программирования С++ для Microsoft Windows 95/NT 4.0. При разработке учитывалась потенциальная возможность применения

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

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

В первом пункте (п. 4.2) просуммированы основные положения методики проектирования программного обеспечения.

Во втором пункте (п. 4.3) описывается методика сбора и подсчета метрик, применяемая при исследовании проектов.

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

В пункте 4.6 приводятся результаты исследований, проведенных на выполненных проектах. В п. 4.6.1 приводятся результаты исследования трудоемкости разработки проектов. Сравнительный анализ трудоемкости приведен на рис. 1. На графике приведены усредненные зависимости трудоемкости разработанного кода от его объема. Данные измерений взяты из баз развития четырех проектов, два из которых описаны в 4-й главе, выполненных согласно предложенной и традиционной

1Ь .

Рис. 1. Зависимость трудоемкости от объема кода

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

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

В п. 4.6.4 поставлена задача оптимизации характеристик приложения. Как один из вариантов задачи рассмотрена оптимизация подхода к построению словаря базовых объектов.

ЗАКЛЮЧЕНИЕ

Основные результаты работы могут быть сформулированы следующим образом.

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

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

3. Для теоретического обоснования разрабатываемой методики сделано следующее:

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

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

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

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

современном этапе их развития.______

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

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

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

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

Р«ауль«а*ы работ отражены а следующих публикациях:

1. Пантелеев П. А. Механизм взаимодействия виртуальных машин и его реализация в мобильной ОС // Тез. докладов Научно-технической конференции студентов. - С.Пб.: СПОРТУ, 1994

2. Махлушев И.В., Золотников В.Н., Пантелеев П.А. Архитектура комплекса программных средств для системы распределенной обработки графической информации // Тез. докладов Всероссийской научно-методической конференции "Телематика"95". - С.Пб.: ИТМО, 1995

3. Котляров В.П., Махлушев И.В., Пантелеев П.А. Комплекс распределенной обработки графической информации // Тез. докладов Российской научно-технической конференции "Инновационные наукоемкие технологии для России". - С.Пб.: СПбГТУ, 1995

4. Пантелеев П.А., Питько А.Е. Объектно-ориентированный

подход в проектировании моделирующих систем обработки информации // Тез. докладов Международной научно-технической конференции "Информационные технологии в моделировании и управлении". - С.Пб.: СПбГТУ, 1996

5. V.Kotlyarov, P.Panteleyev Visual Component Programming Technology 11 Simulation and Modeling for 10X Cycle Time Reduction Symposium. - Plantation, Florida, 1998.

6. Kotjyarov V., Panteleyev P. An Approach to the Component Design of the Robust Software Systems // Motorola Technical Bulletin. - 1998.

САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

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

ПАНТЕЛЕЕВ Петр Анатольевич

УДК 681.3.06

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

Специальность 05.13.11 "Математическое и программное обеспечение вычислительных машин, комплексов, систем

и сетей"

ДИССЕРТАЦИЯ на соискание ученой степени кандидата технических наук

Научный руководитель

профессор каф. Информационных и

управляющих систем, к.т.н.

Котляров В.П.

Соискатель

Пантелеев П.А.

САНКТ-ПЕТЕРБУРГ 1998

Оглавление

Введение 7.

Основные определения 11.

Глава 1. Обзор литературы по методам и инструментальным

системам разработки 13.

1.1. Структура и задачи главы 13.

1.2. Структурное программирование 13.

1.3. Модульное программирование 15.

1.4. Объектно-ориентированное программирование 16.

1.4.1. Объектно-ориентированные языки 18.

1.4.2. Ограничения объектно-ориентированного подхода 20.

1.5. Компонентное программирование 21.

1.5.1. СОИВА 2 3.

1.5.1.1. Язык определения интерфейсов 23.

1.5.1.2. Хранилище интерфейсов 24.

1.5.1.3. Хранилище реализаций ... 24.

1.5.2. ЗОМ/ББОМ 24.

1.5.3. Технология СОМ 2 5.

1.5.4. ^лгаБеапэ 25.

1.6. Сборочная технология программирования 26.

1.6.1. Анализ требований 27.

1.6.2. Разработка спецификаций 27.

1.6.3. Разработка модулей и сборка системы 31.

1.6.4. Метрики программной системы 33.

1.6.4.1. Модель проекта 33.

1.6.4.2. Нормы макроуровня 35.

1.6.4.3. Нормы микроуровня 3 6 .

1.7. Инструментальные системы поддержки разработки 38.

1.7.1. Формальное направление 38.

1.7.2. Прагматическое направление 39.

1.7.3. CASE-технология 40.

1.7.3.1. Общие понятия 40.

1.7.3.2. Структура CASE-систем 41.

1.7.3.3. Классификация CASE-систем 41.

1.7.3.4. Обзор CASE-систем 43.

1.7.4. RAD-системы 45.

1.7.4.1. Visual Age 46.

1.7.4.2. Microsoft Visual Studio 47.

1.7.4.3. Delphi 48.

1.7.4.4. Общие свойства существующих RAD-систем 49.

1.8. Выводы 50.

Глава 2. Модель сборочной технологии компонентного

программирования 52.

2.1. Структура и задачи главы 52.

2.2. Модель активного модуля сборочной технологии 52.

2.2.1. Модуль "один вход - один выход" 53.

2.2.2. Модуль "один вход - много выходов" 54.

2.2.2.1. ДСП-алгебра 58.

2.2.2.2. Определение оператора 59.

2.2.2.3. Аксиомы фундаментальности оператора 59.

2.2.2.4. Экспликатор многовыходных модулей 60.

2.3. Композиция модулей 62.

2.3.1. Композиция операторов 63.

2.3.2. Циклирование оператора 64.

2.3.3. Операция прополки многовыходного модуля 67.

2.4. Многовходной модуль 68.

2.5. Композиция многовходных модулей 70.

2.6. Выводы 70.

Глава 3. Методика автоматизации проектирования программных

проектов по визуальной компонентной технологии 72.

3.1. Структура и задачи главы 72.

3.2. Основные определения 72.

3.3. Методика визуального проектирования 73.

3.3.1. Пункты методики проектирования 73.

3.3.2. Разработка спецификаций 74.

3.3.3. Реализация модулей 75.

3.3.4. Сборка программной системы 7 6.

3.3.5. Оценка характеристик программной системы 77.

3.3.6. Требования к разработчику 78.

3.4. Свойства методики проектирования 80.

3.4.1. Использование алгебры сборки 80.

3.4.2. Применение визуальной техники 81.

3.4.3. Переиспользование компонент 81.

3.5. Принципы построения инструментальной системы 83.

3.5.1. Терминология 83.

3.5.2. Компонента сборки 84.

3.5.2.1. Базовый класс 86.

3.5.2.2. Составной класс 89.

3.5.2.3. Интерфейс 90.

3.5.2.4. Методы класса 90.

3.5.2.5. Поля класса 91.

3.5.2.6. Графическое представление 91.

3.5.2.7. Текстовое описание 92.

3.5.3. Библиотека информационных объектов 92.

3.5.3.1. Библиотека 93.

3.5.3.2. Папка 94.

3.5.3.3. Ссылка 94.

3.5.3.4. Устройство 95.

3.5.3.5. Типы объектов 95.

3.5.4. Навигатор 96. 3.5.4.1. Операции над объектами 97.

3.5.4.2. Операции drag-and-drop 97.

3.5.4.3. Действия над объектами 98.

3.5.4.4. Контекстное меню 99.

3.5.5. Типы данных 9 9.

3.5.5.1. Арифметические типы данных 9 9.

3.5.5.2. Строковый тип 100.

3.5.5.3. Перечислимый тип 101.

3.5.5.4. Запись 101.

3.5.6. Редактор составной спецификации 101.

3.5.6.1. Фиксация интерфейса 102.

3.5.6.2. Размещение элементов 102.

3.5.6.3. Соединение элементов 103.

3.5.7. Редактор внешнего представления 103.

3.5.7.1. Зона соединения 104.

3.5.7.2. Индикаторы 10 4.

3.5.8. Среда исполнения 105.

3.5.8.1. Загрузка проекта 105.

3.5.8.2. Исполнение 107.

3.5.8.3. Отладка 108.

3.6. Выводы 110.

Глава 4. Оценки методики визуального компонентного

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

4.1. Структура и задачи главы 112.

4.2. Применение методики проектирования 112.

4.3. Метрики разработки проекта 113.

4.3.1. Метрики трудоемкости 113.

4.3.2. Объем приложения 113.

4.3.3. Производительность 115.

4.3.4. Экспериментальные измерения 116.

4.4. Проект 1 117.

4.4.1. Описание блоков 117.

4.4.1.1. Календарь событий 117.

4.4.1.2. Логическое ядро симулятора 118.

4.4.1.3. Исполнитель событий 119.

4.4.2. Реализация базовых элементов 120.

4.4.2.1. Next_Time 12 0.

4.4.2.2. Do_Step 121.

4.4.2.3. Start 121.

4.4.2.4. Timer 122.

4.4.2.5. Min 122.

4.4.2.6. MultiOutput 122.

4.4.3. Метрики проекта 123.

4.5. Проект 2 12 4.

4.5.1. Структура проекта 12 6.

4.5.2. Блок формирования параметров 12 6.

4.5.3. Блок расчета начальной точки поиска 12 6.

4.5.4. Блок расчета траектории 12 7.

4.5.5. Блок вывода результатов 128.

4.5.6. Применение методики в проекте 12 9.

4.6. Результаты исследований 12 9.

4.6.1. Трудоемкость 130.

4.6.2. Издержки по памяти 132.

4.6.3. Издержки по производительности 133.

4.6.4. Оптимизация характеристик приложения 134 .

4.7. Выводы 137. Заключение 138. Литература 142.

Введение

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

Существует множество моделей жизненного цикла программного обеспечения. Одной из наиболее распространенных является модель, описанная в [63]. На рис. 0.1 показаны

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

Проектирование

Разработка

Поставка

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

Рис. 0.1. Жизненный цикл программного обеспечения

этапы создания программного продукта согласно этой модели. В России модель жизненного цикла определена стандартом (ГОСТ 34.601-90), который вводит следующие этапы:

• формирование требований к программной системе;

• разработка концепции системы;

• разработка технического задания;

• эскизный проект;

• технический проект;

• рабочая документация;

• ввод в действие;

• сопровождение.

Так как эти модели во многом схожи, в дальнейшем будем опираться на первую модель (рис. 0.1), как наиболее полную и распространенную во всем мире.

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

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

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

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

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

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

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

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

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

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

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

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

3. Дать обоснование разрабатываемой методики.

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

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

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

7. Провести исследования по применению методики на реальных проектах.

Основные определения

Приведем базовые определения согласно стандарту IEEE [66] (в алфавитном порядке):

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

Метрика. Количественная оценка характеристики (атрибута) системы, ее компоненты или процесса.

Модуль. Логически независимая часть программы. В данном значении также часто употребляется термин "компонент". Использование этих терминов в настоящее время не стандартизовано.

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

Программный продукт. Компьютерная программа,

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

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

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

CASE (Computer-Aided Software Engineering).

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

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

DFD (Data Flow Diagram). Диаграмма потоков данных. Диаграмма, на которой изображаются источники данных, прохождение данных и процессы преобразования данных в качестве узлов и логический поток данных в качестве связей между узлами.

Глава 1. Обзор литературы по методам и инструментальным системам разработки

1.1. Структура и задачи главы

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

В первой части главы рассмотрены различные подходы к построению программ:

• структурное программирование (п. 1.2);

• модульное программирование (п. 1.3);

• объектно-ориентированное программирование (п. 1.4);

• компонентное программирование и его различные реализации (п. 1.5).

Во второй части главы (п. 1.6) рассмотрены характерные особенности этапов сборочной технологии программирования.

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

В заключительной части главы (п. 1.8) формулируются требования к эффективной инструментальной системе по критерию снижения трудоемкости разработки программного обеспечения.

1.2. Структурное программирование

Понятия "структурное программирование" и "структурное проектирование" появились в 7 0-е годы. Теоретическая основа

структурного программирования была заложена Боэмом и Жакопини [52], а его практические принципы были сформулированы Э.Дейкстрой [10,57]. В нашей стране работы в этом направлении велись В.М.Глушковым [9].

Авторы работы [32] описывают основные принципы структурного программирования следующими определениями:

1. Структуризованная программа - это программа, составленная из фиксированного базового множества первичных программ.

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

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

Если программное обеспечение строится только из первичных и простых программ, то логика и сам ход процесса ее выполнения значительно проясняются благодаря структуризации. Использование таких структур дисциплинирует разработчика программ, что в результате приводит к появлению более понятных программ, в которых, следовательно, имеется меньшее число ошибок [44].

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

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

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

1.3. Модульное программирование

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

Одними из наиболее ярких реализаций модульной технологии программирования являются модули языка Модула-2 [7] и пакеты языка Ада [11].

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

Использование модулей дает следующие преимущества [48]:

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

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

1.4. Объектно-ориентированное программирование

Идейным предшественником концепции объектно-

ориентированного программирования явилась концепция абстрактных типов данных (АТД). Термин "абстрактный тип данных" был введен в 1974 г. в работе [72], посвященной принципам языка СЬИ. Новое, что было внесено авторами СЫТ в программирование и послужило толчком для развития области АТД, - это, во-первых, отделение внешнего описания (интерфейса, спецификации) данных и операций от их внутреннего представления (реализации) и, во-вторых, инкапсуляция (скрытие, защита) внутреннего представления от действий, не включенных во внешнее описание. Самая общая идея АТД - это идея описания и использования данных на соответствующем, адекватном уровне абстракции [3].

В объектно-ориентированном программировании (ООП) базовыми единицами программ и данных являются объекты [42] . Объект состоит из следующих трех частей:

• имя объекта;

• состояние (переменные состояния);

• методы (операции).

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

Поведение программной системы формируется поведением составляющих ее объектов. Таким образом, одним из свойств объектно-ориентированного подхода является децентрализация управления [8].

Интерфейс объекта с его окружением полностью определен

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

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

Совокупность объектов в системе объектно-

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