CC BY
61
Таким образом, для успешной реализации программных проектов недостаточно основываться только на методах стандартизации процесса разработки и эксплуатации ПП. Необходимо комплексное рассмотрение вопросов и правил разработки, документирования, защиты и оценки соответствия разрабатываемых ПП предъявляемым требованиям.
Список литературы
1. Robert McFeeley «A User's Guide for Software Process Improvement», Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania 15213.
2. Всеобщее управление качеством (Total Quality Management) / Под ред. О.П. Глудкина. - М.: Радио и связь, 1999.
3. Робсон М, Уллах Ф. Практическое руководство по реинжинирингу бизнес-процессов. - М.: Аудит, ЮНИТИ, 1997.
4. James H. Harrington Business Process Improvement: The Breakthrough Strategy for Total Quality, Productivity, and Competitiveness, McGraw-Hill Trade, 1991.
5. Буч Гради, Рамбо Дж., Якобсон А. Унифицированный процесс разработки программного обеспечения. - Изд.-во Питер, 2002.
6. Paulk M.C., Weber C.V., Curtis B., Chrissis M.B. et al. «The Capability Maturity Model: Guidelines for Improving the Software Process», Addison-Wesley, 1995.
7. ГОСТ 19.201-78 ЕСПД. Техническое задание. Требование к содержанию и оформлению.
8. ГОСТ 19.402-78 ЕСПД. Описание программы.
9. ГОСТ 19.301-79 ЕСПД. Программа и методика испытаний.
10. ГОСТ Р ИСО/МЭК 9294-93 Информационная технология. Руководство по управлению документированием программного обеспечения.
11. ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению.
12. ГОСТ Р ИСО 9127-94 Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов.
13. ГОСТ Р ИСО/МЭК 8631-94 Информационная технология. Программные конструктивы и условные обозначения для их представления.
14. Липаев В. Оценка качества программных средств // Сетевой журнал. - 2002. - №3.
15. ГОСТ Р ИСО/MEK 9126-93. Информационная технология. Оценка программной продукции. Характеристика качества и руководства по их применению.
16. ISO 12207:1995. Информационная технология. Процессы жизненного цикла программного обеспечения.
17. Соловьев Р.В. Авторское право: Комментарий к Закону Российской Федерации "Об авторском праве и смежных правах". - Изд-во Ось-89, 2001.
ОТЛАДКА ПОДСИСТЕМ ПОДДЕРЖКИ BLUETOOTH ВО ВСТРОЕННЫХ ПРИЛОЖЕНИЯХ
А.Е. Знамеровский, К.А. Хайт
Motorola Global Software Group, Russia
Технология Bluetooth была создана всего несколько лет назад, но уже успела найти широкое применение. Сегодня большинство выпускаемых сотовых телефонов и карманных компьютеров поддерживают Bluetooth. Выпускаются BT-модемы для ноутбуков, гарнитуры для мобильных телефонов. По прогнозам, в ближайшее время множество бытовых приборов будут оснащены Bluetooth, что, по замыслу разработчиков, позволит лучше координировать их работу.
Целью появления Bluetooth было создание дешевого протокола беспроводного обмена данными, поддерживаемого маломощными передатчиками и доступного по всему миру. Эти протоколы обеспечивают надежную передачу данных и речи в радиусе примерно 10 метров.
Максимально допустимая скорость обмена между двумя BT-устройствами составляет 721 Кбит/с, или три речевых канала. Bluetooth обеспечивает как соединение точка-точка, так и режим сетевого обмена. В одной BT-сети может одно-
временно находиться до 8 активных узлов и до 256 неактивных. Возможно взаимодействие между BT-сетями, когда одно устройство является элементом двух сетей.
Существуют два вида BT-каналов:
- асинхронный (ACL) - нет резервирования слотов времени, в любой момент master может начать обмен с любым из slaves и в любой последовательности;
- синхронный (SCO) - используется обычно для речевого обмена, master сети устанавливает полнодуплексное соединение со slave-устрой-ством и резервирует соответствующие временные слоты.
На нижнем уровне стека протоколов Bluetooth находятся так называемые базовые протоколы, над которыми располагаются «адаптированные». Поскольку BT является открытым стандартом, различные производители могут реализовывать свои собственные или общие пользовательские протоколы.
Общий подход к отладке Bluetooth-подсистем
С точки зрения отладки большинство компонентов Bluetooth представляют собой черные ящики, их внутренняя организация либо полностью недоступна для изучения, либо ее исследование сопряжено с неоправданными затратами ресурсов. Достаточно прозрачными являются прикладные интерфейсы, поскольку они разрабатываются для конкретного приложения или группы приложений, а также аппаратно-зависимый драйвер внешнего канала, соединяющего CPU и микросхему BT.
Стек протоколов и логика работы самого чипа обычно скрыты от разработчика, производящего отладку. К сожалению, в отличие от большинства других протоколов, BT практически недоступен для мониторинга на уровне конечного выхода. Если при проводном соединении отслеживание потока данных является тривиальной задачей, то "прослушивание" радиоканала с динамическим выбором частоты требует специального оборудования, которым не всегда обладают даже крупные компании.
Начальная стадия отладки: сбор информации об ошибках
Традиционными методами сбора информации об ошибках являются: ведение различных протоколов, анализ данных отладочной печати, а также получение представления о маршрутах выполнения программы при ее запуске под отладчиком. В случае встроенных приложений, использующих BT, эффективность последнего метода оказывается весьма невысокой. Необходимость достаточно точно выдерживать временные интервалы между системными событиями, обилие возможных маршрутов и наличие помех в канале часто делают использование отладчика нецелесообразным. Альтернативные способы получения информации о программе обычно оказываются более надежными и эффективными.
Ведение протоколов, содержащих информацию о текущем состоянии отдельных буферов, задач и переменных, абсолютно необходимо в процессе отладки Bluetooth-подсистем. Обладая достаточной информацией о контексте возникновения ошибки, специалист, отслеживающий ход проекта, в частности модификацию кода, может определить причину большинства ошибок до начала утомительного процесса отладки.
BT-стек может изменять порядок прохождения данных и влиять на временные характеристики обмена. Иными словами, вызов функций прикладного интерфейса в некотором порядке не может гарантировать, что соответствующие BT-пакеты будут сформированы и переданы во внешний канал в том же порядке. Тем более, нельзя быть уверенным в том, что в том же порядке бу-
дут получены ответы от микросхемы BT. Последняя проблема решается включением в протокол идентификаторов каждого пакета, что в соответствии с [1] реализуется в стеке протоколов.
Отдельный вопрос, какие именно события необходимо протоколировать. Естественно, для детального анализа ошибочной ситуации полезно иметь максимум возможной информации о поведении системы. Однако протокол, содержащий слишком большой объем избыточных данных, становится очень трудно читаемым. Его сложно фильтровать - отделять события, имеющие отношение к исследуемой проблеме, от посторонних данных.
Проблема чрезмерного объема получаемой информации решается двумя способами.
1. Фильтрация полученного протокола. При использовании этого метода из уже снятого протокола поведения системы вручную или при помощи вспомогательных программных средств извлекается информация о конкретных событиях или сведения, относящиеся к интервалу времени, близкому к моменту появления сбоя.
Данный метод весьма удобен для анализа проблем, имеющих стохастический, трудновоспроиз-водимый характер. Большинство дефектов в приложениях, использующих Bluetooth, относятся к этой категории.
В той или иной форме фильтрация протокола производится всегда: добиться снятия безызбыточных данных на практике почти невозможно. Тем не менее, злоупотреблять этим методом не следует, поскольку отладочный канал во многих встроенных системах имеет пропускную способность, сравнимую со скоростью BT-соединения, и на вывод всех отладочных сообщений его производительности может не хватить.
2. Фильтрация данных в отлаживаемом приложении. Этот метод позволяет избавиться от избыточной информации до того, как она покинет целевую систему. Реализуется вспомогательным программным модулем, через который выводятся отладочные данные. При этом осуществляется отбор сообщений по заранее настроенным критериям, а вывод части данных блокируется.
Отладка драйвера внешнего канала
Теоретически отладка драйвера внешнего канала не имеет прямого отношения к BT-системам, поскольку для соединения CPU с BT-чипом обычно используется многофункциональный интерфейс, такой как UART или SPI. Детальное модульное тестирование этого канала должно служить гарантией отсутствия проблем при соединении с микросхемой Bluetooth.
На практике дело обстоит сложнее. Как уже отмечалось, подключение BT-канала часто осуществляется таким образом, что его мониторинг
сильно затруднен. В связи с этим модульное тестирование драйвера оказывается чересчур сложным, и его отладку приходится осуществлять непосредственно при работе с ВТ-протоколом.
Общего метода отладки драйвера внешнего канала не существует. Можно предложить ряд рекомендаций, призванных упростить этот процесс.
1. Протоколирование. Если возникшая проблема допускает вероятность ошибки в драйвере, необходимо по возможности отследить движение сообщений от прикладных интерфейсов к драйверу и в обратном направлении. Если на этом маршруте пакеты передаются корректно, отладочный вывод для сообщений верхнего уровня можно отключить. Знание потока данных в канале может оказаться полезным, однако, принимая решение о его мониторинге, надо учитывать соотношение пропускной способности ВТ-канала и отладочного интерфейса.
2. Анализ отношений событий. Большое значение имеет оперативное соотнесение переданных пакетов с соответствующими ответами и квитанциями. Это позволяет эффективно выявлять случаи потери или повреждения пакетов на линии, а также дает определенное представление о структуре потока ВТ-данных. Анализ отношений событий особенно важен в случае стохастических, трудновоспроизводимых ошибок, поскольку формирует структурированное описание контекста ошибочной ситуации.
3. Контроль буферов. Периодический контроль заполнения, а в ряде случаев и содержания, входных и выходных буферов драйвера дает информацию о реальном поведении нижнего уровня ВТ-подсистемы.
Особенно важно поведение буферов непосредственно вблизи момента возникновения ошибки. Их постепенная и равномерная загрузка вплоть до переполнения является признаком того, что канал «заткнут» в результате аппаратной (а чаще программной) ошибки при приеме/передаче данных. Если буфер стабильно загружен, следует обратить внимание на производительность ВТ-стека: она может оказаться недостаточной при чтении данных или избыточной при их записи. Возможным способом решения данной проблемы является коррекция приоритетов входящих в реализацию стека задач относительно других процессов в системе. Другие подходы требуют вмешательства в код самих протоколов.
Не следует пытаться решать проблему переполнения буферов только путем увеличения их размера. Если буфер переполнен, проблема, возможно, кроется в модулях, обращающихся к ВТ-стеку.
На обработку как аппаратных, так и программных ошибок необходимо обратить особое внимание. При отладке ВТ-подсистемы разработчик ограничен в возможностях мониторинга пове-
дения приложения, поэтому не следует упускать возможность контроля ошибок как можно ближе к точкам их возникновения. Все модули, связанные с передачей данных по ВТ, требуется снабжать развитой системой отладочной печати и обработки нештатных ситуаций, независимо от вероятности их возникновения.
Отладка внешних интерфейсов
Иногда между реализацией ВТ-стека и приложением организуется еще один уровень модулей. Это делается для организации удобного прикладного интерфейса, сокрытия специфики реализации нижнего уровня, для расширения возможностей, предоставляемых пользователю. Модули включают в себя обработку неких стандартно обрабатываемых событий, для которых можно исключить влияние пользователя, что позволяет уменьшить вероятность внесения дополнительных ошибок на этапе интеграции ВТ в прикладную систему. Число событий, информацию о которых получает приложение, можно свести к необходимому минимуму. Другой причиной появления дополнительного уровня модулей может служить необходимость обеспечения многопользовательского доступа к интерфейсам ВТ-стека. Таким образом, реализация ВТ-подсистемы может состоять из двух уровней: собственно ВТ-стека и дополнительных интерфейсных модулей.
Начальный этап отладки взаимодействия приложения и ВТ-подсистемы рекомендуется проводить на ПК с помощью тестового оборудования и специализированных средств отладки. Преимущества данного метода состоят в возможности проведения большего числа экспериментов в единицу времени, чем на целевой платформе. Кроме того, появляются дополнительные возможности при анализе результатов тестирования и отладке, а главное - начальная отладка может производиться в тот момент, когда целевое аппаратное обеспечение недоступно.
Переход на целевую платформу обычно приводит к появлению целого ряда новых проблем, и не следует рассчитывать, что код, успешно отлаженный на ПК, начнет безошибочно работать в составе приложения. Нелегко найти правильный момент для этого перехода. С одной стороны, необходимо учитывать, что каждый цикл компиляции, сборки и запуска системы будет занимать на порядок больше времени, чем на ПК, и что отладочный стенд обычно является ресурсом, разделяемым большой командой программистов. Однако, с другой стороны, приложение должно работать не на ПК, а на целевой платформе. Поэтому часто при нахождении проблем имеет смысл воспроизвести ошибку на ПК. Если это получилось, можно сосредоточиться на отладке интерфейсов «усеченной» системы и лишь впоследствии вернуться к тестированию на целевом оборудовании.
В противном случае, велика вероятность того, что встретившаяся ошибка носит индуцированный характер.
Отладка индуцированных ошибок
Индуцированные, или наведенные ошибки -еще одна категория проблем, возникающих при отладке В/ие?оо?й-приложений. К ней относятся ошибки, возникающие в других частях приложения при внедрении ВТ-подсистемы. Эти проблемы достаточно трудно идентифицировать, поскольку они имеют разную природу и характер проявления. Кроме того, возникновение сбоев в подобных случаях сильно зависит от случайных факторов, например, физических адресов программных модулей, назначаемых при связывании компоновщиком. В результате проблема может оставаться латентной в течение длительного времени и проявляться без видимых причин в достаточно неожиданных ситуациях.
Большинство индуцированных ошибок можно отнести к одной из следующих групп.
• Повреждение памяти кода или данных -наиболее тяжелый вид ошибок, обычно приводящий к фатальному сбою приложения. Диагностировать, локализовать и отладить проблемы повреждения памяти обычно непросто, однако можно рекомендовать ряд способов, увеличивающих эффективность этого процесса.
• Переполнение стеков задач. Проблема переполнения стеков в многозадачных приложениях для встроенных систем общеизвестна. Множество модулей используют синхронные интерфейсы, и их функции выполняются в рамках стека вызывающего процесса, на что последний, как правило, не рассчитан. Для ВТ типичным примером модуля, использующего синхронный интерфейс, является драйвер внешнего канала.
• Перегрузка процессора. ВТ-подсистема достаточно критична к процессорному времени -ответ от удаленного ВТ-устройства должен быть получен в пределах определенного временного интервала, а после некоторого числа переповторов ВТ-соединение разрывается. Кроме того, потребляемые ресурсы сильно зависят от потока данных, имеющего нерегулярный характер.
Наилучший способ избежать большинства индуцированных ошибок - четкое соблюдение процедур интеграции ВТ-подсистемы. Целесообразно придерживаться ряда простых правил, сильно упрощающих локализацию наведенных проблем.
1. Интеграцию ВТ-модулей следует производить отдельно от других частей приложения.
2. По окончании процесса интеграции необходим полный цикл тестирования ВТ.
3. При обнаружении ошибок следует убедиться, что они отсутствовали в предыдущей версии ВТ-подсистемы.
4. Перед принятием решения о том, что модифицированный вариант BT-подсистемы успешно интегрирован, необходимо локализовать все известные дефекты, включая потенциально индуцированные данным модулем.
Локализация наведенной ошибки существенно зависит от ее типа. Дефекты, связанные с повреждением памяти, проще всего идентифицируются при наличии защиты сегментов или страниц, однако в ряде случаев этот метод неприменим из-за аппаратных ограничений. Можно рекомендовать последовательное отключение (на этапе компиляции либо динамически при помощи отладочной консоли) отдельных задач для идентификации процесса, породившего ошибку. Дальнейший мониторинг адресов, по которым производится запись данных в найденной задаче, при помощи отладчика или контрольной печати является верным путем для точной локализации дефекта.
Проблемы, вызванные переполнением стека, проще всего локализуются путем защиты стеков системными средствами или периодическим мониторингом их свободных областей. Учитывая возможность использования стеков BT-процессов вызываемыми модулями, в частности драйверами аппаратуры, необходимо резервировать для них пространство, как минимум в 1.5 раза превышающее собственные потребности BT-прото-колов.
Ошибки, вызванные перегрузкой процессора, наиболее трудны в локализации и устранении. Для их обнаружения необходимо регулярное профилирование временных параметров системы в целом и, в частности, BT-коммуникаций для получения четкого представления о специфике их поведения. В случае недоступности специализированной программы-профайлера можно использовать простейшую функцию мониторинга, входящую в состав исследуемого приложения.
Обобщенные рекомендации по отладке
Начинать интеграцию подсистемы Bluetooth имеет смысл лишь после подробного тестирования остальной части приложения. Разработчики, осуществляющие интеграцию и отладку BT-подсистемы должны обладать базовыми знаниями реализации стека протоколов, а также имеющихся в ней проблем и ошибок. Значительную помощь может оказать взаимодействие (если это возможно) с командой программистов, реализовывавшей BT-стек.
Начинать интеграцию следует с включения задач, реализующих функции BT, в общий список задач системы. Потом необходимо проверить, что внедрение базовых компонентов Bluetooth не приводит к сбоям. При отсутствии критических ошибок производится включение одного за другим BT-модулей снизу вверх. С высокой долей вероят-
ности можно утверждать, что большая часть проблем, описанных выше, проявится на одном из этапов интеграции.
Высокая сложность процесса отладки ВТ-подсистемы требует в первую очередь обратить пристальное внимание на проектирование системы, четкое согласование интерфейсов и поэтапную, тщательно спланированную интеграцию подсистем. Все это позволяет предотвратить
большинство наиболее сложных проблем и принять правильные решения при отладке оставшихся.
Список литературы
1. Specification of the Bluetooth System. Core. Version 1.1. February 2001.
2. Specification of the Bluetooth System. Profiles. Version 1.1. February 2001.
ИСПОЛЬЗОВАНИЕ НЕЙРОСЕТЕВЫХ АЛГОРИТМОВ В ИНТЕЛЛЕКТУАЛЬНЫХ СИСТЕМАХ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ
Н.А. Семенов, А.Н. Ветров, Абу Суек Атия Ражаб Мохамед
В статье рассматриваются вопросы поддержки принятия решений в процессе стоимостной оценки разнотипных объектов, стоимость которых зависит от тех свойств, которые присущи данному объекту. Такие задачи возникают при кадастровой оценке земель, стоимостной оценке объектов недвижимости, ювелирных изделий и т.п. Наиболее распространенным является подход, основанный на сопоставимости продаж, на прямом сравнении оцениваемого объекта с другими, уже проданными или выставленными на продажу. Когда эксперт располагает информацией по достаточному количеству сопоставимых продаж и предложений, ему сравнительно легко определить ценовые тенденции, служащие своеобразным индикатором рыночной стоимости.
Формально процедуру стоимостной оценки объектов, основанной на сопоставимости продаж, можно рассматривать как последовательность решения следующих задач:
• оптимального выбора эталонных групп объектов со сходными (пересекающимися) свойствами и получения достоверной оценки стоимости объектов в эталонных группах (задача кластеризации);
• отнесения оцениваемого образца к той или иной эталонной группе (задача классификации);
• наилучшей аппроксимации (экстраполяции) стоимостных оценок минералов в эталонных группах на оцениваемый образец.
Обозначим вектором Х—(Х1,Х2,.«.,Хд) переменные, определяющие стоимость минерала определенного вида. Число минералов, для которых известна стоимостная оценка, обозначим через К. Тогда образцы минералов будут характеризоваться набором из К векторов -{(X!, (Х2, г), , (Хк 2к)}, где гь к е {1,...,К} уста-
навливает достоверную стоимость каждого образца. Полученный набор определяет исходную базу знаний для обучения соответствующих нейронных сетей (НС) и построения отображения Е: X ^ г, то есть процедуры оценки стоимости произвольного объекта по его входным параметрам
Для разделения исходного множества образцов на 8 классов можно использовать сеть Кохонена, которая состоит из 8 нейронов (ядер), каждый из которых вычисляет близость объекта к своему классу. Все нейроны работают параллельно. Объект считается принадлежащим к тому классу, нейрон которого выдал минимальный сигнал.
Алгоритм обучения сети решению такой задачи состоит в следующем. Задается некоторый начальный набор параметров нейронов. Один объект Xj предъявляется сети, и находится нейрон, выдавший максимальный сигнал. Пусть номер этого нейрона I Тогда параметры нейрона модифицируются, и сети предъявляется следующий объект и так далее до тех пор, пока после очередного цикла предъявления всех объектов не окажется, что параметры всех нейронов изменились на величину, меньшую заранее заданной точности £. Для некоторых мер близости после преобразования может потребоваться дополнительная нормировка параметров нейрона.
Альтернативой методам пообъектного обучения сетей Кохонена является метод динамических ядер, который напрямую минимизирует суммарную меру близости. Метод является итерационной процедурой, каждая итерация которой состоит из двух шагов. Сначала задаются начальные значения ядер. Затем выполняются разбиение на классы при фиксированных значениях ядер и оптимизация значений ядер при фиксированном разбиении на классы:
