Содержание к диссертации
Введение
ГЛАВА I. СОВРЕМЕННОЕ СОСТОЯНИЕ ПРОБЛЕМЫ ТИПИЗАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ АВТОМАТИЗИРОВАННЫХ СИСТЕМ /3
1.1. Современное состояние проблемы создания программного обеспечения автоматизированных систем 13
1.2. Анализ разработки программного обеспечения систем автоматизированного проектирования объектов капитального строительства 2.0
1.3. Анализ проблемы типизации программного обеспечения систем автоматизированного проектирования
1.4. Методы определения оптимальных параметрических рядов 20
В ы в о д ы Ь9
ГЛАВА 2. МЕТОДИЧЕСКИЕ ОСНОВЫ ТИПИЗАЩИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СИСТЕМ АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ ОБЪЕКТОВ КАПИТАЛЬНОГО СТРОИТЕЛЬСТВА
2.1. Цель и направления исследований 40
2.2. Опыт проведения работ по типизации методов и технологии создания, адаптации и эксплуатации программного обеспечения систем автоматизированного проектирования ^/3
2.3. Постановка задачи определения номенклатуры программных комплексов систем автоматизированного проектирования
2.3.1. Определение проектной задачи
2.3.2. Определение проектной процедуры S3
2.3.3. Определение программы и программного комплекса 56
2.3.4. Формализованная постановка задачи определения номенклатуры программных комплексов систем автоматизированного проектирования 6І
2.4. Применение концепции теории сложных систем для нахождения приближенного решения задачи определения номенклатуры программных комплексов систем автоматизированного проектирования 69
В ы в о д ы 7?
ГЛАВА 3. ОПРЕДЕЛЕНИЕ НОМЕНКЛАТУРЫ ПРОГРАММНЫХ КОМПЛЕКСОВ ОДНИМ РЕШАЮЩИМ ЭЛЕМЕНТОМ ИЕРАРХИЧЕСКОЙ СИСТЕМЫ ОРГАНИЗАЦИОННЫХ УРОВНЕЙ П
3.1. Схема решения задачи ?&
3.2. Качественный анализ проектных задач с целью формирования комплексов задач одной проектной организации 81
3.3. Методы определения комплексов задач одной проектной организации 85"
3.3.1. Разбиение множества проектов на классы с помощью отношений эквивалентности
3.3.2. Разбиение множества проектов на классы с помощью метризованных отношений эквивалентности QZ
3.3.3. Выделение проектов-представителей и определение комплексов задач QS
3.4. Алгоритм определения номенклатуры программных комплексов одним решающим элементом иерархической системы организационных уровней 99
В ы в о д ы {03
ГЛАВА 4. ОПРЕДЕЛЕНИЕ НОМЕНКЛАТУРЫ ПРОГРАММНЫХ КОМШІЕКСОВ
РЕШАЮЩИМИ ЭЛЕМЕНТАМИ ДВУХ ЭШЕЛОНОВ ИЕРАРХИЧЕСКОЙ
СИСТЕМЫ ОРГАНИЗАЦИОННЫХ УРОВНЕЙ
4.1. Схема решения задачи
4.2. Построение критериев эффективности решающего элемента первого эшелона
4.2.1. Затраты на разработку и адаптацию номенклатуры программных комплексов
4.2.2. Затраты на "адаптацию" номенклатуры программных комплексов ІІ6
4.2.3. Объем проектных работ, выполняемый за счет использования "адаптированных" программ
4.2.4. Универсальный критерий эффективности И9
4.3. Краткое описание программы определения параметров номенклатуры программных комплексов
4.4. Построение критериев эффективности решающих элементов второго эшелона
4.4.1. Совместное определение структуры типового программного комплекса и
структур адаптируемых частей всех его копий
4.4.2. Индивидуальное определение структуры типового программного комплекса и совместное определение структур адаптируемых частей всех его копий
4.4.3. Определение структуры типового программного комплекса совместно с индивидуальным определением структуры адаптируемой части каждой его копии
4.4.4. Индивидуальное определение структуры типового программного комплекса и структур адаптируемых частей всех его копий
4.5. Алгоритм определения структур программных комплексов
В ы в о д ы ІЩ
ЛИТЕРАТУРА №
ПРИЛОЖЕНИЕ I. Структура разработанных нормативно-методических документов 16?
ПРИЛОЖЕНИЕ 2. Пример разработки системы признаков для классификации проектов зданий конструктивным решениям {69
ПРИЛОЖЕНИЕ 3. Апробация методики классификации проектов и выделения проекта-представителя из каждого класса
ПРИЛОЖЕНИЕ 4. Результаты моделирования изменения значений параметров номенклатуры программных комплексов в зависимости от значений весовых коэффициентов универсального критерия эффективности
ПРИЛОЖЕНИЕ 5. Результаты моделирования изменения значений параметров номенклатуры программных комплексов в зависимости от значений параметров исходного множества комплексов задач {Q4
ПРИЛОЖЕНИЕ 6. Иллюстративный пример решения задачи определения структур программных комплексов 04
ПРИЛОЖЕНИЕ 7. Пример анализа существующих компонентов программного обеспечения для возможности использования их при определении структур проектируемых программных комплексов
ПРИЛОЖЕНИЕ 8. Справка о внедрении методики и программы для выделения проектов-представителей при определении номенклатуры программных комплексов САПР
- Современное состояние проблемы создания программного обеспечения автоматизированных систем
- Цель и направления исследований
- Схема решения задачи
- Построение критериев эффективности решающего элемента первого эшелона
Современное состояние проблемы создания программного обеспечения автоматизированных систем
Объем научных и проектных работ, выполняемых при помощи ЭВМ, растет по экспоненциальному закону. Это отмечалось, например, на III Всесоюзном семинаре "Системное и теоретическое программирование [I28J . Вместе с ростом объема работ увеличивается и объем ПО автоматизированных систем. Причем, интенсивное нарастание объема ПО сопровождается не менее интенсивным увеличением его сложности. Это является следствием потребности народного хозяйства в автоматизированном решении больших задач со сложной внутренней логикой и большим объемом перерабатываемых данных сложной логической структуры.
Ограниченные возможности ЭВМ обязывают разработчиков ПО бережно расходовать машинные ресурсы - время решения задачи и объем запрашиваемой памяти. Кроме того, ограничивающим фактором на разработку ПО является дефицит программистов, причем программистов всех уровней квалификации. Поэтому разработка ПО в настоящее время является чрезвычайно длительным и дорогостоящим процессом. Вследствие всего этого многие разработки ПО заканчиваются с существенными задержками или даже срывами ранее намеченных сроков. Причем, довольно часто они не удовлетворяют тем требованиям, которые к ним предъявлялись в начальный момент.
Единственным средством преодоления существующих трудностей является вооружение программистов научной теорией, позволяющей формализовать весь процесс создания ПО, начиная от формулировки требований технического задания и кончая проблемами производства, поставки и сопровождения. Это даст возможность уменьшить влияние субъективного фактора на создание ПО. В результате чего ПО можно будет включить в номенклатуру промышленных изделий, ко- торые планируются народнохозяйственными планами, а его разработку перевести на подлинно индустриальную основу. Таким образом можно будет существенно снизить стоимость, сократить сроки создания и повысить качество ПО.
За последнее время выполнено много теоретических исследований, посвященных разным аспектам и проблемам формализации процесса создания ПО. Эти теоретические исследования охватывают довольно широкий круг вопросов: от организации работ, играющей "роль того стержня, который во многом предопределяет "лицо" и содержание проекта" [19] , научной разработки требований, предъявляемых к ПО, принципов построения больших систем, до написания конкретных алгоритмов синтаксического анализа. Столь разносторонний круг задач решается соответственно различными методами, ис- . пользующими разный математический аппарат. Это привело к тому, что в научно-технической литературе в качестве названия предмета, изучающего те или иные стороны процесса создания ПО, используются следующие термины: "теоретическое программирование" и "технология программирования" (84] . Естественно, что границы между отдельными областями исследований, охватываемые указанными терминами,достаточно условны. Более четкую границу между ними скорее можно провести по используемым методам. Теоретическое программирование тяготеет к строгой математической дисциплине, а технология программирования - к научно-технической дисциплине.
Цель и направления исследований
Как было показано в параграфе 1.3, решение проблемы типизации ПО САПР состоит, во-первых, в разработке НМД, описывающих методы и технологию создания, адаптации и эксплуатации ПО, во-вторых, в создании собственно типовых компонентов ПО. Причем, в самой разработке НМД можно выделить два направления. Первое направление заключается в разработке НМД, описывающих самые общие вопросы создания и эксплуатации ПО без акцента на то, какое это ПО - типовое или нетиповое. Второе направление предусматривает разработку НМД, касающихся непосредственно типового ПО.
Данная работа посвящена обоим направлениям в разработке НМД. Причем, основное внимание в работе уделяется второму направлению в разработке ШЩ, полностью базирующемуся на результатах нервого направления. Для разработки НВД второго направления предусматривается применительно к ПО САПР-ОКС развить методы активной типизации, для чего ставится и решается задача, описанная в параграфе Х.4. Для содержательной формулировки такой задачи на основании проведенного анализа современного состояния проблемы создания ПО автоматизированных систем прежде всего необходимо выбрать "наибольшую" компоненту ПО, которую целесообразно типизировать, и выделить ее главный параметр, существенно влияющий на определение оптимальных значений всех других ее параметров.
Наибольшими компонентами специализированного ПО САПР, разработка и использование которых в настоящее время получила широкое распространение и к которым в большой степени подходит термин "изделие", являются ППП. Поэтому типизировать будем именно. Пакет прикладных программ разрабатывается с целью эффективного решения некоторого комплекса задач (КЗ). Оптимальные значения таких параметров ЇЇЗШ, как, например, используемое общесистемное программное обеспечение, структура, языки программирования и т.д. всецело зависят от множества проектных задач, для решения которых он разрабатывается. Поэтому в качестве главного параметра ПШ необходимо взять именно его КЗ.
В целях сокращения написания и удобства чтения в дальнейшем вместо выражений "пакет прикладных программ" и "типовой пакет прикладных программ" будем пользоваться выражениями "программный комплекс (ПК)" и "типовой программный комплекс (ТПК)". Задачу по определению набора ТПК с учетом их адаптации будем называть задачей определения номенклатуры ПК.
Содержательная постановка такой задачи состоит в следующем. Имеется некоторая совокупность проектных организаций, для которых решено разрабатывать САПР. В каждой проектной организации решается некоторое множество проектных задач, поддающихся программной реализации. Основной предпосылкой для возможности типизации ПО служит то, что некоторые проектные задачи решаются более чем в одной проектной организации. Необходимо определить такую совокупность ТПК, чтобы после соответствующего тиражирования отдельных ШК и адаптации их копий оптимальным образом можно было бы решать все задачи заданной совокупности проектных организаций. Под адаптацией некоторой копии ТПК будем понимать расширение КЗ, решение которого первоначально было возможно ТПК, с учетом нужд конкретной проектной организации, в которой она будет использоваться. Критерием оптимальности в данной задаче являются суммарные затраты на создание, адаптацию и эксплуатацию всей номенклатуры ПК.
Схема решения задачи
В данной главе предполагается, что решающим элементом иерархической системы организационных уровней является одна организационная подсистема первого ее эшелона (рис. 2.6.). Другими словами предполагается, что эта подсистема при заданных исходных данных (2.5) может принимать любые решения многоуровневой системы сложности принимаемых решений относительно определения значений параметров компонентов ПО, соответствующих любой страте иерархической системы описания номенклатуры Ж.
Однако отметим, что разработка достаточно жизнестойкой номен- t клатуры Ж зависит в первую очередь от правильности задания и учета изменения исходных данных. Определить исходные данные (2.5) можно только путем объединения соответствующих исходных данных всех проектных организаций gii eji I- УД. В свою очередь при определении исходных данных в одной проектной организации ее представители обычно руководствуются своими частными интересами, которые, как правило, не совпадают с интересами координатора. Тем самым каждая проектная организация, не имея права принимать решения в самом процессе решения задачи, все же может оказывать косвенное влияние на результаты создания номенклатуры Ж.
Организацию работ по определению номенклатуры Ж САПР, исключающую косвенное влияние интересов отдельных проектных организаций, можно представить как последовательность выполнения следующих четырех этапов:
I. Разработка одной или несколькими организационными подсистемами второго эшелона иерархической системы организационных уровней типовой методики, предусматривающей выявление всех проектных задач, определение их параметров и представление собранной информации в заданном видег Согласование методики со всеми остальными организационными подсистемами второго эшелона и утверждение ее у организационной подсистемы первого эшелона.
2. Передача методики решающим элементом первого эшелона иерархической системы организационных уровней организационным подсистемам второго ее эшелона.
3. Определение в каждой организационной подсистеме второго эшелона согласно полученной методике необходимых исходных данных и передача их координатору.
4. Формирование координатором всей совокупности исходных данных и определение по ним номенклатуры ПК САПР.
Напомним, что первая трудность, связанная с решением одним координатором всей задачи определения номенклатуры ПК САПР при задании исходных данных в виде (2.5), обусловлена сложностью формирования альтернативных вариантов количества ТПК и их расширенных областей применения, т.е. с заданием числа Т и распределяющей функции &(х) . Для преодоления такого препятствия на пути решения задачи в данной главе предлагается эвристический алгоритм,позволяющий сократить и упорядочить разбиение множества различных проектных задач X на Т подмножеств
Основная идея такого алгоритма базируется на следующей концепции. Так как наибольшей типовой компонентой ПО, определяемой в рассматриваемой задаче, является ПК, главным параметром которого является его область применения, т.е. КЗ, существенно влияющий на определение оптимальных значений всех остальных параметров ПК, то имеет смысл в исходные данные задачи ввести информацию, характеризующую распределение потребности по проектным организациям в реше -80-тж не только отдельных проектных задач, но и в решении отдельных КЗ. Каждый отдельный КЗ, соответствующий некоторой проектной организации, должен содержать именно такие задачи, для решения которых без учета существования других КЗ, соответствующих этой же проектной организации, желательно иметь один ПК.
class4 ОПРЕДЕЛЕНИЕ НОМЕНКЛАТУРЫ ПРОГРАММНЫХ КОМШІЕКСОВ
РЕШАЮЩИМИ ЭЛЕМЕНТАМИ ДВУХ ЭШЕЛОНОВ ИЕРАРХИЧЕСКОЙ
СИСТЕМЫ ОРГАНИЗАЦИОННЫХ УРОВНЕЙ class4
Построение критериев эффективности решающего элемента первого эшелона
Вместо критерия VV(P &) в качестве первого нового критерия эффективности \д/, (J) ъ s) » значения которого могут быть определены решающим элементом первого эшелона иерархической системы организационных уровней на ранних этапах создания ПО, возьмем суммарные затраты на разработку и адаптацию номенклатуры ПК.
Минимальной информацией, позволяющей вычислять этот критерий эффективности, является исходное множество КЗ X -[л } t iL, Каждый КЗ л соответствует одной проектной организации и содержит задачи некоторой предметной области (7 0 б" Так как информационная взаимосвязь между отдельными КЗ X не учитывается, то решающий элемент первого эшелона иерархической системы организационных уровней согласно алгоритму, изложенному в параграфе 3.4, может определять номенклатуру ПК поэтапно, отдельно для КЗ одной проблемной ориентации.
Наиболее простым предположением, позволяющим оценить затраты на разработку и адаптацию номенклатуры Ж, является предположение, что стоимость разработки ТПК пропорциональна количеству задач, им решаемых, а стоимость адаптации ТПК пропорциональна количеству дополнительных задач, которые он будет решать при внедрении в конкретную организацию,т.е содержательном уровне введенный критерий (4.2) при подстановке в него соотношений (4.3) означает минимизацию количества всех разрабатываемых программ, объединенных в программные комплексы, при условии, что для решения каждой задачи разрабатывается своя новая программа и все задачи одного КЗ могут быть решены одним адаптированным или нет ТЖ. Отмеченное условие запрещает разрабатывать отдельные программы, количество которых равно
I U Х I »т«е., хотя в явном виде не учитывается, но подразу-мевается, что любая программа ПК разрабатывается с учетом взаимосвязи с другими программами этого Щ.
С целью учета влияния каждой задачи на стоимость разработки ПК можно считать, что она пропорциональна стоимости решаемых им задач. Стоимость решения задачи X , независимо от алгоритма ее решения и от того, в каком КЗ X она встречается, обозначим С(х) Тогда выражение для стоимости разработки и адаптации ТЖ можно записать в следующем виде:
Учтем влияние алгоритмической близости задач на стоимость разработки Ж. Напомним, что алгоритмическая близость задач заключается в наличии в их алгоритмах общих фрагментов. Этот фактор будет приводить к снижению стоимости разработки Ж за счет возможности использования одного программного модуля при составлении программ для решения нескольких задач.
Будем исходить из того, что наличие некоторых Ccj (Х) 0 приводит к резкому сокращению количества сочетаний по W?&3 задач, для которых могут существовать общие фрагменты алгоритмов, по сравнению с количеством всех возможных сочетаний такого же числа задач.
