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

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

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

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

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

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

1. планирования и организации всего технологического процесса проектирования КП вплоть до серийного изготовления ПС;

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

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

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

5. обеспечения испытаний программных компонент и всего КП;

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

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

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

Необходимо стандартизировать структуру и формы представления документов на разработанную и испытанную программу. В настоящее время такой стандарт существует и носит название «Единая система программной документации».

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

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

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

2.2. Этапы проектирования сложных пс

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

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

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

Рис. 1. Схема процесса разработки программ

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

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

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

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

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

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

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

2.3. Разработка алгоритмов

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

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

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

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

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

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

2.3.1. Общие понятия об алгоритмах

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

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

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

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

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

1. Конечность. Работа алгоритма должна заканчиваться за конечное число шагов.

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

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

4. Вывод. Алгоритм должен давать некоторый результат.

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

Существует множество разных приемов записи алгоритмов. К изобразительным средствам описания относятся основные способы их представления:

1. словесный – представляет собой описание последовательности действий с тщательным отбором слов, так, чтобы лишних слов, синонимов и т.п. в записи алгоритма не было;

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

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

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

1) Математическое описание задачи

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

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

Если каждый элемент множества А является элементом множества U, то говорят, что A включено в U и обозначают A U. В этом случае говорят, что A является подмножеством множества U.

Пусть U – множество, А – подмножество множества А. Тот факт, что элемент x множества U принадлежит подмножеству А, обозначают в виде . Однако для выражения этой принадлежности можно использовать понятие характеристической функции, значения которой указывают, является ли x из U элементом подмножества A:

Здесь принимает только два значения 0 и 1. Представим теперь, что характеристическая функция может принимать любое значение в интервале [0, 1]. В соответствии с с этим элемент x множества U может не принадлежать подмножеству А ( =0), может быть элементом А в небольшой степени ( близко к 0), может более или менее принадлежать А ( не слишком близко к 0 и не слишком близко к 1), может в значительной степени быть элементом А ( близко к 1) или, наконец, может быть элементом А ( =1).

Пусть U – есть множество, счетное или нет, и x – элемент U. Нечетким подмножеством А множества U называется множество упорядоченных пар A={( , x)}, где - функция принадлежности, принимающая свои значения во вполне упорядоченном множестве М, которая указывает степень или уровень принадлежности элемента x к подмножеству А. Множество М называется множеством принадлежностей. Наряду с термином «нечеткое подмножество» используется также термин «нечеткое множество».

Если М={0, 1}, то нечеткое подмножество будет рассматриваться как обычное подмножество некоторого универсального множества.

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

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