Глава 1. ОСНОВЫ ТЕОРИИ ПРОЕКТИРОВАНИЯ

1.1. ОБЩИЕ ПОЛОЖЕНИЯ

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

            Проектным документом называют документ, выполненный по заданной форме, в котором представлено какое-либо проектное решение.

            Проект — совокупность проектных документов в соответствии с установленным перечнем, которая представляет результат проектирования.

            Проектной ситуацией называется реальность (ситуация), в которой ведется проектирование.

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

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

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

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

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

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

            Стратегия — наука, искусство генерации наиболее существенных общих целей и тактик их достижения.

            Тактика — совокупность средств и приемов для достижения намеченной цели и искусство их применения.

            Метод — способ практического осуществления чего-нибудь.

Методика — совокупность методов практического выполнения чего-нибудь.

            Методология (от греч. «учение о методах») — система принципов и способов организации и построения теоретической и практической деятельности, а также учение об этой системе.

            Современная методология проектирования позволила довести методы проектирования до технологий с набором методик (технология проектирования — апробированная стратегия проектирования).

            Методики излагаются в виде описаний проектных процедур, которые содержат алгоритмы (только для тривиальных нетворческих операций) и эвроритмы (которыми излагаются эвристические операции). Эвроритм может включать алгоритмы. Термин эвроритм образован от легендарного возгласа Архимеда «эврика!», что в переводе с греческого — «нашел, открыл».

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

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

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

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

            Проектные процедуры могут включать другие проектные процедуры и т.д., до проектных операций.

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

            Перед нами также стоит вопрос, который уже ранее был упомянут: «Как определить, достигнута ли цель, привела ли деятельность к желаемому результату: тот ли объект создан, который нам нужен, обладает ли он нужными свойствами?» Для этого используются показатели качества (иногда их называют критериями) — величины, свойства, понятия, характеризующие систему с точки зрения субъекта, позволяющие оценить степень удовлетворения его потребностей. На начальном этапе проектирования анализ потребностей позволяет определить вид объекта, его функции (что объект делает при функционировании), свойства и состояние, при которых удовлетворяются потребности.

            При проектировании решаются задачи синтеза и анализа.

            Синтез — это процесс построения описания системы по заданному функционированию.

            Анализ — процесс определения функционирования по заданному описанию системы.

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

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

            — информацию об условии (условие задачи) — что задано;

            — информацию о решении (признаки исходной ситуации)— что требуется получить;

            — информацию о технологии преобразования условия в решение — как решить.

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

            Рассмотрим пример. Необходимо в уме сложить числа 4 и 3. Ответ, разумеется, 7. Необходимо в уме перемножить числа 7 и 9. Ответ, конечно, известен — 63. Но если вы не знаете таблицы умножения, то надо выполнить нестандартное преобразование в виде многократного сложения. Трудно ли оно для вас? Необходимо в уме перемножить числа 289 и 347. Если вы не феноменальный счетчик, то хватит ли в вашей голове оперативной памяти? Однако если выполнить методическое преобразование, известное еще со школы, с использованием ручки и бумаги, то вы; скорее всего, справитесь и с этой задачей. Более того, полученное вами на бумаге решение сможет проверить любой заурядный человек, который владеет необходимым методическим обеспечением в виде стандартного школьного алгоритма сложения.

            Обычный нормальный человек со средними способностями может одновременно в своей голове удержать не более семи мыслей. В школе задачи с шестью действиями считаются задачами повышенной сложности и помечаются символом «*». В армиях разных стран, времен и народов производилось деление на десятки, сотни, тысячи. У командиров в подчинении находилось либо десять воинов, либо десять младших командиров.

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

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

            В табл. 1.1 приведены пять признаков сложной системы вместе с примерами. Эти признаки инвариантны как для осязаемой системы из реального мира «музыкальный центр», так и для программной системы — текстового редактора.

1.2. ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ ПРОГРАММ

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

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

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

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

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

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

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

1.3. СИСТЕМНЫЙ ПОДХОД И ПРОГРАММИРОВАНИЕ

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

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

            Структурный анализ — выявление элементов объекта и связей между ними.

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

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

            Генетический анализ — исследование объекта на его соответствие законам развития программных систем. В процессе анализа

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

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

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

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

            Локальная оптимизация подразумевает улучшение параметров внутри каждой простой задачи.

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

            Повторяемость — в использовании существующего опыта проектирования.

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

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

