• 2.1. ВЫБОР ОПТИМАЛЬНОГО ВАРИАНТА ПРОЕКТНОГО РЕШЕНИЯ
  • 2.2. ПРИМЕР ВЫБОРА ОПТИМАЛЬНОГО ВАРИАНТА ПРОГРАММНОГО РЕШЕНИЯ
  • 2.3. МЕТОДЫ СИНТЕЗА ВАРИАНТОВ РЕАЛИЗАЦИЙ ПРОГРАММ
  • 2.4. АНАЛИЗ ТРЕБОВАНИЙ К СИСТЕМЕ (СИСТЕМНЫЙ АНАЛИЗ) И ФОРМУЛИРОВКА ЦЕЛЕЙ
  • 2.5. ПРОЕКТНАЯ ПРОЦЕДУРА ПОСТАНОВКИ ЗАДАЧИ РАЗРАБОТКИ ПРОГРАММЫ
  • 2.6. ПСИХОФИЗИОЛОГИЧЕСКИЕ ОСОБЕННОСТИ ВЗАИМОДЕЙСТВИЯ ЧЕЛОВЕКА И ЭВМ
  • 2.7. КЛАССИФИКАЦИЯ ТИПОВ ДИАЛОГА ПРОГРАММ
  • Глава 2

    ОПТИМИЗАЦИЯ ПРОГРАММНЫХ РАЗРАБОТОК

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Таблица 2.1

    Балльная оценка вариантов реализации программы по критериям

    Критерии Варианты реализации
    СУБД ЭТ ОС Редактор текстов Игра
    Объем программы 4 4 4 2,5 3
    Понятность 2 4 1 5 2
    Новые знания 2 4 2 3 2
    Интерес 4 3 3 3 5
    Использование в собственных разработках 2 5 5 4 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)!

    Таблица 2.2

    Морфологическая таблица принципов функционирования алгоритмов нелинейного программирования

    Классификационные признаки Значения классификационных признаков
    Начальная точка поиска 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
    Стратегия шага поиска 5.1 5.2 5.3 5.4 5.5 5.6
    Механизм самообучения 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

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

    признак 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.

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

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

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

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

    Рис. 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. Определите ограничения.

    Рис. 2.2. Модель "черного ящика" проектируемого объекта


    Шаг 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. Сравнение систем и поиск решения на основе максимального резерва развития.

    2.6. ПСИХОФИЗИОЛОГИЧЕСКИЕ ОСОБЕННОСТИ ВЗАИМОДЕЙСТВИЯ ЧЕЛОВЕКА И ЭВМ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    2.7. КЛАССИФИКАЦИЯ ТИПОВ ДИАЛОГА ПРОГРАММ

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

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

    Рис. 2.3. Диалог типа вопрос-ответ


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

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

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

    Рис. 2.4. Диалог типа меню


    Рис. 2.5. Диалог типа заполнения бланков


    Рис. 2.6. Диалог на основе команд


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

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

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

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

    Рис. 2.7. Диалог типа работы в окнах


    Рис. 2.8. Диалог типа по принципу электронной таблицы


    Рис. 2.9. Диалог типа гипертекста


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

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

    ВЫВОДЫ

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

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

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

    • Любые классификации программ повышают вероятность синтеза вариантов. Классификации можно использовать как при работе методом морфологического синтеза, так и методом аналогии.

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

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

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

    Контрольные вопросы

    1. Перечислите основные виды показателей качества программных систем.

    2. Дайте определение понятия "эвристический прием".

    3. Опишите основные шаги, по которым осуществляется системный анализ.

    4. Опишите суть проектной процедуры раскрытия проектной ситуации.

    5. Приведите примеры внутренних закономерностей при описании потребительских свойств системы.

    6. Назовите основные классы существующих программ.

    7. Назовите основные особенности взаимодействия человека и ЭВМ.

    8. Дайте краткую характеристику основным типам диалога программ.

    9. В чем состоит основная задача оптимизации на этапе разработки программ?









    Главная | В избранное | Наш E-MAIL | Добавить материал | Нашёл ошибку | Наверх