Отладка приложений

Книга адресована разработчикам, которые хотят повысить качество своих программ и конкурентоспособность своей организации, а также для менеджеров и руководителей групп, заинтересованных в создании более действенных и эффективных команд разработчиков.
Исходя из технической перспективы, "идеальным читателем" является тот, кто имеет опыт (от одного до трех лет) в применении систем программирования Microsoft Visual C++ и/или Microsoft Visual Basic. Предполагается также, что читатель является членом реальной команды разработчиков, и отправил заказчикам, по крайней мере, один продукт.

Введение
Читая эту книгу, вы заметите, что основное внимание уделено отладчику Visual C++, языкам С, C++ и ассемблеру. Тому есть две причины. Во-первых, языки С и C++ предоставляют разработчикам больше возможностей (чем язык Visual Basic) попасть в аварийные ситуации. Во-вторых, потому что отладчик Visual Basic не может отлаживать свой "родной" (native) откомпилированный двоичный код, и необходимо знать отладчик Visual C++, чтобы отладить приложение Visual Basic.

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

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

Операторы утверждений

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

Типы Windows-отладчиков
Если вы хоть немного программировали для Windows, то, вероятно, слышали о различных типах отладчиков, которые можно при этом использовать. В мире Windows доступны два типа отладчиков: отладчики режима пользователя (user-mode debuggers) и отладчики режима ядра (kernel-mode debuggers).

Расширенные точки прерывания
Установка точки прерывания на исходной строке в отладчике Visual C++ (для проектной конфигурации Win32 Debug или Win32 Unicode Debug) довольно проста: загрузите исходный файл, поместите курсор на строку, где требуется остановить выполнение, переместите указатель мыши на кнопку Insert/Remove Breakpoint и щелкните левой кнопкой мыши.

Основы CPU
Довольно продолжительное время мы живем в окружении набора команд процессоров компании Intel, уходящего корнями в CPU 8086, который Intel впервые выпустил в 1978 году. Во времена MS-DOS и 16-разрядной операционной системы Windows язык ассемблера казался немного странным и трудным (из-за методики работы CPU с памятью — через 64 Кбайтные блоки, называемые сегментами). К счастью, сегодня иметь дело с языком ассемблера намного легче, потому что в Microsoft Windows 98 и 2000 CPU имеет прямой доступ к полному адресному пространству.

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

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

Структурированная обработка исключений
Структурированную обработку исключений (SEH) обеспечивает операционная система. Она напрямую связана с такими авариями, как нарушение доступа. SEH-обработка не зависит от языка и в программах C/C++ обычно реализуется парами ключевых слов _try/_except и _try/_finally. Методика использования пары _try/_except такова: сначала нужно установить свой код внутри блока _try, затем определить, как следует обрабатывать исключения в блоке _except (который называют также обработчиком исключений (exception handler)).

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

Требования к TraceSrv
На первый взгляд, требования к TraceSrv могут показаться чрезмерно завышенными из-за необходимости многоязычного программирования и работы в сети. Я предполагал, что можно переадресовать многоязычную поддержку простой динамически компонуемой библиотеке (DLL), которую мог бы загружать кто угодно. Поскольку я — прежде всего системный программист, а не Web-разработчик, то сказалось незнание языков VBScript и Java.

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

Бич блочного тестирования: интерфейсы пользователя
Я твердо убежден, что разработчики Microsoft получают туннельный синдром запястья не от того, что им приходится вводить исходный код с клавиатуры, а от многократного нажатия одних и тех же комбинаций клавиш при тестировании своих приложений. После 5000-го нажатия Alt+F, О запястья зажаты плотнее, чем арматура в бетоне. Без инструмента автоматизации задач, имеющих доступ к различным свойствам ваших приложений, вообще приходится следовать некоторому сценарию, чтобы гарантировать выполнение блочного тестирования в достаточном объеме.

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

Свойства библиотеки DCRT
Главной причиной популярности DCRT-библиотеки в том, что она поддерживает мониторинг кучи (heap). В отладочных версиях можно проследить всю память, которая распределяется при помощи стандартных С/С++-функций, таких как new, maiioc и calloc. Монитор кучи проверяет как записи (underwrites), которые программа помещает в начало выделенного блока памяти, так и перезаписи (overwrites), размещаемые за концом блока.

Журнал программы Dr. Watson для Windows 2000
Информация заголовка сообщает причину аварийного останова. В данном случае — это исключительная ситуация (исключение), возникшая в приложении. Номера исключений для некоторых аварийных ситуаций невозможно перевести в удобочитаемое описание, например, такое, как показано в последней строке нашего заголовка ("access violation — нарушение доступа" для исключения с (шестнадцатеричным) номером С0000005).

Разработка программного обеспечения
Steve McConnell.Code Complete. — Microsoft Press, 1993. Это лучшая книга по конструированию программного обеспечения, которую я когда-либо читал. Каждый разработчик должен иметь собственный экземпляр этой книги и читать его от корки до корки каждый год.

Позиционные точки прерывания
Все позиционные точки прерывания (location breakpoints) устанавливаются вручную в редактируемом поле Break at на вкладке Location диалогового окна Breakpoints.

Разработка распределенных приложений в Microsoft.NET Framework