1.4. ОБЩЕСИСТЕМНЫЕ ПРИНЦИПЫ СОЗДАНИЯ ПРОГРАММ

            При создании и развитии программного обеспечения (ПО) рекомендуется применять следующие общесистемные принципы:

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

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

            3) принцип развития, предусматривающий в ПО возможность его наращивания и совершенствования компонентов и связей между ними;

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

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

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

            7) принцип инвариантности, предопределяющий, что подсистемы и компоненты ПО инвариантны к обрабатываемой информации, т. е. являются универсальными или типовыми.

            1.5. ОСОБЕННОСТИ ПРОГРАММНЫХ РАЗРАБОТОК

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

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

            — процедурно-ориентированные — алгоритмы;

            — объектно-ориентированные — классы и объекты;

            — логически-ориентированные — цели, выраженные в исчислении предикатов;

            — ориентированные на правила — правила «если..., то...»;

            — ориентированные на ограничения — инвариантные соотношения;

            — параллельное программирование — потоки данных.

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

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

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

1.6. СТАНДАРТЫ И ПРОГРАММИРОВАНИЕ

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

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

            Группа стандартов ГОСТ «Единая система программной документации» (ЕСПД) претерпела мало изменений с момента ее создания, пережила несколько поколений ЭВМ и революционных изменений технологий разработки программ. При этом она до настоящего времени никогда не затрудняла новаций.

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

           В области программирования общепризнанной ведущей организацией по разработке стандартов является институт ANSI (Американский национальный институт стандартов). Данный институт является лидером по установке стандартов языков программирования, кодовых таблиц клавиш и символов, выводимых на экран, и еще многих других. Необходимо также отметить стандарты ISO.

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

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

1.7. ОПИСАНИЕ ЦИКЛА ЖИЗНИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

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

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

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

            1.8. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ ПРОГРАММ

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

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

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

            Стадии и этапы разработки программ по ГОСТ 19.102 — 77 на момент написания книги даны в приложении 1.

            Программный документ «Техническое задание» (T3) помимо основных требований к программному изделию содержит проект порядка взаимодействия заказчика и исполнителя по окончании конкретных этапов, т.е. перечень необходимых стадий и этапов и требований к их выполнению. ТЗ может сразу не устанавливать всех требований, которые могут быть уточнены и согласованы с заказчиком на последующих стадиях. Однако сама возможность изменения требований должна закладываться в ТЗ.

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

            «Технический проект» (ТП) выполняется для получения однозначного описания конечного (оптимального) варианта построения программного изделия и порядка его реализации.

            «Рабочий проект» (РП) необходим для реализации изделия в соответствии с ранее намеченным планом.

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

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

            В соответствии с ГОСТ 19.102 — 77 допускается исключать стадию ЭП, а в технически обоснованных случаях — стадии ЭП и ТП. Допускается объединять, исключать этапы работ и (или) их содержание, а также вводить другие этапы работ по согласованию с заказчиком. Это позволяет разумно построить проект конкретной разработки (ход проекта также является объектом проектирования).

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

            • ТЗ (T3 основное плюс ТЗ на отдельную НИР);

            • ожидание результатов НИР, выполняемой в другой организации специалистами-математиками (срок от месяца до нескольких лет);

            • РП (около месяца);

            • внедрение.

            Пример 2. Требуется разработать программное изделие средней или большой сложности. При средней сложности изделия необходимо проведение ТП, а при большой сложности — и ЭП, и ТП. В отличие от примера 1 в данном случае ТЗ может не содержать законченных требований.

            Пример 3. Требуется создать программные средства, автоматизирующие отдельные виды работ. Разработка такого проекта может проводиться по следующим стадиям:

            • ТЗ;

• ЭП с НИР по исследованию существующих программных средств, автоматизирующих выполнение отдельных видов работ;

            • РП по разработке только документации без реализации каких-либо программ, если НИР показала, что можно обойтись только существующими программными средствами;

            • внедрение. 

