Содержание к диссертации
Введение
1. Анализ развития методов и моделей построения комплексов программ 10
1.1. Эволюция моделей построения комплексов программ 10
1.2. Классификация методов и моделей построения комплексов программ и кризис их развития на современном этапе 27
1.3. Основные методологии построения комплексов программ 34
1.4. Выводы 51
2. Математические основы построения комплексов программ 53
2.1. Проблема сложности создания комплексов программ и разработка требований к среде их проектирования 53
2.2. Базовые модели построения комплексов программ 61
2.3. Модель конструктора моделей 69
2.4. Организация хранения и поиска конструкторов моделей в базе знаний 76
2.5. Выводы 82
3. Разработка методологии построения комплексов программ 84
3.1. Концептуальные положения разработки комплексов программ 84
3.2. Разработка моделей проектируемой программной системы 98
3.3. Разработка конструктора моделей 104
3.4. Выводы 109
4. Проектирование среды разработки комплексов программ 111
4.1. Архитектура среды разработки комплексов программ 111
4.2. Сравнение эффективности разработки комплексов программ 119
4.3. Особенности реализации среды разработки комплексов программ... 128
4.3. Выводы 137
Заключение 139
Список использованныхисточников 141
Приложения 150
- Классификация методов и моделей построения комплексов программ и кризис их развития на современном этапе
- Базовые модели построения комплексов программ
- Разработка моделей проектируемой программной системы
- Сравнение эффективности разработки комплексов программ
Введение к работе
Актуальность проблемы. Все более ускоряющаяся компьютеризация всех областей человеческой деятельности приводит к огромному росту потребности в программных продуктов, которые будут удовлетворять потребностям все новых пользователей. При этом, если на заре компьютерной эры пользователями компьютеров являлись хорошо обученные профессионалы, которых были единицы, то в настоящее время уровень владения языками программирования и даже просто компьютерной терминологией большинства пользователей чрезвычайно низкий. В то же время эволюция языков программирования идет по пути повышения сложности, громоздкости. Для написания простейшей программы требуется хорошее знание основ языка программирования, что является большой редкостью среди работников тех областей, в которых компьютеры появились не так давно. Возникает необходимость привлечения профессиональных программистов, число которых несомненно растет, но не с такой скоростью, с какой растет потребность в их услугах. С другой стороны, эти профессионалы зачастую не владеют проблемной областью того производства, программный продукт для которого их пригласили создавать. Получается, что будущие или настоящие пользователи компьютеров не в состоянии написать программный продукт из-за непреодолимой для них сложности языков программирования, а профессиональные программисты, которых не хватает, вынуждены каждый раз тратить значительное время на изучение предметной области, в которой будет использоваться их программный продукт. Причем далеко не всегда программист способен за столь короткий срок овладеть темой в желаемом объеме. Хотелось бы, чтобы специалист, работающий в своей предметной области, мог сам написать для себя необходимое программное обеспечение. Но пользователи вынуждены эксплуатировать уже готовые программные продукты, которые, даже с учетом какой-то минимальной возможности
модификации под конкретное производство, часто не удовлетворяют требованиям данной предметной области, потому что эти программы унифицированы для повышения количества пользователей в ущерб соответствию потребностям каждого воспользовавшегося этим программным продуктом.
Выходом из сложившейся ситуации может служить создание среды разработки сложных комплексов программ. Эта среда должна быть реализована таким образом, чтобы для создания программного продукта не требовались глубокие познания в области программирования, для того, чтобы качественный программный продукт мог быть написан представителем конкретной предметной области, конкретного производства, который, в свою очередь, владеет темой намного лучше даже самого подготовленного программиста.
Диссертация посвящена научной проблеме, связанной с разработкой математических основ и главных принципов построения сложных комплексов программ, которые была бы ориентированны на профессионалов своих предметных областей, не имеющих глубоких познаний в области программирования, а также с разработкой инструментов для понижения сложности разрабатываемой программной системы.
Разработка программных систем пользователем-непрограммистом с использованием моделей и недоопределенные модели рассматривались в работах Нариньяни А.С., Швецова И.Е., Телермана В.В. Мультипарадигматическому программированию посвящены работы Яхно Т. М., Страуструпа Б. Значительный научный вклад в решение проблем представления и обработки не полностью определенных знаний, представления знаний, описывающих задачи, решаемые в компьютерной человеко-машинной системе гибридного интеллекта, объединения различных видов представления знаний внесли Берштейн Л.С., Мелихов А.Н., Д.Дюбуа, Астанин СВ., Болотова Л.С.
Целью исследований является повышение эффективности разработки сложных программных систем пользователем-непрограммистом.
Для достижения поставленной цели в диссертационной работе решаются следующие задачи:
анализ существующих методов и средств создания программных систем;
анализ сложных систем и понятия сложности;
определение основных факторов, влияющих на разработку сложных программных систем;
разработка математических моделей построения комплексов программ;
выработка методики разработки программных систем;
построение программного обеспечения среды разработки сложных комплексов программ.
В диссертации разрабатываются, исследуются и защищаются следующие основные положения:
моделирование основ разработки сложных комплексов программ;
модель конструктора моделей, поиск конструкторов моделей;
методология разработки сложных комплексов программ;
архитектура среды разработки сложных программных систем. Метод исследований заключается в системном подходе к разработке
принципов, методов и моделей построения комплексов программ. В диссертационной работе использовались теория формальных грамматик, теория графов, элементы теории нечетких множеств, конечные автоматы, методы искусственного интеллекта.
Научная новизна. Основным научным результатом диссертации является разработка моделей построения комплексов программ, удовлетворяющей всем предъявленным требованиям. Вклад в развитие исследований в области создания сложных программных систем складывается из:
моделирования основ разработки сложных программных систем;
модели конструктора моделей;
модели и методы организации хранения и поиска конструкторов моделей.
Практическая ценность и рекомендации по применению.
Выявление недостатков основного пути, по которому идут современные программные технологии и который привел к кризису программирования, позволяет найти пути выхода из него и методы разработки сложных программных систем, в которых эти недостатки будут сведены к минимуму.
Разработанные принципы и методы построения сложных комплексов программ позволяют создать такую среду, в которой смогут работать не только профессиональные программисты, но и специалисты предметных областей, никак не связанных с программированием, но в которых существует потребность в специализированных программных продуктах.
Разработанная методология проектирования сложных программных систем позволяет пользователю-непрограммисту самому создавать нужные ему программные продукты в такой среде разработки комплексов программ, не обладая глубокими познаниями в области программирования, с помощью конструкторов моделей, в которых достаточно знаний в рамках самой предметной области.
Спроектированная среда разработки сложных комплексов программ с некоторым количеством реализованных конструкторов моделей позволяет на практике рассмотреть все достоинства и недостатки нового подхода к созданию сложных программных систем, а также добавлять в среду разработки сложных комплексов программ новые конструкторы моделей предметных областей.
Апробация работы. Результаты работы докладывались и обсуждались на научно-практических конференциях:
XI Всероссийская научно-методическая конференция "Телематика'2004", Санкт-Петербург, 2004;
Международные научно-технические конференции "Интеллектуальные системы" (AIS'05) и "Интеллектуальные САПР" (CAD-2005), Москва, 2005;
Международная открытая научная конференция "Современные проблемы информатизации в моделировании и программировании", Воронеж, 2006.
Публикации. Результаты диссертационной работы были освещены в девяти печатных работах, пять из которых были опубликованы в центральной печати. Четыре были опубликованы в сборниках научных трудов конференций, в том числе три из них в сборниках международных конференций и одна - на Всероссийской конференции.
Объем работы. Материал основной части диссертационной работы изложен на 149 страницах машинописного текста. Диссертация состоит из введения, четырех разделов, заключения и списка литературы из 107 наименований, содержит 27 рисунков, 3 таблицы.
В первом разделе данной диссертационной работы рассмотрены основные парадигмы программирования, а также история развития программирования с позиции возникающих проблем и кризисов и методов и путей их решения вплоть до последнего кризиса программирования, для которого пока не предложено достаточно эффективного метода решения. В разделе рассмотрены недостатки и достоинства уже существующих парадигм программирования, в особенности те достоинства, которыми, по мнению автора работы, не следует пренебрегать в поиске выхода из сложившегося кризиса.
Во втором разделе предложены основные требования, которым должна удовлетворять среда разработки сложных программных систем, выведенные
исходя из анализа сложных систем и выявленных в первом разделе недостатков рассмотренных парадигм программирования и причин текущего кризиса программирования. Среди которых следует выделить ориентированность на пользователя-непрограммиста, наличие средств управления сложностью создаваемой системы, возможность редактирования системы «на лету» в процессе ее создания, поддержка параллелизма, сведение к минимуму самой возможности совершения ошибки пользователем.
В разделе описаны основополагающие понятия, такие как программная система, связь, множество моделей. Рассмотрены модель конструктора моделей и его типы, а также дана иерархия конструкторов моделей и их групп, формализованная через математический аппарат ориентированных графов.
В третьем разделе работы разработана методология проектирования сложных программных систем, предназначенная для пользователя-непрограммиста, который будет создавать свою программную систему в проектируемой среде разработке сложных комплексов программ. В рамках этой методологии рассмотрены концептуальные положения на уровне систем, следование которым может облегчить работу пользователя-непрограммиста и повысить ее эффективность, а также простоту создания систем с высоким уровнем параллелизма.
В четвертом разделе выполнено проектирование среды разработки сложных комплексов программ. Проведено сравнение эффективности разработки комплексов программ, для некоторых примеров, при использовании различных подходов к разработке программных систем.
В заключении содержатся основные результаты проделанной работы, а также указываются пути дальнейшего развития спроектированной среды разработки и рекомендации по добавлению в среду новых конструкторов моделей.
Классификация методов и моделей построения комплексов программ и кризис их развития на современном этапе
Исходя из развития языков программирования, можно ввести их классификацию. Классификацию языков программирования можно провести по-разному в зависимости от рассматриваемых признаков. Чаще всего в качестве основания деления языков программирования выбирается парадигма программирования.
Авторы приведенных выше классификаций языков программирования отмечают, что приведенные ими классификации не претендуют на полноту, т.е. существуют и другие парадигмы программирования. В [51] Классификация языков программирования на основе парадигм программирования обобщается более полно (Рис. 1.4.).
Развитие языков программирования можно рассмотреть как преодоление кризисов программирования [52]. Первые вычислительные машины программировались на аппаратном уровне путем коммутации триггеров соединительными кабелями. Затем появились пульты, с которых программу вводили переключением тумблеров. Первый диалектический кризис информационных систем наступил, когда производительность труда при программировании в машинных кодах с пульта стала отставать от потребностей в вычислениях. Тогда появилось программирование на ассемблере. Но вскоре и этого стало недостаточно, разразился второй кризис программирования — и возникли языки высокого уровня. Третий кризис программирования был снят появлением структурного программирования, в ответ на четвертый (вызванный необходимостью в массовом создании систем с графическим пользовательским интерфейсом) — возникло объектно-ориентированное программирование.
При этом потребности в программных продуктах все больше превосходят возможности программистов. По сведениям [55], "на протяжении многих лет процесс программирования каждый год "совершенствуется" на 4,5%, а это означает, что за последние 50 лет писать программы стало в 10 раз проще (сравните эту цифру с ростом быстродействия компьютеров — за тот же период этот показатель увеличился более чем в миллион раз)". Сегодня все большая часть населения с крайне широким диапазоном потребностей составляет целую армию пользователей персональных компьютеров. Если раньше человека, сидящего за компьютером, можно было смело отнести к классу особо посвященных людей — компьютерщиков, то теперь большинство пользователей — это люди знакомые с компьютером не больше чем с кухонным комбайном. Многие из них не имеют времени или возможности приспособиться к общению с компьютером на уровне понимания его внутреннего устройства и команд. Но соблазнительная стоимость и широкие возможности компьютера привлекают их. Круг задач, решаемых с применением ПК, расширяется, и как следствие этого, увеличивается потребность в новом прикладном программном обеспечении.
Однако, средства разработки программного обеспечения, хотя и развивались все это время, но гораздо меньшими темпами, чем происходило проникновение компьютеров в нашу повседневную жизнь. Для работы с этими средствами до сих пор требуются высококвалифицированные программисты. Несмотря на современные мощные средства разработки, программисты, реально создающие необходимые сегодня программы, до сих пор вынуждены тратить не меньше нескольких недель на проекты, уровень сложности которых хоть сколько-нибудь отличается от нуля.
А разве на уровне домашнего пользователя не нужны индивидуализированные информационные системы? Разве потребности студента и компьютерного художника, писателя и домохозяйки, любителя-фотографа и коллекционера одинаковы? И разве они удовлетворены имеющимся выбором готовых прикладных программ?
Пока потребности пользователей частично удовлетворяются за счет типизированных программ или пакетов, обладающих некоторыми возможностями настройки. Однако решение уже чуть более сложных задач требует навыков и умений программиста, которыми подавляющее большинство пользователей не обладают. Текущий кризис программирования вас обязательно коснется, если вы решите разрабатывать сложную программную систему, например, информационную систему предприятия. При этом не стоит надеяться, что ваша задача не настолько сложна и вас это не затронет. Мир слишком сложен и опыт показывает, что практически любая программная система оказывается достаточно сложной, и что еще хуже — она обычно оказывается гораздо сложнее, чем вы ожидали. Недооценка сложности разрабатываемой программной системы — одна из причин срыва запланированных сроков и даже полных провалов программных проектов. Процесс разработки больших программных систем чрезвычайно сложен и непредсказуем. Программные проекты часто прерываются, выходят за рамки сроков и бюджета и приводят к неудовлетворительным результатам. Причем ужасающа статистика, приведенная в [56]: "только 9% проектов, выполняемых крупными компаниями, завершаются в срок и без превышения запланированного бюджета; 52% проектов стоят в среднем 189% от их первоначально оцененной стоимости; в то же время 31% всех проектов вообще приостанавливаются или полностью прекращаются, причем затраты на них — ничем не компенсируемые убытки".
Обычно разработка программной системы оказывается настолько сложной, что любых имеющихся ресурсов (знаний, количества программистов, времени и т.п.) катастрофически не хватает. Причем далеко не всегда их можно просто увеличить (экстенсивный метод). Например, если вы наберете дополнительных разработчиков, чтобы ускорить разработку, то можете получить прямо противоположный результат. Ведь команда разработчиков — это сложная система и ее нельзя улучшить простым добавлением элементов. Схожая картина и со временем. Если процесс разработки плохо организован — увеличение времени на разработку может ничего не дать, кроме потери времени. В результате, разработчикам приходится мобилизовать все свои ресурсы и работать на пределе своих возможностей. Эти проблемы испытывают даже такие гиганты, как Microsoft, Borland, Symantec и т.п. Иначе, чем объяснить такое низкое качество современного программного обеспечения?
Есть еще одна проблема [53,54]. По мере распространения информационных систем затраты пользователя все больше смещаются с ее покупки на поддержку и сопровождение в процессе эксплуатации. Пока информационные системы могли позволить себе только крупнейшие корпорации, удавалось находить достаточное число инженеров и системных администраторов для того, чтобы системы функционировали нормально. Когда же собственную информационную систему стала требовать каждая мелкая фирма, квалифицированных специалистов для их эксплуатации стало недоставать. Сегодня системный администратор, сетевой администратор -массовые профессии. И если можно требовать высокой квалификации от администратора уникального вычислительного комплекса, обслуживающего научный центр, то уже администраторы серверов локальной сети того же центра (которых может насчитываться несколько сотен) будут иметь гораздо более скромную подготовку.
Базовые модели построения комплексов программ
Одной из главных причин кризиса программирования является нарастающая сложность при проектировании программных систем. Проблема программирования - это проблема управления сложностью.
Любую систему можно представлять в виде совокупности элементов, соединенных между собой различными связями. При этом элементы сами могут являться системами и в свою очередь состоять из подсистем, соединенных связями. Каждый элемент удобно рассматривать как "черный ящик", то есть он имеет входы и выходы для связи с другими элементами, а также внутренность, скрытую от разработчика на данном уровне иерархии. Внутри элемент может быть сколь угодно сложным, но все его поведение (значения выходных сигналов) однозначно определяется последовательностью входных сигналов. В простых случаях элемент является функциональным преобразователем текущих значений входных сигналов в значения выходных сигналов. В сложных случаях (если элемент имеет память) его внутреннее состояние может зависеть от всех значений сигналов, когда-либо подававшихся на вход элемента.
Поток управления G включает в себя управление системой (например, изменение входов, выходов, выбор текущей модели, изменения числа моделей) и управление выделенной моделью (например, настройка универсальной модели предметной области для решения частной задачи). Причем первый подпоток одинаков для всех систем и не зависит от моделей. А второй полностью зависит от текущей модели.
Оператор М представляет собой совокупность любых операций и действий (математических, логических, алгоритмических и т.д.), позволяющих установить соответствие между входными и выходными сигналами. Совокупность доступных операций и действий, а также правила и ограничения их применения для разработки конкретной модели системы определяет язык описания моделей.
Язык описания моделей определим как упрощенное отображение существенных сторон реальной проблемной области, позволяющее в понятиях этой области описать модель системы [75,76].
Исходя из определения язык описания моделей, по сути, есть модель проблемной области. Чтобы далее не возникло путаницы, модель системы будем называть просто моделью, а модель проблемной области - языком описания моделей.
Таким образом, осуществляется запись постановки задачи и методов ее решения в терминах только самой задачи. Проектировщик должен выбрать язык описания моделей из некоторого банка языков и описать с помощью него модель для решения конкретной прикладной задачи. При этом в общем случае пользователь занимается исследованием, а не программированием.
Заметим, что пользователь не обязательно имеет дело напрямую с некоторым языком, в общем случае построение модели может происходить через интерфейс, в том числе возможно и интеллектуальный. Способ взаимодействия разработчика системы (модели системы) и модели проблемной области определяет разработчик языка описания моделей.
С точки зрения пользователя модель можно представлять в виде схемы, изображенной на рис. 2.2. Пользователь записывает правило (оператор) преобразования входных X сигналов в выходные Y с помощью ограниченного языка предметной области (ограниченного по сравнению с естественным языком) либо с помощью какого-нибудь интерфейса пользователя (например, графического). Интерпретатор языка описания моделей преобразует пользовательское описание модели либо в язык, понимаемый компьютером, либо в запись модели на другом языке описания моделей. Язык описания моделей (интерфейс)
Если язык описания моделей базовый (рис. 2.3.)» то его интерпретатор сразу преобразует модель в вид, понятный компьютеру, т.е. автоматически генерирует программу преобразования входных сигналов в выходные.
Интерпретатор Метаязыка описания моделей (рис. 2.4.) преобразует правило, записанное на языке пользователя, в модель, понимаемую интерпретатором другого языка описания моделей. И соответственно использует его для генерирования программы.
Идеальным языком описания моделей являлся бы естественный язык, но его интерпретатор труден для реализации. Некоторые понятия и отношения, определяющие модель системы трудно или нецелесообразно определять внутри только одной предметной области. Поэтому в каждом языке описания моделей должен существовать инструмент, позволяющий использование других языков для доопределения некоторых частей рассматриваемой модели. Чтобы унифицировать этот процесс, необходимо выбрать способ такого взаимодействия и представить его как требование для языка описание моделей. Так как мы создаем модель для системы, то для доопределения ее частей логично использовать подсистемы.
Таким образом, в любом языке описания моделей должны существовать встроенные конструкции, описывающие подсистемы [75,76]. Описание ограничивается только входами и выходами. Т.е. модель относится к подсистеме как к черному ящику, ее не интересует реализация этой подсистемы. Соответственно входы и выходы участвуют в описании модели, в задании понятий и отношений. Подсистема на новом уровне абстрагирования становится самостоятельной системой полностью независимой от модели, впервые описавшей ее. Для реализации моделей этой новой системы соответственно не налагается никаких ограничений на языки описания модели. Ограничения накладываются только на имя новой системы, названия и типы входов и выходов. Менять их можно соответственно только в модели базовой системы.
Исследователь (проектировщик) должен уметь собирать различные точки зрения, коллекционировать полноту представления. Этому способствует множество моделей. Которое, кроме того, поддерживает циклическую модель жизненного цикла системы, отражает эволюцию моделей. Переключение между моделями может осуществляться во время работы системы, через поток управления.
Модель должна позволять рассматривать проблему с различной степенью полноты (настраиваемый инструмент). С помощью потока управления возможна адаптация модели прямо во время работы системы.
Разработка моделей проектируемой программной системы
Для разработки модели системы пользователь должен выбрать конкретный конструктор модели. Общее описание конструкторов моделей и их видов рассмотрено в 2.3. Выбор подходящего конструктора модели осуществляется либо через прохождение ветвей иерархии конструкторов модели и их групп, либо через язык запросов (см. 2.4.). При использовании языка запросов среда разработки выведет упорядоченный список наиболее подходящих конструкторов модели, используя термы запроса и ОКМ (описание конструктора модели) различных конструкторов. Если разработчик системы не смог найти подходящий ему конструктор модели, то существует возможность в рамках одной многопользовательской среды заказать создание нового конструктора модели, более соответствующего его потребностям при построении модели текущей системы. Т.е. разработкой программной системы, необходимой для выполнения задач конкретного пользователя, занимается он сам, используя для этого знакомые для него понятия и конструкции (выбирая соответствующий конструктор модели). А создание конструкторов модели выполняют профессионалы-программисты, скрывающие особенности работы с компьютером за интерфейсом конструктора модели и языком описания модели. Естественно, что создание для каждого пользователя и для каждой системы нового конструктора модели нецелесообразно, да и дорого. Поэтому разработчик всегда имеет возможность использовать ранее разработанные конструкторы. Причем множество конструкторов моделей (хранящееся в виде иерархии) постоянно расширяется в результате работы программистов. Стоимость использования конкретного конструктора модели определяет его разработчик (программист), и ее также можно учитывать при составлении запросов поиска конструкторов модели.
Определим общую последовательность действий, выполняемую при разработке модели системы: 1. Добавление новой модели во множество моделей текущей системы; 2. Выбор конструктора модели наиболее подходящего для текущей системы и конкретного пользователя; 3. Реализация модели системы выбранным конструктором модели; 4. Разработка подсистем, выделенных разработчиком при конструировании модели системы средствами конструктора.
Рассмотрим подробный пример разработки моделей системы. Необходимо создать систему контроля давления газа в замкнутом объеме. Первоначально надо разработать описательную модель, хранящую всю известную информацию о разрабатываемой системе. Выбираем соответствующий конструктор моделей и заносим с его помощью:
Вход системы X - текущее давление газа, Существует оптимальное значение давления Xopt = 1000мм. Необходимо, чтобы система контроля изменяла давление газа в сторону оптимального. Выход системы Y - поворот регулирующего клапана, Y є [0,90]. Если давление газа равно 300 мм, то клапан должен быть полностью закрыт (7 = 0). Если давление газа равно 2000 мм, то клапан должен быть полностью открыт (Y = 90 ). Значение поворота клапана, соответствующее оптимальному давлению, неизвестно, т.к. давление газа зависит не только от клапана, но и от других параметров (температуры, внешнего давления и др.).
Линейная модель проста и легка для реализации, но ее недостаток в том, что достижение эффективного давления маловероятно. Скорее всего, давление и соответственно поворот клапана будут "скакать" вокруг оптимального. Следовательно, не будет устоявшегося значения, когда выход системы не изменит давления газа. Таким образом, программная система будет непрерывно работать, впустую расходуя ресурсы ЭВМ. Отметим, что работа программной системы начинается только тогда, когда меняется какой-нибудь вход системы. Чтобы устранить описанные недостатки можно разработать более сложную модель.
Естественно, что описание этой модели необязательно записывать на ЯОМ, с помощью редактора. Графики преобразование четкого значения давления в лингвистическую переменную удобно вводить графически с использованием манипулятора. Ввод нечеткие правил легко организовать через заполнения стандартных форм.
Теперь у системы есть три модели: описательная, линейная (написанная на языке программирования) и модель на базе нечетких продукций. Можно создавать и другие модели текущей системы. Например, используя настраиваемую модель конечного автомата [77,78], когда выход системы будет формироваться на базе таблиц функций переходов и выходов. Интересной может получиться нейросетевая модель [100,101]. Многие модели можно усложнить и ввести возможность обучения, для приспосабливания модели к конкретной ситуации при неопределенности неучитываемых факторов.
Сравнение эффективности разработки комплексов программ
В ряде работ [6,107] высказывались мнения, что сложность программных модулей зависит от длины программы, от количества альтернатив-предикатов, от количества операндов и т. д. При этом программа как объект исследования может быть описана некоторыми числовыми параметрами, без анализа ее внутренней структуры и логики функционирования. Для определения наиболее адекватных параметров, характеризующих статистическую сложность модулей, проведены и продолжаются исследования, цель которых заключается в выявлении корреляционных связей между различными внешними параметрами программы и процесса ее создания. Статистические исследования реальных корреляционных характеристик программ и процесса разработки позволили выявить наиболее представительные параметры для оценки сложности модулей.
Объем текста программы для определенной задачи зависит от алгоритма и языка, на котором записан текст. Количество символов, необходимых для описания алгоритма, определяется, в частности, полным словарем операторов и операндов данного алгоритма. Полный словарь п характеризует минимальное число бит, которое требуется для описания всех операторов и операндов на соответствующем языке программирования.
Тем самым объем программы характеризуется числом двоичных разрядов, необходимых для записи программы. Под битом подразумевается логическая единица информации - символ, оператор, операнд.
Для сравнения объема программ на различных языках и при различном качестве программирования может быть введен так называемый потенциальный объем описания программ V. Этот объем соответствует наиболее компактному тексту программы для фиксированного алгоритма, написанному на языке самого высокого уровня [107].
Разработка программы по готовому алгоритму состоит в TV-кратном выборе операторов и операндов из словаря, состоящего из п элементов. Для этого необходимо произвести N log2 п число мысленных сравнений, которое равно объему программы V. Каждое мысленное сравнение содержит ряд элементарных мысленных различений, число которых определяется уровнем программы L. На единицу объема программы приходится среднее количество 1/L умственных дискриминаций-решений. Тогда количество умственных сравнений и решений характеризует интеллектуальные усилия на создание программы объемом V:
Таким образом, затраты на создание программ по любым алгоритмам пропорциональны квадрату их объема, независимо от языка программирования. Отсюда очевидна рациональность модульных структур программ, так как при делении на модули затраты сокращаются пропорционально квадрату объема (квадрат суммы всегда больше, чем сумма квадратов).
Экспериментальная проверка [6,107] корреляции интеллектуальной сложности Е с количеством ошибок в программе дала очень высокий коэффициент корреляции 0,98. Следовательно, величина интеллектуальных усилий может полностью объяснить все ошибки в анализировавшихся программах. При этом достаточно хорошо сохраняется пропорциональность между количеством ошибок и величиной Е.
Это выражение проверялось экспериментальными данными [107]. Коэффициент корреляции в первой серии экспериментов на 12 программных модулях разной сложности оказался равным 0,94. Во второй серии для 11 программ получен коэффициент корреляции между экспериментальными и расчетными данными, равный 0,93.
Для оценки адекватности методов и моделей разработки комплексов программ, приведенные выше критерии рассчитываются для двух примеров. Причем для каждого из примеров приведена реализация программной системы как с помощью конкретного конструктора моделей (при использовании разработанной методологии разработки программ), так и с помощью объектно-ориентированного языка программирования С# (при использовании методологии объектно-ориентированного проектирования).
Подробное описание этой системы и разработки ее моделей приведено в разделе 3.2. Сравним реализацию второй модели системы с помощью конструктора моделей на базе языка нечетких продукций и на языке С#. Листинги программ приведены в Приложении 2.
Данные расчетов показывают, что статистическая сложность программы при использовании языка нечетких продукций снижается в 4,5 раза по сравнению с объектно-ориентированным языком С# (в 24 раза, если приходится разрабатывать полную иерархию классов, как обычно и происходит). Объем программы меньше примерно в 5 раз (в 17 раз). Качество программирования возрастает примерно в 10 раз. Интеллектуальные усилия на создание программы уменьшаются в 36 раз (в 170 раз). Время программирования снижается более чем в 30 раз (в 140 раз).
