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

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

Чтобы обсуждение не было голословным, как, скажем, критика Windows 95 поклонниками OS/2, попытаемся сформулировать разумные критерии выбора целевых платформ и средств разработки. Целевой платформой мы называем операционную среду, под которой будет работать создаваемая программа. Критерии выбора целевой платформы почти очевидны:

1. К моменту поступления программы в продажу ее потенциальный покупатель должен либо обладать целевой платформой, либо иметь возможность (и желание) приобрести ее ради программы.

2. Программа должна с приемлемой скоростью и надежностью работать на целевой платформе.

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

К началу разработки FineReader 2.0 (январь 1994 года) первым двум требованиям удовлетворяли Windows 3.1 с каким-либо 32-битным расширителем (extender), Windows NT 3.1, OS/2 2.1 и OS Macintosh. К концу работ (начало 1995 года) ожидался выход Windows 4.0. Поддержка сканеров в виде TWAIN-совместимых Драйверов (поставляемых со сканерами) есть только для Windows и Macintosh. Компьютеры Macintosh в России традиционно используются в основном для специальных полиграфических работ. При этом в тех же организациях набор текста обычно производится на PC – так дешевле. Таким образом, рынка OCR для Macintosh в России практически не существует. Что остается? Windows 3.1 с 32-битным расширителем и Windows 4.0. Естественно, нам хотелось, чтобы версия для Windows 3.1 впоследствии работала и под Windows 4.0. Поэтому в качестве расширителя был выбран Win32s 1.1.

Выбор средств разработки

Затем встал вопрос о выборе средств разработки. Под средствами разработки мы понимаем операционную систему, которую используют разработчики, компилятор, средства отладки и тестирования, Application Framework (объектную библиотеку для создания приложений с GUI) и систему поддержки версий. Далее мы рассмотрим каждое из этих средств в отдельности.

Операционная система

Может показаться странным обсуждение того, какую операционную систему используют разработчики. Казалось бы, работай под целевой платформой – и все. Если целевая платформа – полнофункциональная ОС, то обычно так и происходит. Если же нужно разрабатывать программу для встроенной системы или какого-нибудь DOS- или Windows-расширителя, то гораздо быстрее написать программу для нормальной операционной системы, отладить ее там, а затем уже перенести на целевую платформу, где и провести ее окончательные испытания.

Впрочем, ту же Windows 3.0 трудно назвать надежной ОС: больше пяти минут работы с отладчиком система не выдерживала. Следующая версия – 3.1 – обладала уже большей устойчивостью и имела хорошую диагностику нарушения защиты памяти. Расширитель Win32s как платформа для разработки оказался хуже, чем Windows 3.0, иначе говоря, был практически не пригоден.

Поэтому Microsoft предлагала писать программы для Win32s и Windows 4.0 на Windows NT. С одной стороны, NT – надежная операционная система со встроенной поддержкой сети; с другой – NT очень похожа на Windows по интерфейсу с пользователем и API, что позволяет не переучивать знакомых с Windows программистов. По этим же причинам NT хороша в качестве сервера приложений. Программный интерфейс Win32 имеет широкий набор средств управления памятью и межпроцессного взаимодействия.

Выпустив бета-версию FineReader 2.0 для NT, мы перенесли свою систему на Windows 95 и Win32s. Адаптация к Windows 95 прошла гладко, ас Win32s возникли некоторые проблемы, среди них две серьезные: ошибки самой Win32s и фрагментация памяти. Справиться с первым вопросом нам помогла служба технической поддержки Microsoft, а проблему фрагментации мы решили, заводя отдельные "кучи" (heap) на каждую подсистему (Win32 API поддерживает работу с несколькими "кучами").

За полтора года работы NT хорошо зарекомендовала себя как платформа для разработки, a Windows 95 – как целевая платформа. Эта ОС довольно надежна, хорошо совместима со старыми 16-битными приложениями и драйверами. Поскольку под Windows 95 идет Visual C++, отладка не вызывает никаких проблем. Наконец, Wm95 можно использовать как платформу для разработки, при этом лишь требуется Visual C++ версии 2.1 и выше. Win32s, несмотря на его многочисленные недостатки, позволяет Wln32-пpилoжeниям работать под Windows 3.1.

Компилятор

Компилятор, отладчик и объектная библиотека обычно поставляются в комплекте. С нашей точки зрения, критериями при выборе компилятора являются: совместимость с существующим кодом, надежность фирмы-поставщика и перспективы развития продукта, наличие и качество объектной библиотеки, простота освоения и использования, качество генерируемого кода, средств тестирования и отладки, а также полнота поддержки возможностей C++.

В качестве кандидатов нами рассматривались Borland C++ 4.0, Visual C++ 1.0 for NT и Watcom 9.0.

Мы использовали Borland C++, начиная с его первой версии, и никогда не были довольны качеством генерируемого кода; кроме того, имелись серьезные ошибки в стандартной библиотеке и в OWL.