Пример 4. Разработка таких информационных систем, как

            САПР или АСУ должна осуществляться в соответствии с соответствующими стандартами. ТП САПР или АСУ может содержать технические задания на разработку отдельных программных изделий. Как правило, такие ТЗ очень конкретны. На этапе РП САПР или АСУ сначала ведется контроль над разработкой программных изделий по всем необходимым для этого стадиям разработки программных изделий, затем проводится совместная проверка всех разработанных программ.

            Обычно основанием для заключения договора между заказчиком и исполнителем служит гарантийное письмо заказчика. На основании гарантийного письма составляется договор. Обязательным приложением к договору является ТЗ.

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

            1) анализ требований, предъявляемых к системе (системный анализ). (Обычно проводится на основе первичного исследования потоков информации при традиционном проведении работ с фиксацией видов этих работ и их последовательности.);

            2) определение целей, достигаемых разрабатываемыми программами;

            3) выявление аналогов, обеспечивающих достижение подобных целей, их достоинств и недостатков;

            4) постановка задачи на разработку новых программ, определение внешних спецификаций (т. е. описаний входной и выходной информации, а иногда и их форм) и способов (алгоритмов, методов) обработки информации;

            5) оценка достижения целей Разработки (Далее, при необходимости, этапы 1 — 5 могут быть итеративно повторены до достижения удовлетворительного облика изделия с описанием выполняемых им функций и некоторой ясностью реализации его функционирования.);

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

            7) разработка окончательного варианта архитектуры системы и разработка окончательной структуры программных компонент;

            8) составление и проверка спецификаций модулей;

            9) составление описаний логики модулей;

            10) составление окончательного плана реализации программ;

            11) кодирование и тестирование отдельных модулей и совокупности готовых модулей до получения готовой программы;

            12) комплексное тестирование;

            13) разработка эксплуатационной документации на программу;

            14) проведение приемо-сдаточных и других испытаний;

            15) корректировка программ по результатам испытаний;

            16) окончательная сдача программного изделия заказчику;

            17) тиражирование программного изделия;

            18) сопровождение программы.

            Современные технологии проектирования программного обеспечения (ПО) направлены на частичную автоматизацию этапов и на совмещение их во времени с целью сокращения сроков выполнения проектов.

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

            1.9. ТИПОВЫЕ ОШИБКИ ОБУЧАЕМЫХ ПРИ СОСТАВЛЕНИИ ТЕХНИЧЕСКОГО ЗАДАНИЯ

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

            Главным, что отличает одно T3 от другого, является смысл требований. Все требования оформляются предложениями с использованием оборотов «должно», «требуется обеспечить», «необходимо выполнить». Рекомендуется требования оформлять в форме нумерованных подпунктов. Это позволит давать на них ссылки.

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

            Ниже приведены типовые ошибки обучаемых при написании требований к функциональным характеристикам:

            • непонимание термина «функциональные характеристики» (Смысл этого термина характеризуется следующим предложением: «Проектируемый завод в нормальном режиме работы должен обеспечить выпуск за одну 8-часовую смену не менее 40 пропашных тракторов». Эта фраза содержит как назначение проектируемого объекта — завода, так и то, что выпускает завод и при каких ограничениях. Применительно к программам, для правильного написания требований к функциональным характеристикам необходимо сторонними глазами будущего пользователя рассмотреть, что делает полезного программное изделие и при каких ограничениях.);

            • описание требований к функциональным характеристикам всеобщего, универсального объекта (если по конкретным требованиям можно реализовать целый спектр изделий, то они не конкретны);

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

            1.10. МОДЕЛИРОВАНИЕ И ПРОГРАММИРОВАНИЕ.

            ПОНЯТИЕ СПЕЦИФИКАЦИЙ

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

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

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

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

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

            Любые достаточно большие программы являются сложными системами. Проблема сложности преодолевается путем декомпозиции задачи. Базовая парадигма в подходе к любой большой задаче ясна: необходимо «разделять и властвовать»,

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

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

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

            Отдельные виды абстракций определяют наиболее

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

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

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

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

            Спецификация может описывать соглашение между программистами и заказчиками (пользователями). Программист берется написать программу, а пользователь соглашается не полагаться на знания о том, как именно эта программа реализована, т. е. не предполагать ничего такого, что не было бы указано в спецификации. Такое соглашение позволяет разделить анализ реализации от собственно использования программы. Спецификации дают возможность создавать логические основы, позволяющие успешно «разделять и властвовать».

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

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

            Уже в первичных спецификациях можно выделить две части: функциональную и эксплуатационную.

            Первичная функциональная спецификация в первую очередь описывает:

            — объекты, участвующие в задаче (что делает программа и что делает человек, работающий с этой программой);

            — процессы и действия (проектные процедуры и эвроритмы для человека, алгоритмы методов решения задачи в машине с указанием сути и порядка обработки информации с занимаемым ей и программой размером оперативной памяти);

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

            То есть вначале фиксируются внешние функциональные спецификации, а затем и внутренние.

            В общем случае внешние функциональные спецификации включают:

            — описание того, что делает программа;

            — определение, что делает человек, а что машина (по каким эвроритмам работает человек, откуда он берет информацию и как ее готовит к вводу в ЭВМ);

            — спецификации входных и выходных данных;

            — реакции на исключительные ситуации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

            Например, абстракцию SQRT (извлечение квадратного корня) можно сравнить с операцией: она абстрагирует отдельное событие или задачу. Мы будем ссылаться к абстракциям такого рода, как к процедурным абстракциям. Отметим, что абстракция SQRT включает в себя как абстракцию через параметризацию, так и абстракцию через спецификацию.

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

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

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

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

            Поток данных соединяет выход объекта (или процесса) с входом другого объекта (или процесса). Он представляет промежуточные данные вычислений.

            Хранилище данных — это пассивный объект в составе ДПД, в котором данные сохраняются для последующего доступа. Хранилище данных допускает доступ к хранимым в нем данным в по

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

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

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

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

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

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

            Шаг 1. Основываясь на потоке данных в задаче, выделите 3 — 10 смысловых частей обработки данных.

            Шаг 2. Доопределите главный входной и выходной потоки данных задачи.

            Шаг 3. Проследите, как следует входной поток от части к части, от входа к концу обработки, найдите эту точку. Проследите от конца к началу, как следует выходной поток; найдите абстрактную точку, где он появился (рис. 1.7).

            Найденные точки делят задачу на две или три наиболее независимые (по данным) части.

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

            Шаг 5. Определите сопряжения подпрограмм по данным. Современная, вытесняющая технологии структурного программирования и абстракции данных объектно-ориентированная технология сочетает в себе абстракции процедур и данных в новой абстракции — объекте (рис. 1.8).        Понятие абстракции данных расширено до того, что как внутренние данные, так и код процедур рассматриваются как новый тип данных — объект.

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

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