В настоящее время много внимания уделяется технологиям разработки распределенных приложений, охватывающих несколько независимых компьютеров. В течение последних десяти лет было создано большое число технологий и стандартов, использование которых должно было помочь разработчикам в создании распределенных приложений масштаба предприятия. Однако поддержка многих технологий была изначально достаточно трудоемкой и сложной для разработчиков прикладных программ, использовавших классические языки программирования, такие как C/С++.
Одной из задач, стоящих перед разработчиками Microsoft, создающими так называемую общеязыковую инфраструктуру (Common Language Infrastructure, CLI), так же известную как .NET, была наиболее полная поддержка средств разработки распределенных систем. Поэтому в платформе разработки приложений Microsoft .NET Framework имеется встроенная поддержка четырех взаимосвязанных технологий, предназначенных для использования в распределенных системах: очередей сообщений (messaging queues), объектов COM+, объектов .NET Remoting, веб служб (web services).

Системные требования к курсу
Курс рассчитан на студентов средних или старших курсов. Слушатели должны быть знакомы с архитектурой Microsoft.NET Framework, а так же иметь представление об и языке программирования C#, основных сетевых протоколах стека TCP/IP, основах криптографии, теории графов и формальных языков.

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

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

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

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

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

Служба обмена сообщениями MSMQ
В настоящий момент существует несколько основных разработок в области промежуточного программного обеспечения для работы с очередями сообщений. Наиболее известными разработками являются такие системы очередей сообщений, как MSMQ, Sun Java System Message Queue, IBM MQSeries, Oracle Advanced Queing. Промежуточная среда MSMQ – разработка Microsoft для асинхронной передачи сообщений внутри локальной сети, впервые появившаяся в составе операционной системы Windows NT.

Введение в промежуточную среду COM+
COM+ – промежуточная среда для создания распределенных систем, действующих в локальной сети. Она разрабатывается фирмой Microsoft с конца 90-х годов и впервые появилась в составе операционной системы Microsoft Windows 2000. Основной целью разработки среды COM+ было создание инфраструктуры для разработки распределенных систем автоматизации предприятия

Введение в веб службы
Веб службой или веб-сервисом (web service, WS) называется программная компонента, предоставляющая сервис удаленного вызова на основе группы стандартов WSI (Web Services Interoperability), основными из которых являются протокол обмена сообщениями SOAP, язык описания интерфейса WSDL, HTTP как основной транспортный протокол, а также XML и схемы XML. Для описания спецификаций формата сообщений в веб службах в настоящее время обычно используется схема XML и кодирование тела пакета SOAP Document.

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

Введение в обеспечение безопасности
Распределенная система представляет набор программных компонент, использующих те или иные промежуточные среды для своего взаимодействия ( 9.1). Каждая промежуточная среда использует так называемый транспортный протокол, в роли которого может выступать: промежуточная среда (например, Remoting или COM+ поверх MSMQ);протокол верхнего уровня модели OSI (например, HTTP или HTTPS);протокол транспортного уровня модели OSI (например, TCP).

Взаимосвязь промежуточных сред
Доступные при использовании .NET Framework промежуточные среды не существуют оторвано друг от друга. На 10.1 показана взаимосвязь рассмотренных сред (с учетом приведенного ранее примера Remoting / MSMQ). RPC на 10.1 –стандартный для Windows NT 5.* механизм удаленного вызова процедур, недоступный для управляемого кода. Для простоты не показано возможное применение безопасных транспортных протоколов.

Администрирование каталога COM+
Текущая на момент написания курса версия .NET Framework 2.0 не содержала штатных средств администрирования каталога компонент COM+, отличных от внешней программы регистрации и удаления компонент COM+ regsvcs.exe. В частности, в библиотеке классов .NET Framework нет методов для подписки компонент на события COM+. Ниже представлено одно из возможных решений этой досадной проблемы.

Использование ASPNET без IIS
В учебном процессе или при тестировании приложений иногда возникает потребность работы с веб службами ASP.NET без использования IIS. При использовании .NET Framework 2.0 и операционной системы Windows XP SP2 или Windows Server 2003 можно достаточно просто создать свой носитель веб служб на основе классов HttpListener и HttpRuntime, при этом служба IIS может быть не установлена в системе.

Симметричное шифрование
В теме, посвященной среде .NET Remoting, для шифрования передаваемых по каналу данных используется приведенный ниже класс симметричного шифрования. Он предоставляет интерфейс к стандартному классу FCL RijndaelManaged, реализующему алгоритм шифрования Рижндала. Используется версия алгоритма с генерацией случайного вектора инициализации, который передается вместе с зашифрованными данными.

Bluetooth технические требования, практическая реализация

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

Защита информации
В 1994 году Ericsson Mobile Communications, всемирная телекоммуникационная компания, основанная в Швеции, приступила к исследованию осуществимости маломощного, дешевого радио интерфейса между мобильными телефонами и их аксессуарами. Целью исследования было нахождение способа устранения проводных соединений мобильными телефонами и PC-картами, телефонными гарнитурами, настольными компьютерами и другими устройствами.

Радио и рабочие группы по совместимости
Рабочая группа Bluetooth Radio 2.0, возглавляемая компаниями Ericsson и Nokia, проводит дополнительную разработку технических требований для приемопередатчика Bluetooth. Эта рабочая группа занимается вопросами увеличения скорости передачи данных, улучшения функций Baseband протокола (в частности, усовершенствование процедуры запроса), обеспечения совместимости с другими технологиями, работающими в ISM диапазоне.

Разработка и проектирование мультимедийного приложения

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

Продолжение