Новые возможности C++ фирма Borland обычно поддерживала быстрее конкурентов, но, увы, делала это не всегда качественно. Наконец, у Borland традиционно, от версии к версии, не работал профайлер. Одним словом, если говорить о первом пункте требований к компилятору, то фирма Borland рассматривалась нами в одном ряду с другими компаниями, а по второму – ее продукт значительно уступал аналогам от иных производителей Watcom 9.0 не имел ИСР и объектной библиотеки Кроме того, он очень медленно компилировал. По остальным же критериям – это отменный продукт, который мы подумывали применить для целевой компиляции. Watcom 9.0 генерировал отличный код (лучший!) и обладал простым и удобным отладчиком.

Microsoft Visual C++ 1.0 генерировал несколько худший код, чем Watcom (не разворачивал циклы), но имел хорошую интегрированную среду и поставлялся вместе с MFC 2.O. Библиотека MFC оказалась превосходным изделием и серьезно повлияла на наш выбор в пользу Visual C++. Существенным недостатком Visual C++ было отсутствие поддержки шаблонов и исключений в самом компиляторе. Однако мы, решив, что это временные неудобства, пришли к следующему мнению, преимущества Visual C++ перевешивают все перечисленные недостатки. Так выбор пал на Visual C++ 1.0.

Теперь, спустя два года можно с уверенностью заявить, что мы не ошиблись. За это время вышла прекрасная версия Visual C++ 2.0 с MFC 3.0.

Последняя версия (2.2) поддерживает все визуальные средства Windows 95 Что касается библиотеки классов MFC 3.0, то ее нельзя описать в двух словах, поэтому остановимся на ее более подробном рассмотрении.

MFC 3.0

MFC (Microsoft Foundation Classes, или, если дословно, "базовые классы Microsoft") иногда называют библиотекой классов, хотя это не совсем так. Больше подходит другое определение – Application Framework ("каркас приложения"). MFC не сводится к набору простых и базовых классов, из которых, как из блоков, можно строить приложение. MFC обеспечивает каркас приложения, в который вставляются окна ("представления") и "документы" нужных типов "Документами" в MFC называются объекты, содержимое которых пользователь может просматривать в окнах и редактировать MFC 3.1 поддерживает новые стандартные классы окон в Windows 95.

Понятно, что любую из этих возможностей несложно реализовать самим. Но разработка и осуществление всего того, что делает MFC, требует большого времени и денег и, с коммерческой точки зрения, является довольно бесперспективным занятием. По сравнению с OWL фирмы Borland библиотека MFC имеет три важных преимущества: она проще, ближе по концепции к Windows API и содержит меньше ошибок. Ныне MFC стала стандартом и даже входит в конкурирующие продукты – Watcom C++ 10.0 и Symantec C++ 7.0.

Средства тестирования и отладки

Средства тестирования и отладки служат для обнаружения и локализации ошибок. Их можно разделить на три категории:

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

 – Применение встроенных средств диагностики MFC значительно ускоряет тестирование и отладку программы. Поиск причины сбоя и его устранение занимают обычно не более 15-30 минут.

 – Отладчик Visual C++ встроен в интегрированную среду, имеет удобный графический интерфейс, широкий набор возможностей и, в отличие от большинства других отладчиков, довольно надежно работает.

Отладчиком интегрированной среды можно пользоваться в Windows 95 и Windows NT Для отладки под Win32s применяется специальное удаленное средство, работающее вместе с отлаживаемой программой на удаленном компьютере и взаимодействующее с интегрированной средой через СОМ-порт. Впрочем, удаленный отладчик работает ненадежно, и зачастую в Win32s лучше использовать контрольную печать. Для автоматизации тестирования применяются средства, позволяющие выполнять заранее приготовленные тесты и сравнивать полученные результаты с эталонным. Как правило тесты описываются на макроязыке В качестве подобного средства мы используем Microsoft Test 3.0. MS Test дает возможность записывать (или описывать) на Бейсике сценарии работы с программой, заставляет программу выполнять эти сценарии и имеет средства контроля выполнения сценария. MS Test незаменим при тестировании длительно работающих продуктов: он может неделю без перерывов работать с программой, пока та не исчерпает системные ресурсы Windows 3.1 или пока файл подкачки в Windows 95 не израсходует свободное место на диске.

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

Система поддержки версий

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

Техническая поддержка

Все описанные средства разработки поставляются фирмой Microsoft, технической поддержкой которой мы и пользуемся. Очень полезны диски MSDN, на которых распространяются бета-версии новых продуктов, операционные системы с лицензией для тестирования, техническая документация, списки ошибок в продуктах Microsoft, полезные утилиты, примеры программ и бесплатные исходные тексты. Служба технической поддержки Microsoft, как в России, так и в Америке, своевременно отвечала на наши вопросы и предоставляла всю необходимую информацию. Особенно нам помог список известных ошибок и ограничений Win32s. Более того, когда мы обнаружили фатальный сбой при работе с русскими ресурсами, Microsoft сразу же опубликовала нашу информацию и довольно быстро выслала нам исправленную версию Win32s.

Заключение

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