1.11. ПРОБЛЕМА ТИПОВЫХ ЭЛЕМЕНТОВ В ПРОГРАММИРОВАНИИ

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

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

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

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

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

            Для тиражирования таких элементов программ, как редактор текстов, система иерархического меню, элементов диалога типа «заполнения бланков» фирма «Borland Inc.» предложила применять TPU — Turbo Pascal Unit (модуль ОВJ в ряде языков). TPU-файл позволил использовать механизм сокрытия в секции Implementation неинтересных внутренних подпрограмм и внутренних данных и, наоборот, вне файла механизм сокрытия обеспечил открытость вызова только полезных для пользователя процедур и использование внутренних глобальных переменных, описанных в секции Interface. После этого нововведения программисту для использования, например, редактора, написанного не им, надо знать лишь информацию, описанную в секции Interface. Механизм сокрытия информации в пределах файла был введен еще в целый ряд компиляторов разных языков. Реализация механизма сокрытия упростила задачу использования «кубиков».

            Объектно-ориентированные языки программирования дали четыре новых механизма использования кубиков:

            1) механизм классов, порождающих при выполнении любое количество однотипных объектов, например, ряд однотипных кнопок;

            2) возможность тиражирования объектов от породившей программы во все новые программы;

            3) динамически линкуемые библиотеки с порождающими объекты классами;

            4) механизм сборки программ из «кубиков» — объектов в процессе их выполнения.

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

            Второй механизм привел к возникновению объектно-ориентированных СУБД, поставляющих программам не только данные, но и код, обрабатывающий эти данные.

            Третий и четвертый механизмы позволили попытаться строить гибкие программы, обладающие свойством возможного развития при изменении условий их эксплуатации. Впервые возможность реализации получили идеи эволюционного программирования. Идеи прошлых технологий эволюционного программирования были явно недостаточными для обеспечения гибкости программ, что для длительного развития в изменчивой внешней среде требовало невозможного однозначного предсказания будущего. На основе третьего механизма возникли СОМ-технологии. На основе четвертого механизма Александром Усовым предложен способ создания «кубиков» из «кубиков».

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

            ВЫВОДЫ

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

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

            • При разработке программного обеспечения следует использовать следующие общие принципы: частотный; модульности; функциональной избирательности; генерируемости; функциональной избыточности; «по умолчанию».

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

            • При создании и развитии ПО рекомендуется применять следующие общесистемные принципы: включения; системного единства; развития; комплексности; информационного единства; совместимости; инвариантности.

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

            • Необходимо помнить, что проектирование неотъемлемо от различных стандартов (ГОСТ, ANSI, проекта) и их следует соблюдать как при оформлении документации, так и для унификации вашего проекта.

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

            • В процессе выполнения проекта предусматриваются отдельные моменты времени, которые характеризуются законченным оформлением результатов всех работ, выполненных разработчиками до данного момента. Согласно ГОСТ, возможны следующие стадии разработки: ТЗ; ЭП; ТП; РП; внедрение. Возможны также и нестандартные этапы и стадии. Набор этапов и стадий отражает результаты проектирования самого процесса проектирования.

            • Модели играют важнейшую роль в проектировании программ. При построении моделей используется абстрагирование и декомпозиция.

            • Каждая стадия проекта завершается утверждением программных документов.      Документы включают описания (спецификации). Спецификации являются моделями. Спецификации делятся на внешние и внутренние.

            • Рациональный выбор стандартных элементов («кубиков») имеет два аспекта: удобство при повторном использовании и возможность осуществления синтеза из малых элементов более общих элементов.

