Алгоритмизация задач (стр. 1 из 2)
Алгоритмизация задач
На первом этапе разработки комплексов программ АСУ определяют требования, выполнение которых обеспечивает решение поставленных задач. Основными характеристиками являются время и стоимость обработки информации, вероятность ошибки, допустимые объемы памяти, неизбежность выполнения основных функций и т.п. Требования к системе содержатся в системных спецификациях, которые отображают предполагаемую реализацию системы с помощью ЭВМ. Спецификации являются основополагающим документом в процессе разработки системы. Точность и подробность составления спецификаций определяют вероятность возникновения ошибки на дальнейших этапах разработки. Большинство современных методов создания программного обеспечения допускает появление ошибок в спецификациях проекта, однако цена обнаружения и корректировки ошибок возрастает по мере приближения разработки к завершению. В большинстве случаев ошибки в системе – результат неполных или противоречивых спецификаций (60–70% ошибок). В связи с этим возникает необходимость разработки и использования языков и формализованных методов разработки спецификаций, их анализа и контроля.
В настоящее время известен ряд методов формализации определения спецификаций. Первым шагом в направлении формализации процесса определения спецификаций явилось создание HOS-методологии, основанной на использовании аксиом программного обеспечения высшего уровня, которые определяют допустимые взаимодействия между процедурами задачи. Эти аксиомы предусматривают введение некоторых ограничений на использование процедур. Например, не допускаются ситуации, когда процедура контролирует сама себя, т.е. исключается использование рекурсии, процедура не может управлять пространством своих входных данных и т.п.
Эффективным средством формализации процесса определения спецификаций является система PSL/PSA, которая включает язык определения задач (PSL) и анализатор определения задач (PSA).
Язык определения задач предназначен для отображения функциональных требований к ресурсам. Язык содержит набор средств, позволяющих определять объекты системы, их свойства и взаимосвязи.
Анализатор определения задач осуществляет испытание предложений на языке PSL. Анализатор генерирует базу данных, отображающую системные требования, и осуществляет проверку последовательности и анализ полноты данных.
Система PSL/PSAпозволяет получить формализованное представление проблемы, документирование системных требований в единообразной форме, обеспечивает выявление ошибок, обусловленных неполнотой информации.
Система структурного анализа и проектирования SADTпредставляет собой графическую систему, предназначенную для анализа и проектирования систем. Графический язык системы SADT – это иерархический структурированный набор диаграмм, причем каждый блок диаграммы раскрывается более детально с помощью другой диаграммы. Таким образом, задача представляется все с большей степенью детализации по мере разработки проекта. Система SADTпозволяет повысить качество решений на ранних этапах проектирования на основе легко доступных средств контроля. Однако система не является автоматизированной.
Система SREM, используемая для автоматизации анализа требований, включает язы к определения требований RSLдля установления связи между объектами. Проверка последовательности предложений на языке RSLосуществляется с помощью процессора REVS. Система выполняет следующие операции: разработку требований, включающую описатели данных и этапы их разработки; разработку подробных проектов; моделирование отдельных аспектов проектных решений с учетом принятых допущений; проверку пользователем требований, предъявляемых к системе.
Система структурного проектирования представляет собой неавтоматизированную систему, использование которой обеспечивает создание подробного проекта системы. Система состоит из следующих уровней: подсистема, процесс (часть подсистемы, представляющая отдельную функцию); работа (выполняемая программа или шаг задания); модуль (часть работы). Структурное проектирование выполняется на уровне процесса или работы. Документация включает базисную схему каждого модуля и его полное описание по установленной форме. Функция модуля описывается так, чтобы можно было осуществить его кодирование без использования дополнительной документации.
Приведенные средства определения спецификаций позволяют систематизировать процесс формирования требований к системе, автоматизировать процесс их контроля и снизить вероятность возникновения ошибок, вызванных некорректностью или неполнотой учета условий решаемых задач управления.
Вторым этапом процесса разработки программного обеспечения является составление алгоритма решения поставленной задачи.
При разработке алгоритма решения задачи прежде всего решаются следующие вопросы:
а) следует ли использовать имитационное моделирование или какой-либо из методов оптимизации;
б) следует ли учитывать случайный характер переменных или процессов или использовать детерминированный подход;
в) следует ли учитывать нелинейность некоторых соотношений или достаточно ограничиться их линейной аппроксимацией;
г) можно ли использовать существующие методы решения или требуется разработать новый алгоритм;
д) допустимо ли в данном конкретном случае использование известных оптимизационных методов или необходимо разработать эвристический алгоритм.
При решении приведенных вопросов возникает необходимость оценки качества алгоритмов. Существует много критериев. Чаще всего используется критерий сложности алгоритма, который характеризует время, затрачиваемое алгоритмом на получение решения в зависимости от размера задачи. При этом под размером задачи понимается некоторое число, которое выражает меру количества входных или выходных данных.
Предел временной сложности при увеличении размера задачи называется асимптотической временной сложностью. Аналогично определяется емкостная сложность и асимптотическая емкостная сложность. Именно асимптотическая сложность алгоритма определяет в итоге размер задач, которые можно решить этим алгоритмом. Если алгоритм обрабатывает входы размера п за время сn2, где с - некоторая постоянная, то говорят, что временная сложность этого алгоритма есть О(п2) (читается "порядка n2"). Точнее, говорят, что неотрицательная функция g(n) есть O(f(n)), если существует такая постоянная с, что g(n) ≤ cf(n) для всех, кроме конечного (возможно пустого) множества неотрицательных значений п.
Пусть дано пять алгоритмов А1 – A5(табл. 1). Под временной сложностью здесь понимается число единиц времени, требуемого для обработки входа размера п. В табл. 5.1 приведены размеры задач, которые можно решить за 1 с, 1 мин и 1 ч каждым из этих пяти алгоритмов. Если в качестве основы для сравнения взять 1 мин, то, заменяя алгоритм А4 алгоритмом А3, можно решить задачу в 6 раз большую, а заменяя А4 на А2, можно решить задачу, большую в 125 раз. Если в качестве основы для сравнения взять 1 ч, то различие алгоритмов становится еще значительнее. Отсюда можно заключить, что асимптотическая сложность алгоритма служит важной мерой его качества, причем такой мерой, которая приобретает все большее значение с увеличением размера вычислений.
Таблица 1
Сложность алгоритма определяет также то увеличение размера задачи, которого можно достичь с увеличением скорости машины. Увеличение скорости вычислений в 10 раз увеличивает размер задачи, которую можно решить, для алгоритма А5 только на 3, тогда как для алгоритма А3 – более чем втрое. Однако алгоритм с быстро растущей сложностью может оказаться предпочтительнее для задач с малым размером. Например, если временные сложности алгоритмов А1 – A5равны соответственно 1000n, 100n, logn, 10n2, n3 и 2n, то алгоритм А5 будет наилучшим для задач размера 2 ≤ п ≤ 9, А3 – для задач размера 10 ≤ п ≤ 58, А2 – при 59 ≤ n≤ 1024, aA1 – n> 1024.
Для того чтобы показать, что не существует алгоритма, выполняющего решение задачи менее чем за определенное время, необходимо точное определение того, что есть алгоритм. Уточнение понятий алгоритма и его сложности требует привязки к некоторой конкретной схеме вычислений. Обычно в качестве такой схемы рассматривается машина Тьюринга или так называемая адресная машина. Однако можно принять модель, более близкую к реальному ходу вычислений в оперативной памяти машины с одним процессором, и считать, что вычисления реализуются программой, написанной на некотором упрощении (подмножестве) языка АЛГОЛ.
На первоначальных этапах развития теории сложности в ней чаще всего рассматривались задачи, на которые можно дать лишь один из двух ответов: ДА или НЕТ. Например, классическая "сложностная" постановка известной задачи о ранце (с ограничением в виде равенства) будет заключаться в выяснении того, существуют ли для заданных чисел aj, j= 1,2, ..., nи bзначения булевых переменных xj, удовлетворяющие ограничению
(1)Обычная же формулировка задачи о ранце состоит в максимизации суммы
(2)при условии (1). Однако легко заметить, что ответы на последовательность задач типа "существует ли набор булевых переменных xj, удовлетворяющих (1), такой, что z = kпри k= 0, 1,2, ..." дадут решение задачи о ранце в привычной формулировке. При этом под задачей понимается весь класс однотипных вопросов, различающихся входными данными. Например, в задаче (1), (2) вход представляет собой набор {k, {аj}, {сj}, b}, так что задача о ранце сводится к решению вопроса "существует ли значение целевой функции, равное k, в ситуации, описываемой остальными входными данными". Конкретный набор исходных данных определяет реализацию задачи.