Глава 2. Оптимизация ПРОГРАММНЫХ РАЗРАБОТОК

2.1. ВЫБОР ОПТИМАЛЬНОГО ВАРИАНТА ПРОЕКТНОГО РЕШЕНИЯ

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

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

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

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

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

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

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

            1) показатели функционирования, характеризующие полезный эффект от использования программной системы по назначению, и область применения. (Например, библиотечная информационно-поисковая система характеризуется следующими показателями функционирования: максимальным объемом хранимых литературных источников; максимальным количеством одновременно работающих пользователей; списком обрабатываемых запросов; временем реакции на каждый запрос при максимальном количестве пользователей; временем ввода одной единицы хранения; возможным составом оборудования и др.);

            2) показатели надежности, характеризующие свойства программной системы сохранять свою работоспособность во времени;

            3) показатели технологичности, характеризующие эффективность конструкторско-технологических решений для обеспечения высокой производительности труда при изготовлении и сопровождении;

            4) эргономические показатели, характеризующие систему человек — изделие — среда и учитывающие комплекс гигиенических, антропологических, физиологические и психических свойств человека, проявляющихся в производственных и бытовых условиях;

            5) эстетические показатели, характеризующие внешние свойства системы: выразительность, оригинальность, гармоничность, целостность, соответствие среде и стилю;

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

            7) патентно-правовые показатели, определяющие число используемых патентов, степень патентной защиты, патентную чистоту;

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

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

            2.2. ПРИМЕР ВЫБОРА ОПТИМАЛЬНОГО ВАРИАНТА ПРОГРАММНОГО РЕШЕНИЯ

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

            Фирма «Borland Inc.», создав свой компилятор, решила разработать демонстрационную программу, которая могла бы показать наибольшее количество возможностей компилятора. В табл. 2.1 приводятся наименования критериев, варианты реализации программ и оценки по пятибалльной шкале. Эту таблицу составили обучаемые на одном из практических занятий. Ими же были выставлены оценки.

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

            Система управления базами данных (СУБД) может быть большой или не очень большой программой. Главное в СУБД — мало понятные алгоритмы обработки данных. Интерес для пользователя представляет библиотека обработки данных, а не готовая программа.

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

            Операционная система (ОС) может иметь любой объем. Понятность текстов ОС невысокая.

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

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

            Фирма «Borland Inc.» с ранними разработками компилятора (Turbo Pascal 4.0) поставляла демонстрационную программу простейшей электронной таблицы MicroCalc.

            В более позднем дистрибутиве Turbo Pascal 6.00 появилась новая демонстрационная версия электронной таблицы TurboCalc, реализованная с использованием объектно-ориентированной технологии. Поскольку и другие варианты реализации программ вызывают интерес у пользователей, фирма с поздними разработками компилятора начала поставлять и их. Так поставлялись: игра в шахматы с непонятными алгоритмами; текстовый редактор как библиотечная программа; библиотека поддержки работы с базами данных. Сам компилятор в исходном коде фирмой «Borland Inc.» никогда не поставлялся.

2.3. МЕТОДЫ СИНТЕЗА ВАРИАНТОВ РЕАЛИЗАЦИЙ ПРОГРАММ

            Чтобы отобрать оптимальное решение, необходимо синтезировать множество возможных решений (вариантов), включающих оптимальное решение.

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

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

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

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

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

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

            Если, решая конкретную задачу, проектировщик не ограничится достижением только сиюминутной цели, а сможет «заглянуть в будущее» и выделить инвариантные части системы, то эти части, являясь как бы строительным материалом для данной системы, могут послужить основой и для систем, которые еще будут проектироваться. Будущие системы могут решать совсем иные задачи. В этой связи полезно было бы создавать и накапливать библиотеки инвариантных частей системы или даже параллельно проектировать несколько систем (объектов), преследующих как сходные, так и различные цели. «Заглянуть в будущее» можно лишь хорошо зная прошлое и настоящее, а также новые достижения программирования.

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

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

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

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

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

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

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

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

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

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

            Однако предпочтительным является иной вариант действий. Как показывает опыт, во многих ситуациях содержатся скрытые ресурсы, использование которых позволяет кардинальным образом разрешить противоречие. Такими скрытыми ресурсами во многих случаях являются три вида ресурсов: временные, пространственные и «бросовые». К «бросовым» мы относим ресурсы, имеющиеся в системе (но, как правило, не считающиеся ресурсом, по крайней мере, в рамках решаемой задачи), использование которых не связано с какими-то дополнительными затратами.

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

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

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

            Пример использования метода эвристических приемов для создания алгоритмов описан в книге Д. Пойа. Укороченный фонд эвристических приемов для программирования описан в приложении 3.

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

            Решение проводится в два этапа — генерации и анализа. На этапе генерации создается творческая группа из 5 — 15 человек (специалисты-смежники и люди «со стороны», не имеющие никакого опыта в области, к которой относится решаемая задача). Группе объясняется суть задачи, требующей решения, и проводится этап генерации идей. На этом этапе не допускается критика предлагаемых идей. Поощряется выдвижение даже сумасбродных идей. Затем группа экспертов анализирует высказанные идеи и отбирает те, которые заслуживают более тщательной проработки.

            Методом мозгового штурма работают команды знатоков в популярной телепередаче: «Что? Где? Когда?» Пятьдесят секунд идет генерация идей и только десять секунд тратится на обсуждение выдвинутых идей.

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

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

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

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

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

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

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

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

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

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

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

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

            Интересно отметить, что число возможных реализаций алгоритмов нелинейного программирования по этой таблице составляет N = 5· 6· 8· 5· 7· 7· 6 = 352800, что значительно превышает число опубликованных методов (около 2000)!

            Значения классификационных признаков классификационного признака «Механизм начальной точки поиска».

            признак 1.1 — из точки, указанной пользователем;

            признак 1.2 — из средней точки области определения;

            признак 1.3 — из точки на границе области определения;

            признак 1.4 — из случайной начальной точки поиска; признак 1.5 — начальная точка поиска не задается.

            Значения классификационных признаков классификационного признака «Первичное зондирование гиперповерхности»:

            признак 2.1 — в виде большого числа случайных точек, зондирующих всю гиперповерхность;

            признак 2.2 — поочередные спуски из ряда случайных начальных точек;

            признак 2.3 — конкурирующие спуски из добавляемых случайных точек;

            признак 2.4 — зондирование гиперповерхности случайными точками с выявлением и более тщательным исследованием «подозрительных областей»,.

            признак 2.5 — сканирование всей гиперповерхности с использованием различных разверток,             Например Пеано;

            признак 2.6 — отдельный механизм начала поиска отсутствует. Значения классификационных             признаков классификационного признака «Стратегия шагов поиска»;

            признак 3.1 — один шаг;

            признак 3.2 — последовательные шаги до выявления экстремума;

            признак 3.3 — осуществлять все шаги по одному и тому же механизму;

            признак 3.4 — переключать механизмы шагов от глобального метода до локального;

            признак 3.5 — переключать механизмы шагов от глобальных далее до усредненных и до локальных;

            признак 3.6 — переключать механизмы шагов по эвристическим правилам;

            признак 3.7 — малое количество последовательных шагов из ограниченного ряда лидирующих конкурирующих начальных точек;

            признак 3.8 — шаги поиска отсутствуют.

            Значения классификационных признаков классификационного признака «Направление поиска на шаге»:

            признак 4.1 — новая точка в направлении аппроксимации градиента, построенного на основе данных текущей и предшествующей пробной точек;

            признак 4.2 — по результатам обработки небольшого числа перспективных точек, полученных на предшествующих шагах;

            признак 4.3 — по результатам анализа функции, аппроксимирующей случайные точки в перспективном направлении;

            признак 4.4 — зондирование гиперповерхности большим количеством случайных точек и последующим построением аппроксимирующей функции;

            признак 4.5 — вдоль границы области определения целевой функции;

            признак 4.6 — механизм отсутствует.

            Значения классификационных признаков классификационного признака «Механизм стратегии шага поиска».

            признак 5.1 — пробные точки только на расстоянии предполагаемого экстремума;

            признак 5.2 — пробные точки на большем расстоянии, чем предполагаемый экстремум;

            признак 5.3 — пробные точки на расстоянии, несколько меньшем, чем у предполагаемого экстремума;

            признак 5.4 — объединение признаков 5.1 и 5.2;

            признак 5.5 — объединение признаков 5.1, 5.2 и 5.3;

            признак 5.6 — совмещение поиска направления и расстояния до экстремума;

            признак 5.7 — разделение поиска направления и расстояния до экстремума.

            Значения классификационных признаков классификационного признака «Механизм самообучения»:

            признак 6.1 — сужение границ поиска по мере продвижения к экстремуму;

            признак 6.2 — постепенное повышение точности поиска;

            признак 6.3 — выявление формы гиперповерхности по результатам предшествующих шагов и переход на специальный механизм уточнения экстремума;

            признак 6.4 — выявление формы гиперповерхности по результатам предшествующих шагов и переход на специальный механизм продвижения вдоль оврагов;

            признак 6.5 — выявление формы гиперповерхности по результатам предшествующих шагов и отказов текущего найденного экстремума;

            признак 6.6 — изменение плотности вероятности случайных точек для разных зон поиска;

            признак 6.7 — механизм отсутствует.

            Значения классификационных признаков классификационного признака «Механизм завершения поиска»:

            признак 7.1 — не выявляется направление улучшения функции на следующем шаге;

            признак 7.2 — израсходован ресурс времени;

            признак 7.3 — достигнуто заранее заданное значение целевой функции;

            признак 7.4 — исчерпаны возможности алгоритма поиска экстремума;

            признак 7.5 — выполнено заранее заданное количество шагов поиска;

            признак 7.6 — нет улучшений в «дальней» и «близкой» окрестностях.

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

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

            2.4. АНАЛИЗ ТРЕБОВАНИЙ К СИСТЕМЕ (СИСТЕМНЫЙ АНАЛИЗ) И ФОРМУЛИРОВКА ЦЕЛЕЙ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

            Проблемы, с которыми сталкивается системный аналитик, взаимосвязаны, что является одной из главных причин сложности их решения:

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

            2) заказчик, в свою очередь, не имеет достаточной информации о проблеме обработки данных, чтобы судить, что является выполнимым, а что — нет;

            3) аналитик сталкивается с чрезмерным количеством подробных сведений о предметной области и о новой системе;

            4) спецификация системы из-за объема и технических терминов непонятна для заказчика;

            5) в случае понятности спецификации для заказчика, она будет недостаточной для разработчиков, создающих систему.

            Итак, на данном этапе эволюционного развития ситуация в области проектирования АС выглядит следующим образом:

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

            • имеется перечень потребностей, которые необходимо удовлетворить;

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

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

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

            Как правило, все ошибки начальных этапов, выявленные на последующих этапах, имеют следующие причины:

            1) постановка недостижимой цели;

            2) стремление разработчика и постановщика задачи упростить задачу;

            3) неумение разработчика выделить из формулировки постановщика отдельно описание проблемы и постановку задачи;

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

            Можно сформулировать последовательность рекомендаций (контрольных вопросов):

            Рекомендация 1. Не доверяйте имеющимся формулировкам задачи; решение начинайте с нуля, с выделения субъекта, выявления причин его дискомфорта и потребностей. Дело в том, что зачастую формулировка, предлагаемая заказчиком, неудачна или вовсе неприемлема, так как описывает на самом деле неудовлетворенную потребность, выдавая ее за задачу.

            Рекомендация 2. Уточните требования к конечному результату:

            1) какие функции и с какими показателями качества должен

выполнять функции объект?

            2) какой эффект будет получен в случае успешного решения задачи?

            3) каковы допустимые затраты, как они связаны с показателями качества?

Может оказаться, что затраты существенно превысят эффект, поэтому либо следует отказаться от решения, либо искать более приемлемое.

            Рекомендация 3. Уточните условия, в которых предполагается реализация найденного решения:

            1) тщательно исследуйте связанные с этим ограничения и убедитесь, что все они действительно имеют место;

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

            Рекомендация 4. Изучите задачу, используя следующую информацию:

            1) как решаются задачи, близкие к рассматриваемой?

            2) как решаются задачи, обратные рассматриваемой? (Особое внимание следует обратить при этом на области применения, для которых подобные задачи наиболее актуальны.)

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

            Рекомендация 6. Тщательно отработайте формулировку задачи, желательно с использованием наиболее общих понятий и терминов.

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

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

            В процессе анализа рассматриваются:

            1) работа без ЭВМ и с ЭВМ с разной степенью автоматизации;

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

            3) варианты со специально созданными программами;

            4) время обработки информации;

            5) стоимость обработки информации;

            6) вероятность ошибок, их последствия и качество обработки информации.

            Анализ требований способствует лучшему пониманию системы и достижению наилучшего удовлетворения потребности.

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

            При проектировании необходимо учитывать следующие эффекты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

            Этап формулировки целей могут привести к различным ситуациям.

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

            Ситуация 2. Диаметрально противоположный вариант — новые цели. В этом случае мы имеем дело с задачей, у которой имеется в наличии явно видимая цель и отсутствуют средства для ее непосредственного достижения.

            2.5. ПРОЕКТНАЯ ПРОЦЕДУРА ПОСТАНОВКИ ЗАДАЧИ РАЗРАБОТКИ ПРОГРАММЫ

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

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

            Суть проектной процедуры.

            Шаг 1. Проанализируйте выход системы, определите состав и форму выходных данных.

            Шаг 2. Проанализируйте вход системы, определите состав и форму входных данных.

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

Шаг 4. Определите ограничения.

            Шаг 5. Определите основные алгоритмы обработки информации и рассчитайте время их выполнения.

Шаг 6. Доопределите ограничения.

Шаг 7. До нахождения приемлемой постановки генерируйте варианты постановок.          Используйте классификации алгоритмов, критериев, методов принятия решений, эвристические приемы, практические приемы.

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

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

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

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

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

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

            Закономерность 1. С точки зрения потребительских функций: «Чем шире состав потребительских функций, чем интенсивнее количественная сторона их проявлениях тем совершеннее система».

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

            Попробуйте самостоятельно решить задачу: «Какая из известных вам программ редактора текстов более совершенна?»

            Закономерность 2. С точки зрения воздействия факторов внешней среды компьютера: «Чем шире интервал условий внешней среды, внутри которого способны реализовываться потребительские свойства конкретной системы, тем система совершеннее».

            Пример. Из двух девушек — кандидаток в жены — гораздо предпочтительнее более неприхотливая — это уже совсем банальная истина.

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

            Закономерность 3. С точки зрения интервала ограничений искусственной внешней среды: «Чем уже интервал ограничений для реализации потребительских функций данной системы, тем система совершеннее».

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

            Какой редактор текстов предпочтительнее:

            1) со встроенным орфографическим контролем;

            2) с внешней программой орфографического контроля, разработанной иным производителем?

            Шаг 1. Сформулировать задачи развития по каждому из потребительских свойств.

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

            Шаг 3. На основе прогноза о тенденциях развития потребительского спроса составить полный приоритетный список всех возможных задач совершенствования объекта.

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

            Шаг 1. Перечислим основные функции ЭА:

            → сканирование;

            → распознавание и корректирование ошибок;

            → создание и миграция электронных документов и образов;

            → индексирование документов;

            → оперативный поиск и отображение документов.

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

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

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

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

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

            Шаг 2. Задачи проектирования:

            1) развертывание высокопроизводительной сети, включающей графические рабочие станции и мощные серверы ввода и обработки информации;

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

            3) обеспечение эффективного индексирования и полнотекстового поиска неструктурированной информации большого объема.

            Шаг 3. Возможность технической реализации рассматриваемой системы:

            — появились дешевые носители — компактные диски; резко снизился показатель стоимость/производительность для высоко скоростных вычислительных систем, сетей и устройств;

            — получили развитие аппаратно-программные системы, реализующие параллельную обработку запросов; повысился уровень интерфейса работы с СУБД;

            — появились новые информационные технологии индексирования сверхбольших массивов данных;

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

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

            Шаг 4. В качестве приоритетных задач совершенствования системы можно выделить следующие:

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

            2) использование специализированных промышленных сканеров, ориентированных на потоковый ввод архивных документов. Отличительная особенность таких сканеров — ротационный механизм перемещения документов, позволяющий вводить данные с бумажных носителей плохого качества;

            3) из-за высоких требований к скорости доступа к поисковому образу документа и его целостности, осуществление его хранения в высокоскоростных отказоустойчивых системах хранения, например RAID-массивах. Наиболее подходящими носителями могут быть магнитооптические, фазоинверсные (PD/CD), компакт (CD-R) и WORM-диски. Для автоматизации поиска информации, размещенной на этих дисках, ее извлечения и работе собственно с дисками используются автоматические библиотеки, или оптические дисковые автоматы (JukeBox);

            4) использование только мощных масштабируемых RISC-платформ, ориентированных на параллельные вычисления.

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

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

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

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

            Признак 2. Сравнение систем и поиск решения на основе максимального резерва развития.